ロジックツリーの作り方と例｜Why・How・Whatの違いとMECE切り口一覧

ロジックツリーとは、1つの問いを、漏れと重なりのない枝に分けていく図です。種類は問いの形で決まり、「何で構成されるか」ならWhatツリー、「なぜ起きたか」ならWhyツリー、「どうやるか」ならHowツリーになります。

この記事では、同じ題材（問い合わせ対応の遅れ）を3種類のツリーで書き分け、違いを並べて見られるようにしました。各ツリーは Mermaid のコードと入れ子の箇条書きの両方で載せているので、そのまま貼って書き換えられます。枝の分け方に迷ったときに引ける、MECE の切り口30個の型別一覧表も付けています。題材は架空の社内ヘルプデスクで、時間の数字もすべて架空の例です。

確認環境：Ubuntu 24.04、Python 3.11.15（ツリーの生成、時間の検算、箇条書きから Mermaid への変換）、@mermaid-js/mermaid-cli 11.14.0 と Chromium（ツリーの描画）。確認日は 2026-10-06 です。

この記事の結論

• 種類は問いの形で決まる。 何で構成されるか＝What、なぜ起きたか＝Why、どうやるか＝How。
• 順番は What → Why → How。 全体を分けて大きい部分を見つけ、そこの原因を掘り、原因ごとに手だてを出します。
• 枝は MECE（漏れなく、重なりなく）に分ける。 分け方の型は、足し算・掛け算・時系列・対立概念・フレームワークの5つです。
• 止めどころは種類ごとに違う。 What は数えられる単位、Why は自分たちで変えられる原因、How は担当と期限を書ける行動まで。
• 箇条書きで作ってから図にする。 入れ子の箇条書きは書き直しが速く、Mermaid へは機械的に変換できます。

Why・How・Whatツリーの早見表

題材：問い合わせ対応の遅れ

架空の社内ヘルプデスクを題材にします。備品予約システムへの問い合わせを受け付けていて、「受付から解決まで平均26時間かかっている。もっと速くしたい」という状況です。

この1つの題材から、問いを変えて3本のツリーを作ります。

Whatツリーの例：時間は何で構成されるか

最初の枝は時系列（業務の流れ）で分けました。受付・担当決定・初回返信・解決という出来事で区切ると、どの時間もどこか1つの枝に入ります。

flowchart LR
    R["問い合わせ対応の時間は<br/>何で構成されるか（平均26時間）"]
    R --> B1["受付から担当決定まで（6時間）"]
    B1 --> L11["窓口が気づくまで（4時間）"]
    B1 --> L12["担当を振り分ける（2時間）"]
    R --> B2["担当決定から初回返信まで（8時間）"]
    B2 --> L21["着手待ち（6.5時間）"]
    B2 --> L22["内容の確認（1.5時間）"]
    R --> B3["初回返信から解決まで（12時間）"]
    B3 --> L31["調査（3時間）"]
    B3 --> L32["回答の作成と確認（1時間）"]
    B3 --> L33["利用者の返信待ち（8時間）"]

入れ子の箇条書き：

- 問い合わせ対応の時間は何で構成されるか（平均26時間）
    - 受付から担当決定まで（6時間）
        - 窓口が気づくまで（4時間）
        - 担当を振り分ける（2時間）
    - 担当決定から初回返信まで（8時間）
        - 着手待ち（6.5時間）
        - 内容の確認（1.5時間）
    - 初回返信から解決まで（12時間）
        - 調査（3時間）
        - 回答の作成と確認（1時間）
        - 利用者の返信待ち（8時間）

Whatツリーは足し算で検算できます。葉を足して枝と同じになるか、枝を足して全体と同じになるかを確かめます。

受付から担当決定まで（6時間）: 葉の合計 6 / 枝 6 -> 一致
担当決定から初回返信まで（8時間）: 葉の合計 8 / 枝 8 -> 一致
初回返信から解決まで（12時間）: 葉の合計 12 / 枝 12 -> 一致
枝の合計 26 時間

