コンサルタントを目指す方と話すと、必ずといっていいほど出てくるフレーズがあります。「問題解決力を鍛えたい」。
ただ、正直にお伝えします。「問題解決」という言葉は、使う人によって中身がまったく違います。
フレームワークを覚えること、ロジカルに考えること、データを分析すること——どれも間違いではありませんが、実務で本当に求められるゴールは一つです。「クライアントが提言に合意し、組織として動き出すこと。」
分析が正しくても、提言が合理的でも、クライアントが「やりません」と言えばゼロです。問題解決のゴールは、提言を出すことではなく、合意を取り付けることまで含みます。
私がこの認識を持てたのは、大前研一氏の『考える技術』を読んだことがきっかけでした。本書で示された問題解決のステップを実務に落とし込んでみると、自分の思考のどこに穴があったかが鮮明に見えました。今回はその体験をベースに、コンサルタントが実務で使う問題解決のプロセスを解説します。
大前研一が示した「考える技術」の核心
大前研一氏の『考える技術』が他のビジネス書と一線を画すのは、「頭の良い考え方」を教えるのではなく、「問題の構造を正確に捉えるための手順」を示している点です。
本書のエッセンスを整理すると、問題解決は以下のステップで構成されます。
- 現象の観察：何が起きているかを正確に把握する
- 問題の定義：「本当の問題」を特定する
- 原因の分析：なぜ起きているかを構造的に掘り下げる
- 解決策の立案：原因に対応する打ち手を考える
- 提言と合意形成：クライアントを動かす
特に印象に残ったのは、大前氏が「問題とは、あるべき姿と現状のギャップである」と定義している点です。この定義は単純に見えて奥が深いものです。「あるべき姿」を描けなければ、何が問題かすら定義できません。
本書を読んで「これは自分の仕事そのものだ」と思いました。と同時に、自分が日々の実務でいかにステップを飛ばしていたかも痛感しました。
ステップ①｜現象の観察｜「見ている」と「観察している」は違う
事実と解釈を分離する
大前氏が強調するのは、「現象を正確に観察すること」の重要性です。ビジネスの現場では、事実と解釈が混在した情報が飛び交います。「売上が落ちている」は事実ですが、「景気が悪いから」は解釈です。
実務でやるべきことは、まず生の事実だけを集めることです。
- 売上はいつから、どの程度落ちているか（数字と期間）
- どの製品・チャネル・地域で落ちているか（内訳）
- 競合他社も同様の傾向か（外部環境との比較）
この「観察」の精度が、その後の分析の質を決めます。曖昧な現象把握の上に積み上げた分析は、砂上の楼閣です。
ヒアリングで失敗した、私の実体験
製造業クライアントのプロジェクト初期、私はヒアリングを「仮説の答え合わせ」にしてしまっていました。「残業が多い原因は、特定ラインの稼働率低下ではないですか？」という聞き方をしていたのです。相手は「まあ、そうかもしれません」と曖昧に答えます。私はそれを「仮説が正しい」と解釈してしまいました。
しかし現場を歩いてみると、実態はまったく違いました。本当のボトルネックは、段取り替えのたびに発生する手順の属人化と、それによる時間ロスでした。稼働率は関係なかったのです。
大前氏の言う「現象の正確な観察」ができていませんでした。先に結論を持ちすぎて、事実収集が雑になっていたのです。この失敗以来、ヒアリングでは必ずオープンクエスチョンから入るようにしています。「一番困っていることを教えてください」「それはいつ頃から起きていますか？」と、相手に自由に話させることで、自分の仮説では気づけなかった事実が浮かび上がります。
ステップ②｜問題の定義｜「何を解くか」を間違えると全てが無駄になる
「症状」と「問題」を混同しない
観察が終わったら、次は「本当の問題は何か」を定義します。これが最も重要で、最も難しいステップです。
製造業クライアントの例で言えば、「残業コストが高い」は症状であり、問題ではありません。問題とは「あるべき姿と現状のギャップ」なので、まずTo-Be（あるべき姿）を設定する必要があります。
| 観点 | 内容 |
|---|---|
| あるべき姿（To-Be） | 段取り替え時間を業界標準の20分以内に抑え、残業を月間平均20時間未満にする |
| 現状（As-Is） | 段取り替えに平均45分かかり、残業は月間平均38時間発生している |
| ギャップ＝問題 | 段取り替えの標準化が未整備なことで、工数ロスが常態化している |
このように定義すると、「解くべき問い」が「どうすれば段取り替え時間を半分以下に削減できるか」に絞られます。問いが明確になれば、分析の方向性も自然と決まります。
問題には3つのタイプがある
問題を定義する際は、「発生型」「潜在型」「設定型」という3つの分類を意識すると精度が上がります。発生型はすでに顕在化している問題（今回の残業問題のように、目に見えて困っている状態）、潜在型はまだ表面化していないが放置すると将来問題になるもの、設定型は現状に不満はなくても、より高い目標を掲げることで新たに生まれる問題です。コンサルタントに求められるのは、目の前の発生型に対応するだけでなく、潜在型・設定型まで見据えて課題を設定する力です。
イシューツリーで問いを構造化する
問題定義を精緻にするために有効なのがイシューツリーです。「なぜ？」を繰り返しながら、問題を木構造で分解していきます。MECE（モレなく、ダブりなく）を意識して分解することで、見落としを防げます。
段取り替え時間が長い（課題）
├── 手順が標準化されていない
│ ├── ベテラン依存の属人的なやり方
│ └── 手順書が存在しない・更新されていない
├── 必要な工具・部品の準備に時間がかかる
│ ├── 置き場所が決まっていない（5S未整備）
│ └── 次の段取りに必要なものが事前に揃っていない
└── スキル格差が大きい
└── OJTが体系化されていないため若手が時間を要するステップ③｜原因の分析｜仮説思考で「深さ」と「速さ」を両立する
問題が定義できたら、原因を特定します。ここで重要なのが仮説思考です。
「原因を探る」と言うと、手当たり次第にデータを集めてしまいがちです。しかしコンサルタントのプロジェクトは時間が限られています。だから先に仮説を立てます。「おそらく手順書の未整備が最大の要因だろう」という仮説を持った上で、その検証に集中します。仮説が崩れれば別の枝を掘り下げます。
大前氏も仮説の重要性を強調していますが、同時に「仮説に縛られるな」とも述べています。仮説はあくまで「検証の出発点」であり、事実に基づいてアップデートし続けるものです。私が経験した「ヒアリング失敗→仮説崩壊」も、思い返せば仮説に縛られすぎていました。柔軟に仮説を捨てる勇気も、原因分析では必要です。
ステップ④｜解決策の立案｜「正しい打ち手」より「実行できる打ち手」
ロジックツリーで施策を網羅する
原因が特定できたら、解決策を立案します。ここでもロジックツリーを使い、施策をMECEに洗い出します。
段取り替え時間削減の施策
├── 手順の標準化
│ ├── 作業手順書の作成・整備
│ └── ベテランの暗黙知の形式知化
├── 事前準備の仕組み化
│ ├── 5S（整理・整頓・清掃・清潔・躾）の導入
│ └── 段取り準備チェックリストの作成
└── スキル底上げ
├── OJT体系の整備
└── 定期的な模擬訓練の実施施策評価の3軸
複数の施策が出てきたとき、私が使う評価軸は3つです。
| 評価軸 | 問い | 今回の判断 |
|---|---|---|
| ① インパクト | 課題解決にどれだけ貢献するか | 手順書整備＋5Sが最大効果 |
| ② 実現可能性 | クライアントのリソースで動けるか | 外部コスト不要で着手可能 |
| ③ スピード | どのくらいで効果が出るか | 1〜2ヶ月で効果測定可能 |
完璧な施策より、実行できる施策の方がはるかに価値があります。今回のケースでは「作業手順書の整備＋5S導入」を最初の打ち手として提言しました。
ステップ⑤｜提言と合意形成｜ここまでがコンサルタントの仕事
「正しい提言」が採択されるとは限らない
ここが、多くのコンサル志望者が見落としているステップです。
分析が正確で、提言が合理的であっても、クライアントが動かなければゼロです。
あるプロジェクトで、分析を積み重ねた上で「段取り替え手順の標準化」を提言しました。論理的には完璧なはずでした。しかし現場の責任者から返ってきた言葉は「わかります。でも今の現場にそんな余裕はないですよ」でした。
分析は正しかったのですが、相手の組織の文脈、現場の温度感、変化への抵抗感を読めていませんでした。
大前研一氏が示した問題解決のゴールは、分析や提言の完成ではなく、「クライアントが問題の存在を認識し、解決に向けて動き始めること」です。この視点を持ってから、提言の組み立て方が変わりました。
合意を取り付けるための3つの実務アプローチ
① 「驚き」から入らない
最終報告でいきなり「実は問題の本質はここでした」と発表しても、クライアントは心理的に受け入れにくいものです。重要な発見は途中段階でさりげなく共有し、最終報告では「以前お話しした通り」という文脈にします。合意形成は報告会の前から始まっています。
② 相手の言葉で語る
こちらが使うフレームワークや概念をそのままぶつけるのではなく、クライアントが日常業務で使っている言葉に変換して伝えます。「MECEに分解すると」ではなく「モレなく整理すると」。小さなことに見えますが、心理的な距離が縮まります。
③ 反対意見を事前に潰す
提言を出す前に、「誰がどんな理由で反対するか」を想定し、その反論に対する答えを用意しておきます。反論が出てから慌てて答えるより、「おっしゃる通り、その点については〇〇という理由でこのアプローチを選んでいます」と先手を打てると、議論の主導権を握れます。
提言後：実行と検証まで見届ける
合意形成がゴールだとお伝えしましたが、実務ではもう一歩先まで見届けることが求められます。提言が承認されても、現場で実行されなければ意味がありません。私が意識しているのは、施策実行後にPDCA（計画・実行・検証・改善）のサイクルを回し、「予定通り進んでいるか」「効果は想定通り出ているか」を定期的に確認することです。
先ほどの段取り替え時間削減の例では、手順書整備・5S導入から1〜2ヶ月後に効果測定を行うところまでを提言に含めました。実行フェーズで想定通りに進まないことも珍しくありませんが、その際に「なぜ計画通りにいかなかったか」を分析し、打ち手を修正していく姿勢こそが、提言を「絵に描いた餅」にしないための最後の仕上げだと考えています。
まとめ｜問題解決のゴールは「合意」と「実行」にある
この記事で解説した問題解決のステップを改めて整理します。
| ステップ | やること | 落とし穴 |
|---|---|---|
| ① 現象の観察 | 事実を正確に収集する | 仮説で答え合わせをしてしまう |
| ② 問題の定義 | あるべき姿とのギャップを特定する（発生型・潜在型・設定型を意識） | 症状を問題と混同する |
| ③ 原因の分析 | MECEに分解し、仮説で優先順位をつける | 全部を均等に調べようとする |
| ④ 解決策の立案 | 実行可能な打ち手を評価軸で選ぶ | 完璧な施策にこだわりすぎる |
| ⑤ 提言と合意形成 | クライアントが動けるよう文脈を整える | 報告会で初めて本質を提示する |
| ⑥ 実行と検証 | PDCAを回し、効果を確認・修正する | 提言後をクライアント任せにする |
コンサルタントの問題解決で大切なのは、フレームワークの名前を知っていることでも、分析の精緻さでもありません。「クライアントが問題を認識し、解決に向けて動き出し、実際に成果が出るまで見届ける」という状態を作り出すことがゴールです。
大前研一氏が『考える技術』で示したステップは、そのゴールに向かうための地図です。地図は持つだけでは意味がありません。実際に使い、迷い、修正しながら歩いてこそ、自分のものになります。
コンサルタントを目指すあなたに、まずこの地図を手に取ってほしいと思います。そして実際のビジネスの現場で、自分なりの「考える技術」を磨いていただければと思います。
よくある質問
Q. 大前研一氏の『考える技術』は未経験者でも読めますか？
専門用語は多くありませんが、実務経験がある方の方が「自分ごと」として読める内容だと感じます。未経験の方は、まず本記事のような実務エピソードと合わせて読むと理解が深まると思います。
Q. イシューツリーとロジックツリーの違いは何ですか？
本記事では、問題を「なぜ」で分解して構造化する段階をイシューツリー、解決策を「どうすれば」で分解して洗い出す段階をロジックツリーとして使い分けています。呼び方は文献によって多少異なる場合があります。
Q. 提言が受け入れられなかった場合はどうすればいいですか？
まずは反対理由を丁寧にヒアリングすることをおすすめします。多くの場合、論理の誤りではなく、現場の負荷感や心理的な抵抗が理由です。相手の言葉で語り直す、実行のハードルを下げた代替案を用意するなど、合意形成のアプローチを変えることで状況が動くことがあります。
Q. 問題解決力を鍛えるには何から始めればいいですか？
日常のニュースや自分の身の回りの課題を題材に、「あるべき姿と現状のギャップは何か」を言語化する練習から始めることをおすすめします。フレームワークは後からでも身につきますが、この「問いを立てる」感覚は繰り返し練習しないと養われません。
※本記事は大前研一氏の著書『考える技術』の内容を筆者なりに要約・解釈し、実務経験と合わせて解説したものです。書籍本文の引用は行っていません。より詳しく学びたい方は、書籍本文をお読みいただくことをおすすめします。
【著者プロフィール】
34歳・2歳の娘を育てる、都内近郊在住のコンサルティング会社勤務（年収700万円台）。副業でブログ・不動産投資（2物件）・小売（個人事業主・青色申告）を並行しながら、50歳までの純資産1.5億円を目指して資産設計中。このブログでは、実体験にもとづいた家族資産設計とキャリアの考え方を発信しています。