1. 経営企画のたばこ部屋
  2. #40 人を責めずに仕組みを責め..
2025-05-04 10:16

#40 人を責めずに仕組みを責めるの具体例

◆番組概要

経営企画の「きりん」が経営企画としての悲哀や悦びを語ります。たばこ部屋だからこそ聞ける、なんとなく盗み聞き程度でちょうど良い、でも聞き流すにはもったいない、そんな番組を目指します。

◆Personality:

きりん

外資系コンサルティングファームやBIG4系FASにて、新規事業立案プロジェクトに多数従事し、事業計画策定やビジネスケース作成、企業価値算定等に携わる。

ベンチャー・事業会社では経営企画/経営管理として予算策定、予実管理、着地見込や予予管理を中心に企業価値向上を担う。

◆Twitter:

⁠⁠⁠⁠⁠⁠⁠https://x.com/kirin_fpa⁠⁠⁠⁠⁠⁠⁠

◆Voicy:

https://voicy.jp/channel/2732

※Season1は、2022年頃にVoicy独占配信をしていましたが、Season2よりマルチプラットフォームでの配信を行っております。

※BGM:MusMus

サマリー

このエピソードでは、人を責めるのではなく、仕組みの問題を指摘することが重要であると論じています。営業事務のミスや経理の未払い請求書といった具体例を通じて、業務プロセスの重要性と改善の必要性が強調されています。