7つの葉のうち、長い順に「利用者の返信待ち（8時間）」「着手待ち（6.5時間）」「窓口が気づくまで（4時間）」で、この3つを足すと18.5時間、全体の71%です。次の Why ツリーでは、この大きい部分を中心に原因を掘ります。 調査（3時間）や回答の作成（1時間）のように実際に手を動かしている時間は合わせて4時間で、遅れの大半は待ち時間だと分かります。

Whyツリーの例：なぜ遅れるのか

最初の枝は、Whatツリーと同じ業務の流れに沿って「気づく→担当が決まる→着手する→やり取りする」と分けています。その下に、それぞれの段階で起きていることを原因の候補として書きます。

flowchart LR
    R["なぜ問い合わせ対応が<br/>遅れるのか"]
    R --> B1["問い合わせに気づくのが遅れる"]
    B1 --> L11["窓口がメール・チャット・口頭の3つに分かれている"]
    B1 --> L12["新着の通知が当番に届く仕組みが無い"]
    R --> B2["担当が決まるまでに時間がかかる"]
    B2 --> L21["振り分けの基準が文書になっていない"]
    B2 --> L22["振り分け役が1人で、不在の日は止まる"]
    R --> B3["担当が着手するまでに待ちが出る"]
    B3 --> L31["初回返信の目安の時間が決まっていない"]
    B3 --> L32["ほかの作業との優先度を比べる場が無い"]
    R --> B4["利用者とのやり取りが往復する"]
    B4 --> L41["受付の時点で必要な情報がそろっていない"]
    B4 --> L42["回答のひな形が無く、毎回書き起こしている"]

入れ子の箇条書き：

- なぜ問い合わせ対応が遅れるのか
    - 問い合わせに気づくのが遅れる
        - 窓口がメール・チャット・口頭の3つに分かれている
        - 新着の通知が当番に届く仕組みが無い
    - 担当が決まるまでに時間がかかる
        - 振り分けの基準が文書になっていない
        - 振り分け役が1人で、不在の日は止まる
    - 担当が着手するまでに待ちが出る
        - 初回返信の目安の時間が決まっていない
        - ほかの作業との優先度を比べる場が無い
    - 利用者とのやり取りが往復する
        - 受付の時点で必要な情報がそろっていない
        - 回答のひな形が無く、毎回書き起こしている

Whyツリーの枝は仮説です。書いた時点では候補なので、葉ごとに事実で確かめます。

原因を書くときは、人ではなく仕組みの状態として書きます。「担当者が見落とした」ではなく「新着の通知が当番に届く仕組みが無い」と書くと、そのまま How ツリーの手だてにつながります。

Howツリーの例：どうやって速くするか

Whyツリーの4つの枝を、そのまま手だての4つの枝に対応させています。問いには「初回返信までの時間を半分にする」と数字を入れ、達成したかどうかを確かめられる形にしました。

flowchart LR
    R["どうやって初回返信までの<br/>時間を半分にするか"]
    R --> B1["気づくまでを短くする"]
    B1 --> L11["窓口を1つの受付フォームにまとめる"]
    B1 --> L12["新着をチャットへ自動で通知する"]
    R --> B2["担当決定を速くする"]
    B2 --> L21["問い合わせの種類別の担当表を作る"]
    B2 --> L22["振り分け当番を2人体制にする"]
    R --> B3["着手待ちを短くする"]
    B3 --> L31["初回返信の目安を4営業時間以内と決める"]
    B3 --> L32["毎朝10分、未着手の問い合わせを確認する"]
    R --> B4["往復を減らす"]
    B4 --> L41["フォームに必須項目（画面名・操作・表示された文）を置く"]
    B4 --> L42["よくある質問20件の回答ひな形を作る"]

入れ子の箇条書き：

