なぜなぜ分析(5 Whys):根本原因分析の手法(事例付き)

**なぜなぜ分析(5 Whys)**は、プロセス改善において最もシンプルで強力なツールの一つです。問題を明確にし、それが起きた「なぜ」を問い、最初の答えについてさらに「なぜ」を重ね、症状ではなく実際の原因にたどり着くまで続けます。多くのチームは5回の繰り返しでたどり着きます。3回で済むこともあれば、本当に6回、7回必要なこともあります。

この手法の本質は回数ではありません。最初に出てきた都合の良い答えで止まらない姿勢にあります。

なぜなぜ分析(5 Whys)とは何か

**なぜなぜ分析(5 Whys)**は、反復的な問いかけによって問題を根源までたどる根本原因分析の手法です。定義された問題文から始め、「なぜこれが起きたのか」を繰り返し問い、表面的な症状ではなく根底にあるシステムの欠陥を明らかにするまで続けます。

この手法は、20世紀初頭にトヨタ自動織機の創業者である豊田佐吉によって考案されました。1950年代から1960年代にかけて、大野耐一のもとで**トヨタ生産方式(TPS)**の正式な実践の一つとなりました。大野は、なぜなぜ分析を、事後の不良検査ではなく製造プロセスに品質を組み込むことを可能にした中核的な実践の一つとして高く評価しました。今日ではLeanメソドロジー、Six SigmaのDMAICフレームワーク、そしてほぼすべての継続的改善システムにおける標準ツールとなっています。

この手法にはソフトウェアも統計学の訓練も特別な資格も必要ありません。その手軽さこそ、工場現場から役員会議室まで70年以上生き残ってきた理由です。

重要なポイント

• トヨタ生産方式の生みの親である大野耐一は、1988年の著書『トヨタ生産方式』の中で「なぜを5回繰り返すことで、問題の本質とその解決策が明らかになる」と記しています。この表現は、今日でもLean Enterprise Instituteによるこの手法の標準的な説明として使われています。
• 米国品質協会(ASQ)は、なぜなぜ分析をCertified Quality Engineerの知識体系に含めており、フィッシュボーン図やパレート分析と並んで、分析フェーズの主要なツールの一つとして挙げています。
• Lean Enterprise Instituteによる2021年の調査によると、リーン手法を導入している組織の65%以上がなぜなぜ分析を使用しており、運用管理における単一の根本原因分析ツールとして最も広く導入されていることが分かっています。

なぜなぜ分析 vs フィッシュボーン図 vs 8D

これら3つのツールはよく一緒に語られます。関連はしていますが、互換性があるわけではありません。選択を誤ると時間を無駄にし、浅い結論しか得られません。

問題が絞り込まれており、迅速に答えが必要な場合はなぜなぜ分析を使ってください。どのカテゴリーの原因が問題を引き起こしているか分からず、ブレインストーミングの構造が必要な場合はフィッシュボーン図を使ってください。正式な文書化、封じ込め対応、組織の境界を越えた検証が必要な場合は8D問題解決を使ってください。

なぜなぜ分析とフィッシュボーン図は実際に相性が良い組み合わせです。多くのチームはまずフィッシュボーンで可能性の範囲を洗い出し、その後最も可能性の高い枝になぜなぜ分析を適用します。

なぜなぜ分析のメリット

スピード。 小規模なチームであれば、1時間以内になぜなぜ分析を完了できます。実際に費用がかかっていたり遅延を引き起こしていたりする運用上の問題にとって、このスピードは重要です。

取り組みやすさ。 なぜなぜ分析のセッションを進行するのに統計専門家や認定ブラックベルトは必要ありません。問題を理解しているチームリーダーであれば誰でも進行できます。

人ではなくシステムに焦点を当てる。 正しく行えば、なぜなぜ分析は根本原因としてヒューマンエラーを挙げることから遠ざけ、そのエラーを許してしまったプロセス、システム、方針へと調査を向けます。個人を責めても再発は防げません。壊れたプロセスを直すことが再発を防ぎます。

