イシューツリーは、課題を疑問形の論点に分解し、論点ごとに仮説を立てて検証し、その結果を集めて結論を出すための図です。分解して終わりではなく、仮説、検証、検証結果まで1本のツリーの中で進めて、ようやく意思決定に使えるものになります。
この記事では、ヒアリングで集めた課題を「羅列したまま」にしないための作り方を、手順と例で説明します。
イシューツリーは「分解して終わり」ではない
イシューツリーの流れは次の通りです。
[課題]（事実と影響で定義する）
└ [論点] ○○はどうか？（疑問形、漏れなくダブりなく）
└ [仮説] ○○ではないか？
└ [検証] 誰が、何を、いつまでに、何を基準に確かめるか
└ [検証結果] ○確定 / ×否定 / △不明・要ヒアリング ＋ メモ
↓ まとめる
[結論]
課題を細かく分けたところで手を止めると、「論点はたくさん出たが、何をすればよいか分からない」状態になります。各論点に仮説を置き、確かめる方法まで書いて初めて、次の行動が決まります。
ロジックツリーの種類と使い分け
「ツリー」にはいくつかの型があり、末端に何が来るかが違います。混ぜると考えが止まるので、目的に合わせて使い分けます。
| 型 | 使う場面 | 末端に来るもの |
|---|---|---|
| イシューツリー | 課題を論点に分け、仮説を検証して結論を出す | 論点（疑問形） |
| Whyツリー | すでに起きた問題の原因を「なぜ」で掘る | 根本原因（事実） |
| Whatツリー | 対象を構成要素に分ける | 構成要素 |
| Howツリー | 解決策の候補を広げて比べる | 実行の候補 |
| MECEアクションツリー | ゴールから「そのために」で行動を網羅する | 実行する行動 |
| KPIツリー | 数値を足し算や掛け算で分ける | 測れる数値 |
ヒアリングでそろえたASIS・TOBE・GAPとの関係で言うと、GAP（解くべき課題）を整理するのがイシューツリー、TOBEを実現する行動を洗い出すのがMECEアクションツリーです。解決策の候補を出す段階ではHowツリーを使います。
作り方1：課題を事実と影響で定義する
最初の箱に書く課題がぼやけていると、その下がすべてぼやけます。課題には次の3つを入れます。
- 何が
- どうなっているか（数値や事実で）
- なぜ問題か（利益、リスク、機会損失への影響）
「出荷業務が大変」では課題になりません。「出荷センターの残業時間が前年より大きく増え、人件費が利益を圧迫している」のように書きます。
曖昧な言葉は、質問して事実に変えます。
| 曖昧な表現 | 事実にするための質問 | 書き換えの例 |
|---|---|---|
| 作業が大変 | 1件何分で、月に何件ありますか？ | 1件15分の手入力が月400件 |
| ミスが多い | 月に何回、どの工程で起きますか？ | 出荷ミスが月に数件、主に梱包工程 |
| 属人化している | 今その作業ができるのは何人ですか？ | 対応できるのは1名だけ |
数字にしておくと、後で仮説を検証するときの判断基準にもなります。
作り方2：論点を疑問形でMECEに分ける
課題の下に、論点を疑問形で並べます。「○○はどうか？」「○○の原因は何か？」と書くことで、そこに仮説を立てて確かめる流れが自然に作れます。
- 事実の書き方：「梱包工程の遅れ」
- 論点の書き方：「梱包工程の処理時間はどう変化しているか？」
同じ階層に並ぶ論点は、次の観点で点検します。
| 観点 | 問い |
|---|---|
| 漏れがないか | 並べた論点を合わせると、上の課題を説明しきれるか |
| ダブりがないか | 2つの論点に同じ内容が入っていないか |
| 粒度がそろっているか | 「人件費」と「Aさんが忙しい」のように、レベルの違うものが並んでいないか |
| 分け方の軸が1つか | 1つの階層で、工程別と担当者別を混ぜていないか |
分け方の軸は、ゼロから考えるより型を当てはめるほうが早く進みます。コストの話なら費目別、プロセスの話なら工程の順、組織の話なら部門別、決めにくいときは「人・モノ・金・情報」で仮置きします。
すべての論点を同じ深さで掘る必要はありません。影響の大きい論点を前に置き、掘る論点と掘らない論点を意識して分けます。
作り方3：仮説を立て、検証の方法を決める
論点ごとに「○○ではないか？」という仮説を置きます。粗くてかまいません。仮説がないと、何のデータを集めればよいかが決まらないからです。
検証には「誰が、何を、いつまでに、何を基準に判断するか」を書きます。「さらに調べる」とだけ書くと、誰も動きません。検証が終わったら、○（確定）、×（否定）、△（不明・要ヒアリング）と結果のメモを残します。
情報が足りない論点があっても、ツリーを止めないでください。「△要ヒアリング」と明示して先に進めます。データがないから分からない、ではなく、分からないから仮説を立てて確かめにいく、という順番です。
具体例：出荷センターの残業増加
ある通販事業者の出荷センターで、残業時間が前年より大きく増えているという課題をツリーにします。
[課題] 出荷センターの残業時間が前年より大きく増え、人件費が利益を圧迫している
├ [論点A] 出荷の量はどう変化しているか？
│ └ 仮説：出荷件数よりも、1件あたりの品目数が増えているのではないか
│ └ 検証：出荷データで件数と1件あたり品目数の月次推移を出す（分析担当／今週）
│ └ 結果：○ 件数は横ばい、1件あたり品目数が増加
├ [論点B] どの工程に時間がかかっているか？
│ ├ [論点B-1] ピッキングの時間はどう変化しているか？
│ │ └ 仮説：品目が増えて棚を回る距離が長くなっているのではないか
│ │ └ 検証：作業記録で1件あたりのピッキング時間を比べる
│ │ └ 結果：○ 増加している
│ └ [論点B-2] 梱包の時間はどう変化しているか？
│ └ 仮説：同梱物の確認作業が増えているのではないか
│ └ 結果：△ 作業記録がなく要ヒアリング
└ [論点C] 時間帯ごとの作業の偏りはあるか？
└ 仮説：締め時刻直前に注文が集中しているのではないか
└ 検証：受注時刻の分布を見る
└ 結果：× 受注は終日ほぼ均等
検証結果を集めると、「件数ではなく1件あたりの品目数が増え、ピッキングの動線が長くなっていることが主因。梱包工程は未確認」という結論になります。「締め前の集中」という最初の思い込みは否定されました。
この結論が出て初めて、Howツリーで棚の配置の見直し、まとめてピッキングする方式、品目数の多い注文を別の流れにする案などを比べる段階に進めます。
優先順位を決める
論点や仮説が複数残ったら、重要度（解決したときの効果の大きさ）と緊急度（放置したときの悪化の速さ）で4つに分けます。
| 緊急度が高い | 緊急度が低い | |
|---|---|---|
| 重要度が高い | 最優先ですぐ着手 | 計画を立てて着手 |
| 重要度が低い | 担当を決めて対処 | 定期的に見直す |
よくある失敗
- 解決策がツリーに混ざる：「システム導入」「自動化」は論点でも仮説でもありません。解決策は結論が出てからHowツリーで扱います
- 末端が事実の記述になっている：「設備の老朽化」ではなく「設備の老朽化はどの程度進んでいるか？」と疑問形にします
- 情報がないところでツリーが止まる：「△要ヒアリング」と書いて完成させ、確認の行動につなげます
- 1つの階層で分け方の軸が混ざる：工程別と担当者別が並ぶと、漏れとダブりが同時に起きます
- 課題の定義が曖昧なまま分解する：「大変」「非効率」から分解しても、論点が定まりません
- 検証の方法を書かない：「調べる」だけでは、誰がいつ何を見るのかが決まりません
この記事のまとめ
- イシューツリーは、課題、論点、仮説、検証、検証結果、結論を1本で進める
- 課題は「何が、どうなっているか、なぜ問題か」を数値と事実で書く
- 論点は疑問形で、漏れなくダブりなく、1つの軸で分ける
- 論点ごとに仮説を置き、誰が何をいつまでにどう判断するかを書く
- 分からない箇所は「△要ヒアリング」と明示して止めない
- 解決策は結論が出てからHowツリーで比べる
ツリーに載せる課題を集める方法はASIS・TOBE・GAPをそろえるヒアリング、仮説の立て方は仮説思考、全体を見渡して論点の抜けを防ぐ方法は俯瞰思考で説明しています。
イシューツリーは、FDE Guildのロードマップ ステップ3「課題を構造化する」の中心になるスキルです。元になった手順はFDEガイド「イシューツリー」にまとまっており、スライド・演習問題・テストはlecture.iplot.jpで取り組めます。