炎上したプロジェクトの立て直し方法 – 炎上してしまう理由と対処法

はじめに

プロジェクトに携わっていると、炎上プロジェクトに当たることがあります。
担当プロジェクトが予定通り進まなくて炎上することもあれば、既に炎上しているプロジェクトに投入されることもあります。
このような事態になったら、いち早く消火活動を行ってプロジェクトを正常化する必要がありますが、それは非常に難しく険しい道のりです。

プロジェクトを立て直すには特殊な技能やスキルが必要なのではなく、プロジェクトマネジメントの基本を押さえることが大切ですが、その中でも抑えておくポイントがあります。

今回は、プロジェクトを立て直す流れとポイントについて解説します。

炎上プロジェクトとは

プロジェクトは、日々何かしらの問題が発生します。
この問題が小さいときに対策することで大きなトラブルに発展することを抑止します。
しかし何も対策をしないと問題が火種となり、この火種が積み重なることで大きくなっていきます。
気づいたら手に負えない規模に成長し、そこに火が付くことでプロジェクトは炎上します。
今まで問題なかったのに突然プロジェクトが炎上するのは、見えない状態で火種が大きくなっていたためです。
プロジェクトを炎上させないためには、火種が小さいときに見つけて対処することが大切です。

プロジェクトが炎上する理由

火種があることに気づかない

プロジェクト経験を積んでくると、過去の失敗から「ここは危ないな」という勘所ができますが、その経験がないと目の前にある火種に気づくことができません。

経験を積むには環境の違う多様なプロジェクトを経験することで身に付くのですが、それには相応の時間がかかります。
まだ経験が浅いと感じる場合は有識者にプロジェクト状況に確認してもらうと良いでしょう。
もしプロジェクト監査を受ける機会があれば、面倒事と思わずチェックしてもらえる機会と捉えます。

作業タスクの増加

作業見積もりの精度が低かったり、仕様変更が大量発生することもプロジェクト炎上の要因になります。
仕様変更もコストや期間調整がつけばよいですが、要件定義や基本設計の検討不足が原因の場合、仕様変更扱いにできない場合が考えられます。

軽い変更だからと顧客の要望を簡単に取り込んだ結果、「塵も積もれば山となる」で追加タスクの規模が無視できない量になっていることもあります。

手戻り作業が発生する

要件定義で決めた機能の対応漏れ、勘違いにより作り直しなどの手戻り作業が発生すると、スケジュールやコストが超過してプロジェクトが炎上します。
このケースでは、前触れなく一気に炎上することがあります。

また顧客との仕様打ち合わせやQAのやり取りの中で出た決着事項の取り込み漏れが後から発覚する場合も同様です。
議事録やQAを有識者が査読していれば回避できる可能性が高くなります。

ステークホルダーの関係悪化

ステークホルダーの関係が拗れることでプロジェクトが炎上することがあります。
特に顧客のキーマンなど重要なステークホルダーと関係悪化すると、プロジェクト進行が止まることもあります。
これは開発側と顧客側という場合だけでなく、顧客内でのトラブルでも同様です。

炎上すると起きること

プロジェクトが炎上すると、当然ながらQCDは破綻します。
この破綻したプロジェクトを正常に戻すには、通常の作業だけでなくトラブル対応、問題への対策検討、各所への報告量の増加など生産性のない作業を行う必要があるため、非常に負荷があがります。
その結果、メンバが常に高負荷状態となるため生産性が低下します。
最悪の場合、メンバが体調不良になったり退職する可能性もあります。

炎上プロジェクトの怖いところは、しっかり立て直さないと、いつまでもプロジェクトが終わらない状態になる可能性があることです。
仕様変更が大量に発生したり、成果物の品質低下が発生することで、作業が減らない状態になるためです。

