コンサルタントの問題解決メソッド完全ガイド｜大前研一『考える技術』を実務で使い倒した話

コンサルタントを目指す方と話すと、必ずといっていいほど出てくるフレーズがある。「問題解決力を鍛えたい」。

ただ、正直に言う。「問題解決」という言葉は、使う人によって中身がまったく違う。

フレームワークを覚えること？　ロジカルに考えること？　データを分析すること？　どれも間違いではないが、実務で本当に求められるゴールは一つだ。「クライアントが提言に合意し、組織として動き出すこと。」

分析が正しくても、提言が合理的でも、クライアントが「やりません」と言えばゼロだ。問題解決のゴールは、提言を出すことではなく、合意を取り付けることまで含む。

私がこの認識を持てたのは、大前研一氏の『考える技術』を読んだことがきっかけだった。本書で示された問題解決のステップを実務に落とし込んでみると、自分の思考のどこに穴があったかが鮮明に見えた。今回はその体験をベースに、コンサルタントが実務で使う問題解決のプロセスを解説する。

大前研一が示した「考える技術」の核心

大前研一氏の『考える技術』が他のビジネス書と一線を画すのは、「頭の良い考え方」を教えるのではなく、「問題の構造を正確に捉えるための手順」を示している点だ。

本書のエッセンスを整理すると、問題解決は以下のステップで構成される。

1. 現象の観察：何が起きているかを正確に把握する
2. 問題の定義：「本当の問題」を特定する
3. 原因の分析：なぜ起きているかを構造的に掘り下げる
4. 解決策の立案：原因に対応する打ち手を考える
5. 提言と合意形成：クライアントを動かす

特に印象に残ったのは、大前氏が「問題とは、あるべき姿と現状のギャップである」と定義している点だ。この定義は単純に見えて奥が深い。「あるべき姿」を描けなければ、何が問題かすら定義できない。

本書を読んで「これは自分の仕事そのものだ」と思った。と同時に、自分が日々の実務でいかにステップを飛ばしていたかも痛感した。

ステップ①｜現象の観察｜「見ている」と「観察している」は違う

事実と解釈を分離する

大前氏が強調するのは、「現象を正確に観察すること」の重要性だ。ビジネスの現場では、事実と解釈が混在した情報が飛び交う。「売上が落ちている」は事実だが、「景気が悪いから」は解釈だ。

実務でやるべきことは、まず生の事実だけを集めることだ。

• 売上はいつから、どの程度落ちているか（数字と期間）
• どの製品・チャネル・地域で落ちているか（内訳）
• 競合他社も同様の傾向か（外部環境との比較）

この「観察」の精度が、その後の分析の質を決める。曖昧な現象把握の上に積み上げた分析は、砂上の楼閣だ。

ヒアリングで失敗した、私の実体験

製造業クライアントのプロジェクト初期、私はヒアリングを「仮説の答え合わせ」にしてしまっていた。「残業が多い原因は、特定ラインの稼働率低下ではないですか？」という聞き方をしていたのだ。相手は「まあ、そうかもしれません」と曖昧に答える。私はそれを「仮説が正しい」と解釈した。

しかし現場を歩いてみると、実態はまったく違った。本当のボトルネックは、段取り替えのたびに発生する手順の属人化と、それによる時間ロスだった。稼働率は関係なかった。

大前氏の言う「現象の正確な観察」ができていなかった。先に結論を持ちすぎて、事実収集が雑になっていたのだ。この失敗以来、ヒアリングでは必ずオープンクエスチョンから入るようにしている。「一番困っていることを教えてください」「それはいつ頃から起きていますか？」と、相手に自由に話させることで、自分の仮説では気づけなかった事実が浮かび上がる。

ステップ②｜問題の定義｜「何を解くか」を間違えると全てが無駄になる

「症状」と「問題」を混同しない

観察が終わったら、次は「本当の問題は何か」を定義する。これが最も重要で、最も難しいステップだ。

製造業クライアントの例で言えば、「残業コストが高い」は症状であり、問題ではない。問題とは「あるべき姿と現状のギャップ」だから、まずTo-Be（あるべき姿）を設定する必要がある。

観点	内容
あるべき姿（To-Be）	段取り替え時間を業界標準の20分以内に抑え、残業を月間平均20時間未満にする
現状（As-Is）	段取り替えに平均45分かかり、残業は月間平均38時間発生している
ギャップ＝問題	段取り替えの標準化が未整備なことで、工数ロスが常態化している

このように定義すると、「解くべき問い」が「どうすれば段取り替え時間を半分以下に削減できるか」に絞られる。問いが明確になれば、分析の方向性も自然と決まる。

イシューツリーで問いを構造化する

問題定義を精緻にするために有効なのがイシューツリーだ。「なぜ？」を繰り返しながら、問題を木構造で分解していく。MECE（モレなく、ダブりなく）を意識して分解することで、見落としを防げる。

段取り替え時間が長い（課題）
├── 手順が標準化されていない
│   ├── ベテラン依存の属人的なやり方
│   └── 手順書が存在しない・更新されていない
├── 必要な工具・部品の準備に時間がかかる
│   ├── 置き場所が決まっていない（5S未整備）
│   └── 次の段取りに必要なものが事前に揃っていない
└── スキル格差が大きい
    └── OJTが体系化されていないため若手が時間を要する

