構造化思考：コンサルタントの本当の強み

構造化思考とは、コンサルタントが、曖昧で混沌としたクライアントの課題から、その場の全員が理解し、異論も出せる提言にたどり着くための方法です。意思決定を定義し、問題を重ならない要素に分け、最も可能性の高い答えを先に検証し、その結果を一つの明確な提言にまとめます。

本稿は、プレッシャーの中でもそれを繰り返し再現できる方法を求めているコンサルタントとアナリストに向けたものです。私が頼りにしている4つのツール、次のプロジェクトですぐ使える1ページのワークシート、そしてAIがこのスキルをどう変えたかを取り上げます。

クライアントとの会議で固まってしまう人を見てきました。アイデアがなかったからではありません。どこから始めればよいか分からなかったからです。

状況はよくあるものです。複雑な問題、上級者ばかりの会議室、曖昧なスコープ、そして明確さへの期待。構造のない対応は、とにかく話し始めて、答えが出てくるのを期待することです。出てくることもあります。たいていは、20分ほどぐるぐる回ったあげく、誰も納得しないまま散会します。

曖昧な問題を要素に分け、それぞれを順に検討し、その結果を一つにまとめて提言にする実践です。

テンプレートを埋めて分析と呼ぶことではありません。合わないフレームワークを問題に無理やり当てはめることでもありません。あらゆる状況に2x2のマトリクスを当てはめるコンサルタントは、パターンを照合しているだけで、考えてはいません。

身につけるのは、いくつかの能力です。

1. 本当の問題を見抜くこと。提示された問題とは違っていることがよくあります
2. 別々に分析できる要素に分けること
3. どの情報が重要で、どれが重要でないかを見極めること
4. 見つけたことから、筋の通った主張を組み立てること
5. 場が張り詰めているときに、それをはっきり伝えること

これらの能力が育つまでの間、フレームワークは足場の役割を果たします。もっと幅広い道具立てを知りたい方は、シンプルなコンサルティングフレームワークの解説で、よく使われるものを取り上げています。

フレーミングの問い

どんなフレームワークよりも前に、一つ問いを立てます。どんな意思決定をする必要があり、どんな情報があればその決定が変わるのか。

この問いは、どの構造化ツールよりも分析の質を高めます。アウトプットが何かをはっきりさせ、誰も答えを必要としていない問いに、徹底した作業を費やすのを防ぎます。HBRも何年も前にAre You Solving the Right Problem?で同じ主張をしています。無駄な労力の大半は、問題の定義が甘いところから始まる、というものです。

SAPの文脈では、「この組織に合う導入モデルはどれか」は意思決定です。「S/4HANAとは何か」は説明です。前者には分析が必要で、後者には文書化が必要です。どちらをやっているのかを知ることが、その週の時間の使い方を決めます。

MECE

MECEは、Mutually Exclusive, Collectively Exhaustive（漏れなくダブりなく）の略です。問題を要素に分けるとき、各要素は互いに区別され（重なりがない）、全体として問題の全体を覆っている（抜けがない）必要があります。

カテゴリーが重なると、二重にカウントしてしまいます。抜けがあると、見落としが出ます。この略語を知っているコンサルタントは多いものの、厳密に適用している人は少数です。

二つのテストで精度を保てます。第一に、ある項目が同時に二つの枝に入りうるか。入るなら、枝が重なっています。第二に、すべての枝に答えが出たとき、中心の問いにも答えが出ているか。出ていなければ、抜けがあります。完全なMECEはまれです。大切なのは、毎回この二つの問いを立てることです。

イシューツリー

イシューツリーは、中心の問いを根に置き、サブクエスチョンを枝に置きます。各枝は単独で分析できます。

「このSAPの本稼働は、なぜ計画予算を40%超過したのか」を例にします。最初の分岐は、スコープ変更、リソースコスト、スケジュールの延長、想定外の是正対応といったところでしょう。スコープ変更はさらに、正式な変更要求、非公式な追加、後から発覚した抜け漏れに分かれます。それぞれの葉は測定できます。

イシューツリーが役に立つのは、プロジェクトの初期、まだ分析に着手する前です。ある枝に3週間を費やしている間に、別の枝が手つかずのままになる、という事態を防いでくれます。

仮説思考

すべてのデータを集めてから結論を出すのではなく、最も可能性の高い答えから始めて、それを検証します。戦略系ファームは、この手法で評判を築きました。

時間が限られ、問題が複雑なときは、網羅的な分析はできません。良い仮説は、最初に何を見るべきかを教えてくれます。仮説が成り立てば、答えが手に入ります。成り立たなければ、それを覆した証拠が、有益な方向を指し示すことがほとんどです。

