発注側でプロジェクトを回すと、「なぜこんなことになったの？」と問われる場面が必ず来ます。仕様の取り違え、期日遅延、品質不良—見えている事象はバラバラでも、原因を一本の糸でたぐり寄せて、再発を防ぐ約束を言葉と資料で示すのが事業側プロマネの仕事です。本稿では、ITに明るくないビジネスパーソンでも使いこなせる「なぜなぜ分析（5 Whys）」を、現場の具体例と上層部・協力会社への説明の作法にまで落として解説します。炎上の後始末ではなく、次の成功確率を上げるための実務として身につけてください。
Contents
現場視点で学ぶ事業側プロマネのなぜなぜ分析（5 Whys）基礎と上層部説明への効き目
なぜなぜ分析（5 Whys）は、目の前の不具合に対して「なぜ？」を繰り返し問い、真因にたどり着くためのシンプルなフレームワークです。特別なツールは不要で、会議室のホワイトボードと事実情報があれば始められます。重要なのは「犯人探し」ではなく「仕組みを変える手がかり」を見つける姿勢です。事業側プロマネにとっての価値は、技術の細部ではなく、意思決定と体制に潜む再発要因をあぶり出せる点にあります。
なぜなぜ分析が効く理由は、説明責任の構造を整えるからです。多くのトラブルは複合要因で起きますが、上層部には「全体像」「再発防止の筋の良さ」「費用対効果」が伝われば十分です。5回の「なぜ」を通じて、現場の事実を因果でつなぎ、可視化可能な対策に落とす過程自体が、意思決定者への説得材料になります。結果だけでなく、たどり着いた思考の道筋を示せるのが強みです。
進め方の基本は三点セットです。1) 事実（いつ・どこで・何が起きたか）を証跡付きで固定する、2) なぜを一段ずつ書き出し、推測には「仮説」と明記する、3) 各段に対して「是正できる管理対象か」を判定する。制御可能な原因に到達したら、そこで打ち止めにして対策へ移ります。制御不能（外部環境など）に到達した場合は、リスク管理や契約見直しに軸足を移すのが正しい反応です。
注意すべきは「症状」と「原因」を混同しないことです。「仕様が変わった」は症状であり、「なぜ変わったのか」が原因の入口です。また、単一原因に執着せず、分岐がある場合は枝分かれのまま残して構いません。5回という回数は目安で、3回で十分な時もあれば7回必要な時もあります。大切なのは、事実に裏打ちされた因果の鎖が、再発を防げるレベルまで深くなっているかどうかです。
事業側プロマネの現場では、人・プロセス・契約・データの四層を意識して掘り下げると効果的です。同じ「納期遅延」でも、人（担当者の過負荷）、プロセス（承認経路の長さ）、契約（変更管理の欠落）、データ（見積の根拠精度）と層が違えば打つ手も違います。各層で「いま自分が変えられること」を具体化することで、実装可能な再発防止に変換できます。
上層部への効果は二つあります。第一に、原因を構造化して「投資すべきはここ」と示せるため、意思決定が早まること。第二に、協力会社との関係が健全化することです。「人の問題です」で終わらせず「プロセスと契約の設計が原因です」と言語化できれば、相手も自社も納得できる落としどころを見つけやすい。結果として、責任の押し付け合いを避け、共通の改善プロジェクトに転換できます。
要件ズレ炎上を題材に5回のなぜで深掘りする現場ヒアリングと失敗の芽の見つけ方実践術
題材はよくある「要件ズレ」。新ECのリニューアルで、リリース直前に会員移行の仕様が想定と異なり大量の問い合わせが発生、ベンダー追加見積と期限延長が必要になったとします。まず、事実の固定から始めます。問い合わせ件数、再現条件、関連チケット、議事録、要件定義書の版数、承認日付を集め、時系列に並べて「何が、いつ、どの成果物で、誰の承認のもとで決まったか」を確定します。感情や評価は書き込まず、証憑ベースで線を引くのがコツです。
次に、5回の「なぜ」で因果の鎖を作ります。例：なぜ1 要件がズレたから（現象）→ なぜ2 会員移行の業務ルールが仕様に反映されていなかったから（直接原因）→ なぜ3 ルールを説明した担当者と要件定義書の作成者が異なり、記録が口頭中心だったから（情報伝達の欠落）→ なぜ4 要件レビューのチェックリストに「移行パターンの網羅」と「例外規約の参照」が項目化されていなかったから（プロセス不備）→ なぜ5 チェックリスト策定時にカスタマー業務の代表者を巻き込む仕組みがなかったから（体制設計の欠陥）。このレベルまで来ると、再発防止は「人ではなく仕組み」で打てます。
並行して、別枝の「なぜ」も拾います。例：なぜ1 直前までズレに気づけなかった→ なぜ2 スプリント内で業務側の受け入れテストが実施されなかった→ なぜ3 テスト観点の作成がベンダー依存で、業務シナリオが不足していた→ なぜ4 業務側のテスト時間が確保されておらず、計画時点で調整されていなかった→ なぜ5 プロジェクト計画に「業務側のテスト稼働を確保する稟議・人員交代計画」が欠けていた。ここでも、解決すべきは人的努力ではなく、計画と組織の取り決めです。
ヒアリングは「相手を詰める場」ではなく、「事実の欠片を集める場」です。質問はオープンに、そして時系列・成果物・判断者の三点に必ず触れます。例：「その判断はどの文書のどの箇所に記録がありましたか？」「決めた時点で他の選択肢は検討されましたか？」「承認したのは誰で、どの会議体でしたか？」。意見が食い違ったら、いったん両方を事実候補として保留し、証憑で後日確定させます。
「失敗の芽」を見つけるには、早期警戒の指標を用意します。要件変更チケットの発生密度、要件定義書の版数増加スピード、FAQの未確定項目数、受け入れテスト観点のカバレッジ率など、可視化できるものに絞ります。週次で傾向線を見て「一定の閾値を超えたら是正アクション」を定義しておくと、炎上前に止められます。KPIは少数精鋭（3～5個）にすると運用が続きます。
5 Whysは単独で万能ではありません。要因が多岐にわたる場合は、特性要因図（魚の骨）で候補を洗い出したのち、主要な骨に対して5 Whysで縦に掘るとよいです。また、三現主義（現場・現物・現実）を徹底し、会議室だけで完結させないこと。実機画面、実データ、実ログに触れた上で、因果を確定しましょう。ここをサボると、観念的な改善案になり効きません。
掘り下げの止めどきは「自分たちがコントロール可能な層に到達したか」で判断します。例えば「法改正が直前だった」は外部要因ですが、事業側ができるのは「法改正ウォッチのオーナー設置」「契約上の変更リードタイム条項」「影響評価の定期ゲート」です。外部要因で止めず、制御可能な管理策まで橋を架けたら、分析は合格点です。
再発防止策を上層部・協力会社に通す資料化術A3報告と説明トーク、合意形成の型とNG例
上層部・協力会社を動かすには、A3サイズ1枚で「何が起き、なぜ起き、どう防ぐか」を一気に伝える構成が有効です。推奨の流れは、1) 背景と被害（数値）、2) 現象の時系列（事実）、3) 5 Whysの因果連鎖（真因）、4) 再発防止策（制度・プロセス・体制・ツール）、5) 実施計画とコスト、6) 成果指標と監視方法、7) リスクと代替案。各ブロックは50～100文字で要点化し、図は最小限に。読む側が3分で全体像を掴める密度にします。
数値は「ビフォー／アフター」を意識して設計します。例：問い合わせ件数をリリース週で800件→次回200件以下へ、要件変更チケット率をスプリントあたり15%→5%へ、受け入れテスト観点カバレッジを60%→90%へ。対策と指標を紐づけ、「この施策でこの数字が下がる／上がる」と線で示すと、投資判断が通りやすくなります。「期待効果の根拠」は過去データ／ベンチマーク／パイロットの結果で補強します。
説明トークの型は、1) 先に結論（再発防止の柱は3つ）、2) 根拠（5 Whysの真因）、3) コストと代替案（小・中・大の三案）、4) リスク（やらない場合の損失）です。時間が短い経営会議では、資料の読み上げではなく「判断してほしい論点」を明確に切り出します。協力会社には「責任追及」ではなく「関係設計のアップデート」として語り、契約条項・役割分担・変更管理プロセスの見直しを合意形成の中心に据えます。
再発防止策は「人に頑張らせる」ではなく「仕組みに埋め込む」が基本です。具体例：要件レビューに「業務代表の承認サイン」を必須化、チェックリストに「移行パターン網羅」と「例外規約の参照」を追加、受け入れテストに業務側の確定稼働をPMOが事前ロックし、稟議テンプレートに「テスト稼働確保の根拠」欄を追加、変更管理は「閾値超過時は必ず経営ゲート再承認」。これらをA3の「実装手順」「責任者」「期限」で明記します。
協力会社との合意形成では、RACIとSLAを再定義します。RACI（責任分担）は、要件定義・レビュー・受け入れテスト・変更管理それぞれにオーナーを明文化し、SLAは「要件変更通知から見積提示までのリードタイム」「影響範囲評価の粒度」「欠陥密度の報告周期」など、行動指標を数値で握ります。曖昧な言葉を避け、「いつ・誰が・何を・どの水準で」を契約付帯文書に落としましょう。
避けたいNGは三つです。1) 個人責任に還元する（再発する）、2) 対策が抽象的（運用で吸収に化ける）、3) 経営にとっての意思決定材料が不足（通らない）。NGを避けるために、A3の最後に「決裁事項（Yes/No）」「必要なリソース」「意思決定の期限」を赤枠で載せます。会議の場では、反対意見を先回りして「懸念と対処」を一枚にまとめ、代替案（段階導入・パイロット）の用意で合意へのハードルを下げます。
なぜなぜ分析は、難しい理論ではなく「事実にこだわり、因果でつなぎ、仕組みで防ぐ」ための思考の型です。事業側プロマネがこの型を使いこなせば、炎上の後始末は「責任追及の消耗戦」から「再発防止の投資判断」へと質的に変わります。現場のヒアリングで因果を確かめ、A3で筋の良い対策に結晶化し、上層部と協力会社を同じ地図の上に乗せる—この一連の流れをルーチンにしてください。次のトラブルは必ず来ますが、次の失敗は避けられます。まずは直近案件の小さな不具合から、5 Whysを一度、丁寧にやってみましょう。
コメント