5つのWhyによる根本原因分析チュートリアル¶

1. 5つのWhyとは何か¶

5つのWhyとは、問題の原因と結果の連鎖を体系的に探る根本原因分析（RCA）の技法であり、表面的な症状ではなく、繰り返し「なぜ？」と問いかけながら根本原因を明らかにするシンプルかつ強力な方法です。

この手法は、トヨタ自動車の創業者である豊田佐吉によって開発され、トヨタ生産方式によって採用・推進されました。その基本的な考え方は、多くの問題の根本は明白ではなく、何層もの問いかけによって明らかにしなければならないということです。

5つのWhyを使用する主な目的は以下の通りです：

5つのWhyの実施には、通常以下のステップがあります：

最初の質問：定義した問題に対して最初の「なぜ？」を投げかける。
- 問題：「今週ウェブサイトが3回ダウンした。」
- 質問：「なぜウェブサイトはダウンしたのか？」
- 回答：「データベースサーバーが過負荷だったから。」

繰り返しの質問：前の回答をもとに「なぜ？」を継続する。このプロセスを、さらに合理的に問いかけられない根本原因が見つかるまで繰り返す。一般的に5回の「なぜ」で根本原因に到達できるが、これは厳密なルールではなく、5回より少ない場合や多い場合もあります。
- 2回目の質問：「なぜデータベースサーバーは過負荷だったのか？」
  - 回答：「新しくリリースされたクエリ機能が多くのリソースを消費したから。」
- 3回目の質問：「なぜそのクエリ機能は多くのリソースを消費したのか？」
  - 回答：「フルテーブルスキャンを行い、インデックスを使用しなかったから。」
- 4回目の質問：「なぜインデックスを使わなかったのか？」
  - 回答：「設計時に開発者が関連するフィールドにインデックスを作成しなかったから。」
- 5回目の質問：「なぜ開発者はインデックスを作らなかったのか？」
  - 回答：「私たちのコードレビュー・チェックリストにデータベースのパフォーマンス最適化の確認項目が含まれていなかったため、この問題を見落としてしまった。」

根本原因の特定：上記の例では、根本原因は「コードレビューのプロセスにデータベースのパフォーマンスチェック手順が欠けていたこと」と特定できます。
対策の立案：具体的で実行可能な根本原因に対する解決策を考案します。例えば、「チームのコードレビュー・チェックリストを更新し、すべてのデータベースクエリに対してパフォーマンス評価とインデックスの確認を義務付ける。」

問題の記述
新製品のローンチが2週間遅れた。

1. なぜ遅れたのか？
> 最終の品質保証（QA）テストに失敗したから。

2. なぜQAテストに失敗したのか？
> コア機能モジュールに重大なバグがあったから。

3. なぜそのモジュールにバグがあったのか？
> 開発チームが新旧コードの統合時にコンフリクトが起きたから。

4. なぜ統合時にコンフリクトが起きたのか？
> モジュールを担当した2人のエンジニアが十分な連携を取らなかったから。

5. なぜ十分な連携が取られなかったのか？
> プロジェクト管理プロセスで必須の横断的コミュニケーションポイントが確立されていなかったから。

根本原因と対策
根本原因：プロジェクト管理プロセスに重要なコミュニケーションメカニズムが欠けていた。
対策：プロジェクト管理プロセスに「クロステック技術設計レビュー会議」を追加し、開発前に統合ポイントについて十分な議論を確保する。

客観的に保つ：個人を責めるのではなく、プロセスやシステムに焦点を当てる。
事実とデータに基づく：「なぜ」に答える際は、できるだけ検証可能な事実に基づき、主観的な仮定に頼らないようにする。
論理の連鎖を厳密に保つ：各「なぜ」の回答は、直前の質問に直接つながる必要がある。
やめるタイミングを知る：プロセス、行動、またはシステムレベルの根本原因に到達したら、通常は停止できる。さらに問いかけた結果がコントロール不能な回答（例：「人間の性だから」など）になる場合は、適切な停止点に達したと考えられる。

5つのWhyを効果的に活用することで、チームは問題を体系的に解決し、組織のプロセスにおける継続的な改善を推進することができます。