フレームワーク活用ガイドひとことで言うと#
問題に対して**「なぜ？」を5回繰り返すことで、表面的な症状の奥にある根本原因（Root Cause）** にたどり着く手法。トヨタ生産方式から生まれた、シンプルだけど強力な問題解決ツール。
押さえておきたい用語#
- 根本原因（Root Cause）
- 問題を引き起こしている最も深い構造的な原因のこと。ここを解消すれば同じ問題が再発しなくなる。
- 対症療法（Symptomatic Treatment）
- 表面的な症状だけを一時的に抑える対応のこと。根本原因に手を打たないため同じ問題が繰り返し発生する。
- 仕組み化（Systemization）
- 個人の注意や努力に頼らず、プロセスや構造を変えることで再発を防ぐ手法のこと。なぜなぜ分析の最終ゴールにあたる。
- 事実ベース（Fact-Based）
- 推測や憶測ではなく実際に起きた事実を根拠に分析を進める原則のこと。なぜなぜ分析の精度を決める最重要ルール。
- トリガー条件（Trigger Condition）
- 問題が発生する特定の状況や前提条件のこと。「いつでも起きるのか、特定の条件下でだけ起きるのか」を切り分けることで、分析の精度が上がる。
- 是正処置（Corrective Action）
- 発見された根本原因に対して講じる再発を防ぐための具体的な対策のこと。対症療法とは異なり、問題の構造そのものを変える。
- 連鎖分析（Chain Analysis）
- 原因と結果を一本の因果連鎖としてつなげて深掘りしていくアプローチのこと。なぜなぜ分析の基本的な思考の型。
なぜなぜ分析の全体像#
こんな悩みに効く#
- 同じトラブルが何度も繰り返されて、いつもモグラ叩き状態
- 問題が起きたとき、目に見える原因だけ潰して「対応済み」にしてしまう
- 「なぜそうなったの？」と聞かれると、答えに詰まる
基本の使い方#
まず「何が問題か」を事実ベースで明確にする。曖昧な表現は避ける。
- ❌ 「最近、お客さんの満足度が低い」
- ✅ 「今月のNPSスコアが先月比で15ポイント下がった」
問題の定義が曖昧だと、「なぜ？」の方向がブレてしまう。
実践のコツ: 問題定義の段階で「いつから」「どのくらい」「どこで」を必ず含めること。たとえば「納品ミスが多い」ではなく「2025年12月の東京倉庫からの出荷で、納品ミスが47件発生（前月比+32件）」のように書く。数字と固有名詞が入ると、分析の方向がブレにくくなる。また、問題を1文で言い切れないときは、まだ絞り込みが足りないサインだと考えよう。
定義した問題に対して、「なぜそうなったのか？」を問い続ける。
5回はあくまで目安。3回で根本原因に着くこともあれば、7回必要なこともある。「これ以上なぜと聞いても、自分たちではコントロールできない領域に入る」と感じたら、そこが根本原因。
各回答は事実に基づくこと。推測や憶測で進めると、見当違いの結論にたどり着いてしまう。
実践のコツ: 各「なぜ？」の回答を書いたら、逆方向に読み返してみる。「（なぜ5の回答）だから（なぜ4の回答）が起き、だから（なぜ3の回答）が起き……だから（問題）が発生した」とスムーズにつながるか確認する。途中でロジックが飛躍していたら、間にステップが抜けている証拠。この「逆読みチェック」を挟むだけで、分析精度が格段に上がる。
見つかった根本原因に対して、再発を防ぐ対策を考える。
対策のポイント：
- 「気をつける」「意識する」は対策ではない
- 仕組みや構造を変えることで再発を防ぐ
- 「この対策を実行したら、本当にこの問題は起きなくなるか？」と検証する
実践のコツ: 対策を考えたら「この対策は、担当者が異動しても機能するか？」と自問する。答えがNoなら、まだ属人的な対策に留まっている。チェックリスト、承認フロー、システムによる自動検知など、人が変わっても同じように動く仕組みにまで落とし込んで初めて「対策完了」と言える。
具体例#
問題: 月間チャーンレートが先月の2.1%から今月4.8%に急上昇
なぜ1: なぜ解約が増えた？ → 「使いにくくなった」という声が解約アンケートの68%を占めた
なぜ2: なぜ使いにくくなった？ → 先月のUI大幅リニューアルで操作方法が変わった
なぜ3: なぜUIリニューアルで使いにくくなった？ → 既存ユーザーへの事前告知・移行ガイドがなかった
なぜ4: なぜ事前告知がなかった？ → リリーススケジュールが押して、告知の準備時間がなくなった
なぜ5: なぜスケジュールが押した？ → リリース計画に「ユーザーコミュニケーション」のタスクが含まれておらず、開発完了＝リリースになっていた
根本原因: リリースプロセスに「ユーザーコミュニケーション」工程が組み込まれていない
対策:
| 対策 | 内容 |
|---|---|
| リリースチェックリストに追加 | 「事前告知・移行ガイド作成」を必須タスク化 |
| リリース承認フロー変更 | CSチームの承認なしにはUI変更をリリースできない仕組み |
| 段階リリース導入 | 全ユーザーに一斉適用ではなく、10%→50%→100%と段階的に展開 |
対策実施後、翌月のチャーンレートは1.8%まで回復。「UIの問題」ではなく「リリースプロセスの問題」だったことが根本原因だった。
問題: 月間出荷12,000件に対して誤出荷が30件（誤出荷率0.25%）。目標は0.05%以下。
なぜ1: なぜ誤出荷が起きた？ → ピッキング時に間違った商品を取った（30件中22件がピッキングミス）
なぜ2: なぜ間違った商品を取った？ → 似た型番の商品が隣り合った棚に配置されていた
なぜ3: なぜ似た商品が隣り合っている？ → 棚の配置ルールが「入荷順」になっており、商品の類似性を考慮していない
なぜ4: なぜ類似性を考慮していない？ → 棚配置のルールが倉庫立ち上げ時（3年前）のまま更新されておらず、SKUが5倍に増えた現状に合っていない
根本原因: 棚配置ルールがSKU数の増加に追随して更新される仕組みがない
対策:
| 対策 | 内容 | 効果 |
|---|---|---|
| 類似品分離ルール | 型番が似た商品は最低3棚以上離す | ピッキングミス60%減 |
| カラーラベル導入 | 商品カテゴリごとに棚にカラーラベル | 視認性向上 |
| 四半期レビュー | SKU変動に応じて棚配置を四半期ごとに見直す仕組み | 継続的に最適化 |
3か月後、誤出荷は月30件→月5件（0.04%）に改善。「注意力不足」ではなく「棚配置の仕組み」が根本原因だった。
問題: 月間PVが3か月前の45,000から今月28,000に下落（38%減）
なぜ1: なぜPVが減った？ → Google検索からの流入が42,000→24,000に減少（オーガニック流入が主因）
なぜ2: なぜ検索流入が減った？ → 上位表示されていた記事10本のうち7本が順位下落（1〜3位→8〜15位）
なぜ3: なぜ順位が下落した？ → Googleのコアアップデート後に下がった。競合サイトがより専門性の高い記事を公開していた
なぜ4: なぜ競合に専門性で負けた？ → 自分の記事は2年前に書いたまま更新しておらず、データや事例が古くなっていた
なぜ5: なぜ記事を更新していなかった？ → 「新記事を書くこと」だけをタスク管理しており、既存記事の更新をする仕組みがなかった
根本原因: 既存記事のメンテナンスサイクルが存在しない
対策:
| 対策 | 内容 |
|---|---|
| 記事メンテカレンダー | 上位30記事を6か月サイクルでリライト対象にスケジュール化 |
| PVアラート | 月間PVが20%以上下落した記事を自動通知する仕組み |
| 週の作業配分変更 | 新記事:リライト = 3:2の割合に変更 |
対策後2か月で、リライトした7記事のうち5記事が順位回復（平均+6.2位）。月間PVは36,000まで回復。「Googleアルゴリズムのせい」ではなく「メンテナンス仕組みの欠如」が真因だった。
問題: 社内ITヘルプデスクの一次回答時間が、3か月前の平均45分から平均4時間に悪化。SLA（2時間以内）違反率が62%に到達。
なぜ1: なぜ一次回答が遅い？ → 問い合わせの42%が「対応優先度の判断待ち」で滞留していた
なぜ2: なぜ優先度の判断に時間がかかる？ → 優先度判断がリーダー1名に集中しており、リーダー不在時（会議・休暇）に滞留する
なぜ3: なぜリーダー1名に集中している？ → 優先度の判断基準が明文化されておらず、「経験と感覚」で判断していた
なぜ4: なぜ判断基準が明文化されていない？ → ヘルプデスク立ち上げ時にリーダーが1人で運用を始め、チームが5名に拡大した後も判断プロセスが更新されなかった
根本原因: 問い合わせの優先度判断プロセスが属人化したまま、チーム拡大に対応していない
Before → After:
| 指標 | 対策前 | 対策後（2か月） |
|---|---|---|
| 平均一次回答時間 | 4時間 | 38分 |
| SLA違反率 | 62% | 4% |
| リーダーの判断待ち件数/日 | 18件 | 2件（例外のみ） |
対策:
| 対策 | 内容 |
|---|---|
| 優先度マトリクス作成 | 「影響範囲×緊急度」の2軸で4段階を定義、フローチャート化 |
| 自動振り分けルール | チケットシステムにキーワードベースの自動優先度設定を導入 |
| 権限委譲 | メンバー全員がレベル1〜3の優先度判断を行えるよう研修実施 |
「リーダーが忙しいから」ではなく「判断プロセスの属人化」が真因。仕組みを整えたことで、リーダー不在でもSLAを守れる体制に変わった。
問題: 直近6か月のエンジニア採用で、内定を出した19名中11名が辞退（辞退率58%）。目標は25%以下。
なぜ1: なぜ内定辞退が多い？ → 辞退者へのヒアリングで「他社のオファーの方が条件が良かった」が9名（82%）
なぜ2: なぜ他社に条件面で負けた？ → 内定通知から承諾期限までの間に、候補者が他社の最終面接を受けて比較されていた
なぜ3: なぜ内定後に他社と比較される期間が生まれた？ → 自社の選考が平均28日かかっており、候補者の就活タイムラインの後半でようやく内定が出ていた
なぜ4: なぜ選考に28日もかかる？ → 技術面接の日程調整に平均9日、役員面接の調整に平均7日かかっていた
なぜ5: なぜ日程調整に時間がかかる？ → 面接官のカレンダーを個別にメールで確認する運用で、面接枠の事前確保がなかった
根本原因: 面接官の面接枠が事前に確保されておらず、都度の日程調整がボトルネックになっている
Before → After:
| 指標 | 対策前 | 対策後（3か月） |
|---|---|---|
| 平均選考日数 | 28日 | 12日 |
| 内定辞退率 | 58% | 21% |
| 面接日程調整の平均所要日数 | 9日（技術）/ 7日（役員） | 2日 / 2日 |
対策:
| 対策 | 内容 |
|---|---|
| 面接枠の事前ブロック | 技術面接官は週2枠、役員は週1枠をカレンダーに固定確保 |
| カレンダー連携ツール導入 | 候補者がリアルタイムで空き枠を確認・予約できる仕組み |
| 選考ステップ圧縮 | 技術面接と人物面接を同日実施に変更（所要時間2時間→3時間に延長） |
「年収が低いから」ではなく「選考スピードの遅さ」が真因。選考期間を半分以下に圧縮したことで、候補者が他社と比較する前にオファーを届けられるようになった。
やりがちな失敗パターン#
- 「人のせい」で止まってしまう — 「なぜ？」→「担当者がミスしたから」で終わると何も解決しない。「なぜミスが起きる仕組みになっていたか？」とシステムの問題に目を向ける
- 「なぜ？」を横に広げてしまう — 一つの「なぜ？」に対して複数の原因が出た場合、すべてを追いかけると発散する。最も影響が大きそうなものを一つ選んで深掘りする
- 5回を機械的にこなす — 「5回やればいい」のではなく、根本原因にたどり着いたかどうかが大事。3回で見つかったなら3回でいい
- 対策が「気をつける」「注意する」になる — それは対策ではなく精神論。プロセス変更・チェックリスト・自動化など、仕組みとして再発を防げる対策を必ず考える。「人が変わっても同じ対策が機能するか？」が判断基準
応用テクニック#
なぜなぜ + 対策マトリクス#
なぜなぜ分析で根本原因を特定した後、対策の「効果」と「実現しやすさ」を2軸でマッピングする手法。根本原因が見つかっても、対策が現実的でなければ意味がない。
やり方はシンプルで、考えられる対策を洗い出したら、「効果：大／小」「実現コスト：高／低」の4象限に配置する。優先すべきは「効果が大きく、コストが低い」象限の施策から。これにより「正しい原因に、正しい優先順位で手を打つ」ことができる。
たとえば物流センターの誤出荷の例なら、「倉庫管理システムの全面刷新」は効果大だがコストも高い。一方「カラーラベル導入」は効果中でコストが極めて低い。まずラベルを導入してミスを減らしながら、並行してシステム刷新を検討する、というロードマップが描ける。
チームでの合意形成への活用#
なぜなぜ分析は、チームメンバーの「問題認識のズレ」を可視化するツールとしても使える。
会議で問題が発生したとき、メンバーそれぞれが「なぜ？」に対する答えを付箋に書き出し、ホワイトボードに貼る。すると「Aさんは人の問題だと思っている」「Bさんはプロセスの問題だと思っている」というズレが一目でわかる。
ここから最もデータの裏付けがある回答を選び、次の「なぜ？」に進む。このプロセスを経ると、対策が「チーム全員の合意に基づくもの」になるため、実行段階での抵抗が格段に減る。週次のふりかえりミーティングに15分の「なぜなぜタイム」を設けているチームでは、問題の再発率が平均40%下がったという報告もある。
予防的なぜなぜ#
通常のなぜなぜ分析は「すでに起きた問題」を分析するが、予防的なぜなぜは「まだ起きていないが、起きたら大きな影響がある問題」に適用する。
やり方は「もし〇〇が起きたとしたら、なぜそうなるか？」と仮定から始めること。新規プロジェクトの開始前や、大規模なシステム変更の前に行うと効果的。
たとえば新しいECサイトのローンチ前に「もし注文処理の遅延が発生したとしたら」と仮定し、なぜなぜで掘り下げる。「在庫データの同期遅延→バッチ処理が1日1回→リアルタイム連携になっていない→設計時に想定した注文数が現在の見込みと乖離」という形で、ローンチ前に構造的なリスクを洗い出せる。事後に火消しするよりも、事前に構造を直す方がはるかにコストが低い。
他のフレームワークとの使い分け#
なぜなぜ分析と混同されやすいフレームワークを整理する。どれも「原因を特定する」目的は共通だが、アプローチと得意領域が異なる。
| 項目 | なぜなぜ分析 | 特性要因図（魚の骨） | FTA（故障の木解析） | RCA（根本原因分析） |
|---|---|---|---|---|
| アプローチ | 1本の因果連鎖を深掘り | 原因を分類・網羅的に洗い出す | 故障の発生経路を論理ゲートで図示 | 複数手法を組み合わせて原因を体系的に特定 |
| 得意な場面 | 原因が1本の線でたどれる問題 | 原因の全体像を俯瞰したいとき | 安全性・信頼性が求められるシステム障害 | 複合的で大規模な問題 |
| 所要時間 | 15〜30分 | 30分〜1時間 | 数時間〜数日 | 数日〜数週間 |
| 難易度 | 低（1人でもできる） | 中（チームで実施が理想） | 高（専門知識が必要） | 高（プロジェクトとして実施） |
| 向いている規模 | 個別の問題・日常のトラブル | チームレベルの品質改善 | 製造・インフラ・航空など重大障害 | 組織横断の重大インシデント |
| 弱点 | 複数原因が絡む問題には不向き | 深掘りが浅くなりがち | 準備と分析に時間がかかる | コストと工数が大きい |
使い分けの目安: まず、なぜなぜ分析で素早く仮説を立てる。原因が複数ありそうなら特性要因図で洗い出してから深掘り。安全性に関わる重大事象ならFTA、組織レベルの複合問題ならRCAに切り替える。
よくある質問#
Q1. 「なぜ？」は本当に5回でなければダメですか？
5回は目安であり、ルールではない。大野耐一氏が「5回くらい繰り返せば大体たどり着く」と経験則で語ったのが由来。実際には3回で根本原因に着くこともあれば、7回必要なこともある。判断基準は「これ以上掘り下げても、自分たちがコントロールできない領域に入るかどうか」。たとえば「景気が悪い」「法律が変わった」のような外部環境に到達したら、その一つ手前が実質的な根本原因になる。
Q2. なぜなぜ分析を1人でやるのとチームでやるのと、どちらがいいですか？
問題の規模による。日常的な小さいトラブル（例：タスクの締切超過）は1人で15分で十分。チームに影響がある問題（例：顧客クレーム、システム障害）は関係者を集めてやった方が、見落としが減る。チームでやるときは「事実ベース」のルールを最初に確認すること。感想や推測が混ざると議論が発散する。
Q3. 「なぜ？」に対して原因が複数出てきたら、どう選べばいいですか？
データで裏付けられるものを優先する。たとえば「なぜ売上が下がった？」に対して「価格が高い」「認知度が低い」の2つが出たら、実際のデータ（解約アンケート、流入経路分析など）を見て影響度が大きい方を選ぶ。データがない場合は、関係者の投票で「最も影響が大きそうなもの」を1つ選び、それが外れだったら戻ってもう一方を追う。全部を同時に追いかけると分析が発散して何も解決しない。
Q4. 対策を打ったのに同じ問題が再発しました。何が間違っていますか？
よくあるのは「根本原因まで掘り切れていなかった」ケース。対策が対症療法になっていないか振り返る。チェックポイントは3つ。(1) 対策は「仕組み」を変えているか（「気をつける」「周知する」は対策ではない）。(2) 「逆読みチェック」で因果の連鎖が論理的につながっているか。(3) 根本原因は「自分たちがコントロールできる領域」にあるか。この3つのどれかが欠けていると、対策の効果が持続しない。
Q5. なぜなぜ分析を組織に定着させるコツはありますか？
最も効果的なのは「小さな成功体験を見せる」こと。まず1つの具体的な問題でなぜなぜ分析を実施し、対策の前後でどれだけ数字が改善したかを共有する。「月30件あった誤出荷が5件になった」のようなBefore/Afterがあると、手法への信頼が一気に高まる。形式を押し付けるより、成果を見せて「自分の業務でもやってみたい」と思わせる方が定着が速い。週次のふりかえりに5分だけ「ミニなぜなぜ」を入れるところから始めるのも有効。
実践チェックリスト#
なぜなぜ分析を実施した後、以下の5項目で自己検証してみよう。
- 問題定義に数値・期間・場所が含まれているか（曖昧な表現になっていないか）
- 各「なぜ？」の回答が事実・データに基づいているか（推測や感想が混ざっていないか）
- 因果の連鎖を逆読みしてロジックがつながるか（途中で飛躍していないか）
- 対策が仕組みの変更になっているか（「気をつける」「注意する」になっていないか）
- 根本原因は自分たちがコントロール可能な領域にあるか（外部環境のせいにしていないか）
まとめ#
なぜなぜ分析は、問題の「モグラ叩き」を卒業するための思考法。「なぜ？」を繰り返すだけというシンプルさが魅力だが、事実に基づいて掘り下げる誠実さが求められる。次に何かトラブルが起きたら、すぐに対策を打つ前に「なぜ？」を5回自分に問いかけてみよう。