PLとして担当した案件を、大炎上させたことがある。
言い訳はできない。判断ミスが重なって、収拾がつかない状態になった。クライアントの信頼を失い、チームメンバーを疲弊させ、上司に介入してもらって何とか収拾した。あの経験は、今でも鮮明に覚えている。
失敗談は書きにくい。でも、PLやPMとして同じ立場になる人に伝えておきたいことがある。この記事では、プロジェクト炎上の実体験と、炎上を防ぐために大切なことを正直に書く。
PL就任当時の状況
エンジニアとして6年以上が経ち、PLを任されるようになっていた。
チームリーダーの経験は積んでいた。ただPLとなると、スコープがまったく違う。プロジェクト全体の進行管理、クライアントとの折衝、予算とスケジュールの管理、リスクの把握と対処。責任の重さが、チームリーダーとは別次元だった。
自信があったわけではない。ただ任された以上はやるしかないという気持ちで引き受けた。最初のうちはなんとか回せていた。問題が起きたのは、プロジェクトが中盤に差し掛かった頃だった。
プロジェクト炎上の原因：判断ミスの連鎖
最初の判断ミスは、小さなことだった。
スケジュールに少し遅れが出始めた頃、「このくらいなら取り戻せる」と判断して、クライアントへの報告を先送りにした。問題を小さく見せたいという気持ちが、正確な情報共有を遅らせた。
第1の判断ミス：報告の先送り
「少し様子を見てから報告しよう」という判断が、最初の失敗だった。問題が小さいうちは報告しやすいが、時間が経つほど「なぜ早く言わなかったのか」という話になり、報告しにくくなる。この悪循環に気づかなかった。
第2の判断ミス：無理なリソース投入
遅れを取り戻そうとして、チームメンバーに無理な負荷をかけた。「残業して挽回しよう」という判断だ。ただ疲弊したメンバーの生産性は下がり、品質に問題が出始めた。
第3の判断ミス：品質問題の隠蔽
品質問題が出ても、クライアントへの報告を躊躇した。「修正すれば間に合う」という楽観的な判断が、問題をさらに大きくした。
この3つの判断ミスが連鎖した。スケジュール遅延→無理なリソース投入→品質問題→報告遅れ→クライアントの不信。一つひとつは小さな判断ミスだったが、連鎖することで取り返しのつかない状況になった。
プロジェクト炎上後の状況
プロジェクトは炎上状態になった。
クライアントからの信頼は地に落ちた。毎日のように厳しい指摘が入る。上司が介入して収拾に当たることになった。自分の力では手に負えない状況になっていた。
チームメンバーへの申し訳なさが、一番きつかった。自分の判断ミスが、チーム全体を巻き込んだ。残業が続く中でメンバーが疲弊していく様子を見ながら、何もできない無力感があった。
炎上が落ち着くまで数ヶ月かかった。その間、毎日現場に向かうのが億劫だった。「また今日も謝りに行く」という気持ちで出社する日が続いた。
精神的に一番きつかったのは、「自分の判断がここまで大きな影響を及ぼした」という事実を受け止めることだった。チームリーダーとしての失敗とは、ダメージの質と量が違った。
プロジェクト炎上から学んだ3つの教訓
この炎上経験から、PLとして最も大切なことを学んだ。
教訓①：悪い情報ほど早く正直に共有する
プロジェクト管理において最重要なのは、悪い情報を早期に共有することだ。
問題が小さいうちに報告すれば、対策の選択肢が多い。問題が大きくなってから報告すると、選択肢が狭まる。「このくらいなら大丈夫」という判断が、一番危ない。
クライアントは問題が起きることより、問題を隠されることを嫌う。正直に早く報告した上で一緒に対策を考える姿勢の方が、長期的な信頼関係を保ちやすい。
実際、あの案件で「もし最初の遅れが出た時点でクライアントに正直に報告していたら」と今でも思う。早期に報告していれば、スコープの調整や期日の見直しという選択肢があった。隠したことで、その選択肢を失った。
教訓②：一人で抱え込まない、早めに相談する
判断に迷ったとき、上司や経験者に相談することをプライドが邪魔していた。「PLが相談するのは格好悪い」という思い込みがあった。
でも相談することは弱さではない。早めに相談することが、炎上を防ぐ最も効果的な方法だった。上司に相談していれば、早い段階で別の対処法が見つかっていたかもしれない。
PLやPMを任されると、「自分で解決しなければ」という責任感が強くなる。でもその責任感が、孤立無援の判断につながることがある。「相談できる上司・先輩を作っておくこと」も、PL・PMの重要なスキルだ。
教訓③：リスクを早期に可視化する
炎上を防ぐには、リスクを早期に可視化して共有することが大切だ。
「このタスクが遅れると影響が出る」「このメンバーのキャパが限界に近い」「この仕様変更はスケジュールに影響する」。こういったリスクを早めにチームとクライアントで共有しておくことで、問題が大きくなる前に対処できる。
リスクを隠すのではなく、「こういうリスクがあります、どう対処しますか？」とオープンに議論できる関係性を作ることが、プロジェクト管理の本質だと今は思っている。
プロジェクト炎上を防ぐための具体的な方法
実体験を踏まえて、プロジェクト炎上を防ぐための具体的な方法を整理する。
定期的な進捗の見える化
週次や隔週で、スケジュール・品質・コストの状況をチームとクライアントで共有する場を作る。「問題があるときだけ報告する」ではなく「定期的に状況を共有する」ことで、小さな問題を早期に発見しやすくなる。
バッファの確保
スケジュールを組むとき、楽観的な見積もりだけでなく、リスクを考慮したバッファを設ける。「順調に進めば間に合う」ではなく「問題が起きても対処できる余裕があるか」を確認する。
エスカレーションのルールを決めておく
「どんな状況になったら上司に報告するか」「どんな問題はすぐにクライアントに共有するか」というエスカレーションのルールを、プロジェクト開始時に決めておく。ルールがあれば、報告のタイミングで迷わなくて済む。
チームの状態を定期的に確認する
メンバーのキャパと状態を定期的に確認する。「大丈夫ですか？」という声かけを習慣にするだけで、問題の早期発見につながる。メンバーが限界に近いサインを見逃さないことが、品質問題を防ぐ。
よくある疑問への回答
Q. プロジェクトが炎上しそうなとき、最初にやるべきことは何ですか？
まず現状を正確に把握して、上司に報告することだ。「炎上しそう」という状況を一人で抱え込まない。上司に報告することで、自分だけでは持っていない選択肢や経験値を借りられる。次に、クライアントへの報告タイミングと内容を上司と一緒に検討する。
Q. クライアントへの悪い報告は、どう伝えればいいですか？
「問題が起きています」だけでなく、「現状・原因・対策案」をセットで伝えることが大切だ。「遅れています」より「○○の理由で△日の遅れが発生しています。対策として□□を実施します」という形で伝えると、クライアントは対処しやすい。問題を報告しながら、解決策も一緒に提示する姿勢が信頼につながる。
Q. 炎上プロジェクトに途中からアサインされたとき、どうすればいいですか？
まず状況を正確に把握することが優先だ。何が問題で、何がわかっていないかを整理する。前任者や上司から現状をヒアリングして、自分が貢献できることから始める。「炎上を解決しよう」と焦るより、「現状を把握して、小さなことから改善する」という姿勢が大切だ。
まとめ：炎上から学んだことは、成功から学ぶより深く刻まれる
PLとして案件を大炎上させた。判断ミスが連鎖した結果だった。
あの経験は恥ずかしいし、今でも苦い記憶だ。でも、あの失敗がなければ学べなかったことがある。悪い情報は早く共有する。一人で抱え込まない。リスクを早期に可視化する。この3つは今でも自分の仕事の基本になっている。
炎上を経験したことのあるPL・PMは多いと思う。大切なのは、その経験から何を学んで次に活かすかだ。失敗から学んだことは、成功から学ぶより深く刻まれる。
コメント