マッキンゼー流イシューツリー：Why、What、How を活用したあらゆる問題の解決手法

多くのプロダクトやビジネスの問題は、人々が調査を始める前からすでに間違っています。これは、チームが解決しようとしている問題について合意できていないために起こります。たった一つの質問で、人々は原因、計画、解決策を同時に考えてしまうことがあります。

各人が異なる質問に答えているかもしれません。原因を見つけること、計画を立てること、解決策を選ぶことは、それぞれ異なる仕事です。これらを混同すると、重要な事実を見逃したり、弱い決定を下したりする可能性があります。例えば、チームが本当に計画を必要としているときに、誰かが原因を推測してしまうかもしれません。あるいは、問題の原因がわかる前に、修正方法について話し合ってしまうかもしれません。

問題を研究する良い方法は、3 つの明確な道筋のうちの 1 つに従うことです。チームは一度に一歩ずつ質問をし、何も繰り返されたり欠落したりしていないかを確認します。AI はこれらのチェックを支援できます。プロダクトマネージャーは、どの問題を研究するか、主要な問題は何か、チームがどの質問に答えるべきかを引き続き決定します。

思考の枝を整理する

1. Why-ツリーは原因を見つけます。そのルートは、なぜ何かが起こっているのかを問います。そのリーフは、可能性のある原因をリストアップします。最終的な出力は、テスト可能な仮説のセットです。
2. What-ツリーは作業を分解します。そのルートは、成果物に必要な作業を問います。そのリーフは、分析、決定、コミットメント、成果物、またはプロセスをリストアップします。最終的な出力は、正しい順序の計画です。
3. How-ツリーは可能な道筋をリストアップします。そのルートは、チームが選択した目標にどのように到達するかを問います。そのリーフは、具体的なアクションをリストアップします。最終的な出力は、ランク付けされたオプションのセットです。

原因には Why、作業単位には What、アクションには How を使用します。各リーフタイプは異なる決定をサポートします。

例

入力：「新規ユーザーのアクティベーションのパフォーマンスが低調です。どうすべきか決める必要があります。」

以下のビジュアルは、ブランチタイプにプレースホルダーを使用しており、実際のプロダクトに関する調査結果は含まれていません。

1WHY: なぜ新規ユーザーのアクティベーションのパフォーマンスが低調なのか？
2
3├── 1. [原因候補グループ A]
4
5├── 2. [原因候補グループ B]
6
7└── 3. [原因候補グループ C]
8
9出力: テスト可能な仮説
10
11WHAT: アクティベーションプランを作成するには、何を分解する必要があるか？
12
13├── 1. エビデンス
14
15│   └── 1.1 [分析] 計画に必要なエビデンス
16
17├── 2. 選択肢
18
19│   └── 2.1 [決定] 分析に依存する選択肢
20
21├── 3. 合意事項
22
23│   └── 3.1 [コミットメント] 確認すべきオーナーシップまたは範囲
24
25└── 4. 統合
26
27└── 4.1 [統合] ブランチ 1 ～ 3 に依存する計画
28
29出力: 順序付けられた作業計画
30
31HOW: どのようにして新規ユーザーのアクティベーションを向上させるか？
32
33├── 1. [確認された原因に結びついた介入]
34
35├── 2. [別の確認された原因に結びついた介入]
36
37└── 3. [指定された制約内の介入グループ]
38
39出力: ランク付けされたオプション

ここでは Why を使うでしょう。なぜなら、チームはアクティベーションが低いことを知っているが、原因は見つけていないからです。How は、チームが原因を知っている場合に適します。What は、チームがアクティベーションプランを作成する必要がある場合に適します。

構造的なチェックではツリーが正しいことを証明できない

3 つのツリーはすべて同じ MECE ルールを使用します。

各レベルのブランチは重複してはいけません。各レベルのブランチは、すべての重要な領域をカバーする必要があります。このチェックは、PM が複数のブランチでカバーされている領域と、まったくカバーされていない領域を特定するのに役立ちます。

複雑な問題に直面したとき、私は AI とコンテキストについて話し合います。スキルを使ってブランチをドラフトし、ツリーを構築し、MECE チェックを実行します。結果はチャットに保持するか、Miro や他のビジュアルツールにコピーします。

メソッドを再現可能にする

一人のプロダクトマネージャーが手動で一つの問題ツリーを作成することはできます。しかし、チームは同じ作業を何度も繰り返さなければなりません。彼らはブランチを作成し、順序付け、各レベルをチェックし、多くの異なる問題に対して明確なツリーを描く必要があります。

AI エージェントはこれらのステップを繰り返し実行できます。プロダクトマネージャーはプロダクトに関する詳細を追加し、問題の説明方法、主要な問題の命名、不要なブランチの削除を決定します。全員が同じステップを使用すると、プロダクトリーダーやレビュアーは作業をより簡単に理解できます。彼らは、なぜチームがそのようにツリーを構築したのかを理解し、問題全体をカバーし、アイデアが重複していないかを確認できます。

新しい問題に直面したときは、まず必要な答えを決めてください。原因を見つける必要がありますか？ 作業計画を作成する必要がありますか？ それとも異なるオプションを考える必要がありますか？ 次に、その目標に合わせて Why、What、または How を選択します。最初のツリーを構築します。次に、ツリーを使用する前に、欠落しているブランチと、別のアイデアを繰り返しているブランチを探します。

プロダクトチームがこのメソッドを繰り返し使用したい場合、すべてのプロダクトマネージャーにプロセス全体を構築させ、すべてのルールを手動でチェックさせるべきではありません。AI がその繰り返し作業を行えるため、チームは問題解決により多くの時間を費やすことができます。

チームにこのスキルを提供する

mckinsey-issue-tree は、プロダクトチーム向けの共有オペレーティングシステムである AI PM OS 内の 243 の PM スキルの 1 つです。これは Claude Code、Cowork、または Cursor で実行され、少なくとも 2 週間に 1 回、バージョン 2.5 で更新されます。

各 PM は自身のプロダクトコンテキストを保持し、チームはワークフローとレビュー基準を共有するため、問題ツリーと分析計画は、一般的な PM アドバイスではなく、あなたのプロダクト、ユーザー、実際の制約に基づいて返されます。

何も組み立てる必要はありません。AI PM OS は、mckinsey-issue-tree を、戦略、リサーチ、決定、ステークホルダー業務、測定のためのワークフローとともに、チームのオペレーティングレイヤーに組み込みます。

AI PM OS は、年間 $499 で最大 10 名の PM まで利用可能です。 フルオンボーディングが含まれます。