5 Whys 根本原因分析
概要
5 Whys 根本原因分析は、問題の記述から始め、順に「なぜ？」と5回問いかける構造化された問題解決手法です。各回答が次の問いの対象となります。目的は症状を超えて、実際に対処できるプロセスやシステムの不具合（根本原因）を特定することです。
利用者
製品およびエンジニアリングチーム
運用および DevOps チーム
カスタマーサポートおよびサービスチーム
プロジェクトマネージャー
品質保証チーム
再発する課題やインシデントを調査する人
使用方法
明確な問題の記述を作成する — 何が起きたか、いつ起きたか、どのような影響があったか。
「なぜこのようなことが起きたのか？」と尋ねる、回答を記録する（回答 1）。
「なぜ回答 1 は発生したのか？」と尋ねる、回答を記録する（回答 2）。
回答 3、4、5 についても繰り返す。
プロセスやシステムの変更で対処できる原因に到達したら中止する — これが根本原因です。
是正措置を定義する：各アクションに所有者と期日を割り当てる。
ヒント：良い根本原因は人ではなくプロセスやシステムを指します。もし回答が人名なら、もう一度「なぜ？」と尋ねてください。
例
問題の記述：チェックアウトページが 8 月 12 日に約 3 時間ダウンしました — 約 $18,000 の受注損失と 40 件以上のサポートチケットが発生しました。（プラットフォームチームが 8 月 13 日に調査）
なぜ 1：決済サーバーのメモリが枯渇してクラッシュした。
なぜ 2：決済サービスにメモリリークがある。
なぜ 3：8 月 8 日のリリースが古いデータベース接続を閉じていない。
なぜ 4：リリースは本番公開前に負荷テストを実施していなかった。
なぜ 5：リリースのチェックリストにパフォーマンステストの項目がない。
根本原因：リリースプロセスに必須の負荷／性能テストが組み込まれていない。
是正アクション：
CI パイプラインに自動化された負荷テストを追加する（DevOps リード、8 月 30 日）
メモリ使用率が 80% に達したらアラートを設定する（SRE チーム、8 月 22 日）
リリースのチェックリストを更新し、チームにトレーニングを行う（エンジニアリングマネージャー、8 月 20 日）
よろしくお願いします！
カワジャ・リズワン