これは、最も誤用されやすい手法でもあります。コンサルタントは仮説を立てたあと、それを裏づける証拠だけを探してしまいます。自分が間違っていることを示す証拠は何かを問い、まずそれを探しに行ってください。

これは、新人コンサルタントが最初の診断に入る前に私が渡す手順です。スプレッドシートを一つも開く前に、これを埋めます。

1. 01フレーミング意思決定を一文で
2. 02分解MECEな問いを三つから五つ
3. 03仮説を立てる枝ごとに一行
4. 04反証を探す自分が間違っていることを示す証拠
5. 05検証枝ごとの発見事項と出典
6. 06統合まず提言、その後に根拠
7. 07ストレステスト場から指摘が出る前に、想定される反論に答えを用意する

ステアリングコミッティを通過できる提言

ステップ	答えるべき問い	アウトプット	承認する人
1. フレーミング	クライアントはどんな意思決定を、いつまでに行う必要があるか。	一文	クライアントのスポンサー
2. 分解	合わせて答えればその意思決定が決まる、3〜5つの問いは何か。	第一階層のイシューツリー（MECEテスト済み）	案件責任者
3. 仮説を立てる	現時点で答えは何だと考えていて、それはなぜか。	枝ごとに一行の仮説	案件責任者
4. 反証を探す	各仮説が間違っていることを示す証拠は何か。	データ依頼リスト（優先順位付き）	クライアントのデータオーナーが提供に同意する
5. 検証	証拠は何を示しているか。	枝ごとの発見事項と出典	チーム内の各枝の担当者
6. 統合	では、クライアントは何をすべきか。	まず提言、続いて裏づけとなるポイント	案件責任者
7. ストレステスト	場にいる誰が、何について反対するか。	想定される反論と回答（準備済み）	その作業に関わっていない同僚

ステップ7は、多くの人が飛ばすステップです。提言がステアリングコミッティを通過できるかどうかを決めるのも、このステップです。

あるSAPのお客様、大規模な製造グループは、大幅にカスタマイズされたECC環境を運用していました。IT責任者ははっきりと言いました。「運用コストを削減したい。ただし、何も壊すわけにはいかない」。

本能的には、コスト削減のアイデアを列挙し始めたくなります。それでは、長いリストと、不安になった大勢の人と、優先順位のない状態が残るだけです。

私たちはコスト分析を3つの枝に整理しました。アプリケーション保守、インフラ、ライセンスです。そこにカスタムコードの分析を重ねました。実際に使われている改修はどれだけあるのか。半数以上が使われていませんでした。冗長なインターフェース、使われていない独自レポート、重複するワークフローです。

こうして構造化したことで、使われていないカスタムオブジェクトのアーカイブや開発環境の統合など、安全だと感じられる削減策を示すことができました。明確になったことで政治的な摩擦が和らぎ、信頼も築けました。ツリーがなければ、誰も署名したがらない削減案の羅列になっていたでしょう。

同じ方法は、もっと曖昧な依頼にも通用します。ある企業向けソフトウェアベンダーから、サウジアラビアの中堅市場向けの「地域展開戦略」を求められたことがあります。私たちは作業を、市場の需要、競争上の位置づけ、パートナーの準備状況に分けました。パートナーの準備状況の下で、同社のリセラーネットワークにはSAP S/4HANA Cloudの経験がほとんどないことが分かりました。市場がどれほど魅力的に見えても、その障害のために実行は止まっていたはずです。構造化したおかげで、キャンペーン予算を使う前にそれが見えてきました。

フレームワークは変わっていません。変わったのは、ほかの二つです。

たたき台が安くなりました。Joule、ChatGPT、Claudeは、イシューツリーや仮説ツリーを数秒で作ります。かつては最初のたたき台に一晩かけていた若手コンサルタントは、いまでは30秒で生成し、その晩をモデルにできないことに使います。構造が問題に合っているかを検証すること、見落としを見つけること、プロンプトに含まれる前提に異議を唱えることです。

判断力のプレミアムが大きくなりました。誰でもMECEな分解を生成できるようになると、問われるのは「問題を分解したか」ではなくなります。「クライアントが述べている問題は、実は別の問題だと気づいたか」「モデルがデフォルトで受け入れた前提に気づいたか」が問われます。実際のプロジェクトで判断力を磨いてきたコンサルタントは、2024年の時点よりも大きなリードを持っています。

つまり、スキルが移りました。もはや「イシューツリーを作れるか」ではありません。「AIが作ったツリーが間違っているときにそれに気づき、クライアントの前で直せるか」です。

