【「スゴ本」中の人が薦める】「諸悪の根源」コンサルタントから学ぶ。ITエンジニアが現場で活かせる思考法を習得する4冊＋α

コンサルティングファームの人と働くとすぐに気づくのだが、やつらはめちゃくちゃ頭がいい。この「頭がいい」とは、引き出しがたくさんあり、こみいった物事の理解が早く、口先が達者で、文章が上手い。悪用さえしなければ、ITエンジニアが学ぶところが大いにある。

 

• keyboard_arrow_down はじめに
• keyboard_arrow_down コンサルは「諸悪の根源」だ
• keyboard_arrow_down コンサルの報告書から学ぶ
• keyboard_arrow_down コンサルの「解答」を先に見る
• keyboard_arrow_down コンサルは、どのように頭を使っているか
• keyboard_arrow_down コンサルは、どのように手を動かしているのか
• keyboard_arrow_down コンサルの武器を自分のものにする

あなたがITエンジニアをやっている限り、そのキャリアの中で1回は思ったことはあるだろう。

プロジェクトが失敗する原因は、コンサルタントのせいだ。
プロジェクトが失敗する原因は、コンサルタントのせいだ。

コンサルタント―――企業の全社戦略や、事業統合のサポート、新規参入戦略など、企業経営のトップレベルに関わる問題解決を謳う連中だ。全員が全員クズだとは言わないが、中には極悪非道なやつもいる。

顧客を財布、しかも巨大な財布だと見なし、知ったかぶりの業界通を気取り、難解な経営用語で煙に巻き、「お客さまと一体となって」嘘八千を並べ、プロジェクトが焦げ付く前にトンズラする、そういう連中である。

やつらが掲げる「最先端の経営理論」なんてものは、たまたま成功した特殊な事例の拡大解釈であり、一般化することはできないのに、法外なコンサルティング料を請求してくる。

それにも関わらず、経営者は喜んで財布を開く。

従業員の給料を必死こいて削減する一方、コンサルタントに莫大な金をつぎ込む。一般企業のみならず、官公庁、行政機関もしかり。ひどいことに、失敗と分かっているにもかかわらず、金を注ぎ続ける首脳陣がいる。コピー機の設定を「2 in 1」の集約コピーに固定するくらいケチなのに、コンサル連中に金を払う。バカとしか言い様がない。

ただ悔しいことに、やつらの頭は恐ろしいほど切れる。それに加えて、強力な武器を持っている。コンサルタントを名乗るなら必ず身につけている思考法だ。これほど万能な武器で攻略されたら、経営者が陥落するのも仕方ないな、と思えるくらいである。

ここでは、そんなコンサルタントのやり口と、やつらが持っている強力な武器を紹介する。この武器は、ITエンジニアにとっても強力に役立つことを請け合う。

コンサルがどんな売り文句で経営者に近づき、どんなやり口で仕事をしているかについては、『コンサルタントの危ない流儀』に詳しい。

『コンサルタントの危ない流儀』デイヴィド・クレイグ著, 松田和也訳、日経BP

例えば、「解体屋」と呼ばれる手法。結論を先に言うと、最もコストがかかる部分、即ち人件費を削れというビジネスモデルだ。その結論をもっともらしくするために、現状分析（As-Is）を徹底的に行う。

1. 1. 各部署に行き、行われている業務と完了にかかる時間を測定する（As-Is：現状）
2. 2. 上記のうち、非効率とする時間（損失時間）を見積もる
3. 3. 各業務の回数と、損失時間を除去した時間を掛け合わせて、必要な人時を計算する（To-Be：あるべき）
4. 4. 「現状」と「あるべき」を比較して、スタッフの何パーセントを解雇すべきかを勧告する報告書を作成する
5. 5. 報告書とともに、新たな管理手法を導入するプロジェクトを提示する

ちょっと待って！「2.非効率とする時間」は誰が見積もるの？もちろんコンサルタントである。でも「非効率」なんてどういう根拠で言えるの？大丈夫、ステップ4で「〇％解雇すべき」が30％程度になるように逆算して見積もるから（理屈は後付けでどうとでもなる）。

そう、スタッフ削減ありきの提案なのである。