他のツールとの統合。 なぜなぜ分析は、DMAICの分析フェーズ、PDCAの計画段階、カイゼン活動に自然に組み込まれます。単独の手法ではなく、モジュール式のテクニックです。

対策の明確さ。 なぜなぜ分析は特定の根本原因で終わるため、是正措置は通常明確になります。それがこの手法の目的そのものです。答えがあいまいであれば、まだ十分に掘り下げられていないということです。

よくある間違いと限界

なぜなぜ分析はシンプルです。そのシンプルさこそが最大の弱点でもあります。

早く止めすぎる。 最も多い間違いは、症状を原因として受け入れてしまうことです。「機械が故障した」は症状です。「コスト削減のためメンテナンススケジュールが削減されたために機械が故障した」が根本原因です。時間的なプレッシャーの下にあるチームは最初にもっともらしい答えを受け入れて先に進んでしまいます。すると問題は再発します。

一本の経路しかたどらない。 実際の問題には、各段階で枝分かれする複数の寄与要因があることがよくあります。単一のチェーンだけの厳密な分析では、並行して起きている失敗を見逃します。複雑な問題については、チェーンを直線ではなく樹形図として描いてください。

プロセスではなく人を責める。 5番目の「なぜ」が「ボブが報告書を確認しなかったから」であれば、根本原因を見つけたことにはなりません。責める相手を見つけただけです。さらに問いを続けてください。なぜ確認を自動化する仕組みがなかったのか。なぜボブは訓練を受けていなかったのか。なぜボブが単一障害点になっていたのか。

記憶や推測に頼る。 なぜなぜ分析は、記憶ではなくデータに基づいて行うのが最も効果的です。チームが記憶から出来事を再構成すると、バイアスが入り込み、実際に起きたことを見逃します。可能な限り、観察、データログ、プロセスの実地確認と組み合わせてください。

複雑な複数システムにまたがる障害に使う。 問題が5つの部門、3つのソフトウェアシステム、2つの規制当局にまたがる場合、会議室でのなぜなぜ分析セッションではそれを捉えきれません。それは反復的な質問ではなく、統計分析を伴うフィッシュボーン図の仕事です。

なぜなぜ分析の使い方(ステップごと)

ステップ1: 問題を明確に定義する

問題を具体的で観察可能な文として書き出してください。あいまいな問題文からは、あいまいな根本原因しか得られません。「売上が落ちている」は問題文ではありません。「第2四半期に受注処理エラーが23%増加し、48件の顧客クレームを引き起こした」は問題文です。

何が起きたか、どこで起きたか、いつ最初に気づいたか、測定可能な影響は何かを含めてください。このステップに5分かける価値は十分にあります。後の作業時間を何時間も節約できます。

ステップ2: 「なぜこれが起きたのか」を問う(なぜ1)

問題文に焦点を当ててください。観察したことについての直接的な原因、第一段階の説明を書き出します。事実に基づいてください。この答えは推測ではなく検証可能なものであるべきです。

ステップ3: 最初の答えについて「なぜ」を問う(なぜ2)

先ほど記録した原因を取り上げ、なぜそれが起きたのかを問います。もはや最初の問題について問うているのではありません。ステップ2で特定した原因について問うています。答えを書き出してください。

ステップ4: 「なぜ」を問い続ける(なぜ3〜5)

新しい答えごとにこのプロセスを繰り返します。各段階で、これは本当に原因なのか、それともまだ症状なのかを自問してください。次のいずれかの条件を満たすまで続けます。第一に、答えが実際に修正可能なプロセス、方針、システムの欠陥を明らかにする場合。第二に、その原因についてこれ以上コントロールできない領域(外部の規制、物理法則、固定的な制約)に到達した場合。第三に、答えが別途調査を必要とするリソースや知識のギャップを明らかにする場合です。