辛い状況がいつまで続くかわからない中、追われながら作業することになるのでメンバのモチベーション維持も困難です。
ステークホルダーとの関係性も拗れることが多く、そのような状態で説明や報告、提案をしても疑って見られるので対応に時間を要することになります。

炎上プロジェクトの立て直し方法

プロジェクトが炎上したまま、何も手を打たずにプロジェクト推進してもトラブルが解決されずプロジェクト終結することができません。

最優先でプロジェクトを消化する必要がありますが、その対処法を知らないとかえって火傷することもあります。
炎上プロジェクトを正常化するには、次のような流れで対策を行います。

①エスカレーション

炎上プロジェクトを正常化するには相当のパワーが必要になります。
現場レベルだけで対応することは難しく、組織の支援が必要になることもあります。

組織的に支援を得るためには上位層に正しく情報を共有している必要があります。
報告することで色々と言われることもあるかもしれませんが、プロジェクトだけで問題を抱え込んでも解決は難しく、各方面から責められる事態にもなるので精神的にも良くありません。

報告先はプロジェクト体制図での上位層になるので、一般的にはプロジェクトオーナーへの報告が該当します。

最初から炎上していることがわかって参画する場合は、プロジェクト状況を正しく把握したうえで上位層に状況報告します。

②現状把握・火元の確認・対策検討

炎上プロジェクトでは問題点をたくさん発見できますが、それらを手当たり次第に対応したところで焼け石に水になることが多く、消化することはできません。
そのため、いったん手を止めて炎上している原因を分析するところから始めます。
火元である根本原因を発見することができれば、有効な対策を打つことができます。

計画と実態の差異

まずプロジェクト計画と現状の差異を明確にします。

品質
「品質分析」で解説しているように品質状況を見極め、問題点と対策を分析します。
分析するための諸元データがあればそのまま分析できますが、分析データがない場合はデータ収集するところから始めることになります。
ただデータ収集に時間をかけてもプロジェクト正常化が遅れるだけなので、主要な機能や品質問題が顕著なものを対象に絞ってデータ収集と分析を行うと良いでしょう。

コスト
規模見積もり誤り、または計画時より作業スコープが増えたことで、作業が対処できない量になっているケースが考えられます。
予算超過が発生している場合、計画時と比較して何が増えているのか整理し、その理由を洗い出します。
増えた作業が妥当なのか棚卸を行い、不要なタスクは削除したり費用交渉できないか検討します。

また作業スコープが増えた理由を分析し、プロジェクト計画にある仕様変更管理の運用が機能しているか確認します。

スケジュール
遅延が発生している場合、対象と遅延理由を確認します。
遅延理由については「なぜなぜ分析」などを活用することで、当初の計画通りに進まなかった真因と対策を検討します。

遅延が発生することで、どのマイルストーンに影響があるのか、業務インパクト、ステークホルダーへの影響についてもまとめます。

課題管理の棚卸

課題管理の対応不備によりプロジェクト推進が滞ることも考えられます。
対処しなければいけない課題が後手に回ることで火種が増えていき、結果として炎上につながることがあります。
この課題を棚卸して計画的に解消することで、プロジェクト推進を円滑に進めることができます。

逆に、まったく課題が記載されていない場合は課題管理が形骸化している可能性があります。
これは課題が滞留しているよりも危険で、対応しなければいけない課題が担当者やリーダの頭の中にしかない状態になっています。
メンバを招集し、速やかに残課題の抽出と今後の対応計画を策定します。

体制・役割の確認

体制・役割が機能していないことで、プロジェクトが炎上する可能性があります。
特定メンバに作業が集中しているためボトルネックになっていたり、指揮命令が明確になっておらず現場が混乱するなど、体制・役割に起因したトラブルも考えられます。
ステークホルダーにヒアリングをしながら、体制に問題がないか確認をします。

