「プロジェクトが炎上する本当の原因を、20年のPMが正直に話す——技術の話は、ほぼ関係ない」

✍️ プロローグ｜炎上は、突然来ない

「突然、炎上した」と言うPMは多い。

でも20年間、大小さまざまなプロジェクトに関わってきた私の経験では、炎上が本当に突然来たことは、一度もなかった。

必ず兆候があった。小さな違和感があった。数字を見れば明らかだった。それを見て見ぬふりをした結果が、終盤の爆発だった。

この記事では、炎上の「本当の原因」を正直に書く。技術的な失敗談ではない。人間と組織の、もっと泥臭い話だ。PMである私自身が加害者だった話も含めて。

読んでいて耳が痛くなる人もいると思う。でもそれが、現場の真実だと思っている。

✍️ 第1章｜「技術的な問題」で炎上したプロジェクトは、実は少ない

炎上の原因を聞くと、現場では大抵こういう答えが返ってくる。「要件が複雑すぎた」「技術的に想定外のことが起きた」「外部サービスの仕様変更があった」——。

嘘ではない。でも、本当の原因ではないことが多い。

私が関わった炎上プロジェクトを振り返ると、技術そのものが原因だったケースは2割にも満たない。残りの8割は、人間と組織の問題だった。

「誰がどこまで決める権限を持っているか」が誰も分かっていなかった。まずいと気づいていた人間が誰も声を上げなかった。クライアントと開発側が「了解です」と言いながら、まったく違うものを想像していた。PMが怒られるのを恐れて問題の報告を1ヶ月遅らせた。

技術は、言い訳になりやすい。人間や組織の問題を「技術的な難しさ」に転嫁すると、次のプロジェクトで同じことを繰り返す。

炎上から本当に学ぶには、技術ではなく人間の話をしなければいけない。

✍️ 第2章｜見積もりは最初から無理だった——でも誰も言えなかった

炎上プロジェクトの現場に入って最初にやることは、現状把握だ。スケジュール、コスト、品質、チームの状態——数字を並べていくと、ある事実に気づくことがある。

「これ、最初から無理だったんじゃないか」

受注のために工数を圧縮した。競合に負けないよう納期を短くした。クライアントの要求を全部「できます」と言って受けた。そういうプロジェクトが、一定数ある。

問題は、それを知っていた人間が必ずいるということだ。営業は分かっていた。PM候補も薄々感じていた。でも、契約を取るために、受注を優先するために、「なんとかなる」と自分に言い聞かせた。

私も経験がある。引き継いだプロジェクトのWBSを見た瞬間に「これはどう計算しても間に合わない」と分かった。でも、すでに契約が済んでいた。「前任が合意したことだから」と、前提条件を疑わずに走り始めた。

最初から無理な見積もりのプロジェクトは、PMがどれだけ頑張っても、構造的に追い詰められる。炎上の火種は、キックオフより前に埋め込まれていることがある。

✍️ 第3章｜PMである私が、嘘に嘘を重ねた

これが一番書きにくい話だ。でも、一番大事な話だと思っている。

あるプロジェクトで、私は中盤から「このままでは納期に間に合わない」と気づいていた。数字を見れば2ヶ月前から明らかだった。

でも、報告しなかった。

最初は「まだ挽回できるかもしれない」という希望的観測だった。次第に「報告したら怒られる」という恐怖になった。そのうち「ここまで来たら言い出せない」という状況になった。

代わりに何をしたか。週次報告に「概ね順調」と書き続けた。リスク欄に「対応中」と記入し続けた。チームに無理を言って残業でカバーしようとした。

嘘に嘘を重ねた。

終盤、もう隠しきれなくなった段階でようやく報告した。当然、大混乱になった。2ヶ月早く報告していれば取れた選択肢——スコープの削減、納期の再交渉、増員——が、すべて消えていた。

このときの教訓は今も私の中にある。悪いニュースを一番最初に知っているのはPMだ。そのPMが隠したとき、プロジェクトは詰む。