必ず5回にする必要はありません。本当の根源にたどり着いたら止めてください。まだ症状を説明しているだけなら5回を超えて続けてください。

ステップ5: 根本原因を特定する

チームが「これは実行可能でシステム的だ」と合意した最後の「なぜ」が根本原因です。それを明確に書き出してください。問題から根本原因までのチェーンを声に出して見直し、各段階が論理的に成り立っているか確認します。

ステップ6: 対策を定義し検証する

チェーンの途中にある症状ではなく、根本原因に対して具体的な是正措置を割り当ててください。目標日を設定し、担当者を割り当てます。実施後、元の問題が再発しないことを検証してください。再発した場合、根本原因のチェーンが不完全だったということです。さらに深く掘り下げてください。

なぜなぜ分析の事例

製造業:機械のダウンタイム

生産現場から完全に検証済みの事例を紹介します。

モーター(症状)を交換していれば、1,200ドルと2週間のリードタイムがかかっていたはずです。チェックリストの更新には20分しかかかりませんでした。

ソフトウェアエンジニアリング:システム障害

あるSaaSプラットフォームで、2,000人の顧客に影響する重大な障害が発生しました。

• なぜ1: プライマリデータベースサーバーのディスク容量が不足した。
• なぜ2: バッチジョブが非圧縮のログファイルをデータベースボリュームに書き込んでいた。
• なぜ3: バッチジョブはデフォルトでそのように設定されており、誰も変更していなかった。
• なぜ4: バッチジョブの設定に対するコードレビューの要件がなかった。
• なぜ5: デプロイプロセスは、アプリケーション以外の設定ファイルを必須レビュー対象としてフラグ付けしていなかった。

根本原因: デプロイプロセスの欠陥。設定ファイルがアプリケーションコードと同じレビューゲートの対象になっていなかった。 対策: すべての設定変更に対してエンジニアリングレビューを必須とするようデプロイパイプラインを更新。ディスク使用率70%でアラートを発する仕組みを追加。

カスタマーサービス:クレームの急増

あるサブスクリプションソフトウェア企業で、月初の1週間に請求関連の問い合わせが30%急増しました。

• なぜ1: 顧客が請求書上の想定外の料金について困惑している。
• なぜ2: 料金プランの変更が、アプリ内の請求説明を更新しないままリリースされた。
• なぜ3: プロダクトチームと財務チームが料金エンジンを更新したが、UXチームに通知していなかった。
• なぜ4: 料金変更に関する部門横断のチェックリストにUXレビューが含まれていなかった。

根本原因: 料金変更プロセスにおけるステップの欠落。 対策: 変更を本番反映する前にUX、財務、カスタマーサクセスの承認を必須とする料金変更ランブックを作成。

なぜなぜ分析を最大限に活用するベストプラクティス

適切な人を集める。 障害に最も近い立場にいた人と、上流のシステムを理解している人を含めてください。その場にいなかったマネージャーだけでなぜなぜ分析を進めないでください。

ファシリテーターを立てる。 チームに正直であることを求め、あいまいな答えには反論し、各「なぜ」が前の答えから論理的に導かれているかを確認する役割が必要です。ファシリテーターは、特定の結論に最も強い利害関係を持つ人物であってはいけません。

チェーンを視覚的に記録する。 各ステップをホワイトボードや共有ドキュメントに書き出し、チェーン全体が見えるようにしてください。問題から根本原因までの論理の流れが見えると、チームはより良い判断ができます。

各答えに疑問を投げかける。 各段階で「これが本当だとどうして分かるのか」を問うてください。もっともらしい推測は検証済みの原因ではありません。データや直接観察で答えを確認できない場合は、それを仮定としてフラグ付けし、チェーンを確定する前に検証してください。

