炎上プロジェクト立て直し｜PMがおさえておくべき火消しのポイント

「今、プロジェクトが炎上していて辛い」
「しんどい状況に終わりが見えない」

全てとんとん拍子でうまくいくプロジェクトなんてほとんどありません。

炎上プロジェクトを任されると先行きの不透明さに不安になり、辞めたいと思うほど辛いこともあります。

私が今まさに担当しているプロジェクトが炎上案件で、最近ようやく状況が落ち着いてきたので学んだことを記事としてご紹介します。

この記事では、炎上事例をもとに立て直しのポイントをご紹介します。

この記事の筆者

プロジェクトマネージャーを任されるようになって2案件目が今回の炎上案件です。
びくびく右往左往しながら立て直しに奔走してようやく落ち着いてきました。

【結論】炎上プロジェクトの立て直しは「問題の特定」が命運をにぎる

実際の事例ベースで以下についてお話しします。

炎上プロジェクトは突然に…「え、私！？」

上司から突然の連絡がありました。

「ＸＸＸＸＸ（今回のプロジェクト）なんだけど、だいぶ苦戦しているらしい」
「プロマネが休職することになった」
「混沌としてるので状況整理して立て直しを手伝ってほしい」

という依頼でした。

連絡を受けた時には驚きました。このプロジェクトは私が所属する部署ではなく、隣の部署のプロジェクトだったのでノーマークでした（なんでも隣の部署は複数のプロジェクトが同時に炎上していてヘルプしてほしいとのこと）。

そこで、状況を把握してプロジェクトを立て直すためのヒアリングから進めます。

プロジェクトの状況（最初に聞いた基本情報）

会社のプロジェクトなので特定できないようにオブラートに包み、少しだけ内容を変更してご紹介します。若干、抽象的ですがご容赦ください。

• 自社ソリューションのリニューアル案件
• パッケージA＋パッケージBを統合して新パッケージとして提供
• 新パッケージはプレスリリースを出してる。本稼働時期は絶対に動かせない
• 開発規模：5千万円〜1億円（約10人ほどで1年くらいのPJ）
• 開発手法：ウォーターフォールモデル
• 現在の工程：要件定義が完了。設計を進めている
• 若手プロジェクトマネージャーが担当（この度休職することになった）
• ベテランPMO（プロジェクトマネジメントの支援）も参画。複数PJ掛け持ち。
  なお『今回統合するパッケージAに数十年関わってきた』ので製品の知識も豊富
• 状況が混沌としている。整理してプロジェクトの立て直しを手伝ってほしい

プロジェクトの状況（関係者にヒアリングして整理）

「まだプロマネ経験浅いのに、大変なことになった。」
「でも、立て直しのプランをまとめないとみんな辛いままだ。」
とびびって泣きそうになりつつヒアリングをはじめます。

プロジェクト関係者にヒアリング

責任者
責任者：最近あり得ないくらい忙しくて。ベテランPMOさんいるからOKでしょ。と思って任せきりだった。
きなこ（心の声）：え。堂々と丸投げを認めた。なんか変だぞ。

前プロマネ
休職のためヒアリング断念

PMO
PMO：XXという機能は改修した方がいいし、XXサブシステムはこの際だからマスタデータを整備して〜〜〜。
きなこ（心の声）：プロジェクト全体というよりシステムの枝葉の話しばかりしているぞ。プロジェクトの状況を知りたいのに詳細の話にばかりそれていくな。

開発リーダー
開発リーダー：正直、今回のプロジェクト何がやりたいのかよく分からないです。スコープすら決まってないんですよね。
きなこ（心の声）：スコープ決まってない？要件定義終わって今設計工程だよ？

開発メンバー
開発メンバー：実は具体的な指示が降りてきていなくてあまり忙しくないんすよね。
きなこ（心の声）：「・・・。」

と言うのが最初にヒアリングした状況でした。

これまでの成果物をチェック｜要件に無い設計書が飛び交う現場

