なぜなぜ分析（5 Whys）でプロジェクト炎上の根本原因を特定する

プロジェクトが炎上したとき、「誰のせいか」を探すミーティングになりがちだ。しかし「誰が悪いか」を特定しても、同じ問題は別のプロジェクトで繰り返される。5 Whys（なぜなぜ分析）は、問題の表面ではなく根本原因にたどり着くための構造的な手法だ。

5 Whysとは

5 Whysはトヨタ生産方式で生まれた問題解決手法だ。問題に対して「なぜ？」を5回繰り返すことで、表面的な現象から根本原因（root cause）にたどり着く。

「5回」は目安であり、3回で根本原因に到達することもあれば、7回必要なこともある。重要なのは「もうそれ以上『なぜ』と聞けない」レベルまで掘り下げることだ。

プロジェクト炎上への5 Whys適用例

事象： 開発フェーズが2週間遅延した

なぜ1： なぜ2週間遅延したのか？ → APIの仕様変更対応に想定以上の時間がかかったから

なぜ2： なぜ想定以上の時間がかかったのか？ → 外部APIの変更内容を事前に把握していなかったから

なぜ3： なぜ把握していなかったのか？ → 外部ベンダーへの仕様変更の確認プロセスがなかったから

なぜ4： なぜ確認プロセスがなかったのか？ → プロジェクト計画時に外部依存リスクを洗い出していなかったから

なぜ5： なぜリスク洗い出しをしていなかったのか？ → プロジェクト開始時のリスク管理プロセスが定義されていなかったから

根本原因： プロジェクト開始時のリスク管理プロセスが組織として定義されていない

この根本原因に対処すれば、同様の問題を別のプロジェクトでも防げる。「APIの変更確認を怠った担当者」を責めても、組織的なリスク管理プロセスのなさという根本原因は解決しない。

「犯人探し」にならないファシリテーション

5 Whysが「犯人探し」になってしまう最も多い原因は、「なぜ」の問いが「誰が」にすり替わることだ。

悪い問い： 「なぜ確認しなかったのか？（担当者が悪い）」 良い問い： 「なぜ確認のための仕組みがなかったのか？（プロセスに問題）」

ファシリテーターとしてのPMは、「なぜ」が人への攻撃になりそうなときに「それはプロセスや環境の問題として言い換えるとどうなりますか？」とリフレームする役割を担う。

ファシリテーション時のルールを事前に共有する：

1. 個人を責めない——問題はプロセスと環境にある
2. 「事実」だけを扱う——推測・感情は一旦置く
3. 「なぜ」は5回以上繰り返す——最初の答えは根本原因ではない

複数の根本原因がある場合：5 Whysツリー

1つの問題に対して「なぜ」の答えが複数ある場合、ツリー状に展開する。

事象：リリース遅延
├─ なぜA：テストが間に合わなかった
│   ├─ なぜA-1：テスト環境の準備が遅れた
│   └─ なぜA-2：テスト担当者が他案件と兼務だった
└─ なぜB：バグ修正に時間がかかった
    ├─ なぜB-1：コードレビューが不十分だった
    └─ なぜB-2：技術負債が多くて修正範囲が広かった

各ブランチで「なぜ」を繰り返すことで、「テスト環境のリードタイム管理」「兼務調整プロセス」「コードレビュー文化」「技術負債対策」という複数の根本原因が特定できる。

根本原因への対処アクション

5 Whysで根本原因を特定した後、必ず対処アクションを決めることが重要だ。根本原因を特定して終わりにしてしまうと、分析は「振り返りの儀式」になって終わる。

アクション設計の原則：

• 担当者を決める（「誰かが」ではなく「〇〇が」）
• 期日を決める
• 完了基準を決める（何をもって対処完了とするか）

根本原因：プロジェクト開始時のリスク管理プロセスが定義されていない

対処アクション：
- 担当者：PMリード（山田）
- 内容：プロジェクト開始チェックリストに「外部依存リスク洗い出し」を追加
- 期日：2週間後
- 完了基準：チェックリストv2.0を作成し、次プロジェクトで適用する

まとめ

5 Whysは構造がシンプルなだけに、「正しく使う」ファシリテーション力が問われる手法だ。個人攻撃を避けてプロセス・環境にフォーカスすること、根本原因からアクションへ確実につなげること——この2点を押さえるだけで、炎上後の振り返りが組織の学習機会に変わる。