対策は症状ではなく根本原因に結びつける。 対策がなぜ5ではなくなぜ2に対処しているのであれば、根本的な修正ではなく回避策を作っただけです。回避策は問題を覆い隠します。根本原因への対策は問題を排除します。

フォローアップする。 なぜなぜ分析は、対策が実施され検証されて初めて価値があります。実施から30日後にフォローアップレビューを予定し、問題が再発していないことを確認してください。

関連記事

• 根本原因分析: RCA手法全般、それぞれの使い分け、品質マネジメントシステムへの組み込み方についての幅広いガイド。
• パレート分析: 80/20の原則を使って、どの問題を優先的に調査すべきかを判断します。
• フィッシュボーン図: 原因カテゴリーをマッピングするための、なぜなぜ分析を補完する視覚的ツール。
• DMAIC: 分析フェーズでなぜなぜ分析を使用するSix Sigmaフレームワーク。
• SIPOC図: なぜなぜ分析を始める前にプロセスをマッピングし、問題文のスコープが正しく設定されているか確認します。

よくある質問

なぜ5回で、それより多くも少なくもないのですか?

5という数字は目安であってルールではありません。豊田佐吉のもともとの洞察は、ほとんどの業務上の問題は5回の問いかけの範囲内で根本原因にたどり着けるというものでした。実際には、3回の「なぜ」で解決する問題もあれば、本当に7回必要な問題もあります。重要なのは、システム的で実行可能な原因にたどり着ける回数です。そこに到達したら止め、まだであればさらに深く掘り下げてください。

なぜなぜ分析は根本原因分析と同じものですか?

いいえ、しかし、なぜなぜ分析は根本原因分析の手法の一つです。根本原因分析(RCA)は、問題の根底にある原因を特定するより広い実践のことです。なぜなぜ分析はその実践の中の一つのツールです。他のRCAツールには、フィッシュボーン図、故障の木解析、故障モード影響解析(FMEA)などがあります。多くのRCA実践者は、より厳密な統計的手法を重ねる前の出発点として、なぜなぜ分析を使用します。

なぜなぜ分析とフィッシュボーン図を組み合わせることはできますか?

はい、実際に非常に有用な組み合わせです。フィッシュボーン図は、どのカテゴリーの原因が最も可能性が高いか(人、プロセス、設備、材料、環境、測定)を特定するのに役立ちます。特定の枝に絞り込んだ後、なぜなぜ分析を適用してその枝を深掘りし、根本原因を確認します。フィッシュボーンは広げ、なぜなぜ分析は深めます。

なぜなぜ分析を使うべきでないのはどんなときですか?

統計的に複雑で、複数の相互接続されたシステムにまたがる問題、あるいは規制上または顧客対応上正式な文書化が必要な問題には、なぜなぜ分析を避けてください。また、障害に最も近い人やデータにアクセスできないチームにとっても適切なツールではありません。そうした場合は、フィッシュボーン図、8D問題解決、あるいは本格的な故障モード影響解析を活用してください。

なぜなぜ分析は製造業だけでなく、サービス業やナレッジワークの現場でも機能しますか?

もちろんです。この手法は製造業で生まれましたが、プロセスを定義でき、障害を観察できる場所であればどこでも機能します。ソフトウェアチームはポストモーテムでこれを使用します。カスタマーサクセスチームは解約の診断に使用します。人事チームは離職率が急増した後の根本原因レビューで使用します。同じ論理が当てはまります。最初のもっともらしい説明で止めれば問題は再発し、問い続ければ実際に変える必要があるものが見つかります。

なぜなぜ分析には特別なツールも高額なトレーニングも必要ありません。必要なのは、分かっていないことに対する正直さ、居心地の悪い問いを問い続ける忍耐力、そして見つけた欠陥を実際に修正するという組織的なコミットメントです。その習慣を身につけたチームは、同じ火消しを何度も繰り返すことをやめられます。それこそが本当の見返りです。