【FW-04】なぜなぜ分析とは？「なぜ」を5回繰り返し根本原因にたどり着く思考法
【FW-04】なぜなぜ分析とは？「なぜ」を5回繰り返し根本原因にたどり着く思考法
初級 ／ ★☆☆ ／ 全文無料公開
このシリーズについて
「ビジネスフレームワーク」は、マーケティングに限定しない、経営戦略・問題解決・思考整理のための汎用フレームワークを1本1フレームワークで解説する全7回のシリーズです。前回（FW-03）では、業界の競争構造を5つの力で分析する「5F（ファイブフォース）分析」を取り上げ、SWOT・PEST・5Fという「外部環境・競争環境を分析する」3本のフレームワークが完結しました。第4回となる今回からは、外部環境分析で見えてきた課題を「どう根本原因まで掘り下げ、構造的に整理するか」という実務フェーズに入ります。最初に扱うのは、トヨタ生産方式の一部として広まった「なぜなぜ分析」です。
この記事でわかること：
なぜなぜ分析とは何か——「なぜ」を繰り返す思考法の基本
なぜ5回なのか——回数にこだわりすぎてはいけない理由
実務での正しいやり方——原因分析と犯人探しの違い
自社（サイバーフォレスト）を題材にしたなぜなぜ分析の実例
なぜなぜ分析でよくある失敗パターンと対策
すぐ使えるなぜなぜ分析シート（テンプレート）
なぜなぜ分析とは何か
なぜなぜ分析（Why-Why Analysis、5 Whys）とは、発生した問題に対して「なぜ？」という問いを繰り返し投げかけることで、表面的な現象の奥にある根本原因（真因）にたどり着くための思考法です。トヨタ自動車の生産現場で発展し、トヨタ生産方式（TPS）の重要な要素の一つとして広く知られるようになりました。考案の経緯については諸説あり、トヨタ自動車工業の創業者一族である豊田佐吉・喜一郎の現場改善の思想に端を発し、大野耐一氏らによって体系化されたと言われています。
なぜなぜ分析の基本的な考え方は、次のようなものです。
【なぜなぜ分析の基本構造】
問題：機械が停止した
なぜ①：機械が停止した
→ なぜ？ ヒューズが切れて過負荷がかかったため
なぜ②：ヒューズが切れて過負荷がかかった
→ なぜ？ 軸受け部の潤滑が不十分だったため
なぜ③：軸受け部の潤滑が不十分だった
→ なぜ？ 潤滑ポンプが十分に汲み上げていなかったため
なぜ④：潤滑ポンプが十分に汲み上げていなかった
→ なぜ？ ポンプの軸が摩耗し、がたつきがあったため
なぜ⑤：ポンプの軸が摩耗していた
→ なぜ？ 濾過機（ストレーナー）が付いておらず、
切り粉が入り込んでいたため
【真因】濾過機が付いていなかった
【対策】濾過機を取り付けるこの例は、なぜなぜ分析を語る際にしばしば引用される、ポンプの故障を題材にした事例です。表面的な現象だけを見ると「ヒューズが切れた」で対処が終わってしまい、ヒューズを交換して終わりになりがちです。しかし「なぜ」を5回繰り返すことで、真の原因である「濾過機の欠如」にたどり着き、根本的な再発防止策（濾過機の設置）にたどり着けます。この「表面的な対症療法ではなく、根本原因への対策を打つ」という発想こそが、なぜなぜ分析の核心です。
なぜ5回なのか——回数にこだわりすぎてはいけない理由
「なぜなぜ分析」は英語で「5 Whys」と呼ばれ、「5回」という数字が独り歩きしがちですが、この「5」はあくまで目安であり、絶対のルールではありません。
【「5回」という数字の正しい理解】
・3回で真因にたどり着くこともあれば、7回かかることもある
・重要なのは回数ではなく「対策を打てる粒度の原因」に
到達しているかどうか
・「対策可能な原因」に到達したら、そこで分析を止めてよい
・逆に5回で終わっても、まだ「〇〇の意識が足りなかった」
のような精神論止まりであれば、分析は不十分実務でよくある誤解は、「とにかく5回『なぜ』を書けば正解」という機械的な運用です。回数を数えることが目的化すると、無理やり理由をひねり出して分析の質が落ちてしまいます。正しい終着点の見極め方は「その原因に対して、具体的で実行可能な対策を打てるかどうか」です。対策が「気をつける」「注意する」「意識を高める」といった精神論にしかならない場合は、まだ掘り下げが足りないというサインです。逆に「濾過機を設置する」「チェックリストの該当項目を追加する」のように、具体的な行動として対策を書ける段階まで来たら、そこがその分析における適切な終着点です。
実務での正しいやり方——原因分析と犯人探しの違い
なぜなぜ分析を職場で導入する際、最も注意すべきなのが「原因分析」と「犯人探し」を混同しないことです。この違いを理解していないと、なぜなぜ分析は形骸化するどころか、職場の心理的安全性を損なう危険なツールになってしまいます。
【原因分析と犯人探しの違い】
犯人探し（NG）
「誰が」ミスをしたのかを特定し、責任を追及する
例：「なぜバグを見逃した？」→「Aさんの確認漏れです」
→ そこで終了、Aさんへの注意で完結
原因分析（OK）
「なぜ」その状況（ミスが起きやすい状態）が
生まれたのかという、仕組み・プロセスを掘り下げる
例：「なぜバグを見逃した？」→「確認漏れがあった」
→「なぜ確認漏れが起きた？」→「チェックリストがなかった」
→「なぜチェックリストがなかった？」→
「レビュープロセスが標準化されていなかった」
→ 対策：レビュー用チェックリストを整備し、
全員が使う運用にする「なぜ」を人（誰が）に向けてしまうと、1回目の「なぜ」で「〇〇さんの不注意」という答えにたどり着き、そこで思考が止まってしまいます。人は原因ではなく、あくまで「その人がミスをしやすい状況・仕組みがなぜ存在したのか」を掘り下げることが重要です。主語を常に「人」ではなく「仕組み・プロセス・環境」に置くことを意識すると、犯人探しに陥りにくくなります。もう一つの実務ポイントは、なぜなぜ分析を一人で行わず、関係者を交えたチームで行うことです。一人で行うと自分の思い込みだけで浅い分析に終わりがちですが、複数の視点を入れることで、見落としていた原因に気づきやすくなります。
自社（サイバーフォレスト）を題材にしたなぜなぜ分析の実例
理解を深めるために、サイバーフォレスト株式会社（CBT-Medical販売・受託開発・SES事業）を題材にした、架空のなぜなぜ分析の実例を3つの事業それぞれについて示します（実際の事業内容と大きく矛盾しない範囲で、説明のために作成したものです）。
【実例①：CBT-Medical事業——問い合わせへの返信が遅れた】
問題：顧客からの問い合わせメールへの返信が3日以上遅れた
なぜ①：返信が遅れた
→ なぜ？ 担当者がメールに気づくのが遅れたため
なぜ②：メールに気づくのが遅れた
→ なぜ？ 問い合わせ専用メールを個人のメールボックスで
管理しており、他の業務メールに埋もれたため
なぜ③：問い合わせを個人メールボックスで管理していた
→ なぜ？ 問い合わせ受付から対応完了までの
共有フローが整備されていなかったため
なぜ④：共有フローが整備されていなかった
→ なぜ？ 顧客数が少なかった創業初期の運用が、
顧客数増加後も見直されずに続いていたため
【真因】問い合わせ件数の増加に対して、
受付・管理の仕組みが追いついていなかった
【対策】問い合わせ管理ツール（共有受信箱・チケット管理）を
導入し、担当者不在時も他メンバーが状況を把握できる
体制にする【実例②：SES事業——エンジニアの契約更新が土壇場になった】
問題：SES契約の更新可否確認が、契約満了の1週間前になって
ようやく行われた
なぜ①：更新確認が直前になった
→ なぜ？ 契約満了日を管理する一覧表が
更新されていなかったため
なぜ②：一覧表が更新されていなかった
→ なぜ？ 案件担当者が変わった際に、
引き継ぎ漏れがあったため
なぜ③：引き継ぎ漏れがあった
→ なぜ？ 契約満了日確認のタイミングが、
個人の記憶・手動確認に依存していたため
なぜ④：個人の記憶に依存していた
→ なぜ？ 契約満了日をリマインドする仕組みが
なかったため
【真因】契約満了日の確認プロセスが属人化しており、
自動的にリマインドされる仕組みがなかった
【対策】契約管理表にリマインド機能（満了60日前・30日前に
自動通知）を組み込み、担当者交代時も引き継ぎ漏れが
起きない仕組みにする【実例③：受託開発事業——納品直前にバグが発覚した】
問題：納品直前の最終確認で、想定外の重大バグが発覚した
なぜ①：重大バグが直前まで発覚しなかった
→ なぜ？ そのバグが起きる操作パターンを
テストしていなかったため
なぜ②：そのパターンをテストしていなかった
→ なぜ？ テストケースが正常系の操作を中心に
作られていたため
なぜ③：正常系中心のテストケースになっていた
→ なぜ？ テスト設計を行う時間が、
スケジュールの後ろ倒しで圧縮されていたため
なぜ④：テスト設計の時間が圧縮された
→ なぜ？ 見積り段階でテスト工程に
十分な期間を確保していなかったため
【真因】見積り段階でのテスト工程の期間見積りが甘く、
スケジュール遅延時にまずテスト工程が
しわ寄せを受ける構造になっていた
【対策】見積りテンプレートにテスト工程の最低確保期間を
明記し、スケジュール調整時にテスト工程を
最初に削らないルールを徹底する3つの実例に共通するのは、「なぜ」を重ねるほど、原因が「個人の不注意」から「仕組み・プロセスの不備」へと移っていく点です。実例①では「担当者がメールに気づかなかった」という個人の行動から出発しても、最終的には「問い合わせ管理の仕組み」という組織的な課題にたどり着いています。これは偶然ではなく、なぜなぜ分析が正しく機能している証拠です。個人の注意力に依存した対策（「次から気をつけます」）ではなく、仕組みで再発を防ぐ対策（ツール導入、リマインド機能、テンプレート整備）にたどり着けたときが、分析が正しく完了したサインだと考えてよいでしょう。
なぜなぜ分析でよくある失敗パターンと対策
なぜなぜ分析はシンプルな見た目に反して、実務では次のような失敗が頻繁に起こります。
【なぜなぜ分析のよくある失敗パターン】
失敗①：「なぜ」の主語が「人」になり、犯人探しになる
→ 対策：主語を常に「仕組み・プロセス・環境」に置き換える
（前述の「原因分析と犯人探しの違い」を参照）
失敗②：1つの「なぜ」に対して原因を1つしか挙げない
→ 対策：実際には1つの問題に複数の原因が
絡んでいることが多い。可能であれば
「なぜ」に対する答えを複数洗い出し、
枝分かれさせて検討する（ロジックツリー
（次回FW-05）との組み合わせが有効）
失敗③：回数だけを目的化し、無理に5回まで続ける
→ 対策：対策可能な粒度に到達したら、
回数にこだわらず打ち切ってよい
失敗④：一人で行い、思い込みだけで完結させる
→ 対策：関係者を交えたチームで行い、
複数の視点から原因を検証する
失敗⑤：最後に出てきた原因に対して、
対策を考えずに分析だけで終わらせる
→ 対策：なぜなぜ分析はゴールではなく手段。
必ず「真因に対する具体的な対策」まで
セットで検討する
失敗⑥：表面的な事実確認をせず、推測だけで
「なぜ」を進めてしまう
→ 対策：可能な限り、各段階で実際に
起きたことを関係者に確認し、
推測と事実を区別する特に失敗①は、なぜなぜ分析が組織に定着するかどうかを左右する最も重要なポイントです。なぜなぜ分析が「吊るし上げの道具」だと認識されてしまうと、次第にメンバーが問題を報告しなくなり、かえって問題の早期発見が遅れるという逆効果を招きます。なぜなぜ分析を導入する際は、「これは個人を責めるためのものではなく、仕組みを良くするためのものである」という前提を、実施前にチーム全体で共有しておくことが欠かせません。
すぐ使えるなぜなぜ分析シート（テンプレート）
実務でそのまま使える、なぜなぜ分析の記入フォーマットを示します。会議やチームでの振り返りの際に、このままコピーして使ってください。
【なぜなぜ分析シート】
■ 分析日： ■ 記入者：
■ 分析対象チーム：
【問題（事実として起きたこと）】
（例：機械が停止した／納品直前にバグが発覚した）
【なぜ①】上記の問題は、なぜ起きたか？
【なぜ②】①の答えは、なぜ起きたか？
【なぜ③】②の答えは、なぜ起きたか？
【なぜ④】③の答えは、なぜ起きたか？
【なぜ⑤】④の答えは、なぜ起きたか？
（対策可能な粒度に到達していれば、④で打ち切ってもよい）
【真因（対策可能な粒度の原因）】
【対策（誰が・いつまでに・何をするか）】
担当： 期限： 内容：
【チェック項目（記入前後に確認）】
□ 「なぜ」の主語が人（誰が）ではなく仕組み・プロセスになっているか
□ 推測ではなく、確認できた事実に基づいているか
□ 対策が「気をつける」等の精神論で終わっていないか
□ 対策に担当者・期限が明記されているか
□ 一人だけでなく、関係者を交えて検討したかこのシートのポイントは、最後の5項目のチェックリストです。なぜなぜ分析は「なぜ」を書き出すこと自体は簡単ですが、質の高い分析になっているかどうかは、この5つのチェック項目を満たしているかで判断できます。特に「対策に担当者・期限が明記されているか」は見落とされがちですが、真因を特定しても対策の実行責任が曖昧なままでは、分析が「やりっぱなし」に終わってしまいます。分析結果を会議の議事録に残すだけでなく、必ず担当者と期限をセットで記録し、次回の振り返りで実行状況を確認する運用にすることをお勧めします。
まとめ
なぜなぜ分析は、「なぜ？」という問いを繰り返すことで、表面的な現象の奥にある根本原因（真因）にたどり着くための思考法です。「5回」という回数は目安に過ぎず、重要なのは具体的な対策を打てる粒度の原因にたどり着くことです。実務で最も注意すべきは、「なぜ」の矛先を人（誰が）ではなく仕組み・プロセスに向け、犯人探しではなく原因分析として運用することです。サイバーフォレストの3つの事業（CBT-Medical・SES・受託開発）の実例で見たように、個人の不注意に見える出来事も、掘り下げていくと組織的な仕組みの不備にたどり着くことが多く、そこにこそ再発防止のための本質的な対策が見つかります。今回紹介したシートを使い、まずは身近な小さな問題から、チームで「なぜ」を繰り返す習慣を作ってみてください。
次回予告
次回（FW-05）では、「ロジックツリー——問題を構造的に分解する思考法」を取り上げます。なぜなぜ分析が「原因を縦に掘り下げる」思考法であるのに対し、ロジックツリーは「問題を横に分解する」思考法です。両者を組み合わせることで、複雑な問題をより網羅的かつ構造的に整理する方法を、具体例を交えて解説します。
サイバーフォレスト株式会社では、業務課題を「使えるIT」で解決するお手伝いをしています。
#サイバーフォレスト #なぜなぜ分析 #5Whys #ビジネスフレームワーク #経営戦略 #問題解決 #トヨタ生産方式 #原因分析 #ビジネス思考 #スタートアップ経営