「話しを聞くだけじゃなくて成果物をチェックしてみよう。何か分かるかも。」
と思ってこのプロジェクトで作成された成果物の現物を見てみました。

計画工程：一見すると問題なし。

要件定義工程：一見すると問題なし。

設計工程：明らかに要件に定義されてないことをやっている。プロジェクトの目的「パッケージA＋パッケージBの統合」以外に改修案件が7件。

ここで「あれ？改修案件なんてやるんだっけ。ちょっと聞いてたのと違うな…。この辺に何かあるぞ。」と感じるわけです。

なぜ、要件にないものを設計しているのか

今回プロジェクトの開発手法「ウォーターフォールモデル」は、上流から下流に水が流れ落ちるように行う開発手法のことで、基本的に一度終わった工程の作業に戻ることはありません。

開発工程
■計画
■要件定義
★設計←今ココ
□開発
□テスト
□稼働
□運用

要件定義工程は、「パッケージA＋パッケージBの統合」のみやるという内容で完了していました。

一方で、設計工程では上記以外にシステム改修の要件が7件追加になっていました。

開発リーダーに、もうちょっと詳しくヒアリング

設計の指揮をとっている開発リーダーに更に詳しく話を聞きます。

システム改修7件
↓
パッケージAのものばかり
↓
言い出しているのは全てPMO

と言うことがわかりました。
これはPMOについてもっと詳しく知る必要があるな…。と、今度はPMOについて情報を集めます。

PMOについて更にヒアリングしてわかった情報

まとめると
「パッケージAはよく知っているがプロマネのスキルは無い。」
「忙しくてプロジェクトに顔を出したり出さなかったりだが、強引にシステム改修を進めている（プロマネを経由せず直接開発リーダーへ依頼）」
という状況でした。

このことから、実はPMOは、期待されている役割をこなせない。
→プロジェクトマネージャーのフォロー業務（進捗や品質の管理、集計・資料作成などの作業）を行える管理スキルを持ち合わせていない。
ことがわかりました。

どうやら

熱い想いを持つベテランPMOが空回りする状況が続く。
↓
前任の若手プロジェクトマネージャーはどうしていいか分からなくなる。相談できる人もいない。
↓
キャパシティオーバーで休職。
↓
プロジェクトも炎上。

という成り行きだったようです。

※補足：私はPMOの方が嫌いというわけではありません。淡々と事実を文章に起こすと冷たく感じますが、一生懸命で人柄も良い方です。炎上しているときほど現場の雰囲気に流されず冷静に対処することを心がけました。

なお、PMOという役割については別の記事にまとめています。興味ある方は読んでみてくださいね。
≫なぜPMOがいらないと言われてしまうのか

炎上プロジェクトの問題点を特定 ※ここが一番大切

状況を把握すると次に問題点はどこなのかを考えました。

問題を正しく特定できるかが、炎上プロジェクト立て直しの9割をしめます（9割については私が勝手に言ってます）。問題を正しくとらえないと対策が表面的なものになったりズレてしまうことになるので、問題を正しく特定することが一番大切だと思います。

今回の炎上プロジェクトは挙げるとキリがないくらい問題だらけですが、主な問題として以下の3つを中心に片付けていくことにしました。

プロジェクト立て直しのためにやったこと

問題が特定できると、立て直しの対策は「上層部に必要だと思うことを遠慮なしに言う」ことを心がけました。

今回、炎上案件に途中から入ることになりましたが、一つだけ良いことだと感じているのは「関わっている人たち全員の期待値が下がっている」ことです。

現時点である意味「失敗している状態」なので後は良くなっていくしかありません。なので、立て直しに関する期待値は低くて、必要なコストや要員（今回はスケジュールをズラせないけど、可能な場合はスケジュールも）を調整しないといけない。という認識を持ってくれています。

ですので、炎上プロジェクト立て直しのシーンでは、必要だと思うことは遠慮なく「これがこれだけ必要」と言ってみるのが良いです。言ってみるのはタダです。
（ちなみに今回の事例ではリクエストしたコスト・要員は概ね調整してくれました！）