「解体屋」が売りつける管理手法はSIS（Short Interval Schedule） と呼ばれている。簡単に言うと、現場監督が2時間ごとに生産高と目標値を照らし合わせ、達成できないものは訓練するかクビにする方法だ。

キーマンの見つけ方から、キーマンに刺さる殺し文句とNGワード、スタッフに問題点を書かせるブラウンペーパー、問題点を炙り出す技法（DILO : Day in the Life Of）など、コンサルタント悪の手引き書ともいうべき怪著である。

ブラウンペーパーとは、現状分析の手法だ。現状の業務プロセスのフローを大型の模造紙（ブラウンペーパー）に描きだし、全関係者を集め、気づいた点をふせんで貼り付けるやつだ。現状の問題点や改善点を洗い出すときに使われている。経営層のフロアの廊下や、社内カフェテリアの壁に張り出されたものを見かけた人もいるかもしれない。

こうした手口を見ていると、「御社は時代遅れ、まさに瀕死の恐竜です」「この戦略パッケージなしには、業界で生き残れません」といった言葉にコロっと騙されてしまう経営者もいるだろうな……という気になってくる。

とばっちりを喰らうのは下っ端である。

そして、コンサルが犯してきた罪を暴露しているのがこれ、『申し訳ない、御社をつぶしたのは私です。』である。

『申し訳ない、御社をつぶしたのは私です。』カレン・フェラン著, 神崎 朗子訳、大和書房

「戦略計画」「最適化プロセス」「業績管理システム」―――これらの看板の実体と、糊塗されている大嘘をひっぺがす。経営コンサル業界で30年働いて、いい加減この「お芝居」にウンザリして、懺悔の名を借りた暴露本になる。その具体例が生々しくておぞましい、そしてあるあるなのである。

たとえば、何も考えない経営目標をカスケードした悲劇。今期の収益がナンボといった目標をぶち上げて、何も考えずに部→課→担当者へと落とし込んでいく（カスケードという）。各部署の状況や、業界の景気なんて考慮せず、機械的に割り振って、後はその数値でもって管理する。

数字による目標管理だから、達成／未達成が容易に判別できる。さらに、達成度に応じて報酬や罰則を設定すれば、社員はなりふり構わず目標にまい進するはず―――コンサルタントはそうささやき、クライアントのみならず、社会全体をそう信じ込ませてきた。

非現実的な目標を押し付けられると人はどうするか。結果は、火を見るよりも明らかだ。文字通り、なりふり構わず、その数値だけをクリアしようとする。

ある地域営業の担当マネージャーの例では、取引先に頼み込む。年度末の売り上げ目標を達成するために、本来よりも水増しして発注してもらうのだ。年度が変わったら差分を返品してもらう。償却コストや在庫保管料だけでも莫大なものになる。

とあるアメリカの都市の交通局の例もひどい。バスの運転手に対し、運行時間の遵守率という目標を押し付け、その数字に応じて報酬を支払うことを決定する。当然のことながら、運転手は運行時間を厳密に守ろうとする。渋滞や天候により遅れが出はじめると、たとえバス停で客が待っていても、運転手は停車せずに走り過ぎるようになったという。

こうした考え方の根本には、「ストレッチ目標を与えれば、現場はどうにか知恵を絞って達成するもの」というコンサルタントのアドバイスが背景にある。確かに現場は知恵を絞り、目標を達成したはした。だがそれは、貢献どころか損害を与えている。

やつらの言い分を聞いたばっかりに、とんでもない事態を招いた例が詰め込まれている。コンサルタントこそが、諸悪の根源なのである。

しかし、しかしである。ただ一点、この一点だけ、コンサルに非の打ち所がない点がある。

それは、やつらが出してくる報告書そのものだ。

やつらの報告書は、簡潔で、分かりやすくできている。可読性は非常に高く、何よりも「理解してもらおう」という配慮が隅々にまで行き届いている。ボリュームも100ページぐらいあるが、無駄が一切ないというのもすごい。

主張は明確で、一枚のスライドに、一文のみ。主張を支える根拠の粒度は揃っていて、根拠同士がロジカルに支え合っている。それぞれの根拠を確かなものにするために膨大な調査を行い、簡潔かつ正確なグラフに表され、エビデンスとなっている。

