Home / 5 Whys（なぜなぜ分析）｜「なぜ」を繰り返して問題の原因を探る

5 Whys（なぜなぜ分析）｜「なぜ」を繰り返して問題の原因を探る

5 Whys（ファイブ・ホワイズ、なぜなぜ分析）は、問題が発生したときに「なぜそうなったのか」という問いを繰り返し、表面的な現象の背後にある原因を探る問題分析手法です。トヨタ生産方式（Toyota Production System）で広く知られるようになり、現在では製造業の品質管理だけでなく、業務改善、システム障害の分析、サービス品質の改善などにも利用されています。

方法は単純です。問題が起きた理由を考え、その答えに対してさらに「なぜ」と問いかけます。これを繰り返すことで、最初に見えていた問題の背後にある条件や仕組みを明らかにしようとします。ただし、5回質問すれば必ず真の原因に到達できるわけではありません。5 Whysは原因を自動的に発見する方法ではなく、原因についての仮説を掘り下げるための思考技法です。

5 Whysの起源と基本的な考え方

5 Whysは豊田佐吉の問題解決思想に起源を持つとされ、トヨタ生産方式を体系化した大野耐一によって重視されました。大野は、機械が停止した場合、その直接的な原因だけを取り除いても、問題が繰り返される可能性があることを説明しています。

例えば、機械が停止した原因がヒューズの切断であれば、ヒューズを交換することで運転は再開できます。しかし、ヒューズが切れた理由が過負荷であり、過負荷の理由が軸受の潤滑不足であれば、ヒューズの交換だけでは再発を防げません。さらに潤滑不足を引き起こした装置の不具合や、その不具合を生んだ条件まで調べる必要があります。

このように、直接的な不具合を修復することと、その不具合を発生させた原因を取り除くことは異なります。5 Whysの目的は、問題が繰り返されないように、より深い原因や管理上の問題を明らかにすることです。

名称には「5」が含まれていますが、必ず5回質問しなければならないという規則ではありません。問題によっては3回で十分な場合もあれば、さらに調査が必要な場合もあります。

5 Whysの基本的な手順

1. 問題を具体的に記述する

最初に、何が起きたのかを明確にします。「品質が悪い」「顧客対応が遅い」「売上が減った」といった漠然とした記述では、さまざまな原因が考えられ、分析の方向が定まりません。

可能であれば、発生した現象、場所、日時、頻度、数量、通常の状態との差異などを記録します。

例えば、「顧客対応が遅い」という表現を「今月、問い合わせの初回回答が社内基準の24時間を超えた案件が20件あった」というように具体化します。ここで示した数値は説明用の仮定です。

問題の記述に、最初から原因を含めないことも重要です。「担当者の注意不足によって回答が遅れた」と書いてしまうと、注意不足が原因であることを検証する前に結論を決めてしまいます。

2. 最初の「なぜ」を考える

問題が起きた直接的な原因の候補を考えます。

例えば「なぜ問い合わせへの初回回答が遅れたのか」という問いに対して、「担当者への案件の割り当てが遅れた」という答えが得られるかもしれません。

ただし、これはまだ仮説です。実際に案件の割り当てが遅れていたのか、受付記録やシステムのログなどで確認する必要があります。

3. 答えに対して、さらに「なぜ」と問う

次に「なぜ担当者への案件の割り当てが遅れたのか」と考えます。

例えば、「自動振り分けに必要な製品名が入力されていなかった」という可能性が考えられます。

さらに、なぜ製品名が未入力だったのか、なぜその状態で受け付けられたのか、なぜ必要な入力条件が整備されていなかったのか、と問いを進めます。

ここでも、それぞれの答えが事実なのか推測なのかを区別します。

4. 複数の原因がある場合は分岐する

「なぜ」という問いに対して、答えが一つとは限りません。

例えば、初回回答の遅延には「担当者への割り当てが遅れた」だけでなく、「割り当て後の処理に時間がかかった」という原因も考えられます。