ステップ③｜原因の分析｜仮説思考で「深さ」と「速さ」を両立する

問題が定義できたら、原因を特定する。ここで重要なのが仮説思考だ。

「原因を探る」と言うと、手当たり次第にデータを集めてしまいがちだ。しかしコンサルタントのプロジェクトは時間が限られている。だから先に仮説を立てる。「おそらく手順書の未整備が最大の要因だろう」という仮説を持った上で、その検証に集中する。仮説が崩れれば別の枝を掘り下げる。

大前氏も仮説の重要性を強調しているが、同時に「仮説に縛られるな」とも言っている。仮説はあくまで「検証の出発点」であり、事実に基づいてアップデートし続けるものだ。私が経験した「ヒアリング失敗→仮説崩壊」も、思い返せば仮説に縛られすぎていた。柔軟に仮説を捨てる勇気も、原因分析では必要だ。

ステップ④｜解決策の立案｜「正しい打ち手」より「実行できる打ち手」

ロジックツリーで施策を網羅する

原因が特定できたら、解決策を立案する。ここでもロジックツリーを使い、施策をMECEに洗い出す。

段取り替え時間削減の施策
├── 手順の標準化
│   ├── 作業手順書の作成・整備
│   └── ベテランの暗黙知の形式知化
├── 事前準備の仕組み化
│   ├── 5S（整理・整頓・清掃・清潔・躾）の導入
│   └── 段取り準備チェックリストの作成
└── スキル底上げ
    ├── OJT体系の整備
    └── 定期的な模擬訓練の実施

施策評価の3軸

複数の施策が出てきたとき、私が使う評価軸は3つだ。

評価軸	問い	今回の判断
① インパクト	課題解決にどれだけ貢献するか	手順書整備＋5Sが最大効果
② 実現可能性	クライアントのリソースで動けるか	外部コスト不要で着手可能
③ スピード	どのくらいで効果が出るか	1〜2ヶ月で効果測定可能

完璧な施策より、実行できる施策の方がはるかに価値がある。今回のケースでは「作業手順書の整備＋5S導入」を最初の打ち手として提言した。

ステップ⑤｜提言と合意形成｜ここまでがコンサルタントの仕事

「正しい提言」が採択されるとは限らない

ここが、多くのコンサル志望者が見落としているステップだ。

分析が正確で、提言が合理的であっても、クライアントが動かなければゼロだ。

あるプロジェクトで、分析を積み重ねた上で「段取り替え手順の標準化」を提言した。論理的には完璧なはずだった。しかし現場の責任者から返ってきた言葉は「わかります。でも今の現場にそんな余裕はないですよ」だった。

分析は正しかった。しかし、相手の組織の文脈、現場の温度感、変化への抵抗感を読めていなかった。

大前研一氏が示した問題解決のゴールは、分析や提言の完成ではなく、「クライアントが問題の存在を認識し、解決に向けて動き始めること」だ。この視点を持ってから、提言の組み立て方が変わった。

合意を取り付けるための3つの実務アプローチ

① 「驚き」から入らない

最終報告でいきなり「実は問題の本質はここでした」と発表しても、クライアントは心理的に受け入れにくい。重要な発見は途中段階でさりげなく共有し、最終報告では「以前お話しした通り」という文脈にする。合意形成は報告会の前から始まっている。

② 相手の言葉で語る

こちらが使うフレームワークや概念をそのままぶつけるのではなく、クライアントが日常業務で使っている言葉に変換して伝える。「MECEに分解すると」ではなく「モレなく整理すると」。小さなことに見えるが、心理的な距離が縮まる。

③ 反対意見を事前に潰す

提言を出す前に、「誰がどんな理由で反対するか」を想定し、その反論に対する答えを用意しておく。反論が出てから慌てて答えるより、「おっしゃる通り、その点については〇〇という理由でこのアプローチを選んでいます」と先手を打てると、議論の主導権を握れる。

まとめ｜問題解決のゴールは「合意」にある

この記事で解説した問題解決のステップを改めて整理する。

ステップ	やること	落とし穴
① 現象の観察	事実を正確に収集する	仮説で答え合わせをしてしまう
② 問題の定義	あるべき姿とのギャップを特定する	症状を問題と混同する
③ 原因の分析	MECEに分解し、仮説で優先順位をつける	全部を均等に調べようとする
④ 解決策の立案	実行可能な打ち手を評価軸で選ぶ	完璧な施策にこだわりすぎる
⑤ 提言と合意形成	クライアントが動けるよう文脈を整える	報告会で初めて本質を提示する

コンサルタントの問題解決で大切なのは、フレームワークの名前を知っていることでも、分析の精緻さでもない。「クライアントが問題を認識し、解決に向けて動き出す」という状態を作り出すことがゴールだ。

大前研一氏が『考える技術』で示したステップは、そのゴールに向かうための地図だ。地図は持つだけでは意味がない。実際に使い、迷い、修正しながら歩いてこそ、自分のものになる。

コンサルタントを目指すあなたに、まずこの地図を手に取ってほしい。そして実際のビジネスの現場で、自分なりの「考える技術」を磨いてほしい。