炎上プロジェクト5つの共通点|PMO歴10年の現場から

炎上プロジェクトとは何か

炎上プロジェクトとは、予算超過、納期遅延、品質問題などが複合的に発生し、プロジェクト関係者が疲弊して収束の見通しが立たなくなった状態を指します。IT業界では決して珍しくない現象です。

私はPMO実務を約10年続けてきましたが、その間に大小さまざまな炎上プロジェクトを目の当たりにしてきました。ある案件は本番2週間前に致命的な設計ミスが発覚し、別の案件は要件定義のやり直しで半年の遅延が確定しました。

興味深いことに、炎上するプロジェクトには明確な共通点があります。それは業界や規模を問わず、驚くほど似通ったパターンで崩壊していくのです。今回は私が実際に見てきた炎上プロジェクトから、5つの共通点を抽出してお伝えします。

教科書では語られない炎上の実態

プロジェクトマネジメントの教科書には、リスク管理の手法や進捗管理の方法論が丁寧に書かれています。PMBOKやPRINCE2といったフレームワークも、理論としては完璧に見えます。

しかし現場では、それらの知識があっても炎上は起こります。むしろ炎上するプロジェクトほど、表面的には正しいプロセスを踏んでいるように見えるのです。

形式だけの進捗会議

週次の進捗会議は必ず開催されます。議事録も残ります。課題管理表も更新されます。しかし実態は、誰も本当の問題を指摘しない会議です。PMは予定通りと報告し、ベンダーは問題ないと答え、ユーザー部門は理解したと頷きます。

私が参画した金融システムの案件では、毎週1時間の進捗会議が開かれていました。しかし会議で報告されるのは作業完了率のパーセンテージだけで、品質の話は一切出ませんでした。本番3ヶ月前になって初めて、誰も気づかなかった根本的な設計ミスが発覚したのです。

数字だけの管理

プロジェクト管理ツールには、タスクの進捗率が細かく入力されています。ガントチャートも美しく色分けされています。しかし数字の裏にある実態を、誰も確認していません。

進捗率80%と報告されているタスクが、実は要件の理解が間違っていて全部作り直しになる。こういうことは日常的に起こります。数字で管理していると安心しますが、数字だけでは何も見えないのです。

問題の先送り文化

炎上するプロジェクトでは、問題が発見されても決断が先送りされます。まだ大丈夫だろう、様子を見ようという空気が支配的になります。そして気づいたときには、もう手遅れになっています。

教科書には早期発見・早期対処と書かれていますが、現場では誰も火中の栗を拾いたがりません。問題を指摘すると責任を取らされると考えるため、みんな見て見ぬふりをします。これが炎上の最大の温床です。

10年間で見てきた炎上の実例

私は金融、保険、製造、公共インフラ、医療、メディア、自動車など、さまざまな業界のプロジェクトにPMOとして参画してきました。その中で最も印象に残っている炎上案件がいくつかあります。

特に記憶に残っているのは、ある保険会社のシステムクラウド化プロジェクトです。プロジェクトメンバーは約200名、予算規模は30億円を超える大型案件でした。要件定義から基本設計、詳細設計と順調に進んでいるように見えていました。

私はPMOとして約10年、多数のプロジェクトを見てきました。炎上プロジェクトには5つの共通点があります。第1は要件定義の曖昧さ。決めないまま開発に進むケース。第2はPMの決断力不足。判断を先延ばしにする方が組むと、必ず炎上します。第3はベンダー間の連携不足。複数ベンダーの認識ズレが放置される状態。第4は経営層のコミット不足。プロジェクトを丸投げして口を出さない姿勢。第5はリスク管理の軽視。楽観的な計画のまま突き進むケース。特に印象的だったのは、200名規模の保険登録システムクラウド化プロジェクトの本番2週間前です。3つのベンダーからは順調と報告されていたのに、実態は仕様齟齬でテストが回らない状態でした。この時は上記5つのうち3つが揃っていて、私は徹夜で調整に走りました。炎上を回避するには、早い段階でこの5つを見抜くことが重要です。

この経験から学んだのは、炎上は突然起こるのではなく、プロジェクト初期から兆候があるということです。その兆候を見逃さないことが、PMOとしての重要な役割だと痛感しました。

別の製造業の案件では、5社のベンダーが参画する複雑な体制でした。各社は自分の担当範囲だけを見て、全体を見る人がいませんでした。結果として、システム間の連携部分で致命的な齟齬が発生し、結合テストの段階で大炎上しました。

医療系のプロジェクトでは、経営層が予算を承認した後、まったく関心を示さなくなりました。現場は苦しんでいるのに、経営層は他人事です。最終的にプロジェクトは頓挫し、責任者が更迭される事態になりました。

炎上プロジェクト5つの共通点

私が見てきた炎上プロジェクトには、驚くほど似通った特徴があります。業界や規模が違っても、失敗のパターンは共通しているのです。ここでは5つの共通点を具体的に解説します。