たった一文を「正しい」と説得させるために、どれだけ膨大な調査と綿密な論理思考を積み重ねてきたかと想像すると、恐れ入るしかない。そうした一文が、全ページに亘って隙なく存在している。

完璧な資料というのがあるのなら、それはコンサルが出してくるものだ。読めば分かるし、読むだけで納得させられる。一読で、コンサルと同じように問題が説明できるし、改善点を掲げられるようになる（忘れたらサマリを見るだけで思い出せる仕掛けになっている）。

ロジックは一分の隙も無いから、エビデンス、すなわち調査データに疑義を挟むくらいしかできない。ところが質・量ともに優れており、見せ方も上手いので、「これほどキレイにまとまっているデータが間違っているはずがない」と思わされてしまう。

経営層にとって、これは都合が良い。社内をとりまとめ、「うちはこれで改革していく」と明確に打ち出せるからである。

組織構造に手を入れたり、仕事の管轄やフローを変えようとすると、大なり小なり反発があることは否めない。改革の実効性を疑ったり、そもそも変更の必要性を否定するといった声があちこちで挙がるだろう。

そういう抵抗勢力を黙らせるための武器となるのが、コンサルの資料だ。

「経営層」とは言っても、偉そうにしていられるのは数年で、全社をまとめる力を持っていない場合が多い。自分が培ってきた経験をもって「正しい」なんて言い切る胆力も持っていない。

一般企業のみならず、省庁も然り。数年しかいない立場で、それだけ大きな影響を与える決定を、自分の知見だけでできるわけがないし、それで庁内を説得できるわけもない。

そんな経営層にとってコンサル資料は、カンダタにとっての蜘蛛の糸に等しい。「それ」しかないのだ。でもそのおかげで、抵抗勢力を押さえ、社内をとりまとめることができる（なんなら社内の説得役にコンサルを当ててもいいし、実際そうしている）。

さらに、コンサル資料の結論が「ふわっと」していることも重要だ。

抽象的に「ふわっと」書かれているからこそ、賛成しやすく、合意も取り付けやすくなる。もし各論にまで具体的に落とし込んでいたなら、抵抗勢力の方は、反対意見を先鋭化させていただろう。総論賛成・各論反対のファーストステップは、コンサルの資料が取っ掛かりとなるのだ。

コンサルのおかげで社内をまとめ、相当の予算と社内リソースを確保し、プロジェクトの実行を決定することができる。つまり、プロジェクトが開始できるのは、コンサルのおかげなのである。

プロジェクトの失敗はコンサルのせいなのだが、コンサルがいないとプロジェクトそのものが始まらない。悲しいけど、これが事実なのだ。

コンサルに調査を委託すると、ウン千万円のお金がかかる。

通常であれば資料が外部に流出することはありえない。また、どの企業にどんな調査報告をしているかについては、守秘義務により口外できない。従って、原則的にコンサルタントの資料を見ることはできない。

だが、原則があるなら例外もある。

それは、政府が作成した報告書だ。市場や技術の最新動向を把握し、今後の政策の方向性を検討するために、コンサルやシンクタンクに調査を依頼する。「委託調査報告書」と呼ばれ、公開されている。

経済産業省：委託調査報告書

デジタル庁：委託調査報告書

eスポーツの人材育成から、衛星データのオープン化まで、面白そうなネタが沢山ある。ITエンジニアなら、たとえばこの報告書が飯の種になるのではなかろうか。

『戦略的基盤技術高度化・連携支援事業（中小企業のAI活用促進に関する調査事業）』マッキンゼー＆カンパニー

日本の中小企業において、「AI導入・活用を促進していくにはどうするか？」をテーマに、多数の企業にヒアリングを行い、現状とあるべき姿を示した報告書だ。メッセージ性の高いリード文やこれみよがしな面積図など、いかにもマッキンゼーらしい資料である。

フィット＆ギャップを明示し、実現すべき施策ごと章立てを分けて必要性を説いている、まさにお手本のような資料である（その施策が現実として進められるかどうかは経産省次第だが、ここではあえて問わない）。