またステークホルダー間のコミュニケーションにも問題がなかったのか確認します。
情報連携が不十分だったり、メンバ間のトラブルといった問題に起因している場合もあります。
プロジェクトを立て直す場合、ステークホルダー間のコミュニケーションが十分に取れていることは必須です。
体制・役割と合わせて状況を確認します。

③プロジェクト計画の見直し

プロジェクトの問題点と対策を検討したら、プロジェクト計画書を見直して修正します。
修正したプロジェクト計画書をもとにステークホルダーと合意を取る必要があるためです。
計画の見直しポイントについて説明します。

作業スコープ見直し

現在の作業スコープが妥当なのか確認します。
当初計画から作業スコープが増えているか、契約書やプロジェクト計画書と比較します。
もし想定外に増加している場合、顧客やスポンサーなどに作業調整や費用交渉を行います。
その際、プロジェクト計画書で仕様変更の扱いを定義しているか、もしくは議事録やQAなど記録が残っているかが鍵になります。

また課題棚卸を行うことで、WBSに含まれていないタスクを発見することもあります。
このようなタスクはスケジュール化し、要員をアサインして対応していきます。
作業スコープの追加にはなりますが、これらのタスクはプロジェクト推進で必要な作業のはずなのでWBSに組み込みます。

体制・役割見直し

体制や役割に問題がある場合、プロジェクト計画書の体制図を見直します。
要員やスキルが不足している場合、要員追加やサポート強化など体制面の見直しも検討します。

ちなみに作業が遅れているからといって安易にメンバ追加するのは危険です。
その要員追加が本当に有効なのかよく考える必要があります。
スキルがマッチしないメンバを追加したところで既存の有識者のサポート量が増えることもあります。
不用意な要員追加により、かえって悪化する場合もあるので注意しましょう。

考慮すべきは、リーダクラスの能力に問題がないか確認することです。
プロジェクトが炎上する場合、往々にしてリーダクラスの能力に問題がある可能性があります。
もし能力不足がある場合、ベテランのアドバイザーをつけたり、作業負荷を軽減するためのサポーターをつけたりします。
それでも難しい場合、リーダ交代することも視野に入れます。

マスタスケジュール見直し

作業スコープ、体制・役割を見直したらマスタスケジュールを再検討します。
必要に応じてマイルストーンの再設定を検討しますが容易に変更できません。
ステアリングコミッティを開催して調整することになります。

マイルストーンに影響が出るリスケを行うのは、多くのステークホルダーに影響を与えます。
頻繁に行えるものではないので、リスケする場合は楽観的ではなく実現性の高いスケジュールを作成します。

コミュニケーションルール見直し

炎上しているプロジェクトで見受けられるのが、ステークホルダー間の連携不足です。
会議や報告の仕方に問題があり、情報が共有されなかったり正しく伝わらない状況になりがちです。
またチーム内での会話が少なく、困ったことがあっても相談できない環境になっているかもしれません。

また会議などのコミュニケーションに無駄がないことも確認します。
情報共有だけであれば周知の運用ルールを見直すことで会議が不要にできるかもしれません。
多くのメンバが参加しているが発言メンバが限られる会議であれば、参加要員を絞ることも検討します。
会議体は気づくと参加メンバが増えていることがあります。
生産性を考慮した会議設定になっているか再確認すると良いです。

作業プロセス修正

プロジェクト計画で定義した作業プロセスが機能していたか、また作業プロセスの定義が充足していたか確認します。
プロジェクト計画が十分に整備されており正しく運用されていれば、プロジェクト炎上のリスクは低いでしょう。

プロジェクト推進に支障のあるプロセスがあれば、その内容や進め方を見直してプロジェクト計画に反映します。

④プロジェクトの再スタート

立て直しキックオフ

プロジェクト計画書を修正したらキックオフを行います。
あらかじめ修正版のプロジェクト計画書はステークホルダーに合意を取っている前提ですが、それをキックオフの場で正式に合意します。

