イシューツリーでプロジェクト課題を構造化する：マッキンゼー流問題解決

プロジェクトで何か問題が起きたとき、「何が課題なのか」を正確に定義できていない状態で解決策を考え始めてしまうことがある。イシューツリーは、この「課題の定義と構造化」を体系的に行うためのコンサルタント必須スキルだ。

イシューツリーとは

イシューツリーは「問い（イシュー）」を木構造で分解するフレームワークだ。最上位の問いから始めて、それを「なぜそれが問題か」「問題を引き起こしている要因は何か」という形で分解していく。

重要なのはMECEの原則だ。MECEとは「Mutually Exclusive（相互に排他的）and Collectively Exhaustive（全体として網羅的）」の略で、各ブランチが重複せず、かつ全体を漏れなくカバーしていることを意味する。

プロジェクト課題へのイシューツリー適用例

状況： SaaSプロダクトの解約率が上昇している

最上位イシュー： なぜ解約率が上昇しているのか？

解約率上昇の原因
├─ [製品価値]の問題か？
│   ├─ 機能が競合と比較して不足している
│   └─ 既存機能の使い勝手に問題がある
├─ [顧客サクセス]の問題か？
│   ├─ オンボーディングが不十分で価値を理解できていない
│   └─ サポート対応が遅くて不満が高まっている
└─ [外部環境]の問題か？
    ├─ 競合の価格が大幅に下がった
    └─ 業界全体の予算削減で解約が増えている

このツリー全体を見ると、「製品価値」「顧客サクセス」「外部環境」の3つに分類されており、重複なく漏れなく（MECE）原因を網羅している。

イシューツリーを作る手順

Step 1：最上位イシューを「問い」として定義する

「売上が低い」という現象ではなく、「なぜ売上が低いのか」という問いの形にする。問いとして定義することで、「何を調べるべきか」が明確になる。

Step 2：第1層を分解する（MECE確認）

最上位イシューを3〜4つのサブイシューに分解する。この段階でMECEを確認する方法は「これ以外に他の可能性はないか？」（網羅性）と「この分類は重複していないか？」（排他性）を問うことだ。

よく使われるMECE分解パターン：

プロセス分解：Input → Process → Output
構造分解：顧客層別・地域別・製品別
時系列分解：短期・中期・長期

Step 3：アクション可能なレベルまで分解する

「原因」の分解から、「解決策」の分解に切り替えるタイミングを見極める。「機能が不足している」という原因が特定されたなら、「どの機能を優先して追加するか」を分解する。

Step 4：データで仮説を検証する

各ブランチの原因仮説について、「どのデータが正しいかを教えてくれるか」を特定して、最小限のデータを集める。

イシューツリーとKPIツリーの違い

よく混同される概念を整理する。

	イシューツリー	KPIツリー
目的	問題の原因を構造化	目標の達成手段を可視化
方向	問いから原因へ（下向きに掘る）	目標から指標へ（下向きに分解）
使う場面	問題が起きたとき	プロジェクト計画時

書籍紹介

プロジェクトのトラブル解決大全

著者: 木部智之 — 「再生工場」と呼ばれた著者による炎上プロジェクトの火消し術86を収録

詳細を見る

プロジェクトMTGでのイシューツリー活用

会議の中でリアルタイムにイシューツリーを使う場合、ホワイトボード（またはMiro）が有効だ。

ファシリテーションの流れ：

「今日の議論のイシューは何か？」を1行で書く
「この問いに対する答えの候補を3つ挙げてください」と参加者に問う
挙がった答えをホワイトボードに貼って第1層を作る
「これで漏れはありませんか？重複はありますか？」と確認
優先するブランチを決めてさらに掘り下げる

この流れを20分で行うと、会議の議論が「具体的な原因と解決策」に集中するようになる。

まとめ

イシューツリーはコンサルタントが最初に習う思考ツールだが、PMの実務にも直接応用できる。複雑に見える問題も、MECEで分解していくと「解くべき本質的な課題」が見えてくる。週次の課題整理や四半期の振り返りで、ぜひ一度試してみてほしい。