- どうやって初回返信までの時間を半分にするか
    - 気づくまでを短くする
        - 窓口を1つの受付フォームにまとめる
        - 新着をチャットへ自動で通知する
    - 担当決定を速くする
        - 問い合わせの種類別の担当表を作る
        - 振り分け当番を2人体制にする
    - 着手待ちを短くする
        - 初回返信の目安を4営業時間以内と決める
        - 毎朝10分、未着手の問い合わせを確認する
    - 往復を減らす
        - フォームに必須項目（画面名・操作・表示された文）を置く
        - よくある質問20件の回答ひな形を作る

Howツリーの葉は、担当と期限を書けるところまで分けます。「対応を速くする」「連携を強める」のような葉は、まだ行動になっていないので、もう1段分けます。

葉が出そろったら、効果と手間で並べて取りかかる順を決めます。ツリーは選択肢を漏れなく出す道具で、どれを選ぶかは別の表で決めます。

3種類を並べて比べる

同じ「着手待ち」が、What では時間の大きさ、Why では起きている状態、How では行動として現れます。3本のツリーは別々の図ではなく、同じ問題を3つの問いで順に見たものです。

ロジックツリーの作り方（7つの手順）

枝を点検する5つの質問

MECEの切り口一覧（型別30個）

MECE は Mutually Exclusive, Collectively Exhaustive の頭文字で、「互いに重ならず、全体として漏れがない」という意味です。分け方には型があり、型を知っていると最初の枝を速く決められます。

タブ区切り版：

No  型   切り口 分け方の例   向く問い    確かめ方・気をつける点
1   足し算 利用者の区分  新規の利用者／継続の利用者   だれの問題かを分ける  件数を足すと全体になる
2   足し算 組織の内と外  社内／社外   原因や相手の所在を分ける    どちらにも入るものが無いかを見る
3   足し算 窓口・経路   メール／チャット／口頭 どこから入ってくるかを分ける  「その他」を置いて漏れを受ける
4   足し算 種類  使い方の質問／不具合の連絡／要望    中身の違いで分ける   1件が2種類に入らない定義にする
5   足し算 部署・チーム  開発／総務／営業    どこで多いかを見る   組織図の単位に合わせる
6   足し算 時間帯 午前／午後／夜間    いつ多いかを見る    境目の時刻を決めておく
7   足し算 曜日・期間   平日／休日、月初／月中／月末  波があるかを見る    暦のとおりに分ければ重ならない
8   足し算 時間の内訳   作業している時間／待っている時間    どこに時間が使われているかを見る    足すと全体の時間になる
9   掛け算 件数×1件あたり    総対応時間＝件数×1件あたりの時間   量と効率のどちらを動かすかを決める   掛けると元の数字に戻る
10  掛け算 人数×1人あたり    総件数＝利用者数×1人あたりの問い合わせ件数  利用者の増加か、1人あたりの増加かを分ける   掛けると元の数字に戻る
11  掛け算 対象×割合   利用者数＝対象者数×利用率   母数と割合のどちらを動かすかを決める  割合の分母をそろえる
12  掛け算 人数×期間   工数＝人数×期間    体制と期間のどちらで調整するかを見る  単位（人日・人月）をそろえる
13  掛け算 時間×速さ   処理件数＝稼働時間×1時間あたりの処理件数   時間を増やすか、速さを上げるかを分ける 掛けると元の数字に戻る
14  掛け算 段階ごとの通過率    完了数＝受付数×着手率×完了率 どの段階で減っているかを見る  段階の順に掛ける
15  時系列 業務の流れ   受付→振り分け→調査→回答→完了    どの工程に原因や手だてがあるかを見る  工程の境目を出来事で決める
16  時系列 開発の工程   要件定義→設計→実装→テスト→リリース どの工程で入り、どの工程で見つかったかを見る  工程の定義をチームでそろえる
17  時系列 前・中・後   開始前／作業中／完了後 準備・進行・後処理に分ける   境目の出来事を決める
18  時系列 過去・現在・未来    これまで／いま／これから    経緯と今後を分ける   日付で区切る
19  時系列 期間の長さ   短期／中期／長期    手だてをいつまでに打つかで分ける    「1か月以内」など期間を数字で決める
20  時系列 改善のサイクル 計画→実行→確認→改善 どの段が回っていないかを見る  4つの段を順にたどる
21  対立概念    内部／外部   自分たちで変えられること／変えられないこと   手を打てる範囲を分ける Aと「A以外」になっているかを見る
22  対立概念    量／質 件数の問題／1件ごとの中身の問題    増えたのか、難しくなったのかを分ける  両方に当てはまる枝は掛け算に直す
23  対立概念    人／仕組み   スキル・人数／手順・道具・決まり    手だてを仕組みの側に寄せる   人の側は「何が足りないか」まで書く
24  対立概念    固定／変動   量に関係なくかかるもの／量に比例するもの    量が増えたときに効く部分を見る 量を2倍にしたとき増えるかで判定する
25  対立概念    増やす／減らす 入ってくる量を増やす／出ていく量を減らす    Howの最初の分け方に使う   差し引きの式に戻せる
26  対立概念    発生／流出   起きないようにする／起きても広げない  不具合や遅れの手だてを分ける  どちらか片方だけになっていないかを見る
27  対立概念    一時的／恒常的 今回だけの事情／毎回起きる事情 応急の手だてと恒久の手だてを分ける   過去の記録で繰り返しを確かめる
28  フレームワーク QCD 品質／コスト／納期   成果物や進め方の評価を分ける  3つのどれを優先するかも決める
29  フレームワーク 4M  人／設備／方法／材料  原因の洗い出しの最初の枝に使う ソフトウェアでは設備＝環境・道具、材料＝入力データと読み替える
30  フレームワーク 5W1H    いつ／どこで／だれが／何を／なぜ／どのように  状況の聞き取りの抜けを防ぐ   問いに関係の薄い項目は枝にしない