そして、このキックオフで重要なのが「なんとしてもプロジェクトを立て直して成功させる」という気持ちを全体で共有することです。
顧客やスポンサーは、プロジェクトが炎上したことで疑心暗鬼になっているかもしれません。
チームメンバは、炎上プロジェクトに巻き込まれてモチベーションも下がっているでしょう。
それまでの失敗を引きずらないように、気持ちを切り替える場とします。

プロジェクト実行

見直したプロジェクト計画に則ってプロジェクト実行します。
プロジェクト運用も変わっているため、最初はメンバも困惑するかもしれません。
しかし日々の状況を見てメンバに指導したり、問題点があればプロセス改善していきます。

時には上手くプロジェクト遂行できない場合があるかもしれません。
現場はリーダに任せるのが基本ですが、対処が難しいと判断する場合は一時的にプロマネが介入することもあります。
ただ、これは越権行為でありリーダやメンバのモチベーションが下がる可能性があるので必要最小限にとどめます。

⑤振り返り

プロジェクト完了時、または状況が落ち着いたタイミングでプロジェクトの振り返りを行います。
炎上プロジェクトは非常に辛いものですが、そこでないと得られない経験もたくさんあります。
どのような行動が炎上につながるのか、回避するために取り組むべきことは何かを振り返ることで、その経験はメンバの大きな糧となるでしょう。

この振り返りにおいて「ただ辛かった」という失敗体験でなく、辛い状況を乗り越えたという成功体験につなげられると良いです。

立て直しのポイント

炎上プロジェクトを立て直す際、意識すると良いポイントについて記述します。
通常のプロジェクトでも有効なのですが、炎上プロジェクトでは立て直しに直結する重要なポイントです。

隠し事を洗い出す

プロジェクトの立て直しで最も重要なことは、プロジェクトの隠し事は全て表に出すことです。
炎上プロジェクトでは、顧客や外部に言えないことの１つや２つはあるものです。
それらを考えなしに顧客へ伝えるのは問題ですが、チーム内や自社組織内では共通認識とします。

これらの隠し事があると、どのように計画を見直してもステークホルダー間で認識齟齬はでますし、計画の辻褄が合わなくなります。

どれだけ秘密にしても、いずれは露見します。
隠し事という問題は個人で抱えるのではなく、チームや会社などの組織で一丸となって解決すべきです。

責任を追及しない

炎上するくらいなので、何かしら人に責められる状況はあるものです。
しかしプロジェクトの問題点を分析するときに「〇〇さんの問題で失敗した」のように人の責任を追及するのは厳禁です。
大切なのは問題点を洗い出して対策を打つことであり、人が問題を起こさないように作業プロセスを見直すことが大切です。
人を責めても何も解決しません。
それどころか責任追及を恐れて誰も意見を出さなくなってしまいます。
このような状況にならないよう、チーム内の雰囲気づくりには注意します。

リーダは作業タスクを持たない

炎上プロジェクトでは、リーダが現場作業を持ってしまう光景を目にします。
目先の作業を片付けるのは速いかもしれませんが、リーダの役割はチームを統率することです。
作業タスクを抱えてしまうと、リーダとしての活動に手が回らなくなることもあるでしょう。
必要なタスクはメンバにアサインし、どうしても必要であればリーダがサポート役になる程度に留めます。
体制・役割の整理の時に、状況整理して対策を検討します。

会議を効率化する

プロジェクトでは多くの会議が開かれますが、その進め方によって成果の出方が大きく違ってきます。
良くない会議の例として、結論が決まらずフワッとした状態で終わるケースが挙げられます。
決定事項やネクストアクションが決まっていないため、また同じような会議を繰り返すことになります。
これでは参加者の時間を無駄にするだけでなく、議論の決着も進まないためプロジェクト進行に影響が出ます。

効率よく会議を行うことで、炎上プロジェクトの立て直しもスムーズに進むことができます。
会議の進め方については、別記事「会議術」を参考にしてください。