ITプロジェクトには、『炎上』という言葉が付きものです。
規模が大きれば大きいほど、火は大きくなり、鎮火には時間・労力がかかります。
くろねこは、これまで数十を超える炎上プロジェクトを経験してきました。
自分で発火させたもの、飛び火を受けたもの、道連れになったもの。
共通していることは、『炎上プロジェクトのプロマネは大変！！』だけです。
何が大変かというと、３つの「ない」からスタートするからです。
炎上プロジェクトはやりたくないです！！
いいこと何もなさそう！！
そうですね。
でも悪いことばかりではないですよ？
今回はくろねこの経験からみた炎上プロジェクトについてお話します。
ITPJTの炎上は、起きるべくして起きる
くろねこがお話する、ITプロジェクトのスコープは下記だと定義しています。
この各工程において、炎上する可能性があるのはほぼ全行程だと言えるでしょう。
炎上プロジェクトの発生原因はたいてい３つしかない
そもそもプロジェクトが炎上する理由は、経験上下記のいずれかだと思っています。
質問です！
要件や目的が定まっていないのに、プロジェクトはスタートするんですか？
良い質問ですね。
回答は、「Yes」です。
理由は、そのときに気づかないことが多いからです。
１．プロジェクトの目的が定まっていない
多くの場合がこれでしょう。では目的が定まっていないと、何が起こるのかです。
結果、プロジェクトを立ち上げたときに定めたはずのスコープがズレて、余計なコストやスケジュール遅延を生みます。他にも、企画と開発チームの仲が悪くなったり、開発チームの中でも険悪なムードになることが往々にしてあります。
くろねこの場合、複数の会社で構成されたチームだったので、会社間で仲が悪くなってしまったり、さまざまな人間関係の崩壊も経験しています。（なんの得もないです）
こういうケースの場合、誰かのせいにしたがるのが人間誰しもあるので仕方のないことです。素直に受け入れましょう。
ただ、PMはPJTの責任者でもあるので嫌われても、一人になってもPJTを最後まで背負うことが課せられます。
辛いですが…それがPMの最大のお仕事と言えます。
２．要件が未確定で開発してしまい、想定と異なっている
これは１と同じ理由ですね。ただ追加要素があります。
例えば、常に同じ用語で口頭にて会話していても、その用語の理解がお互いに異なっていた場合に認識の齟齬が発生しています。
そこから、ソフトウェアやシステムが出来上がって動かしてみたら、違う！！ということがあるんです。
これは、ドキュメントによる確認を怠ったため、齟齬に気づけなかったケースです。
これも意外と起きます。誰かが気をつけていても起きますし、会話した内容をドキュメントに修正できていなかった、ドキュメントの横展開が漏れていた、など様々なケースが起こります。
その結果、手戻りや修正によるコスト増となり、確認するコミュニケーションが増えてしまい人間関係も悪化してしまうということがあります。
完璧に修正するものを管理できていればいいのですが、作業するのはどうしても人なので、漏れがある想定で動くほうが好ましいです。
ただ漏れがあるから手間をかけるのではなく、仕組み化を行い漏れを防いでいくことが好ましいと言えます。
３．開発自体の品質が悪い
だが、発注側である場合、無理やりなコストカットで成果物を省いたり、根拠のない効率化を求めたり、自分がそうだからと相手に無理な生産性を求めていないだろうかを見直してみよう
この原因も、よくあります。発注側にたつと社内でコストカットを嫌でも求められるため、開発ベンダーへそれを求めてしまうことです。
適切なコストカットであればそれは良いでしょう。（くろねこもやるので）
ただ根拠のないコストカットを迫ってたりはしてないかです。
コストカットをすれば、当然品質も下がると思っておくべきだとくろねこは考えます。
開発側のくろねこの経験でいくと、見積ミスが主な原因ですかね。
要求事項を汲み取れていなかった、仕様理解が浅かった、調査ができていなかったと理由は多数挙げられますが、そこは次回に活かしていくようにしてました。
発注側も開発側も、根拠をもってコストを見極めるべきであるということですね。過剰なコストカットは余儀なくされますが、その分品質ダウンとトレードオフであることは、PMがしっかりと認識した上で、社内外と調整をしていきましょう。
ちなみにくろねこはコストカットを迫ることは大嫌いです。品質ダウンで絶対に怒られるので。
炎上プロジェクトを鎮火するためにすることこそ、プロマネである
ここでは、くろねこが炎上プロジェクトを起こした時、参画したときにまず最初にやることを解説します。
いよいよ、くろねこ流ですね！
まずやること、それは「事態を正しく把握すること」の一択です。
では、その手順を説明します。
２．プロジェクト計画書との比較（ギャップを探す）
３．プロジェクト計画書のどこを修正（手直し）するかを考える
４．プロジェクトコストの残額と取り得る手段を考える
５．対応方針をプロジェクトメンバーと擦り合わせて、プロジェクトを進行する
６．１週間後状況を再確認。改善されていれば、そのまま進めていく
７．改善されていなければ、再度なぜかを分析する（１．をやる）
※１つの要因ではなく複数要因が重なっていることが多いので１つの要因ごとに分析して進めていくことが手堅いでしょう。
ロジカルシンキングはこちらから
この手順で、くろねこはやりますが正解ではないです。
この進め方が、協力も仰ぎやすく、ゴールへ向かいやすいです。
いつか自分にあった型をつくり出すことをオススメします。
このように、炎上している箇所だけにフォーカスしてもやることは、通常のプロマネと変わりません。
むしろ、通常のプロマネを使ってピンチをチャンスに変えられるのです。
プロマネは、プロジェクトを立ち上げて正常に運営するだけのスキルではないのです。
いかなる状況のプロジェクトでも、プロマネは有効に使えますし、そのスキルレベルはあまり問われません。
大事なことは、ゴールまでの道を照らし出せるか、ゴールまでを照らせなくても、次の一手を仲間に伝えられるか、です。
炎上プロジェクトは、みんなが疲弊しています。そこに新規ヘルプで入ったならばそれは救いになります。
PMからすると、打てる手段が増えるかもしれないし、プロマネができるとなれば、一緒に立て直すこともできる。可能性が増えるのでありがたいのです。
なにより、炎上プロジェクトのPMは誰よりも責任を感じています。
その支えが増えるだけでもPMは息を吹き返します。
PMじゃなくても、プロマネができるだけで、助けになれるなんて、スーパーマンみたいです！かっこいい！！
でも失敗したら…
スーパーマンに見えますよ。
それに失敗したら…と思う気持ちはわかります。
でも、すでに炎上という失敗状態なので、ここでミスしても誰も文句は言いません。
安心してできる最大限をやってみてください。
まとめ：炎上プロジェクトは、プロマネの経験値があがるボーナスステージ
・炎上プロジェクトの対応は、手順がある
・プロマネができれば、スキルレベル関係なしに重宝される
炎上プロジェクトは、チームメンバー全員が協力しないと鎮火できません。
燃えているので、そこでのミスもあまり気にすることじゃないです。
炎上プロジェクトでは、プロマネのスキルを磨くにはいい機会です。
なぜならそこでのミスも咎められることもないですし、さらにはプロマネを局所的に使うことができるので経験を積むにももってこいの練習場と言えます。
炎上プロジェクトを嫌がるのはわかりますし、楽しくないのもわかります。
ただその中に、自分を成長させる機会とチャンスが埋もれています。
積極的にまでは行かなくてもいいでしょう、ただ周りで困っている人がいたら手を差し伸べてみてください。
プロジェクトがうまく進められないな〜って人はこちらの本がおすすめですよ。
PMへ転職を考えている方は、こちらの記事もぜひご一読ください。
【成功の実体験】高年収のプロジェクトマネージャーになりた人向けおすすめキャリアプラン | 黒猫のプロマネ塾 (promane.xyz)