フレームワーク型は、観点の抜けを減らすための借り物です。足し算や掛け算のように式で検算できるわけではないので、問いに関係の薄い観点は枝から外し、足りない観点は足して使います。

切り口の選び方

箇条書きからMermaidに変換する

ツリーは、まず入れ子の箇条書きで書くと直しやすくなります。形が決まったら、次のスクリプトで Mermaid のコードに変換できます。スペース4つを1段として読み取ります。

# 入れ子の箇条書き（スペース4つで1段）を Mermaid の flowchart に変換する
import sys

def convert(text, direction="LR"):
    lines = [l for l in text.splitlines() if l.strip().startswith("- ")]
    out = [f"flowchart {direction}"]
    stack = []                      # (深さ, ノードID)
    for n, line in enumerate(lines):
        depth = (len(line) - len(line.lstrip(" "))) // 4
        label = line.strip()[2:].replace('"', "'")
        node = f"N{n}"
        out.append(f'    {node}["{label}"]')
        while stack and stack[-1][0] >= depth:
            stack.pop()
        if stack:
            out.append(f"    {stack[-1][1]} --> {node}")
        stack.append((depth, node))
    return "\n".join(out)

if __name__ == "__main__":
    print(convert(sys.stdin.read()))

Whatツリーの箇条書きを what.md に保存して実行します。

python3 md2mmd.py < what.md

実行結果：

flowchart LR
    N0["問い合わせ対応の時間は何で構成されるか（平均26時間）"]
    N1["受付から担当決定まで（6時間）"]
    N0 --> N1
    N2["窓口が気づくまで（4時間）"]
    N1 --> N2
    N3["担当を振り分ける（2時間）"]
    N1 --> N3
    N4["担当決定から初回返信まで（8時間）"]
    N0 --> N4
    N5["着手待ち（6.5時間）"]
    N4 --> N5
    N6["内容の確認（1.5時間）"]
    N4 --> N6
    N7["初回返信から解決まで（12時間）"]
    N0 --> N7
    N8["調査（3時間）"]
    N7 --> N8
    N9["回答の作成と確認（1時間）"]
    N7 --> N9
    N10["利用者の返信待ち（8時間）"]
    N7 --> N10

