あなたの会社も要注意！「善意の行動」が仕組みを破壊するメカニズム

　「河合さん、河合さんがつくったKPI（重要業績評価指標）をさらに拡大解釈し、新KPIを加え、どんどん進化させていますよ」

　再建に成功した企業のキーパーソンから最近いただいたメールである。その企業には正しいKPIがなく、また社員はKPIがないと動けないという妙な癖をもった会社で万年赤字だった。つまり、経営企画部がつくった「ぶらさがりニンジン」に向かって各組織が動けば売上もあがり、利益率も上がるはずだが、その指針が壊れているというわけだ。

　 この企業は、非常にタフなプロジェクトを経て黒字化した。だが、その後、私が作ったKPIを複数の社員が勝手に弄り、複雑怪奇なスプレッドシートがあちこちで作られてしまった。私はExcelでモデルをつくって、在庫レベル、発注点管理、売上の予実が連動するモデルをつくり黒字化を果たしたのだが、社員が「これは便利だ」とばかりに浅い見識でKPIを弄り倒し、その人にしか分からない複雑なものに改悪され、動かなくなってしまったのである。

　私のつくったver1.0のおかげで全体最適ができ、みなの業務フローが揃ったばかりだった。私の予想通り、この企業はキャッシュショートに陥り、もはや死の谷へ転げ落ちるか、ハゲタカに身をささげるかの二択しかない状況に陥っている。

シンプルであることの難しさ

　私は、自分のコンサルティング経験からいって、指示、報告、チャート作成、システム設計などは、すべて無駄をこれ以上そぎ落とせないというぐらいにそぎ落とした姿こそ、完成形だと考えている。冒頭の例は、論理的に在庫量を計算するマクロを組んだロボティクスといってよいファイナンスモデルだ。

　これは事業会社側の無理解によってだけ起こるものではない。実際、コンサル側でも同様のことが起こったことがある。

　そのコンサルは、上司にあれこれ指示されるのを嫌がって、単独でクライアントの元に向かい、話し合いながらモデルを作ったのである。しかし、よく考えてもらいたい。クライアント側は、「最適なモデルを作れなかった」から在庫過多に陥り、破綻寸前までいったのだ。その人達の言うとおりにモデルをつくってもうまくいくはずがない。

　できあがったものは、私が予感したとおり、何を計測するのか分からないようなチャートやグラフのオンパレードだった。肝心な余剰在庫の計算や、私が提唱する「4KPI」はことごとく破壊され（彼らは、「進化・深化させたものだ」と主張していたが）、誰も使えないガラクタのモデルができあがっただけだった。

　私は、「分からないことがあれば、まず私に聞くように」指示をしたのだが、彼は指示を仰ぐことをせず、クライアントから聞いたのだから間違っているわけではないとうそぶき、ガラクタExcelを完成させた。当然それは、誰にも使われることなく、ゴミ箱に直行となった。

 

河合拓氏の新刊、大好評発売中！
「知らなきゃいけないアパレルの話 ユニクロ、ZARA、シーイン新３極時代がくる！」

話題騒然のシーインの強さの秘密を解き明かす！！なぜ多くのアパレルは青色吐息でユニクロだけが盤石の世界一であり続けるのか！？誰も書かなかった不都合な真実と逆転戦略を明かす、新時代の羅針盤！

システム開発の落とし穴は標準化

　私が開発したモデルは、Excelをつかった簡単なRPA （ロボティクス）による余剰在庫撲滅のためのロジックを組み込んだ6MBもあるシステムである。

　彼が、私をスルーし、クライアントと勝手にどんどん進めるものだから、止めようにも止まらない。彼はクライアントを抱え込み、自分のやりたいように夜遅くまで働いたかと思ったら、朝は遅刻をしだした。彼の説明は何がいいたいのかわからないデジタル用語のオンパレードで、クライアント側は「横文字も知らないのか」と思われるのを嫌ってか、質問はゼロだった。

　このままでは組織もプロジェクトもめちゃくちゃになると危機感を感じた私は、とうとう彼をチームから外したのであった。

　このように、魔物はクライアント側にも、そして、コンサル側にも住んでいる。すべて、自分の力の過信と無責任（自分にはカットオーバーの責任はないので、思いつきレベルの助言のつもりでいる）が原因だ。

　これは特に「標準化」に対して、重要性を理解していないことが原因である。 

　私は16年アメリカ企業に勤めていたので、「標準化」についての重要性を熟知している。日本人が考えているより遙かに厳しいコード（やりかた・様式）があるのが外資である。特にものつくりの「標準化」は、現在と過去、現在と未来、一個と複数、一個と別の一個など、ありとあらゆるパーツがそのまま一定の法則で作られているため、人が急にいなくなっても代わりの人が代替できる。

　　「そんなこと、当たり前じゃないか」という声が聞こえそうだが、きれいに標準化ができていて、チームプレイが当たり前の組織というものを見たことがない。みな、唯我独尊。自分達のやり方が数千、いや、時に数万分の一の特別な手法でやっているため、バリューチェーンがメチャクチャになるのだ。

 　 「システム」というものは、すべてのプロセスが繋がっており、あるプロセスが実行される場合、その前のプロセスがトリガーとなる。このように、ドミノ倒しのように、最初の一打がドミノをどんどん倒し、大がかりなシステムを動かすのだ。これに対し、現実の業務というのは、「調達部」「企画部」「販売部」などで、自社の業務範囲がきまっており、主に部門をまたいだ業務のやり取りは印鑑のついた書類でなされる。

　その感覚で、「ああ、ここはおれの業務範囲だから」とやりたいようにやってしまえば、そのプロセスがトリガーとなって実行される大規模なシステム全体の動きに不具合が生じてくるわけだ。Excelでつくった業務支援システムや、AccessでつくったイントラネットベースのRDB（リレーショナルデータベース）もすべて止まってしまうのである。これは、「無自覚の無責任」といって、自分の狭い見識の中でシステムを自由に動かせると考え、自分には責任がないから、そのために起きるシステムの不具合には一切責任をとらないということがおきてくるのだ。

　くどいようだが、システムのプロセスはすべて繋がっており、たとえば調達部のプロセスは余剰在庫の簿価評価に連動するため、何か1つの項目を変えるとまったく別のところで不具合がでてくる。その結果、何が原因となってこのようなことになっているのかが分からなくなってしまうのだ。 

　この問題がややこしいのは、「無責任のアドバイス、あるいは、命令」をした人間とて、もともとはシステムをめちゃくちゃにしようと思ってやっているわけでなく、「よりよくやりたい」という思いからやっているということだ。したがって、みなが「良い人」だし「うまくシステム化が進むことを願っている人」であるということなのだ。

 　この問題、このように文字にすれば極めて簡単であるが、やり取りの中で一度ボタンを掛け違えてしまった。そこから喧嘩になり、どうでも良いようなところで開発がスタックしてしまうなど、人が多く集まればそれだけ複雑性が増し、人が多く集まれば、それだけ考え方もいろいろでてくる。このように、善意の行動がシステムの仕組みを壊してしまうメカニズムはよく理解しておきたい。