この場合、一方の原因だけを選んで分析を続けると、重要な要因を見落とす可能性があります。

必要に応じて複数の原因を並行して調べ、それぞれについて「なぜ」を繰り返します。5 Whysは直線的な手順として紹介されることが多いものの、現実の問題には複数の因果経路が存在します。

5. 原因を検証する

質問を繰り返すだけでは、原因が明らかになったことにはなりません。

例えば「入力フォームの仕様に問題があった」という仮説が得られた場合、仕様変更の履歴、実際の入力データ、システムの動作などを調べます。

また、見つけた原因から元の問題へ向かって因果関係をたどり直すことも有効です。

「製品名が入力されなかったために自動振り分けが失敗し、そのために担当者への割り当てが遅れ、初回回答が遅延した」という説明が、実際の記録と一致するかを確認します。

6. 対策を実施し、再発を確認する

原因が十分に確認できたら、対策を考えます。

入力フォームの必須項目を変更する、振り分けに失敗した案件を通知する、未割り当ての案件を監視するなど、複数の対策が考えられます。

対策を実施した後は、同様の問題が減少したかを確認します。期待した効果が得られなければ、原因についての仮説や対策の妥当性を再検討する必要があります。

実践例 ― 顧客への回答が遅れる原因を探る

次の表は、問い合わせの初回回答が遅延する問題について、5 Whysを適用した仮想的な例です。実際の原因が確認された事例ではありません。

段階問い仮説としての答え
問題なぜ初回回答が遅れたのか担当者への割り当てが遅れた
Why 2なぜ割り当てが遅れたのか自動振り分けが正常に機能しなかった
Why 3なぜ自動振り分けが機能しなかったのか必要な製品名が未入力だった
Why 4なぜ製品名が未入力だったのか入力フォームで任意項目になっていた
Why 5なぜ任意項目になっていたのか振り分け方式の変更時にフォームの仕様が更新されなかった

この分析が事実によって裏付けられた場合、担当者に「回答をもっと早くするように」と指導するよりも、入力フォームと振り分け処理を修正する方が再発防止につながる可能性があります。

しかし、別の原因も存在するかもしれません。担当者が割り当てられていても、問い合わせが集中していたため処理できなかった可能性があります。休日や夜間に対応する体制が不足していた可能性もあります。

したがって、この表だけで問題の原因が完全に明らかになったと考えることはできません。

「根本原因」とは何か

5 Whysでは「根本原因（Root Cause）」という言葉が使われます。一般には、その原因を取り除けば問題の再発を防止できると考えられる、重要な原因を指します。

しかし、どこまで原因をたどれば「根本」に到達したと言えるのでしょうか。

例えば、入力フォームの仕様が更新されなかった理由として、仕様変更時の確認手順がなかったことが挙げられるかもしれません。その確認手順がなかった理由として、開発部門と運用部門の役割分担が不明確だったことが考えられます。さらに、組織の管理体制や予算配分に問題があったという説明へ進むことも可能です。

原因をたどり続ければ、組織制度や社会的条件など、分析対象が際限なく広がることがあります。

このため、根本原因を絶対的なものとして考えるより、対象とする問題の範囲内で、再発防止に重要であり、実際に対処できる原因を明らかにすると理解する方が実務的です。

もちろん、対処しやすいという理由だけで、重要な構造的原因を無視してよいわけではありません。問題の重大性に応じて、どの範囲まで調査する必要があるかを判断します。

5 Whysの長所

5 Whysの第一の長所は、方法がわかりやすいことです。特別な数理知識やソフトウェアがなくても、問題について問いを繰り返すことができます。

第二に、直接的な現象と、その現象を引き起こした条件を区別しやすくなります。これは、表面的な対症療法だけで問題を処理することを避ける助けになります。

第三に、原因についての仮説を明示できることです。なぜその対策が必要なのか、どの原因に対応するのかを他の人と共有できます。