「報告したら怒られる」は本当かもしれない。でも「報告しなかったとき」の爆発は、その何倍も大きい。

✍️ 第4章｜上長ガチャ・顧客ガチャ——「ポンコツで威張っているだけ」の人間の話

ここからは、もう少しだけ正直な話をする。

炎上の原因が「PM自身の失敗」ではないケースも、当然ある。私が経験した中で、最も消耗したのが「上長ガチャ・顧客ガチャに外れたとき」だ。

具体的にはこういう人物だ。

現場の状況を理解しないまま「もっと頑張れ」しか言わない上長。問題を報告しに行くたびに「なんでそうなったんだ」と詰めるだけで解決策を一切出さない上長。「俺が昔やったときはできた」という昔話しかしない上長。

クライアント側にも似た存在がいる。要件を決める権限がないのに承認の場に出てくる担当者。会議で「いいですね」と言って翌週「やっぱり違う」と言う人。自分の社内の反対意見をPMにぶつけてくる人。

これらは全部、実在した人物だ。

こういう環境に置かれたPMが疲弊するのは、能力の問題ではない。構造の問題だ。 上長や顧客の質は、PMの努力でコントロールできない。

ただ、一つだけ言えることがある。こういう人物の「存在」そのものをリスクとして早期に認識して、対策を立てるかどうかで、被害の大きさが変わる。「なんとかなる」と放置した私は、毎回後悔した。

怒りをぶつけたいわけではない。「これはリスクだ」と早く認識することが、唯一の現実的な対処法だったという話だ。

✍️ 第5章｜クライアントの期待値と、私たちの認識がずっとズレていた

もう一つ、どのプロジェクトでも繰り返された炎上の原因がある。

毎週定例会議をやって、議事録を共有して、レビューを重ねているのに、なぜ最後になって「そんなものを作ってほしかったわけじゃない」という話になるのか。

答えは「会議の場では、本音が出ないから」だ。

クライアントの担当者は、自分の上司の手前、弱気なことを言いにくい。「実は私もよく分かっていないんです」とは言えない。「前回と言っていることが違う」とも言いにくい。だから「問題ありません」「了解しました」が積み重なり、終盤になって本音が噴き出す。

私が何度も経験した中で、最も多かったパターンがこれだ。「言っていないが、当然そうなると思っていた」期待を、最後まで確認しなかった。

要件定義書には書いていない。レビューも通っている。でも完成品を見て「これじゃない」と言われる。

本当の期待値を確認するには、公式の場ではなく非公式の場が要る。定例会議後の雑談、個別でのヒアリング、「正直なところ、どう思いますか？」という直接の問いかけ。こういった非公式のコミュニケーションで初めて、相手の本音が見えてくる。

これをサボったツケは、必ず終盤に来る。

✍️ エピローグ｜炎上は「運の悪さ」ではない

炎上したプロジェクトを振り返るとき、人は「運が悪かった」と言いたくなる。

難しいクライアントに当たった。能力のない上長の下についた。無理な見積もりを押しつけられた——どれも事実だし、外部要因は確かにある。

でも20年間で私が学んだことは、「炎上の8割は、前の段階で取れた選択肢があった」ということだ。

最初の見積もりに無理があったとき、受注前に交渉できた。問題に気づいたとき、2ヶ月早く報告できた。クライアントの本音を、定例会議以外の場で確認できた。ポンコツ上長のリスクを早期に認識して、迂回ルートを作れた。

やらなかったのではなく、やれなかった。組織の圧力、恐怖、経験不足——様々な理由があった。

でもそれを「仕方なかった」で終わらせると、次も同じことを繰り返す。

炎上は運の悪さではなく、早期に手を打てなかった結果だ。だから、次は早く打てる自分になればいい。それだけの話だ。

▼ 「じゃあ、炎上したときどう立て直すか」を 知りたい方へ 最初の48時間で何をするか、 全手順をまとめた有料記事（980円）を書きました。 テンプレート4点付きです。 📌「炎上プロジェクトの救い方」→ リンク