フレームワーク活用ガイドひとことで言うと#
従来の「なぜ」を5回繰り返す手法に、分岐探索・証拠検証・アクションプランを加えた進化版。オリジナルの5Whyは直線的で主観に偏りやすいという弱点がある。5Why+は「なぜ」で深掘りしつつ、分岐点で複数の原因を検討し、データで裏付けを取ることで、より正確に真因にたどり着く。
押さえておきたい用語#
- 真因（Root Cause）
- 問題を引き起こしている根本的な原因のこと。表面的な原因（症状）ではなく、それを取り除けば問題が再発しなくなるレベルの原因を指す。
- 分岐探索（Branching）
- 「なぜ」の各段階で複数の仮説を並列に出すこと。従来の5Whyが直線的に1つの原因だけを追うのに対し、5Why+の最大の特徴。
- 証拠検証（Evidence Check）
- 各段階の仮説をデータやログで裏付けてから次に進むこと。主観的な決めつけを防ぐ。
- 対策の3層（Three Layers of Countermeasures）
- 即時対策・暫定対策・根本対策の3段階のこと。真因が見つかった後、短期〜長期で段階的に手を打つ。
- システム原因
- 個人のミスではなく、仕組みや構造の欠陥のこと。5Why+では「人のせい」で止めず、必ずシステム原因まで掘る。
5Why+の全体像#
こんな悩みに効く#
- 5Whyをやっても「人のせい」「気合が足りない」で終わってしまう
- 原因分析が主観的で、毎回違う人が違う結論に至る
- 根本原因を特定したつもりが、同じ問題が再発する
基本の使い方#
「何が、いつ、どこで、どのくらい」起きたかを事実ベースで記述する。
- NG: 「お客さんが怒っている」（曖昧）
- OK: 「3月5日、A社の田中さんから、注文した商品が届かないとクレームが入った。注文日は2月28日、通常の配送期間は3営業日」
問題定義が曖昧だと、「なぜ」の方向がブレる。最初の定義に時間をかけることが最終的な精度を決める。
従来の5Whyとの違いは、各段階で複数の原因候補を出すこと。
問題: 注文した商品が届かなかった
Why 1: なぜ届かなかった？
- 仮説A: 配送業者が誤配した
- 仮説B: そもそも出荷されていなかった
- 仮説C: 住所が間違っていた
検証: 出荷ログを確認 → 出荷されていなかった（仮説B）
Why 2: なぜ出荷されなかった？
- 仮説A: 受注データが倉庫に連携されなかった
- 仮説B: 在庫切れだった
- 仮説C: 出荷担当者が見落とした
検証: システムログ確認 → 受注データは連携されていた。在庫も十分あった。出荷リストにはあるが未処理（仮説C）
各段階で「仮説→検証」を行うことで、主観的な決めつけを防ぐ。
5Whyの最大の落とし穴は「担当者のミス」で止まること。もう一段深く掘る。
Why 3: なぜ出荷担当者が見落とした？
- 仮説A: 出荷リストが見づらい
- 仮説B: その日の出荷件数が通常の2倍だった
- 仮説C: 担当者が新人だった
検証: その日の出荷件数は通常の1.8倍。担当者は2ヶ月目の新人。リストはExcel管理で未処理の強調表示なし。
Why 4: なぜ出荷件数が増えたときに見落としが起きるシステムになっている？
- 出荷リストに「未処理」のアラートがない
- ダブルチェックの仕組みがない
- 繁忙期の応援体制が未整備
「人のミス」で止めず「なぜミスが起きるシステムになっているか」まで掘る。
特定した根本原因に対して、再発防止策を設計する。
根本原因: 出荷管理がExcelベースで、未処理アイテムのアラートやダブルチェックがない
アクションプラン:
| 対策 | 種類 | 期限 | 担当 |
|---|---|---|---|
| 出荷リストに未処理アラートを追加 | 仕組み化 | 今週中 | システム担当 |
| 出荷件数が1.5倍を超えたら応援者を配置するルール | プロセス | 今月中 | 倉庫リーダー |
| 出荷管理システムの導入検討 | 根本対策 | 来月までに判断 | 業務改善チーム |
対策の3層:
- 即時対策: 今すぐ被害を止める（A社に謝罪と再配送）
- 暫定対策: 同じ問題を防ぐ応急処置（アラート追加）
- 根本対策: システムレベルで再発を防ぐ（管理システム導入）
具体例#
問題定義: 3月3日14時〜16時、Webアプリのレスポンスタイムが通常200msから3,000msに悪化。影響ユーザー数約2,000人。
5Why+の実施:
| 段階 | なぜ？ | 仮説 | 検証結果 |
|---|---|---|---|
| Why 1 | なぜレスポンスが遅くなった？ | A: DBが遅い B: APIサーバーの負荷 C: ネットワーク | モニタリングでDB待ち時間が10倍に → A |
| Why 2 | なぜDBが遅くなった？ | A: スロークエリ B: コネクション枯渇 C: ディスクI/O | スロークエリログにN+1クエリを検出 → A |
| Why 3 | なぜN+1クエリが本番に出た？ | A: レビューで見落とし B: テスト環境で検出できず C: 新機能の影響 | 前日の新機能リリースのPRにN+1あり → A, C |
| Why 4 | なぜレビューで見落とした？ | A: レビューアが不慣れ B: チェック項目にDB効率がない C: PRが大きすぎた | PRが500行超。チェック項目にDBパフォーマンスなし → B, C |
| Why 5 | なぜチェック項目にDB効率がない？ | - | 過去にDB起因の障害がなく、リスクとして認識されていなかった |
根本原因: コードレビューのチェック項目にDBパフォーマンスの観点がなく、大きなPRで見落としが起きやすい構造
アクションプラン:
- 即時: 問題のクエリを修正しレスポンスを200msに復旧（1時間）
- 暫定: レビューチェックリストに「N+1クエリがないか」を追加
- 根本: CI/CDにスロークエリ検出ツールを導入。PR分割の目安を200行以内に設定
結果: 対策導入後3ヶ月間でDB起因の障害はゼロ。PR平均行数も500行→180行に減少し、レビューの精度が全体的に向上した。
問題定義: 従業員120名の食品メーカーで、出荷遅延率が前年比で3.2%→7.8%に悪化。月間約50件の遅延が発生。
5Why+の実施:
| 段階 | なぜ？ | 仮説 | 検証結果 |
|---|---|---|---|
| Why 1 | なぜ出荷が遅れている？ | A: 製造が間に合わない B: 梱包が遅い C: 配送手配のミス | 製造完了→梱包開始のリードタイムが平均4.2時間（基準は1時間） → A寄り |
| Why 2 | なぜ製造から梱包への引渡しが遅い？ | A: 製造完了の通知が遅い B: 梱包チームの人手不足 C: 保管場所の混乱 | 製造完了はホワイトボード記入のみ。梱包チームは1時間に1回しか確認していない → A |
| Why 3 | なぜリアルタイムで通知されない？ | A: システムがない B: コスト意識で導入されていない | 過去に検討されたが「費用対効果が不明」で却下された → B |
| Why 4 | なぜ費用対効果が不明だった？ | - | 遅延による損失（クレーム対応・信用低下）が定量化されていなかった |
根本原因: 出荷遅延のコストが定量化されておらず、通知システムへの投資判断ができない状態
アクションプラン:
- 即時: 梱包チームの確認頻度を1時間→15分に変更
- 暫定: LINEワークスで製造完了時に自動通知するフローを構築（費用月額5,000円）
- 根本: 遅延コストを算出し（月間推定180万円の損失）、製造管理システムの導入稟議を提出
結果: LINE通知だけで遅延率が7.8%→3.5%に改善。遅延コストの可視化により、製造管理システム（初期費用300万円）の導入も承認され、6ヶ月後に遅延率1.2%を達成した。
問題定義: 副業で運営する技術ブログ。月間PVが3ヶ月前の8万→3.2万に60%減少。広告収益も月5万円→2万円に低下。
5Why+の実施:
| 段階 | なぜ？ | 仮説 | 検証結果 |
|---|---|---|---|
| Why 1 | なぜPVが減った？ | A: 検索順位が下がった B: SNS流入が減った C: 記事数が減った | Search Consoleで主要20記事の平均順位が3位→12位に下落 → A |
| Why 2 | なぜ検索順位が下がった？ | A: Googleアルゴリズム変更 B: 競合の台頭 C: コンテンツの陳腐化 | アルゴリズム変更のタイミングと一致。かつ上位を奪った競合記事は2024年以降の最新情報を掲載 → A, C |
| Why 3 | なぜコンテンツが陳腐化した？ | A: 更新頻度が低い B: トレンドの変化を追えていない | 主要記事の最終更新が平均14ヶ月前。技術トレンドは6ヶ月サイクルで変化 → A |
| Why 4 | なぜ更新できていない？ | A: 本業が忙しい B: 更新の仕組みがない | 記事ごとの「要更新チェック日」を設定しておらず、更新が後回しになっていた → B |
根本原因: コンテンツの鮮度管理の仕組みがなく、記事が放置されて検索評価が低下するサイクルに入った
アクションプラン:
- 即時: PV上位10記事を最新情報にリライト（2週間）
- 暫定: 各記事に「次回チェック日」を設定し、Googleカレンダーにリマインダーを登録
- 根本: 四半期ごとの全記事レビューを習慣化。更新コストの低い「エバーグリーンコンテンツ」の比率を60%以上に引き上げ
結果: リライト完了から2ヶ月でPVが3.2万→6.5万に回復。定期レビューの仕組み化により、6ヶ月後には過去最高の9.2万PVを記録し、広告収益も月7万円に到達した。
やりがちな失敗パターン#
- 「なぜ」を直線的にしか掘らない — 各段階で分岐（複数の仮説）を出さないと、最初の思い込みに引きずられる。必ず2〜3個の仮説を出してから検証する
- データで検証しない — 「たぶんこれが原因だろう」で次の「なぜ」に進むと、間違った方向に深掘りしてしまう。各段階でログやデータで裏付けを取る
- 個人の責任追及で終わる — 「担当者が確認を怠った」は原因ではなく症状。「なぜ確認を怠りやすい仕組みになっているか」まで掘る
- 真因の特定で満足してアクションを出さない — 原因がわかっても対策を打たなければ何も変わらない。即時・暫定・根本の3層で必ずアクションプランまで落とし込む
まとめ#
5Why+は従来の5Whyの弱点（直線的・主観的・個人攻撃になりがち）を克服した進化版。「なぜ」の各段階で複数の仮説を出し、データで検証し、人ではなくシステムの問題にたどり着く。問題が起きたとき、この手法で30分かけて分析するだけで、同じ問題の再発率を大幅に下げることができる。