営業事務のミス
おつかれさまです。経営企画のたばこ部屋、40回目の配信です。今日もキリンガーをお届けします。
問題が発生したときに、人を責めるのではなくて、仕組みを責めようという、そんな話をしようと思っていますけれども、割とよく言われる話ですよね。
これについては、よく事例がちゃんとないと、そうだよねという話になるかと思っていますので、今日はその具体的な事例を交えながらお話をしてみようと思います。
一つ目として、営業事務のミスを取り上げてみようと思いまして、これは例えば、発注受け書を他の会社に送ってしまったという、そんな事例です。
発注受け書というのは、ある会社に対して、あなた方にこの商品を下ろしますと、具体的に仕切り価格はこれぐらいで、割引販売価格はこれぐらいですよみたいな、値段とかも思いっきり書いているわけですね。
そういうものを間違えた会社に送ってしまうということは、つまり他社とはこれぐらいの割引率とかでやり取りをしていますよということがバレてしまうという話なんですね。
お客さんごとに割引率を変えることは割と一般的ですので、そういう秘密が他社に漏れてしまうということは非常に取引先との関係の構築の上で厄介なわけですね。
なんでうちよりも安い価格で下ろしているんだとか、そういう話になってしまうので、営業としては非常に困るわけですよ。
事実、その事例でもですね、営業の方はとても怒られていまして、怒っていて、営業事務の方を非常に責めていたんですね。
その責め方についてもですね、割と人格否定的な責め方をしていて、〇〇さんはしょっちゅうミスをするのでもうやめさせた方がいいとか、あの人は業務に適性がないよねとか、そもそもやる気がないよねとか、
そんな話ばっかりしているんですよね、延々と。他の人も言うんですけれども、じゃあ目標設定に組み込んだ方がいいんじゃないかと。
ミスをした数と言いますか、ミスをしなかったということをちゃんと評価しないといけないんじゃないか。
そういう仕組みがないからミスをしても改善しようという気にならないんじゃないかというふうにおっしゃるわけですね。
一理あるかもしれませんけれどもですね、そういう後ろ向きな話とか個人の資質とかやる気根性みたいなところに問題を起きするのではなくて、こういうふうに問題を捉えるべきだという話をしているわけですけれども、
そもそも人はミスをする前提で業務プロセスを組まなければなりませんよねと。
考えてみてくださいと。そもそもシステムで管理していてガチガチに答制を聞かせていれば、何々さんがいかに仮に無能だったとしても絶対に送り間違えることはシステム上不可能なわけで、
それを入れていないということがそもそもの原因だというか捉えたほうがいいんじゃないでしょうかと。
実際システムを入れるっていうことはお金もかかりますし、手間もかかるから現実的ではないかもしれませんけれども、
それに類する業務プロセスというものを社内で人力でですね、組み上げることは不可能ではないというふうにも思いませんかねと。
システムを入れないのであれば最低限その方が注意力が多少あれなのであれば、他の方がダブルチェックをしてやる。
メールを送る前に必ず誰かのチェックを入れて承認を得るというようなプロセスを置いておくとか、ちょっと時間はかかるかもしれませんけれども安全にはなりますよね。
他にもファイル名の命名ルールとして今は何か分かりづらいものが文字列として入っているのであればそうじゃなくて、
何々様あてみたいな感じの音柱かな、その会社の名前を入れておいて、一社一フォルダでしっかりと分けて管理をしておくとか、
ちょっとその場合にもですね、一つのフォルダの中に複数の会社の注文の受け書がですね、いっぱい並んでいたからそれを取り違えてしまったらしいんですけれども、
フォルダの分け方とかフォルダの命名規則とかそういったものをそもそも見直すことができればあまりミスそのものが発生しなくなるんじゃないかなと、
人間の注意力が同じだったとしてもミスが起きにくい構造を作ることはできるんじゃないかという、そんな話をしたかなと思います。
未払い請求書の問題
実際それでですね、改善されるかどうかというのはまた今後の経過を見てみないといけないんですけれども、論理的には減るはずみたいな感じにはなっていると。
他にももう一つ事例を挙げてみようと思います。
支払い請求書を未払いだったという、そんな事例があります。
経理の方で毎月請求書を取りまとめているんですけれども、その請求書について払ってないですよという通知が取引先から来たことがあるんですね。
その経理担当が責められてしまったという、そんな事例でございます。
経理の人はそもそもその請求書に気づいてなかったんですね。
というのもですね、各所から経理のメールアドレス宛てにバラバラといろんな方がいろんな手段で請求書を転送してくることがあったということが原因でした。
メールに限らずスラックとかでもそうですね、スラックでも送られていたと思います。
スラックなんか特に一回見落としてしまうともう何が既読で未読なのかみたいなことがですね、もう見分けつかなくなるので、一度それを見落とすともう埋もれてしまう構造にあるじゃないですか。
だからメールに比べるとより危ないんですけれど、そういう構造でありましたということを分析する前にですね、やっぱりその経理の人を責めるわけですよね、皆さん。
確かにその方はミスが多いというのはこれまでの歴史の中でもあったとは思うんですけれども、それを個人の処理能力の問題にしてしまうというのは非常に問題だったかなと思います。
あの人はそもそもやる気がないとか、ボキ3級も持っていないんだからとか、今回の話とは関係ないですよね、その資格を持っている持っていないというのは注意力とかそういう話かもしれませんけれども、
全然関係ないところに問題を起してその人を責めたがるっていうのは何か人間の心理なんですかね、もう本当に無駄なことをしているなと思うんですけれど、やっぱり今回もこの問題意識として正しいのは、
メールはそもそも見落とすものであるし、スラックもそもそも見落とすものであるという、そういう前提で業務プロセスを組まないといけない。
そう組まれていなかったことが問題であり、見落としてしまうのはその結果であるというふうに考えるべきだと。
もう一つ、請求書を十分これが全て届いているというふうに確認するプロセスが組める構造になかったのも問題だというふうに考えました。
今じゃあ請求書が11枚手元にあるとして、本当は13枚届くべきなのに、あと2枚来ていないということに気づくことができないっていう、そもそも照らし合わせる先の表みたいなものがないから、
届いている今手元にあるものが全てだと信じて処理をしていたみたいな非常に怖いことになってたわけですよ。
こういうことになっていると、それは気づきようがないというか、チェックもしようがない。
ダブルチェックも誰か他にかませたところで、私もわからないみたいな話になるので、これはそもそものプロセスに改善が必要だなというふうに気づくことができました。
ひるがえると、これはつまり表がないということは、その請求書について払っていいんだっけっていうふうなところの確認すらできていないということだと思います。
だから架空の請求が届いていても、なんかこれ払わなきゃいけないやつだなというふうに信じて払ってしまうという構造になっていたという、これはこれで恐ろしいですよね。
こういうことも併せて問題意識として見つけることができるわけです。
なので、個人に責任を期していたら見つからない問題っていうのも併せて見つかりますよというのがここで言いたいことなんですけれども、
結局、システムを導入しまして、その事例では発注先とかから請求書が自動でこのシステム上に上がってくるような仕組みというものを作りました。
具体的には、請求書をこのメールアドレスにあてに送ってくださいねというふうに取引先に協力を仰いで、
ここに送ってもらえれば自動的にシステム上に上がって列挙されていくというものですね。
その請求書については各位に確認が行って、これを払っていいですよというふうな承認を得てから支払うというプロセスになったわけですけれども、
こういう形で発注申請の厳格化とか付き合わせプロセスとか支払い承認プロセスとか、
そういったものまで併せて作ることができたのはこの災い転じて良くなったという事例ですね。
仕組みの重要性
まとめなんですけれども、今2つの事例をお話しさせていただきました。
営業事務の発注受け書の取り違いと他者に送ってしまったというのと、
2つ目の事例としては支払い請求書未払いだったという話。
両方とも人の問題とか人の注意力、資質の問題に期してその人を責めていたというところから、
問題は仕組みであるというふうに捉え直して、その周辺の問題も見つけて何とか改善したという事例なんですけれども、
要は誰かが全て悪い、誰かの資質の問題ではなく、どちらかの部署の問題ではなく、
それぞれのプロセス、それらを司っているプロセスの問題であるというふうにまず考えてみると、
どういうものが見えるかというのをやってみる、これが大事だと思います。
人を責めていい場合があるとしたら、誠実さを欠いた場合なんじゃないですかね。
恋にお金を盗むとか、何かわざわざサボるとかですね。
そういう事をすると、プロセスがあったとしてそのプロセスを吹っ飛ばされると意味がないので、
そういう時はもちろん人を責めていいのかもしれません。
キックバックとか応料とかが起こる場合であっても、それでも人を責めるよりも、
それができてしまうプロセスを責めた方が本当は生産的だとは思いますけれども、
そういう感じでできる限り、人間というものではなくて仕組みを責めようという話を今日はさせていただきました。
以上とさせていただきます。
良ければチャンネル登録であったり、フォロー、いいねといただけると励みになりますのでよろしくお願いいたします。
お疲れ様でした。
10:16

コメント

スクロール