第四に、現場の知識を分析に取り入れやすいことです。問題が実際に発生した場所で作業の流れを観察し、関係者から情報を得ることで、机上の推測ではわからない原因を発見できる可能性があります。

5 Whysの限界 ― なぜを繰り返しても真実に到達するとは限らない

5 Whysは広く普及していますが、方法の単純さには注意が必要です。

原因を一つの連鎖に単純化しやすい

現実の問題は、多数の要因の組合せによって発生する場合があります。

例えば、製品不良には材料、設備、作業条件、温度、工程設計などが関係することがあります。これらの要因が相互作用している場合、単一の原因を深く掘り下げるだけでは問題全体を理解できません。

5 Whysの結果を一本の線として表すと、分析者が選択した因果経路以外の要因が見えにくくなります。

分析者の先入観に左右される

同じ問題であっても、異なる担当者が分析すると、別の原因に到達する可能性があります。

例えば、管理者は「教育不足」に注目し、現場担当者は「作業手順の複雑さ」に注目するかもしれません。システム開発者は「入力フォームの仕様」に原因を求めるかもしれません。

どれか一つが必ず誤りというわけではなく、それぞれが問題の異なる側面を捉えている可能性があります。

もっともらしい物語を作りやすい

「なぜ」と繰り返し質問すると、人は何らかの説明を考えようとします。しかし、説明が論理的につながっているように見えても、それが事実であるとは限りません。

例えば「確認不足が起きたのは担当者の意識が低かったからだ」という説明は、直接観察された事実ではなく、心理状態についての推測です。

こうした推測を検証せずに次の質問へ進むと、最終的に根拠の乏しい説明が完成してしまいます。

個人の責任に問題を帰着させやすい

分析が「作業者が注意しなかった」「担当者がルールを守らなかった」で終わる場合もあります。

しかし、その背景には、作業環境、手順の不備、過大な業務負担、情報の不足、設備の設計などが関係しているかもしれません。

人間の行動を原因として挙げる場合には、その行動が生じた条件についても検討する必要があります。

因果関係の検証が十分ではない

5 Whysは原因を考えるための質問方法であり、因果関係を統計的・実験的に証明する方法ではありません。

複数の要因が関係する場合、実験計画法、多変量解析、故障解析、シミュレーションなど、別の分析方法が必要になることがあります。

2017年に『BMJ Quality & Safety』で発表されたAlan J. Cardの論考は、医療安全における5 Whysの普及に比べて、その有効性を裏付ける証拠が十分でないことや、単一の因果経路に注目する危険を指摘しています。

この批判は、5 Whysを使うべきではないという意味ではありません。質問を繰り返す作業と、原因を科学的に確認する作業を区別する必要があるということです。

他の原因分析手法との組合せ

5 Whysは、他の手法と組み合わせることで適用範囲を広げられます。

手法主な役割5 Whysとの関係
特性要因図（魚骨図）原因候補を幅広く洗い出す各原因候補を詳しく掘り下げる
FTA（故障の木解析）故障を引き起こす条件を論理的に分析する複数原因の組合せを検討する
FMEA故障モードとその影響・リスクを評価する発生した不具合の原因を検討する
実験計画法（DOE）要因と結果の関係を実験によって調べる原因仮説を検証する
多変量解析複数の変数と結果の関係を分析する単一の因果連鎖では扱えない関係を調べる
システム思考相互作用やフィードバックを分析する循環的・構造的な問題へ視野を広げる

特に、複数の原因がありそうな場合には、最初に特性要因図で候補を整理し、その一つひとつについて5 Whysを実施する方法が考えられます。

ただし、特性要因図も原因を自動的に証明するものではありません。両方を組み合わせても、観察や測定による裏付けが必要です。

5 Whysとアブダクション

論理学の観点から見ると、5 Whysはアブダクション（仮説形成的推論）と深い関係があります。