出力を Mermaid に対応したエディタや文書に貼ると、上の What ツリーと同じ形の図になります。ノードのラベルは ["..."] のように二重引用符で囲んで出力しています。

似た手法との違いと選び方

一本の因果を掘るか、全体を漏れなく分解するか

どれを使うかの判断表

確かめて分かったこと

• What ツリーに数字を入れると、遅れの71%が3つの待ち時間だと分かりました。 26時間のうち、返信待ち8時間・着手待ち6.5時間・気づくまで4時間で18.5時間です。数字の無いツリーでは、どの枝から掘るかを決められません。
• 手を動かしている時間（調査3時間＋回答作成1時間）は4時間でした。 「作業を速くする」手だてより「待ちを減らす」手だてのほうが効く、という方向が What の段階で見えます。
• Why の4つの枝と How の4つの枝は、1対1で対応させられました。 Why の枝を「〜を短くする」「〜を減らす」と言い換えると How の枝になり、原因の無い手だてが混ざりにくくなります。
• Mermaid は、ツリーの向きで図の幅が大きく変わりました。 Why ツリーを flowchart TD（上から下）で描画すると幅2446・高さ350、flowchart LR（左から右）では幅858・高さ990でした。葉の文が長いツリーは LR のほうが文書に収まります。
• Mermaid のラベルに半角の丸かっこを引用符なしで書くと、Parse error になりました。 A[窓口(メール)が分かれている] は描画できず、A["窓口(メール)が分かれている"] と二重引用符で囲むと描画できます。この記事のコードはすべて引用符で囲んでいます。
• 箇条書きからの変換結果は、手で書いたツリーと同じ枝の構成（枝3・葉7）になりました。 箇条書きを直して変換し直すほうが、Mermaid のコードを直接直すより速く済みます。

よくある質問

Q. ロジックツリーとは何ですか？ A. 1つの問いを、漏れと重なりのない枝に分けていく図です。全体を部分に分ける What、原因を洗い出す Why、手だてを洗い出す How の3種類があります。

Q. Whyツリー・Howツリー・Whatツリーの違いは何ですか？ A. 問いの形が違います。What は「何で構成されるか」、Why は「なぜ起きたか」、How は「どうやるか」に答えるツリーで、枝の中身はそれぞれ要素・原因・行動になります。

Q. ロジックツリーは何階層まで分ければよいですか？ A. 階層の数ではなく、止めどころに届いたかで決めます。What は測れる単位、Why は自分たちで変えられる原因、How は担当と期限を書ける行動になったら止めます。今回の例は3種類とも、問いを含めて3階層でした。

Q. MECEに分けられないときはどうすればよいですか？ A. まず対立概念（Aと「A以外」）で2つに割ります。「A以外」の中身を書き出し、まとまりが見えたら枝として独立させます。数字があるなら、足し算か掛け算の式に戻せるかを確かめると重なりと漏れが見つかります。

Q. ロジックツリーとなぜなぜ分析の違いは何ですか？ A. ロジックツリーは全体を横に広く分解し、なぜなぜ分析は1つの事象を縦に深く掘ります。どこが問題かが決まっていないならロジックツリー、起きた事象が1つに決まっているならなぜなぜ分析が向いています。

まとめ

• ロジックツリーの種類は、問いの形で決まる。 何で構成されるか＝What、なぜ＝Why、どうやって＝How。
• What → Why → How の順に作ると、大きい部分に絞って原因と手だてを出せる。
• 枝は MECE に分ける。 型は足し算・掛け算・時系列・対立概念・フレームワークの5つで、切り口30個の一覧から選べます。
• 止めどころは、測れる単位・変えられる原因・担当と期限を書ける行動。
• What には数字を入れ、足し算で検算する。 大きい葉が次の問いの出発点になります。
• 箇条書きで作り、Mermaid に変換して図にする。 葉の文が長いときは LR の向きが収まります。
• 1件の出来事を深く掘るならなぜなぜ分析、全体を漏れなく分けるならロジックツリー。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。