マッキンゼーITの本質

ここしばらく開発現場を離れ、「こんさるたんと」のお手伝いをしている。そこでマッキンゼーの中の人と仕事をしているのだが、奴らはスゴいの一言に尽きる。激務という言葉はまさに奴らのためにある。

たしかに、私も佳境に入ると夜討ち朝駆け徹夜仕事になる。システム屋は盆と正月こそ稼ぎ時だ（悲しいけどこれ現実）。しかし、奴らの場合はそれがデフォルトで、言葉どおり休みがない。「オレも休みなんてずいぶんもらっていないよ」と言いたい人は沢山いるだろうが、もう何年も一日たりとて休んだことないよという人はいないだろ。でも奴らはそれが普通。24時間戦えますか?（死語） もちろん、という連中。

だから奴らは、通勤時間を惜しんで六本木や新宿にマンションを買っている（←激務に見合うだけ給料もハンパじゃないといっておく）。まぁマッキンゼーですら一つのステップで、激務の見返りにノウハウやパイプを吸えるだけ取って独立するつもりで身を粉にしているわけだし。

じゃぁその論文「マッキンゼーITの本質」もスゴいのかというと、そうでもない。とっぴなことは一切書いていない。膨大なデータを元に「仮説→検証→仮説→検証」の議論を反復した結果がこの本。サブタイトルの情報システムを活かした「業務改革」で利益を創出するうたい文句に偽りはないが、実行するには経営者の鉄の意思を要する。まさにマッキンゼーのやり方。

ITへの投資とリターンについて悩むエライ人が読むと、ああやっぱりな～と身につまされること請け合い。社畜が読んでもタメになるのは第1章。ITによる課題解決が何故うまくいかないのかと、その処方箋がまとめてある。自分のプログラムは完璧なのに、業務システムのレベルになるとどうして上手く実装されないかがよく分かる。

■IT課題解決を阻む5つの理由

1.ITの企画・推進に関するアカウンタビリティがない

CIOが具体的に何をする人で、何に対する責任を有するのかを明確化しないまま、CIOに命ぜられている。ぼんやりと「社内のITシステム全般について責任を有する役員」というあいまいなミッション定義のまま、IT便利屋の窓口になっている。

IT投資の企画における目標設定は誰が行うのか?　要件定義やプロジェクト管理はどの部門がどのように行うのか?　業務改革を含めた新システムの現場への定着はどの部門がどのような責任と権限で推進するのか? こうしたアカウンタビリティが存在しない。

2.目標がQCD（quality/cost/delivery）の面から定められていない

ITで業務を変えようとする際、最終的にどう変えたいのかが明確になっていないまま「システム改善」が着手されている。顧客満足度などの業務アウトプットの品質（quality）なのか、労働総量・残業代や不良在庫削減などのコストカット（cost）なのか、業務処理の時間短縮や顧客リクエストの迅速対応（delivery）なのかぼやけている。

いつまでに何を達成しなければならないのかが曖昧なままだと、それを「どう」達成するのか（=システムに何を求めるのか）は絶対に明らかにならない。

3.外来語をわからないまま受け入れる

オープン化、ERP、CRM、EA、SOAなど、何かいいことがありそうだが具体的に突き詰めてみるとよく分からないまま意思決定をしてしまう。その結果、ふたをあけてみれば「そんなつもりじゃなかった」という台詞が双方から聞かされることになる。

ITベンダーが提案するソリューションは、経営・業務の観点からするとただのツールでしかない。何のためにどのような道具が最も有効か、議論をつくす必要がある。

4.ベンダーとの協働がうまくできない

法律なら法律事務所、会計なら会計士事務所があるが、ITには背景に法・規制を伴ったルールが存在しない。さらにITエキスパートは開発業務を請け負うベンダーであることが多い。その結果、エキスパートといいながら仕事を請け負う立場としての遠慮から、顧客企業の指示や要望に従う下請けになりがち。

5.システムの完成が目的化し、成果や構築プロセスがなおざり

システム開発にまい進しているうちに、予定通りのカットオーバーが目的となってしまい、完成したシステムが実際に役立っているかを確認・検証する機会が忘れ去られている。ユーザ企業のIT投資・推進におけるPDCAサイクルが絶たれている。

■6つの処方箋

1.ITコストの可視化

自社がどれぐらいの資産を有し、どこにいくらのコストがかかっているかを可視化する。いわばITバランスシートを作成することで、どこに優先順位がつけるべきについて、現場担当レベルではなく、経営者が判断できるようになる。ITバランスシートは開発費、運用費だけでなく、ライセンスコストや稼働率も考慮して作る。

2.CIOをコアにした議論の場

システム単体を取り上げて事業への貢献を議論することは無意味。システムも含めた業務改善が事業にどれだけ貢献したかについて考えるべき。

3.PMOによるチェック

狭量になりがちな情報システム担当ではなく、PMOに第三者的なチェック視座を設けることで、システムの企画段階からIT投資・運用の効率性を経営者がチェックすることができる。

4.ユーザ部門のノウハウ集積

ファーストリテイリング（ユニクロ）の例。情報システム部ではなく、業務システム部を設け、主業務のプロセス担当者を置き、その担当者が業務改善を企画し、一環としてITの企画・導入・運用を行っている。

5.事業の本質に根ざしたIT戦略

全体最適されたIT投資を行うため、その目的・コンセプトを明確化する。次に、事業の生産性・収益性を向上する最大のレバー（梃子）は何か、その向上のために業務を、組織を、どう変えるべきかについて検証する。

6.ベンダーとのwin-win

仕様確定などベンダーとの共同作業を重視する。そこまで議論してきた業務フローなどの本質を理解できないままなら、いくら要件定義を緻密におこなっても似て非なる代物になるだけ。すべてをさらけだすつもりでベンダーを取り込むことで、システム改善の「肝」を腑に落ちてもらう。

なんてあたりまえな…という印象をもたれたかと思う。アタリマエなことがあたりまえにできていないことが問題なのだが、翻って私はどうかと。経営者の視点ではなくとも、分析の基本であるMECEやロジックツリーをやっているか? 否とよ。そこいらのHowTo本で分かった気になって、ちょっと使って上手くいかないとすぐに「MECEは現場離れしていて使えない」と断定。恥ずかしい限りだ。

一方、マッキンゼーの中の人は本当に使う。定石どおりに使うというよりもむしろ徹底的に使う。徹底的に使うとは、人が1時間考えるなら10時間考えてきている。だからプレゼン中に思いついただけの反論にもびくともしない。反論への反駁も準備万端（つまり客を不快にさせないように反駁するところまで考え抜いている）。

最後にネタばらし。マッキンゼーの中の人とはいっても、コンサルタントやプリンシパルだけがスゴいのではない。奴らの後ろにデータ解析屋がいて、パワーポイントの猛者がいる。彼らがスゴいのだ。莫大なデータをひたすらピボットテーブルしまくって傾向→対策を洗う解析屋。出てきたアウトプットを見栄えのいいストーリーに仕立て上げるパワーポイントマスター。彼らのおかげでコンサルタントはひたすらコンサルタントができる。マッキンゼーのプレゼン術なるHowTo本が書店にあるが、奴らのパワーポイントファイルを読んでみるだけでいい。そのスゴさ（あたりまえのことを徹底的に積み重ねること）が良く分かる。