MECEとロジックツリーの使い方｜問題を構造化する実践手順と具体例

「で、他の選択肢は検討したの？」

会議室でそう言われた瞬間、頭が真っ白になった経験はありませんか。資料を作り込んで臨んだのに、根拠を問われるとうまく答えられない。MECEもロジックツリーも研修で習ったはずなのに、いざ実務で使おうとすると手が止まってしまう——そんなもどかしさを抱えている方へ、この記事は書きました。

この記事を読むと、「概念は知っているのに使えない」状態から、実際の業務課題をMECE→ロジックツリー→解決策導出まで自分1人で整理できる状態になります。

「知っている」と「使える」の間にある深い溝

筆者がプロジェクトマネージャーとして若手を育ててきた経験から、正直に言わせてください。

ロジカルシンキングの研修を受けた若手エンジニアやPMが、その翌週の会議で突然MECEやロジックツリーを使いこなせるようになる——そんなことは、まずありません。

なぜかというと、研修で教わるのは「概念の地図」であって「歩き方」ではないからです。地図を持っていても、一度も自分の足で歩いたことがなければ、目的地にたどり着けないのは当然なんですよね。

筆者自身、SIer時代に要件定義の議事録を上司に見せるたびに「で、この分類って網羅できてる？」と赤ペンを入れられていました。MECEという言葉は知っていましたが、自分のアウトプットがMECEになっているかどうかを確認する方法を、誰にも教わっていなかったんです。

MECEとロジックツリーを「知っている」だけの人がやりがちな3つの失敗

実務でよく見かける失敗パターンを正直に書いておきます。これを読んで「あ、自分だ」と思ったら、有料パートが確実に効きます。

失敗①　分類が「思いついた順」になっている

MECEとは「Mutually Exclusive, Collectively Exhaustive（ミューチュアリー・エクスクルーシブ・コレクティブリー・エグゾースティブ）」の略で、「漏れなく・ダブりなく」という意味です。

ところが実際の作業では、思いついたことを上から書き並べて、それをあとから箱に入れようとするケースが多いです。結果として、重複する項目が出てきたり、気づかないまま重要な観点が抜けていたりします。

失敗②　ロジックツリーの「枝の深さ」がバラバラになる

ロジックツリーとは、問題や課題を木の枝のように階層的に分解していく図のことです。根っこが「問題」で、枝が「原因」や「要素」になります。

ただ、書き慣れていないうちは、ある枝は3階層まで掘り下げているのに、別の枝は1階層で止まっていたりします。これだと全体の深さが揃わず、分析の精度にムラが出てしまいます。

失敗③　ツリーを作ったあと「で、どうするか」につながらない

これが一番もったいないパターンです。一生懸命ロジックツリーを作ったけれど、それを会議で見せただけで終わってしまう。「ツリーを作ること」が目的になってしまって、「問題を解決すること」に至っていないケースです。

ツリーはあくまで「考えるための道具」です。道具を磨くことに熱中して、本来の仕事を忘れてしまっては本末転倒なんですよね。

Before / After で見る「構造化思考」の威力

実際の変化を見てもらった方が伝わりやすいと思うので、ひとつ例を出します。

あるプロジェクトで「チームの生産性が上がらない」という問題を上司に報告しなければならなくなったとします。

Before（構造化なし）の報告

これを聞いた上司は「で、根本原因は何なの？」と言いたくなるはずです。

After（MECE＋ロジックツリー活用後）の報告

同じ状況を報告しているのに、受け手の印象はまったく違います。後者は「考えた形跡」が見えるので、上司は安心して次のアクションを任せられるんです。

このAfterの状態を自分でゼロから作れるようになる手順を、ここから全部お見せします。

この記事で得られること

• 実務の問題をMECE→ロジックツリー→解決策導出まで1人で完結させる5ステップの手順

• 自分でロジックの穴に気づける「自己チェック5つの質問」

• コピペして使える穴埋め式ロジックツリーテンプレート

• ロジックツリーの3種類（WHYツリー・WHATツリー・HOWツリー）の使い分け判断基準

• 解決策を絞り込んで上司への報告資料に落とし込む方法

ここまでの内容だけでも「失敗パターンの自覚」は持てます。ただ、本当に差がつくのはこの先——具体的な手を動かす手順とテンプレートです。

実践5ステップ：問題の構造化を完全ウォークスルー

以降では「チームの生産性が上がらない」という実務でよくある問題を題材に、ステップ1から5まで一緒に手を動かしながら進めていきます。

テンプレートはそのままコピーして使えます。自分の問題に当てはめながら読んでみてください。

ステップ1：問題を「1文」で言語化する