自分のキャリアがこの先どうなるかを考えているなら、SAPopediaのキャリアパスがコンサルティングのトラックを整理しており、ERPCVのキャリアパックは、フレームワークを並べるだけでなく、この種の判断力を職務経歴書に示すのに役立ちます。

解決策から入る。 クライアントかコンサルタントが、問題が定義される前から答えを決めています。分析は、裏づけ作業になってしまいます。

構造化しすぎる。 単純な問題には、MECEによる分解ではなく、直接の答えがふさわしいものがあります。いつ構造を使わないかを知っていることは、使い方を知っていることと同じくらい大切です。

間違った深さで分解する。 早い段階で深く掘りすぎたツリーは、身動きを取れなくします。浅いままのツリーは、誰も実行できない提言を生みます。意思決定と使える時間に合わせて深さを決めます。

統合のない分析。 厳密なツリーが、データの山で終わるものです。構造は思考を助けます。提言を生むのは判断です。

伝え方の構造と、考え方の構造を混同する。 バーバラ・ミントのピラミッド原則のように結論から提示するのは、コミュニケーションの技法です。その下にある思考が健全だったかどうかについては、何も語りません。悪い分析をうまく伝えても、悪い分析のままです。

これは資質ではなく、スキルです。練習で身につきます。

重要なクライアントとの会話のたびに、自分が理解している問題、分解、仮説、そしてそれを検証する証拠を書き出します。データを見る前にやってください。書くことは、頭の中で考えるだけでは得られない明確さを強いてくれます。

分析だけでなく、統合も練習します。証拠の山から、擁護できる提言を一つ導くのは、難しいほうの半分です。若手コンサルタントの多くは、分析は十分にこなしますが、統合が育っていません。そのギャップこそ、次の昇進がある場所です。また、流行語を取り払ったときのコンサルタントが実際にやっていることの大きな部分でもあります。

コンサルティングにおける構造化思考とは何ですか？

複雑で曖昧な問題を要素に分け、それぞれを順に検討し、その結果を明確な提言にまとめる手法です。難しい問題を扱いやすくし、推論の過程を見えるようにするため、クライアントは結論を鵜呑みにせず、筋道を追って異論を出すことができます。

主なツールは、フレーミングの問い、イシューツリー、MECE、仮説思考です。どれも判断の代わりにはなりません。

MECEとは何を意味し、どう使いますか？

Mutually Exclusive, Collectively Exhaustive。分解した要素は重ならず、合わせると問題の全体を覆っている必要があります。

重複のテスト：ある項目が二つの枝に入りうるか。抜けのテスト：すべての枝に答えが出たとき、中心の問いにも答えが出るか。イシューツリーを組み立てるときに適用します。完成した分析に後から当てはめても、たいていは手遅れです。

仮説思考はどのように機能しますか？

最も可能性の高い答えを早い段階で言葉にし、それを裏づける、あるいは覆す証拠を列挙してから、検証に向かいます。どこを見るべきかが分かるため、先にすべてを集めるより速く進みます。

リスクは確証バイアスです。まず、自分が間違っていることを示しうる証拠を探してください。

コンサルティングの問題を正しくフレーミングするには？

どんな意思決定をする必要があり、どんな情報があればそれが変わるのかを問います。そのうえで、クライアントの問題設定を受け入れる前に検証します。

「どのSAPモジュールから導入すべきか」と尋ねるクライアントは、実は「そもそも今がSAPプログラムを始める時期なのか」を決めようとしているのかもしれません。フレーミングを検証せずに、述べられた問いに答えると、技術的には正しく、商業的には間違った分析になります。

コンサルティングにおける分析と統合の違いは何ですか？

分析は、問題やデータセットを要素に分けて理解することです。統合は、発見事項を一つの提言にまとめることです。

成果物で最もよくある失敗は、分析は山ほどあるのに統合がないことです。クライアントは、発見事項の束を受け取っても、依頼した問いへの答えを受け取れません。結論を先に書くと、統合が強制的に行われます。

構造化思考はERP導入にどう当てはまりますか？

プログラムの開始時には、本当の問題が理解される前にチームがコンフィグレーションを始めてしまうのを防ぎます。「SAPが必要だ」と言う組織は、SAPがかえって目立たせるだけのプロセスやデータの問題を、先に直す必要があるのかもしれません。

フィットギャップ分析では、業務プロセスをMECEに分解することで、ワークショップで挙がったプロセスだけでなく、すべてのプロセスが確実に検討されます。難航した本稼働の後は、意思決定（安定化、立て直し、置き換え）をフレーミングし、主な原因についての仮説を検証すると、症状を並べるよりも速く、擁護できる提言にたどり着けます。