こうした「解答」を見てしまうと、コンサルには敵わないことがよく分かる。仮説思考を繰り返し、ロジックツリーを組んでは壊し、膨大なデータ分析を積み上げたうえで成り立っている。訓練していないと、何をどう見せれば良いのか、そのためにどんなデータを集めればよいのか分からず、途方に暮れるだろう。

腹立たしいが、コンサルに学ぶべきものは多い。やつらみたいになる必要はないが、やらが持っている武器はいただこう。

ただし、パワポ術やエクセル技のような表層的なものではない。

それっぽいグラフのデザインやチャートのレイアウトを並べてやった気にさせる本は大量にあるが、それらはお小遣いの無駄だ。見栄えは大切だが、「何を伝えるのか」の中身のほうが遥かに重要だ。

その筆頭となるのが、『問題解決プロフェッショナル』だ。

『新版 問題解決プロフェッショナル―思考と技術』齋藤 嘉則著、ダイヤモンド社

ビジネス上の「問題」に対し、コンサルタントがどのようにアプローチしているかが、手に取るように分かる。以下の「問題」も、未定義で、切り分けられておらず、いわゆる「ふわっとした」ものだ。

• ・「従業員の意識改革をして社風を変えたい」
• ・「ここ数年の売上げの落ち込みをなんとかしたい」
• ・「社内における人材不足と余剰人財のバランスをとりたい」

これらの「問題」は、全く中身がない。形だけ提示されているが、あまりに抽象的すぎる。これを出発点として、何をどう取り組めばよいのか、具体的に分からない。経営層の「何とかしなければ」という焦燥感をそのまま言葉にしただけの思いつきに過ぎない。

先ほど、「コンサルタントの結論はふわっとしている」と述べたが、実際のところ、コンサルタントが取り組む問題のほうが、もっとふわふわしている（ふわふわどころか、経営者の愚痴＆戯言に近い）。それを、社内で合意を取り、予算を確保できるぐらいまでに具体化するのが、コンサルの仕事と言っていい。

実際、「問題」を与えられて「解決策」を考えるなんて思いつきでだってできる。

でも、その「問題」って、本当に解くべき問題だろうか？そこから疑ってかかる。

与えられた問題を解くというより、その背景を分析し、なぜその問題が「問題」として認知されているかまで掘り下げ、真の原因にまでどうアプローチしたら届くかを、説得的に述べるのは、かなり難しい。

具体的には、問題自体を検証し、既成の枠を取っ払って考え、要所要所で仮説を立てては裏付けを取る。そこに漏れやダブりがないか確認しつつ、限られた時間の中で最も有効な手立てを選びんでゆく……これには、相当の訓練が必要だ。

本書では、そのツールが紹介されている。「ゼロベース思考」「仮説思考」「MECE」「ロジックツリー」など、見知った用語が並んでいる。

多くの人はこれらの言葉をどこかのまとめサイトを斜めに読んで、分かった気になっていた。私がまさにそうだった。だが、「知ってる」のと「できる」のは大きく違う。本書を読めば、「できる」にまで到達できる。

というのも、この本は実例でもってねじ伏せてくれるから。

• ・ある医薬品メーカーが抱える問題「営業1人あたりの主力商品Ａの売上生産性が下がっている」を解決する
• ・大手家庭用品メーカーの主力商品の売上減少の原因を特定する
• ・成熟した寡占状態の日本の洗剤市場へ新規参入するにはどうすば良いか
• ・「おいしいビールを提供する」ことを阻害している悪循環を解消する

実際に著者が現場で考え、実践してきた思考の「型」が紹介されている。調査を進めていく上でどのような壁が生じ、どうやって乗り越えていったか。そのときに採用した方法のどこが効いたのかなどが、生々しく書いてある。

例えば、「MECEで考えるだけでなく、最後に優先順位をつけているか？」と問うてくる。「MECE」は「Mutually Exclusive, Collectively Exhaustive」の頭文字で、「モレなくダブリなく」を意味することは知っていた。

だが、なぜモレやダブリを避けるべきなのかは、本書で教わった。

MECEに要素分解する理由は、分解された要素への打ち手や解決策を考えるためだ（古代ローマの分割統治を思い出そう）。分けたほうが容易に扱えるし、具体的に考えやすい。