最初のステップは、問題をあいまいなまま進めないことです。

「なんとなく生産性が低い気がする」という状態でツリーを書き始めても、途中で方向を見失います。まず問題を1文に絞り込むことが、構造化の出発点になります。

問題言語化テンプレート

【問題文】
「（誰が）（何を）（どのくらい）（いつから）できていない」

記入例：
「開発チーム（5人）が、週次のスプリント目標を
 平均30%の達成率でしか完了できておらず、
 3スプリント連続で継続している」

ポイントは「数字」を入れることです。「遅れている」「低い」のような形容詞だけだと、後で原因を特定しても「それで本当に問題が解決したか」を判断できません。

筆者がPM時代に痛感したのは、問題の言語化があいまいなプロジェクトは、解決策を実施したあとも「改善したのかどうかわからない」状態が続くということです。計測できない問題は、解決できません。

ステップ2：MECE分解——「切り口」を選ぶ

問題が言語化できたら、次は「どんな軸で分解するか」を決めます。

ここで多くの人がつまずくのは、「正解の切り口がわからない」という点です。実は、切り口に唯一の正解はありません。ただ、実務でよく使われる切り口パターンを知っておくと、ゼロから考える手間が大きく省けます。

よく使えるMECE切り口パターン

| 時系列（Before・During・After） | プロセス改善 | リリース遅延、対応ミス | | 内部要因・外部要因 | 原因の整理全般 | 売上低下、顧客離脱 | | 定量・定性 | 分析の切り口整理 | データと感覚の分離 |

今回の「スプリント達成率30%」という問題には「人・プロセス・環境」が合っています。

MECE分解テンプレート（記入用）

【問題】：（ステップ1で作った1文をここに入れる）

【切り口】：（上のパターン表から選ぶ）

【分解結果】：
  ├─ 軸A：（記入）
  ├─ 軸B：（記入）
  └─ 軸C：（記入）

【ダブりチェック】：AとBは重複していないか？ → はい / いいえ
【漏れチェック】：A＋B＋Cで問題全体をカバーできているか？ → はい / いいえ

記入例：

【問題】：開発チームがスプリント目標を平均30%しか達成できていない

【切り口】：人・プロセス・環境

【分解結果】：
  ├─ 人：スキル・知識・モチベーション・工数見積もり精度
  ├─ プロセス：タスク優先順位付けルール・レビューフロー・割り込み対応
  └─ 環境：開発ツール・情報共有の仕組み・作業スペース

【ダブりチェック】：人とプロセスは別軸になっている → はい
【漏れチェック】：3軸でほぼカバーできている → はい

ステップ3：ロジックツリーを展開する——WHY・WHAT・HOWの使い分け

MECE分解で軸が決まったら、各軸をさらに掘り下げていきます。ここで使うのがロジックツリーです。

ロジックツリーには3つの種類があり、問題のフェーズによって使い分けます。

ロジックツリーの種類と使い分け

• WHYツリー（原因追求型）：「なぜ問題が起きているか」を掘り下げる。問題の根本原因を探したいときに使う

• WHATツリー（要素分解型）：「問題はどんな要素で構成されているか」を整理する。問題の全体像を把握したいときに使う

• HOWツリー（解決策検討型）：「どうすれば解決できるか」を展開する。打ち手を考えるときに使う

今回のケースでは、まずWHYツリーで原因を特定してから、HOWツリーで解決策を展開するという順番で進めます。

WHYツリー展開テンプレート（記入用）

【問題】：スプリント達成率30%

　├─【軸A：人】
　│　├─ なぜ？：工数見積もりが毎回2倍以上ずれている
　│　│　├─ なぜ？：見積もり時にタスクの細分化が不十分
　│　│　└─ なぜ？：過去の実績データを参照していない
　│　└─ なぜ？：特定メンバーに作業が集中している
　│　　　└─ なぜ？：タスク分担のルールが属人的になっている
　│
　├─【軸B：プロセス】
　│　├─ なぜ？：レビュー待ちで1〜2日止まるケースが頻発
　│　│　└─ なぜ？：レビュアーのスケジュール確保が任意になっている
　│　└─ なぜ？：スプリント中の割り込みタスクを制限できていない
　│　　　└─ なぜ？：割り込み対応のガイドラインが存在しない
　│
　└─【軸C：環境】
　　　└─ なぜ？：タスク管理ツールに進捗が反映されるのが遅れる
　　　　　└─ なぜ？：更新がメンバーの習慣として定着していない

ここまで書けると、「スプリント達成率30%」という大きな問題が、いくつかの具体的な原因に分解されます。次のステップで、この原因のどれに手を打つかを絞り込みます。