共通点1:要件定義の曖昧さを放置する

炎上するプロジェクトのほぼすべてで、要件定義が曖昧なまま設計フェーズに進んでいます。ユーザー部門は何となくイメージを語り、開発側は何となく理解した気になります。そして後工程で認識の齟齬が一気に噴出します。

ある公共インフラのプロジェクトでは、発注者側の担当者が3名いて、それぞれ言うことが違いました。開発側は誰の要件が正しいのか分からないまま、とりあえず全部を盛り込もうとしました。結果として、誰も使わない機能が大量に作られ、本当に必要な機能は仕様から漏れていました。

要件定義書が100ページあっても、具体的な判断基準が書かれていないケースがよくあります。ユーザーが操作したときにどうなるべきかという記述はあっても、例外処理やエラー時の挙動については誰も決めていません。開発側が勝手に判断して実装し、テスト段階でユーザーが違うと言い出します。

曖昧さを放置する背景には、誰も責任を取りたくないという心理があります。厳密に要件を定義すると、ユーザー側も開発側も後で変更できなくなります。だから両者とも、わざと曖昧なまま進めるのです。しかしそのツケは必ず後工程で回ってきます。

共通点2:PMに決断力がない

炎上するプロジェクトのPMは、技術的な知識は豊富でも決断力に欠けています。問題が発生したときに、誰かに判断を委ねようとします。あるいは複数の選択肢を示すだけで、自分では決めません。

保険システムのプロジェクトで、PMが開発ベンダーとユーザー部門の板挟みになっている場面を見ました。ユーザーは機能追加を要求し、開発側は予算と納期が守れないと主張します。PMは両者の言い分を聞くだけで、どちらの意見を採用するか決められませんでした。

結局、その案件では決断を先送りし続けた結果、両方の要求を中途半端に満たす形になりました。ユーザーは不満を持ち、開発側は過度な負荷で疲弊し、品質も劣化しました。三方一両損どころか、全員が損をする結果です。

PMが決断できない理由は、責任を取りたくないからです。決断すれば誰かが不満を持ちます。自分がその矢面に立ちたくないのです。しかしPMが決断しなければ、プロジェクトは漂流します。誰も舵を取らない船は、必ず座礁します。

共通点3:ベンダー間の連携が機能しない

大規模なプロジェクトでは、複数のベンダーが参画します。プライムベンダー、サブベンダー、さらに専門領域の協力会社など、体制は複雑になります。しかし各社が自分の担当範囲しか見ていないと、システム全体の整合性が取れなくなります。

自動車業界のプロジェクトでは、フロントシステムをA社、バックエンドをB社、インフラをC社が担当していました。各社とも優秀なエンジニアを投入していましたが、3社間のコミュニケーションはほとんどありませんでした。結合テストの段階で、データのフォーマットが合わない、API仕様の解釈が違う、性能要件を誰も確認していないといった問題が次々と発覚しました。

ベンダー間の連携が機能しない背景には、契約の壁があります。各社は契約範囲外の作業はやりたがりません。問題が発生しても、それは自分の範囲ではないと主張します。PMOが全体を調整しようとしても、各社の利害が対立して前に進みません。

さらに悪いことに、ベンダー間で情報が共有されません。A社が持っている設計情報をB社が知らず、B社の実装方針をC社が理解していません。プロジェクト全体の設計書は存在しても、誰もそれを読んでいないのです。

共通点4:経営層のコミットがない

炎上するプロジェクトでは、経営層がプロジェクトを他人事として扱っています。予算は承認したが、後は現場に任せたという姿勢です。問題が発生しても、現場で何とかしろと突き放します。

医療システムの案件では、病院の理事長がプロジェクトのキックオフには出席しましたが、その後は一度も進捗を確認しませんでした。現場では要件の優先順位が決まらず、各部署が自分の要求を押し通そうとして混乱していました。しかし経営層が判断しないため、プロジェクトは迷走しました。

経営層のコミットがないと、現場は重要な決断ができません。予算の追加が必要でも承認が得られず、スコープの変更が必要でも決裁されず、リスクが顕在化しても経営判断が下りません。結果として、現場は小手先の対応で何とかしのごうとし、問題はさらに深刻化します。

経営層がコミットしない理由は、ITプロジェクトを理解していないからです。システム開発は専門家に任せておけば大丈夫だと考えています。しかしプロジェクトの成否は、技術的な問題ではなく、経営判断が必要な場面で決まるのです。

共通点5:リスク管理を軽視する

炎上するプロジェクトでは、リスク管理表は存在しても機能していません。形式的にリスクは列挙されていますが、誰も本気で対策を考えていません。そしてリスクが顕在化したときに、想定外だったと言い訳します。

製造業のプロジェクトで、外部APIの仕様変更というリスクが管理表に記載されていました。しかし対策欄には注視すると書かれているだけで、具体的な行動は何も取られていませんでした。案の定、本番3ヶ月前にAPI仕様が大幅に変更され、システム全体の改修が必要になりました。