もし、分解した要素にモレやダブリが生じていると、その解決策にモレやダブりが出てくる。それぞれの解決策には、予算や時間、人手といったリソースが配分される。その配分にモレが出るなら効果が薄まるだろうし、ダブリが生じるなら、リソースが無駄になる。だから、モレやダブリを避けるべしと言われるのだ。

さらに、すべての解決策を実行するだけのリソースは、当然のことながら、ない。リソースを握っている経営層から理解を得るためには、どこから優先して手を付けるべきかを説明しなければならない。MECEで考えるだけでなく、どの要素がクリティカルなのかを優先づける必要がある。

つまり、問題への解決策を効果的に実行するためにMECEがあり、個々の解決策をどの順番でどこまで実施するかを勘案するために、MECEへの優先順位付けが必要となる。

この武器は、ITエンジニアにとって、非常に有効だ。

自分に渡されたタスクが、いつでも明確になっているものとは限らない。ふわっとした、「現行業務を実装せよ」みたいな指示もある。そこには、「現行業務を（そこで起きている問題解決しつつ）実装せよ」というニュアンスが込められている場合もある。

そういうとき、どのように具体化するか、どうやって問題を再定義し、重要度を見極め、タスクに落とし込み、優先順位をつけるか。ここで紹介される原理原則は、そのまま役に立つ。

コンサルがどのように頭を使っているのか、本書で学ぼう。

コンサルの回答を導き出すために、どんな風に頭を使っているのか分かった。次はコンサルの手の動かし方を紹介する。

頭で分かっていても、実際に手を動かしてみると、思った通りにならない場合がある。書く前はすらすらと浮かんでいたことも、いざ書き始めると雲散胡散霧消し、具体的に何をどのように伝えたかったのか、出てこなくなることがある。

そういうとき、『考える技術・書く技術』が役に立つ。

『考える技術・書く技術―問題解決力を伸ばすピラミッド原則』バーバラ ミント著, 山崎 康司訳、ダイヤモンド社

マッキンゼーでライティング指南をする著者が、そのエッセンスを濃縮したのが本書になる。伝わる文章が書けないのは、論理構造にあるという。その論理構造の作り方を懇切丁寧に教えている。

「考える技術」と「書く技術」と並んでいるが、両者を貫いているものは、ピラミッド構造になる。頂点には結論が入り、下部にはその結論を支える主張や根拠が入る。こういうやつ。ネットにもよく転がっているので、見かけたこともあるかもしれない。

で、やってみると分かるけれど、手が止まる。

「結論」は最終的に伝えたいことだからすぐ書ける。主張1やその根拠も、言いたいこととその理由だから、まあ書ける。だが、手を動かしていくにつれ、箱が埋まらなくなったり、どの箱にするか迷いが出てくる。

結論を支える主張は、こんなにキレイに分かれない。主張1が主張2を包含していたり、階層性が出てきたりする。また根拠もこんなに整然としない。根拠同士が相互に依存したり、主張に含まれていたりする。そのうち、主張の箱なのか、根拠の箱なのか、分からなくなってくる。

コンサルタントも、同じように手が止まり、同じように頭が働かなくなるのだろうか？

そうさせないために、『考える技術・書く技術』では、「結論」に焦点を向ける。いま「結論」の箱に書いたものは、本当に結論として成立するのかを、徹底的に考える。

まず、いきなり結論を考えるのではなく、その結論を伝える相手を考える。その文書を読むのは、上司なのか顧客なのか。文書の内容について、どこまで知っているのか。上司や顧客のどんな疑問に答える文書なのか。

1. 1. 状況：最初にすることは、上司や顧客と状況を共有することになる。するべき仕事があるのか、何らかの問題があるのかといった、お互いに知っている事実があるはずだ
2. 2. 複雑化：その状況において、何かが起きたり、変化が生じたはずだ（本書ではこれを、複雑化と呼ぶ）。仕事の妨げとなることが起きたのか、問題への解決策が見つかったのかといった、変化があるはずだ
3. 3. 疑問：複雑化の結果、疑問が生じる。するべき仕事の妨げについて、「どうすればよいか？」といった疑問だったり、問題への解決策に対し「その解決策は正しいのか？」といった疑問だ