ステップ4：自己チェック5つの質問——ロジックの穴を自分で見つける

ツリーを作ったあと、そのまま上司に見せるのは少し待ってください。まず自分でチェックする習慣をつけると、「で、ここって検討した？」という指摘が激減します。

以下の5つの質問を、ツリーを書き終えたあとに必ず自分に問いかけてください。

自己チェック5つの質問

1. 「この分類、他の誰かに見せたら同じように理解してもらえるか？」 — 自分だけが意味を知っている分類になっていないかを確認します。「対応が遅い」だけでは人によって解釈が変わります。「レビューの返答に24時間以上かかる」のように具体化できているか確認してください

2. 「各枝を全部合わせると、問題全体をカバーできているか？」 — 「人・プロセス・環境」以外に、別の軸はないかを30秒間だけ考えます。「顧客要件の変更」「外部ベンダーの遅延」など外部要因が抜けていないかを確認してください

3. 「一番深く掘り下げた枝と、浅い枝の間に理由はあるか？」 — 深さが不揃いになっているときは、浅い方がまだ掘り下げられる余地があるサインです

4. 「根本原因まで到達しているか、それとも中間の症状で止まっているか？」 — 「見積もりがずれる」は症状です。「なぜずれるか」まで追えているかを確認してください

5. 「このツリーから、具体的なアクションが1つ以上導き出せるか？」 — ツリーを見たとき、「じゃあまず○○をやろう」と言えないなら、もう1段階掘り下げが必要です

この5問に「はい」と答えられれば、ツリーとしての完成度はかなり高い状態です。

ステップ5：解決策の絞り込みと報告資料への落とし込み

原因が特定できたら、HOWツリーで解決策を展開し、打ち手を絞り込みます。全部の原因に同時に対処しようとすると、リソースが分散して効果が出なくなります。「影響が大きくて、すぐ着手できるもの」から優先するのが実務的なアプローチです。

優先度マトリクス（記入用）

　　　　　│　影響大　│　影響小
──────────┼──────────┼──────────
すぐできる │ ★優先1位 │　後回しOK
──────────┼──────────┼──────────
時間がかかる│　計画的に │　やらなくていい

今回の例で「★優先1位」に入るのは「割り込みタスクのガイドライン作成」と「レビュアーのスケジュール確保ルール化」あたりです。どちらも着手コストが低く、効果は即座に出やすいです。

上司への報告フォーマット（コピペして使えます）

【問題の定義】
○○（数字入り）という状態が、○週間継続しています。

【原因の構造化（MECE分解）】
「人・プロセス・環境」の3軸で分析した結果、
主因は以下の2点と判断しています：

  1. プロセス：割り込みタスクの制限ルールがない
  2. プロセス：レビュアーのスケジュール確保が任意

【提案する打ち手】
  ①（具体的なアクション）：担当（名前）・期限（日付）
  ②（具体的なアクション）：担当（名前）・期限（日付）

【期待する効果】
上記2点を実施することで、スプリント達成率を
○週以内に○%以上に改善できると見込んでいます。

このフォーマットで報告すると、上司が「で、根拠は？」と聞きたくなる部分があらかじめ埋まっています。筆者の経験上、このような構成で報告してくる部下には「任せられる」という印象を持ちやすいです。

まとめ：今日から使える5ステップの要点

• ステップ1：問題を「誰が・何を・どのくらい・いつから」の1文に絞る

• ステップ2：切り口パターンから軸を選んでMECE分解し、ダブり・漏れをその場で確認する

• ステップ3：WHY→HOWの順でロジックツリーを展開し、具体的な原因まで掘り下げる

• ステップ4：自己チェック5つの質問でロジックの穴を自分で潰す

• ステップ5：優先度マトリクスで打ち手を絞り、報告フォーマットに落とし込む

完璧なツリーを一発で作ろうとしなくて大丈夫です。最初は粗くていいので、まず書いてみて、自己チェックで直す——この繰り返しが、「使える」状態への最短ルートです。

この記事が役に立ったら

ここまで読んでいただき、ありがとうございます。

「概念はわかるけど使えない」という状態から抜け出すには、一度自分の問題でテンプレートを動かしてみるのが一番の近道です。まずは今週直面している業務課題を1つ選んで、ステップ1の「問題言語化テンプレート」だけでも試してみてください。

この記事が参考になった方は、スキを押していただけると励みになります。論理思考やデジタル活用の実践的な内容を定期的に発信していますので、フォローもぜひお願いします。

「テンプレートを使ってみた」「こういうケースはどう分解すればいい？」など、コメントで気軽に教えていただけると、次の記事のヒントになります。実際に動かして詰まったところがあれば、なるべく一緒に考えたいと思っています。