なぜなぜ分析（5 Whys）で本当の原因を見つける
はじめに
- バグを修正したはずなのに、似たような問題がまた発生する
- 障害対応をしたのに、数週間後に同じようなインシデントが起きる
- 「原因は分かった」と思っても、実は症状しか見ていなかった
そんな経験はないでしょうか。
開発現場では「問題を直す」ことに意識が向きがちですが、本当に重要なのは「なぜその問題が起きたのか」を深掘りすることです。
そのために役立つのが、トヨタ生産方式でも使われている 5 Whys（なぜなぜ分析） です。
単純ですが非常に強力で、障害分析・品質改善・振り返りなど、ソフトウェア開発とも相性が良い考え方です。
1. 5 Whys（なぜなぜ分析）とは？
- 問題に対して「なぜ？」を繰り返し問い続けることで、根本原因を見つける分析手法
- 表面的な現象ではなく、背後にある「仕組み」や「プロセス」の問題を明らかにする
- 一般的には5回程度「なぜ」を繰り返すことで本質に近づけると言われている
ポイント
- 「誰が悪いか」ではなく「なぜ防げなかったか」を考える
- 個人のミスで終わらせず、再発防止につながる仕組み改善へ繋げる
- バグ修正よりも“同じ問題を繰り返さない”ことを目的にする
2. なぜ開発で重要なのか？
同じ種類の障害を繰り返さなくなる
- 一時的な修正だけでは、似た問題が別の場所で再発する
- 根本原因まで辿ることで、構造的な改善ができる
チームの品質改善につながる
- コーディングルール
- レビュー体制
- テスト不足
- ドキュメント不足
など、開発プロセス全体の問題が見えてくる
属人化を減らせる
「〇〇さんしか分からない」 「たまたま気付けなかった」
ではなく、
- なぜ誰でも気付けなかったのか？
- なぜ仕組みで防げなかったのか？
を考えるようになる
3. 実際の例（障害対応）
問題
本番デプロイ後、サービスが2時間停止した
| 段階 | なぜ？ | 回答 |
|---|---|---|
| Why 1 | なぜサービス停止した？ | デプロイスクリプトが途中で失敗した |
| Why 2 | なぜ失敗した？ | 本番環境に必要な環境変数が存在しなかった |
| Why 3 | なぜ環境変数が無かった？ | ローカルだけ追加されCI/CDへ反映されていなかった |
| Why 4 | なぜCI/CDへ反映漏れした？ | 追加時の確認手順が存在しなかった |
| Why 5 | なぜ確認手順が無い？ | デプロイチェックリスト自体が整備されていなかった |
根本原因
- 環境変数漏れではなく
- 「デプロイ前確認プロセスが存在しない」ことが問題だった
対策
- デプロイチェックリスト作成
- CI/CDで環境変数差分チェック
- Pull Requestテンプレートへ確認項目追加
4. Salesforce開発での例
問題
Trigger実行時にGovernor Limit Errorが発生した
| 段階 | なぜ？ | 回答 |
|---|---|---|
| Why 1 | なぜGovernor Limitが発生した？ | forループ内でSOQLを実行していた |
| Why 2 | なぜループ内にSOQLを書いた？ | Bulk化の知識不足だった |
| Why 3 | なぜ知識不足だった？ | Apex開発ガイドが存在しなかった |
| Why 4 | なぜガイドが存在しない？ | 標準化担当が決まっていなかった |
| Why 5 | なぜ担当が決まっていない？ | コードレビュー文化が弱かった |
根本原因
- SOQLの書き方ではなく
- 「知識共有とレビュー文化不足」が本質だった
対策
- Apexベストプラクティス整備
- レビュー観点の明文化
- Bulkificationチェック追加
5. よくある失敗
Why 2〜3で止めてしまう
悪い例
- 「SOQLがforループ内にあった」
- 「環境変数が漏れていた」
これはまだ“現象”であり、本質ではないことが多い
人を原因にしてしまう
悪い例
- 「担当者が確認不足だった」
- 「レビューアが見落とした」
個人ミスで終わらせると、同じ問題はまた発生する
重要なのは、
- なぜ見落とせたのか？
- なぜ仕組みで防げなかったのか？
を考えること
対策を作らず終わる
分析だけして満足してしまうケースも多い
5 Whysは「原因を探すこと」が目的ではなく、
- 再発防止
- 品質改善
- 開発効率改善
まで実施して初めて意味がある
6. 実は開発以外でも使える
振り返り（Retrospective）
- なぜスプリント遅延した？
- なぜ見積もりがズレた？
- なぜレビュー待ちが発生した？
問い合わせ分析
- なぜ同じ問い合わせが増えている？
- なぜユーザーが迷う？
- なぜ操作ミスが起きる？
チーム改善
- なぜ情報共有されない？
- なぜ属人化する？
- なぜレビュー負荷が偏る？
技術だけでなく、チーム運営にも非常に有効
7. 5 Whysを強くするコツ
問題を具体的に書く
悪い例：
- 「システム障害が起きた」
良い例：
- 「2026/05/01の本番リリース後、認証APIが500エラーを返した」
複数人で実施する
1人だけで分析すると視点が偏る
- 開発者
- レビューア
- QA
- 運用担当
など複数視点が重要
“事実”で話す
推測ではなく、
- ログ
- PR
- 監視結果
- タイムライン
など客観的事実を元に分析する
8. まとめ
- 5 Whysは「表面的な症状」ではなく「根本原因」を見つけるための手法
- ソフトウェア開発では障害分析・品質改善・振り返りと非常に相性が良い
- 重要なのは「誰が悪いか」ではなく「なぜ防げなかったか」
- 本当の改善は、コード修正ではなく“仕組み改善”にある
- 小さな問題でも繰り返し実践すると、チーム全体の品質文化が変わっていく
最後に
次に障害やバグが発生した時、
「どう直すか」だけでなく、
「なぜ起きたのか？」
を少し深く考えてみるだけでも、開発の見え方はかなり変わります。