手を動かし、「状況－複雑化－疑問」を書き出していくと、自分の文書がそれに「答え」となることが分かるはずだ。あるいは、自分の文書がそれらの「答え」となるように、「状況－複雑化－疑問」を書き直すことになるだろう。

その「答え」がピラミッドの頂点となる。

そして、その「答え」を述べると、今度は読み手（上司や顧客）が、それに対する新たな疑問を抱くことになる。その疑問への説明を、一段下のラインで答えることになる。読み手が、「それって何なの？（So What?）」という疑問を抱くのであれば、その答えは主張の箱に入る。あるいは、「なぜそう言えるの？（Why So?）」という質問が来るのなら、根拠の箱で答える。

「結論」は言いたいことだからすぐに入るだろう、と考えてしまう。だが、結論で答えることこそ、念入りに検討し、何度も修正が必要で、すぐには埋めることができない。「状況－複雑化－疑問」を繰り返し考え抜く必要がある。これが「考える技術」である。

ずっと「書く技術」について説明してきたが、「考える技術」にも繋がっているのは、こういうわけなのだ。いわば、手を動かしながら考える技術をレクチャーするのが、本書になる。

ピラミッド構造で考え抜かれていれば、上司や顧客にとって、この上もなくありがたいだろう。なぜなら、自分が悩んでいる状況について、対応できそうな解決策が示せるという前置きの元、あふれ出る疑問について、「それは何か？」「なぜそう言えるのか？」を答えてくれるのだから。高価な買い物だとしても、経営層にとってコンサルが手放せない理由は、まさにここにある。

本書をお手本に、何度も手を動かしていくと、次第に頭の中で組み立てられるようになる。エレベータートークで、「先日の〇〇のトラブルの件ですけど、△△の対策の有効性について整理しました、ポイントは2点あります……」みたいに切り出せる。聞く側の上司も、この「状況－複雑化－疑問ー答え」の順番で理解が進むはずだ。

『考える技術・書く技術』は一生モノだ。

タイトルに「書く技術」とあるけれど、メールやレポート、プレゼン文書に留まらない。口頭での報告、会議でのコメントや議論も変わってくる。本書は、単なるライティング指南を越えた、「自分の中で整理して、相手に理解してもらう技術」なのだから。

「嘘つきは経済学者の始まり」という諺があるが、コンサルタントも入れるべき。

息を吸うように嘘を吐き、口八丁手八丁でキーマンを丸め込む。経営層の「ふわふわした」戯言を辛抱強く聞き取って、組織横断タスクフォースをサポートし、魑魅魍魎がばっこする社内派閥をねじ伏せる完璧なプレゼン資料をつくり上げる。

重要なのは、コンサルが嘘を吐くことではなく、説得力のある嘘を吐くことだ。泥棒や経済学者が吐く、すぐバレるような嘘ではないのだ。

漏れも抜かりもなくロジカルに考え抜かれ、エビデンスと数字に裏打ちされた根拠に支えられ、キーラインがすっと頭に入ってくる明快で分かりやすい論理構造でもって、堂々を嘘を吐く。

嘘が嘘であるとバレるのは、プロジェクトがコンサルの手を離れ、サービスやシステムを構築するフェーズの終盤だ。そこにコンサルはいない。だから、プロジェクトが失敗する原因はコンサルにあるというのだが、コンサルに責を負わすことは不可能なのだ。責めるなら、コンサルの嘘ではなく、説得力のある嘘を信じた経営層だろう。

ITエンジニアの仕事は、嘘を吐くことではない。だから、コンサルの嘘のマネをする必要はない。だが、コンサルの武器を学ぶ意義はある。彼らがどのように考え、伝え、説得しているかは大いに学ぶべきだろう。

『問題解決プロフェッショナル』や『考える技術・書く技術』は、彼らの武器の根幹を成している。基本かつ実践のエッセンス本といっていい。

だが、どちらも読んだらすぐにできるような本ではない。

どんな枠組みに沿って考え、どのように手を動かせばよいのかは分かる。だが、実際に考え、手を動かして身につけるのは自分だ。いったん身につけることができたならば、生涯役に立つが、速効性を求めてはいけない。すぐ効く本はすぐ効かなくなるから。

コンサルの武器は使える。ITエンジニアのあなたにとっても、一生モノの武器になる。くれぐれも、悪用するなかれ。