①責任者が丸投げしてしまう状況の解消

責任者は自ら毎日20分の進捗ミーティングに出て、プロジェクトの課題フォローをしてもらうことにしました。

権限を持っているので、課題が発生するとすぐコストの調整や部署を跨いだスキル要員の調整などをフォローしてもらうことで合意しました。

②体制の変更（PMOの見直し）

ベテランPMOの方の役割を見直して、パッケージAの作業アドバイザーとして定義。PMOできる要員を別途アサイン（進捗や品質の管理、集計・報告資料の作成）。

開発メンバーへの依頼、上司へのコミュニケーションは体制図どおりにプロマネ（私）を通してもらうことにしました。

③今回プロジェクトのゴールを再確認

今回のプロジェクトでやること（パッケージの統合）、二次開発でやること（システム改修）を定義しました。

システム改修は、追加していた7件の内容をまとめて、緊急度・重要度を整理しました。緊急性をチェックすると全案件が先送り可能だったので、キリがいいところまで設計ドキュメントを作成して二次開発プロジェクトへの引き継ぎ資料としました。

その後、立て直しのリカバリ対応を含めて作業スケジュールを取りまとめ再キックオフを実施しました。

この炎上プロジェクト立て直しで出来なかったこと

今回、なんとか立て直しのプランをまとめることができましたが、正直なところ「根本的なところまで手が届いていない…。」と感じています。

正論を言うだけでは話しが前に進まないし、まずは根本原因の解決ではなくてプロジェクトを進めることを優先して以下のことは一旦保留しています。

（1）チームビルディング
今回、現場で感じたのは「プロジェクト関係者に一体感が無い（それぞれで動いている）」という空気感です。
実は、今回のプロジェクトは部署再編のタイミングで発足していて、ほとんど初めての人が集まってチーム編成されていました。しかもプロジェクトメンバー全員がリモートワークというフルリモート開発プロジェクトです。

（2）コミュニケーションが形骸化
進捗報告や、定期的な上司との1on1を実施してはいますが、カタチだけになっていて重要な問題をスルーしていました。

お互いのことをよく知らないので遠慮があったり、上手くいっていないことを本音ベースで言えない空気感をなんとかしないとまた炎上しそうな気がしています。

と言いつつも具体的に今すぐどうすべきか分からない。と言うのが現状なので、引き続き悩み続けてみます。
この炎上プロジェクトは今も進行中で結末はまだ先ですが、ちゃんと収められるようにがんばります。

炎上プロジェクトの立て直しのポイント（学んだこと）

ここ数ヶ月すごく忙しかったストレスをぶつける勢いで書き綴ってしまいましたが、重要な学びをまとめておきます。

プロジェクト計画の「目的」はものすごく大切

目的がはっきりしないと「やるべきでないこと」をやってしまうことがある。
目的が変わるようなら「仕切り直しする」or「目的に戻ってはみ出る分は別プロジェクト」とする。

※誰も混乱させようと悪気があって逸れていない。むしろ一生懸命であればあるほど目的を見失うことがある。

「〜だろう」は危険

「PMOの方は経験があるので大丈夫だろう」と思い込んでしまった。

想定には裏どりが必要。今回PMOとして参画していたベテランの方について、知っている人に聞くとすぐに「プロマネの適正は無い（生粋の技術者）」と分かった。
事前に裏どりできないのなら、状況を監視して問題があればすぐに手を打つべきだった。

※今回は責任者がPMOをアサインした→結果的に上手くいかなかった。ということで責任者のミス。でも私にとっても人ごとではないので反面教師として学ぶ。

チームビルディングもかなり大切

チームメンバー間で本音を話せる関係性を構築できると炎上の兆候を把握して早めに手を打てる。
炎上する前に、不安なことをチームで共有してみんなで知恵を絞って対策できる。
万が一炎上しても、辛い思いを特定の誰かが抱え込むのではなくみんなで「祭り」として楽しむことすらできる（はず）。