ある現象を観察して「なぜ起きたのか」と考えるとき、私たちはその現象を説明できる仮説を作っています。

例えば「自動振り分けが失敗した」という現象から、「製品名が未入力だったためではないか」という仮説を考えます。

しかし、他にもサーバーの障害や振り分け条件の設定ミスなどが考えられます。

つまり、5 Whysによって得られる答えは、演繹的に必ず導かれる結論とは限りません。複数の説明候補の中から、事実によって支持される仮説を選択する必要があります。

この違いを理解すれば、「なぜを5回繰り返せば正解が見つかる」という誤解を避けられます。

AI時代の5 Whys ― 原因を説明するAIから、原因を検証するAIへ

5 Whysは、LLMとの組合せを考えやすい思考技法です。問題の文章を入力すれば、LLMは原因の候補を挙げ、それぞれについて「なぜ」という質問を繰り返すことができます。

しかし、ここには重大な問題があります。

LLMは、もっともらしい原因を次々に生成できます。入力された問題について実際の観測データを持っていなくても、筋の通った因果関係の説明を作ることが可能です。

そのため、LLMに「この問題について5 Whysを実行してください」と依頼するだけでは、実際の原因分析ではなく、原因らしい物語の生成になる危険があります。

この問題を避けるには、AIの役割を明確にする必要があります。

原因候補を複数生成する

最初の「なぜ」に対して、可能性のある原因を複数提示させます。ここで一つに絞らず、必要な観測データや検証方法も併せて考えます。

根拠を確認する

各原因候補について、どの情報によって支持されるのかを記録します。LLMが推定した内容と、ログ、記録、測定結果などから確認された事実を区別します。

因果関係を構造化する

「原因Aが結果Bを引き起こす」という関係を記録し、複数の原因経路を扱えるようにします。これにより、一本の5 Whysの連鎖に限定されず、因果関係のネットワークとして問題を捉えられます。

検証方法を提案する

原因候補に対して、必要な観察、測定、比較、実験などを提案させます。これによって、AIが単に説明を生成するだけでなく、実際の調査を支援できる可能性があります。

対策の効果を追跡する

採用した対策と対応する原因を記録し、対策後の結果を確認します。問題が再発した場合には、最初の原因仮説を見直します。

このように、5 Whysを単なる質問の連鎖から、仮説・証拠・因果関係・対策を管理する分析方法へ拡張することが考えられます。

ThinkNaviでの位置づけ

ThinkNaviでは、5 Whysを代表的な問題原因分析手法として紹介します。

ThinkNavi Freeで実装する場合には、問題の記述、「なぜ」の質問、原因候補、根拠、対策を記録できる手入力型の分析ツールが考えられます。複数原因の分岐や、元の問題に向かって因果関係を確認する機能も有用でしょう。

LLM活用版では、原因候補の生成、追加調査の提案、因果関係の整理、根拠の不足や矛盾の指摘、対策案の比較などを支援する可能性があります。これらは将来の機能構想であり、現時点で提供済みの機能を示すものではありません。

重要なのは、古典的な5 Whysの手順をそのままコンピュータ化することではありません。

5 Whysを通じて得られる原因候補を、観察された事実や実験結果と関連づけることで、原因分析をさらに深めることができます。

5 Whysの価値は「なぜ」を5回質問することではなく、最初に思いついた説明で満足せず、問題の背後にある原因を調べ続けることにあります。

関連ページ

参考文献・関連資料

Alan J. Card, “The Problem with ‘5 Whys’,” BMJ Quality & Safety, 26(8), 2017, pp. 671–677.

大野耐一『トヨタ生産方式 ― 脱規模の経営をめざして』ダイヤモンド社、1978年。

Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production, Productivity Press, 1988.

Lean Enterprise Institute — 5 Whys

Lean Enterprise Institute — How Many Whys Should I Ask?

American Society for Quality — Five Whys and Five Hows

Institute for Healthcare Improvement — 5 Whys: Finding the Root Cause