炎上プロジェクトの現場で本当に起きていること
炎上プロジェクトに投入されるPMOの仕事は、教科書で学ぶプロジェクトマネジメントとはまったく違います。私は30年のIT業界キャリアの中で、何度も炎上プロジェクトの立て直しに関わってきましたが、現場に入った瞬間に感じるのは、理論が通用しない混沌とした空気です。
炎上しているプロジェクトには共通した特徴があります。誰もが忙しそうに動いているのに成果物が進んでいない。会議は毎日のように開かれるのに何も決まらない。ベンダー間で「聞いていない」「それは契約範囲外だ」という言い合いが日常化している。そして何より、現場のメンバーの表情から生気が失われています。
私が最も記憶に残っているのは、ある200名規模の大型プロジェクトです。本番稼働まで残り3ヶ月というタイミングで、PMOとして火消しに入りました。
私は30年のIT業界キャリアの中で、PMOとして炎上プロジェクトを何度も救ってきました。特に印象的だったのは、200名規模の保険登録システムクラウド化プロジェクトの本番カットオーバー2週間前です。3つのベンダーからは『順調』と報告されていたのに、実態は仕様齟齬でテストが回らない状態。当時PMOだった私はまず全体像を掴むため、各ベンダーのリーダーに個別ヒアリングを実施。次に課題を『致命的』『重要』『後回し可』の3階層に仕分け、致命的なものから経営層のリソースを引き出しました。チームのメンタルも崩れかけていたので、朝会を『進捗確認』から『昨日の勝ちを共有する場』に変更。当時は残業も多い時期でしたが、今なら『健全な稼働時間の中で、優先順位をつけて対応する』のがPMOの本来の役割だと感じます。実際、現代のプロジェクトでは『無理な稼働で乗り切る』文化を残さないことも、PMOの重要な仕事の1つになっています。炎上時のPMOは『冷静に全体像を掴み、人の力を最大限引き出す』ことに尽きます。
この状況で、私はPMOとして何をすべきか。まず分かったのは、「正論」を振りかざしても誰も動かないということでした。炎上プロジェクトでは、教科書的なプロジェクトマネジメント手法をそのまま適用しても機能しません。現場は既に疲弊しきっており、新しいルールやプロセスを押し付けても反発されるだけです。
必要なのは、今この瞬間にプロジェクトを前に進めるための、即効性のある具体的な動きです。それも、理論ではなく現場で本当に効く動き。私が30年の経験で学んだのは、炎上プロジェクトにおけるPMOの役割は「管理者」ではなく「調整者」であり「支援者」だということでした。
炎上の兆候は必ず事前に現れている
振り返ってみると、プロジェクトが炎上する前には必ず兆候があります。私が経験した炎上案件のほとんどで、初期段階から以下のような兆候が見られました。
- 週次報告では「順調」と報告されているのに、現場メンバーの残業時間が急増している
- 課題管理表の未解決課題が増え続けているのに、エスカレーションされない
- ステークホルダー間の会議で、同じ議題が何週も繰り返し議論されている
- 仕様変更の依頼が頻発し、影響範囲の調整が追いついていない
- ベンダー間の連携会議で、「それは聞いていない」という発言が増えている
こうした兆候を見逃さず、早期に手を打てるかどうかが、PMOの腕の見せ所です。しかし現実には、これらの兆候が見えていても「まだ大丈夫」「本番までには何とかなる」という楽観的な判断で放置され、気づいたときには手遅れになっているケースが非常に多いんですよね。
200名規模プロジェクトの現場に入って最初に見たもの
先ほど触れた200名規模のプロジェクトで、私が現場に入って最初に見たのは、完全に分断された組織でした。元請けベンダー、協力会社A、協力会社B、そして顧客側のIT部門。それぞれが別々の課題管理表を持ち、別々の進捗会議を開き、別々の認識でプロジェクトを進めていました。
特に深刻だったのは、各ベンダーが自社の契約範囲だけを守ろうとしていたことです。「この機能は当社の契約範囲外です」「その作業は別ベンダーの担当です」という言葉が、会議のたびに飛び交っていました。誰もプロジェクト全体の成功を考えておらず、自社の責任範囲を守ることだけに必死になっていたのです。
このような状態では、どれだけ優秀なエンジニアがいても、どれだけ予算を追加投入しても、プロジェクトは前に進みません。必要なのは、技術的な解決策ではなく、人と組織を動かすための調整力でした。
なぜプロジェクトは炎上するのか
30年間、様々な炎上プロジェクトを見てきて分かったのは、炎上の原因は技術的な問題ではなく、ほとんどが人と組織の問題だということです。システム開発の技術は年々進化していますが、プロジェクトが炎上する構造的な原因は30年前からほとんど変わっていません。
情報の非対称性が生む認識のズレ
炎上プロジェクトで最も深刻な問題は、情報の非対称性です。プロジェクトマネージャーが見ている情報と、現場のエンジニアが見ている情報が違う。顧客が理解している進捗と、ベンダーが報告している進捗が違う。この「認識のズレ」が積み重なって、やがて取り返しのつかない事態を招きます。
例えば、進捗率80%という報告があったとします。PMは「あと20%で完成」と理解しますが、現場エンジニアの認識は違います。残り20%には、最も難易度の高い機能実装が含まれていたり、テストで見つかる大量のバグ修正が含まれていなかったりします。私が見てきた炎上案件の多くで、この「進捗率の錯覚」が問題を隠蔽していました。
責任の所在が曖昧になる構造
大規模プロジェクトでは、複数のベンダーが関わることが一般的です。元請け、協力会社、さらに再委託先と、多層構造になっているケースも珍しくありません。この構造が、責任の所在を曖昧にします。
何か問題が起きたとき、「それは別ベンダーの責任範囲です」「契約書にはそこまで書かれていません」という言葉が出てきます。契約上の責任範囲を明確にすることは重要ですが、炎上プロジェクトでは、その「契約の壁」が問題解決を妨げる最大の障害になります。
私が経験した金融系の大型プロジェクトでは、契約上の責任範囲を巡って、ベンダー間で1ヶ月以上も協議が続いたことがありました。その間、実際の開発作業はほとんど進みませんでした。本番稼働日は刻一刻と近づいているのに、「誰がやるか」の議論だけで時間が過ぎていく。この状況を打開するのが、PMOの最も重要な役割でした。
現場の疲弊が生む悪循環
炎上プロジェクトのもう一つの特徴は、現場メンバーの疲弊です。長時間労働が常態化し、休日出勤が当たり前になり、メンバーの表情から笑顔が消えていきます。疲弊したメンバーは、ミスを犯しやすくなり、コミュニケーションの質が下がり、さらなる問題を引き起こします。
私が見てきた炎上案件では、メンバーの離脱が相次ぐケースも多くありました。優秀なエンジニアほど、炎上プロジェクトの先行きを見通して、早めに離脱します。残されたメンバーは、さらに負荷が増え、さらに疲弊する。この悪循環を断ち切ることが、PMOの重要な仕事の一つです。
30年の経験から言えるのは、技術的な問題は時間と人員を投入すれば解決できるが、組織の問題や人の疲弊は、単純に時間や人員を投入しても解決しないということです。むしろ、問題を悪化させることさえあります。炎上プロジェクトの立て直しには、技術論ではなく、人と組織を動かすマネジメントが必要なのです。
炎上プロジェクトでPMOが本当にすべき5つの動き
ここからは、私が30年の現場経験で学んだ、炎上プロジェクトにおいてPMOが本当にすべき5つの動きを紹介します。これは教科書に書いてある理論ではなく、実際の炎上現場で効果があった具体的な行動です。
動き1:まず全体像を掴む——72時間以内の現状把握
炎上プロジェクトに投入されたPMOが最初にすべきことは、全体像の把握です。私は炎上案件に入ったら、必ず最初の72時間で以下の情報を集めます。
- プロジェクトの当初計画と現在の進捗の乖離状況
- 主要なステークホルダーとその関係性、力学
- 現在抱えている課題とリスクの一覧(表面化していないものを含む)
- 各ベンダーの契約範囲と実際の作業分担
- 現場メンバーの稼働状況と疲弊度
この現状把握で重要なのは、公式な報告書や会議資料だけでなく、現場メンバーとの1対1の会話から得られる情報です。私は必ず現場に足を運び、実際に作業しているエンジニアと直接話をします。「報告書では見えない本当の問題」は、現場の雑談の中にこそ隠れているんですよね。
200名規模のプロジェクトでも、私は最初の3日間で、主要なメンバー30名以上と個別に話をしました。そこで分かったのは、公式な進捗報告では「80%完了」となっている機能が、実際には「動くが品質が低すぎて本番では使えない」状態だったことです。この情報は、現場のエンジニアと直接話さなければ絶対に得られませんでした。
動き2:優先順位を明確化する——何を捨てるかを決める
全体像を把握したら、次にすべきことは優先順位の明確化です。炎上プロジェクトでは、すべてを完璧にやろうとすると必ず失敗します。限られた時間とリソースの中で、「何をやるか」よりも「何を捨てるか」を決めることが重要です。
私がPMOとして最も重視するのは、「本番稼働日に絶対に必要な機能」と「後回しにできる機能」の峻別です。顧客は「すべての機能が必要」と言いますが、本当にすべてが初日から必要なケースは稀です。PMOの仕事は、顧客と一緒に優先順位を再定義し、段階的なリリース計画を組み直すことです。
先ほどの200名規模プロジェクトでは、当初予定していた120の機能のうち、本番稼働日には40の機能に絞り込みました。残りの80機能は、稼働後3ヶ月以内に段階的にリリースする計画に変更しました。これにより、開発チームは重要機能に集中でき、品質を確保する時間も生まれました。
この「捨てる決断」をするには、顧客との信頼関係が必要です。単に「無理です」と言うのではなく、「この優先順位で進めれば、確実に本番稼働できます」という代替案を示すことが重要です。私は必ず、削減した機能の代替策やリリース後の追加実装計画を具体的に示し、顧客が納得できる形で優先順位を調整しました。
動き3:ステークホルダーの再調整——対立から協力へ
炎上プロジェクトでは、ステークホルダー間の対立が必ず存在します。顧客とベンダー、元請けと協力会社、開発チームと運用チーム。それぞれが自分の立場を守ろうとして、プロジェクト全体の成功が二の次になっています。
PMOの重要な役割は、この対立構造を協力関係に変えることです。私が実践しているのは、「共通の敵」を設定するアプローチです。共通の敵とは、「本番稼働の失敗」です。すべてのステークホルダーにとって、本番稼働が失敗すれば損失を被ります。この共通認識を醸成することで、対立から協力へとシフトさせます。
具体的には、週次で全ステークホルダーが参加する「全体調整会議」を設置しました。この会議では、各社の進捗報告ではなく、「プロジェクト全体として今週クリアすべき課題」を共有し、「誰が何をするか」を全員で決めます。契約上の責任範囲の議論は別の場で行い、この会議では「プロジェクト成功のために必要な行動」だけにフォーカスしました。
最初は各社とも警戒していましたが、2週目、3週目と続けるうちに、会議の雰囲気が変わっていきました。「それは当社の範囲外です」という発言が減り、「その課題なら当社が対応できます」という前向きな発言が増えていきました。対立していたベンダー同士が、会議後に自発的に調整ミーティングを設定するようにもなりました。
動き4:チームのメンタル支援——小さな成功体験を積ませる
炎上プロジェクトで見落とされがちですが、私が最も重要だと考えているのが、チームのメンタル支援です。疲弊しきったメンバーに「頑張れ」と言っても効果はありません。必要なのは、「このプロジェクトは立て直せる」という希望を持たせることです。
私が実践しているのは、「小さな成功体験」を意図的に作ることです。優先順位を明確化した後、最初の2週間で達成可能な小さなマイルストーンを設定します。例えば、「今週中に〇〇機能のテストを完了させる」「金曜日までに顧客との仕様確認を終える」といった、確実に達成できる目標です。
そして、その小さな目標を達成したら、必ずチーム全体に共有し、称賛します。私は毎週金曜日の夕方に、15分程度の「今週の成果共有会」を開いていました。そこで達成できたことを振り返り、メンバーの頑張りを認める時間を作りました。
この小さな成功体験の積み重ねが、チームの雰囲気を変えていきます。「どうせ無理だ」という諦めムードから、「やればできるかもしれない」という希望のムードへ。この変化は、プロジェクトの生産性に直結します。私が関わった炎上案件では、メンバーのモチベーションが回復した後、生産性が30%以上向上したケースもありました。
動き5:継続的なコミュニケーション——透明性の確保
炎上プロジェクトで最も重要なのは、継続的なコミュニケーションと情報の透明性です。問題を隠蔽せず、現状を正確に共有し、全員が同じ情報を持っている状態を維持することが、PMOの最大の仕事です。
私は炎上案件では、必ず毎日の「デイリースタンドアップミーティング」を実施します。時間は15分程度。各チームから、昨日やったこと、今日やること、困っていることを簡潔に報告してもらいます。この毎日のコミュニケーションが、問題の早期発見につながります。
また、週次では顧客を含む全ステークホルダーに対して、進捗レポートを配信します。このレポートでは、良い情報だけでなく、悪い情報も包み隠さず共有します。「今週発生した問題」「現在抱えているリスク」「対策の進捗」を明確に記載します。
問題を隠蔽すると、必ず後で大きな問題として噴出します。私の経験では、悪い情報を早めに共有したプロジェクトの方が、最終的には成功率が高いです。顧客も、問題を隠されるよりは、正直に報告してもらった方が信頼できるものです。透明性の確保は、ステークホルダーとの信頼関係構築にも直結します。
現代のツールでPMOの動きを支援する
ここまで紹介した5つの動きは、30年前から本質的には変わっていません。しかし、現代のITツールを活用することで、これらの動きをより効率的に、より確実に実行できるようになりました。私が現場で実際に使っているツールを紹介します。
Backlogは、課題管理とプロジェクト全体の可視化に使っています。炎上プロジェクトでは、複数のベンダーが別々の課題管理表を持っていることが多いですが、Backlogに統一することで、全員が同じ情報を見られるようになります。私がBacklogを推奨する理由は、UIが直感的でITに詳しくない顧客側のメンバーでも使いやすいことです。炎上案件では、新しいツールの学習コストは極力下げたい。Backlogなら、導入初日から使えます。また、ガントチャート機能で全体スケジュールを可視化できるため、ステークホルダーへの報告資料作成の手間も減ります。
Slackは、デイリーコミュニケーションの中心ツールとして使います。炎上プロジェクトでは、メールのやり取りでは遅すぎます。Slackのチャンネルを用途別に分け(全体連絡用、技術課題用、顧客調整用など)、リアルタイムで情報共有します。私が30年の現場経験から感じるのは、問題は「報告するタイミング」を逃すと手遅れになるということです。Slackなら、問題が起きた瞬間に関係者全員に共有でき、即座に対策を協議できます。また、スレッド機能で議論の履歴が残るため、「言った言わない」のトラブルも減ります。
Notionは、プロジェクトのナレッジベースとして活用しています。炎上プロジェクトでは、仕様変更や決定事項が頻繁に発生します。これらの情報を一元管理しないと、「どれが最新の仕様か分からない」という混乱が生じます。Notionのデータベース機能を使えば、仕様書、議事録、決定事項を構造化して管理でき、検索性も高い。私が現場で使うなら、Notionの「関連付け機能」が特に便利です。ある仕様変更が、どの課題に関連し、どの議事録で決定されたかを紐付けられるため、情報の追跡が容易になります。
30年現場にいた私が思うこと
30年間IT業界で働き、何度も炎上プロジェクトの立て直しに関わってきた私が思うのは、炎上プロジェクトは決して特別なことではないということです。どれだけ優秀なPMがいても、どれだけ綿密に計画を立てても、プロジェクトは炎上するリスクを常に抱えています。
重要なのは、炎上を恐れるのではなく、炎上したときにどう対処するかを知っておくことです。私がPJM-A資格を取得したのも、理論を学ぶためではなく、体系的な知識を持つことで、現場での判断精度を上げるためでした。理論と実践の両方を持つことが、PMOには必要だと考えています。
炎上プロジェクトの立て直しで最も大切なのは、技術力でもマネジメントスキルでもなく、「人を信じる力」だと私は思っています。疲弊しきったメンバーも、対立しているベンダーも、本心ではプロジェクトを成功させたいと思っています。その思いを引き出し、一つの方向に向けることができれば、どんな炎上プロジェクトでも必ず立て直せます。
私が関わった200名規模のプロジェクトは、最終的に予定より1ヶ月遅れで本番稼働しましたが、大きなトラブルなく成功裏に終わりました。顧客からは「もうダメだと思っていたが、よく立て直してくれた」という言葉をいただきました。この成功は、私一人の力ではなく、現場のメンバー全員が諦めずに取り組んでくれた結果です。
もしあなたが今、炎上気味のプロジェクトに関わっているなら、まず最初にやってほしいことがあります。それは、現場のメンバーと直接話をすることです。報告書やメールではなく、顔を合わせて、15分でいいので話を聞いてください。「何が一番困っているか」「どうすれば前に進めそうか」を聞いてください。
その小さな一歩が、プロジェクト立て直しの第一歩になります。炎上プロジェクトの立て直しに魔法の解決策はありませんが、現場と向き合い、一つずつ問題を解決していけば、必ず道は開けます。私は30年の経験から、それを確信しています。
コメント