リスク管理を軽視する背景には、リスクを指摘すると評価が下がるという空気があります。問題を報告した人が責任を取らされるため、誰もリスクを表に出したがりません。みんな問題ないことにして、プロジェクトを進めようとします。

私が見てきた炎上プロジェクトの多くで、リスクは初期段階で認識されていました。しかし誰もそれを声に出して言いませんでした。そして時間が経つほど、そのリスクは言い出しにくくなります。最終的に爆発するまで、誰も触れないのです。

炎上を防ぐために本当に必要なこと

炎上プロジェクトの共通点を見てきましたが、教科書的な対策では防げないことが分かります。プロセスを整備しても、ツールを導入しても、根本的な解決にはなりません。

私が10年間のPMO実務で学んだのは、炎上を防ぐために必要なのは技術ではなく文化だということです。問題を隠さない文化、決断する文化、責任を共有する文化です。

問題を指摘した人を守る仕組み

炎上を防ぐ最も重要なポイントは、問題を早期に表に出すことです。しかし現実には、問題を指摘した人が攻撃されます。お前が言い出したのだから対策を考えろと責任を押し付けられます。

私は問題を報告してきたメンバーを、必ず守るようにしています。問題を指摘したことは正しい行動だと明言し、その場で対策を考えるのは全員の責任だと伝えます。問題を隠した人を評価せず、問題を報告した人を評価する空気を作ることが、PMOの重要な役割だと考えています。

決断のスピードを上げる

炎上するプロジェクトは、決断が遅いという共通点があります。問題が発生してから対策を決めるまでに、何週間もかかります。その間に問題はさらに悪化します。

私が参画するプロジェクトでは、問題が報告されたら48時間以内に方針を決めるというルールを設けています。完璧な解決策でなくても構いません。とりあえず方向性を決めて、動き出すことが重要です。間違っていたら修正すればいいのです。

全体を見る人を置く

複数ベンダーが参画するプロジェクトでは、誰も全体を見ていないという問題が起こります。各社は自分の範囲しか見ません。この問題を解決するには、全体を見る専任の人を置くしかありません。

私はPMOとして、各ベンダーの担当範囲を超えた部分を常に気にしています。システム間の連携部分、誰の責任範囲にも入っていない領域、契約書に書かれていない作業などです。そこに問題が潜んでいることを、経験上知っているからです。

経営層を巻き込み続ける

経営層は放っておくと、プロジェクトから離れていきます。現場に任せたと言って、関心を失います。しかし重要な局面では、必ず経営判断が必要になります。

私は経営層向けの報告を、形式的な進捗報告ではなく、判断を求める報告にしています。このままだとこういう問題が起こる、今決めてほしいことは何かを明確に伝えます。経営層を逃がさないことが、PMOの重要な仕事だと考えています。

リスクを語れる場を作る

リスク管理表は形骸化しやすいツールです。形式的に記入するだけで、誰も本気で議論しません。だから私は、リスクを語る場を別に設けています。

月に一度、プロジェクトメンバーが集まって、心配していることを自由に話す会です。管理表には載せないけれど、何となく不安に思っていることを共有します。そこで出た話題の中から、本当に対策が必要なリスクを特定します。形式ではなく、対話が重要なのです。

炎上の兆候を見逃さないチェックリスト

最後に、あなたのプロジェクトが炎上する前兆がないか、確認してほしい項目をまとめました。一つでも当てはまったら、黄色信号です。早めに対策を打ってください。

チェック項目	確認ポイント	危険度
要件の曖昧さ	要件定義書の例外処理やエラー時の挙動が、具体的に記述されているか。曖昧な表現で後で決めるとなっていないか。	高
決断の先送り	課題管理表で1ヶ月以上担当者未定または対策未定の項目がないか。重要な判断が保留されていないか。	高
ベンダー間の溝	各ベンダーの担当者同士が直接コミュニケーションを取っているか。連携部分の仕様が明文化されているか。	中
経営層の関心度	経営層が最後にプロジェクトの状況を確認したのはいつか。重要な判断事項を経営層に上げても反応が遅くないか。	中
リスクの放置	リスク管理表に記載されているリスクに、具体的な対策と担当者が割り当てられているか。注視するだけの項目が多くないか。	高
問題報告の頻度	最近、新しい問題が報告されているか。すべて順調という報告ばかりになっていないか。	中
メンバーの疲労度	プロジェクトメンバーが長時間労働を続けていないか。疲弊した表情や無関心な態度が見られないか。	高

炎上プロジェクトは突然起こるのではなく、必ず兆候があります。その兆候を見逃さないこと、そして見つけたら即座に対処することが、PMOとして最も重要な仕事です。

私はこれからも現場で、プロジェクトの炎上を防ぐために動き続けます。完璧なプロジェクトなど存在しませんが、炎上させないプロジェクトは作れます。そのためには、教科書の知識ではなく、現場の経験と勇気が必要なのです。