「プロジェクトが炎上する本当の原因を、20年のPMが正直に話す」

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

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

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

必ず、兆候があった。小さな違和感があった。「なんかおかしい」という感覚があった。それを見て見ぬふりをした結果が、終盤の爆発だった。

この記事では、私が経験してきたプロジェクト炎上の「本当の原因」を、できる限り正直に書く。技術的な失敗談ではない。人間と組織の話だ。そして、PMである私自身の失敗の話でもある。

耳が痛い話もあると思う。でもそれが、現場の真実だと思っている。

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

炎上の原因を聞くと、多くの現場でこういう答えが返ってくる。「要件が複雑すぎた」「技術的に難しかった」「外部APIの仕様が変わった」——。

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

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

• 「誰がどこまで決める権限を持っているか」が曖昧だった

• 「このままいくとまずい」と気づいていた人間が、誰も声を上げなかった

• クライアントと開発側が「分かった」と言いながら、まったく違うものを想像していた

• PMが「報告したら怒られる」という恐怖から、問題を上に上げるのを遅らせた

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

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

✍️ 第2章｜原因①｜要件定義の甘さという「静かな爆弾」

炎上の原因として最も多かったのが、要件定義の段階に埋め込まれた「静かな爆弾」だ。

爆弾は2種類ある。

ひとつは「曖昧な合意」だ。
「柔軟に対応できるシステムにしてほしい」「使いやすいUIにしてほしい」——こういった言葉を、確認せずに受け取る。開発側は自分たちの解釈で進め、クライアントは自分たちのイメージ通りのものが来ると思っている。終盤になって初めて、両者の「柔軟」も「使いやすい」も、まったく違うものを指していたと気づく。

もうひとつは「言っていない期待」だ。
クライアントが「当然そうなるはずだ」と思い込んでいるが、一度も口に出していない要件がある。これが一番厄介だ。要件定義書には書いていない。レビューも通っている。でも完成品を見て「これじゃない」と言われる。

私はこの「言っていない期待」を見逃したことで、金融機関向けの大規模プロジェクトで終盤に大炎上を経験した。現場の担当者が「当然こうなる」と思っていたワークフローを、私は一度も確認しなかった。

要件定義は「書いてもらう」作業ではない。「言っていないことを引き出す」作業だ。

✍️ 第3章｜原因②｜PMである私自身が、問題を隠し続けた

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

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

でも、報告しなかった。

理由は単純だ。怖かったからだ。クライアントに怒られる。社内で責任を問われる。プロジェクトが中止になるかもしれない。そういう恐怖が、正直な報告を邪魔した。

代わりに何をしたか。「なんとかなるかもしれない」という希望的観測で進め続けた。残業でカバーしようとした。チームに無理を言い続けた。そして終盤、もう隠しきれなくなった段階でようやく報告した。

当然、大混乱になった。2ヶ月早く報告していれば取れた選択肢が、すべて消えていた。

PMが問題を隠す理由は、大抵「怖いから」だ。怒られたくない。評価を下げたくない。プロジェクトを止めたくない。その気持ちは理解できる。でも、隠せば隠すほど、後の爆発は大きくなる。

「悪いニュースは早く届ける」——これがPMの最も重要な仕事のひとつだと、私は失敗してから学んだ。

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

3つ目の原因は、期待値のズレが最後まで埋まらなかったことだ。

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

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

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

私が学んだのは「会議の場の合意は、本当の合意ではないことがある」ということだ。

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

ズレに気づくのが遅れるほど、修正のコストは指数関数的に増える。

✍️ 第5章｜早期に気づいていたのに、なぜ言い出せなかったのか

「問題には早く気づいて、早く動け」——これはどのPM論でも書いてある。

でも現実は、早期に気づいていても言い出せないことの方が多い。なぜか。

組織が「問題を報告すること」にペナルティを与えているからだ。

問題を報告したら怒られた経験があるPMは、次から報告を遅らせる。悪い情報を持ってきたメンバーが責められる組織では、誰も悪い情報を上げなくなる。「なんとかします」と言い続けることが評価される環境では、「無理です」と言える人間がいなくなる。

これはPM個人の問題ではなく、組織の問題だ。

ただ、個人として今すぐできることもある。まず自分が「悪いニュースを歓迎する」側の人間になることだ。チームメンバーが「実はこれ、まずいかもしれません」と言ってきたとき、怒るのではなく「教えてくれてありがとう、一緒に考えよう」と返すこと。

それだけで、チームの中に「早期報告が報われる」文化の小さな芽が生まれる。炎上予防は、制度ではなく日常の反応から始まる。

✍️ エピローグ｜炎上の「後始末」より「火種の発見」が先だ

炎上プロジェクトの立て直しは、できる。私は何度もやってきた。

でも正直に言う。立て直しはしんどい。チームは疲弊し、信頼は傷つき、失ったものは完全には取り戻せない。

だから「後始末の技術」より「火種を早く見つける習慣」の方が、何倍も価値がある。

今日からできることは3つだ。

ひとつ、週に一度「このプロジェクトで一番まずいことは何か」を自分に問う。
答えを考えること自体が、火種の発見につながる。

ふたつ、クライアントとの会話の中で「言っていない期待」を意識的に探す。
「当然そうなると思っている」ことを、あえて言葉にしてもらう質問を入れる。

みっつ、「問題ない」が続いたときほど疑う。
本当に問題がないプロジェクトは、ほぼない。問題が見えていないか、報告が上がっていないかのどちらかだ。

炎上の本当の原因は、技術ではなく人間と組織にある。そしてその解決策も、技術ではなく人間と組織の中にある。