リアルタイムな状況共有が必要

今回は炎上してしまった後での立て直しで私を含めた複数の人を追加して火消しにあたりました。リアルタイムに状況共有できていれば、問題が発生した場合には早期に対処することができ、プロジェクト炎上を回避することができます。

炎上プロジェクトの心構え

「学び」ということではないのですが、炎上プロジェクトに参画するにあたり思うこともあったので心構えとしてまとめます。

立て直しは「やさしく接する」

炎上プロジェクトを立て直しする役割で参画した場合は、すでにいるメンバーへやさしく接することを心がけましょう。すでにいるメンバーは疲れきっていることが多いです。炎上させたい人はいないので気持ちをくみ取りましょう。

ただ、遠慮して言うべきことを言うな。と言うことではなくて必要なことは粛々と進めつつ、意識すべきポイントとして「正論を突きつける」のはやめましょう。
やるべきことを出来ていない・上手くいっていないことはみんな分かっています。

あと、そもそも立て直すためにはメンバーが元気でないといけませんので、気持ちよく働けるように心がけることは大切です。

いつか終わりは来る

今回の炎上プロジェクトには、はじめてプロジェクトマネージャーという立場で参加しました。

一方で、プロジェクトマネージャーという立場ではなくても、これまで13年のシステムエンジニア人生でいくつか炎上プロジェクトを経験しています。

一つ確実に言えるのは「永遠に続く炎上プロジェクトはない。」ということです。いつか終わりは来ると開き直ることも大事なことです。

本音を話せる人を見つける（最低一人でも）

できれば職場に最低一人、本音を話せる人間関係を構築しておきましょう。職場にいなければ家族でも友人でも良いです。

特に今はリモートワークが普及しているので、オンラインで仕事を進めるプロジェクトもたくさんあります（今回の炎上プロジェクトも全員リモートワークです）。顔を合わせないとコミュニケーションが難しいこともあります。一人で抱え込まないように普段から良好な人間関係を心がけましょう。

自分のことを知らない第三者が良いのであれば、私や夫に連絡してくれても大丈夫です。このブログの問い合わせフォームやTwitterからDMをください。解決できるかは分かりませんが一緒に悩むことはできます。

大切なのは、一人で抱え込まないことです。

健康を損なってまでやるべき仕事はない

今回の炎上プロジェクトでは、前任の若手プロジェクトマネージャーが休職してしまうという非常に残念な事態となりました。仕事が上手くいかないストレスを抱えつつ、毎日遅くまで働き体調を崩してしまったそうです。

どんなに追い込まれても「健康より優先すべき仕事は無い」と思います。体調を崩す前に逃げてしまいましょう。

逃げるための選択肢を用意しておく

前任者（若手プロマネ）の休職を受けて、追い詰められる前に取れる選択肢を考えてみました。

人間は選択肢が限られるときに苦しいと感じます。追い詰められる前に、普段から選択肢を用意しておくことがおすすめです。

例えば、

1）今の職場で役割を変える
役割を変えてもらう（例えばプロマネ→リーダーへ）。今の会社で別の部署へ異動する。などの方法です。必要ないつでも意思表示できるように、希望する内容を具体的にイメージしておき心の準備を整えておきましょう。

2）転職
転職エージェントや転職サイトに登録しておきましょう。秘密にしておけばリスクもありません。転職アカウントは追い詰められた時のお守りのようなものです。

3）独立（副業から）
フリーランスで働く、もしくは起業する選択肢もあります。急に独立は不安が大きいと思いますのでまずは副業からチャレンジしましょう。

まとめ：プロジェクトマネージャーはハードな仕事。逃げ道を用意しておくことも大切

この記事では、炎上プロジェクトの現場で立て直しに奔走しているプロジェクトマネージャーのリアルをまとめてみました。

炎上はある意味では失敗のこと。できることなら炎上させて消火ではなく、防火するのが一番良いです。

この記事がどなたかの炎上プロジェクトの火消しや、火事予防のお役に立てるとうれしいです。