こんにちは。
入社4年目に突入した、技術リーダーの因藤です。

この4年間で、多くのプロジェクトを技術リーダーとして経験してきました。
酸いも甘いも経験してくると、自然と炎上を回避できる術を身に着けてくるものです。

個人的に「よし！何事もなく完璧にやり切った！」という案件はあまり記憶にありません・・笑
※うまくいった案件は記憶に残らないというのもありますが、、、

こう書くと、「プロジェクトの進め方に問題があるんじゃないか？」と思われるかもしれません。
しかし、どんなに計画を練っても、大規模かつ複雑なプロジェクトになればなるほど、予想外な事象というのが必ず起きるものだと考えています。

完璧な計画を立てられること以上に、起きた想定外の事象に対してどうアクションできるかを瞬時に考えられることこそ、プロジェクトリーダーや、技術リーダーには必要なスキルだと思っています。

とはいえ、明らかに目の前に見える地雷を踏んでいくことは、プロジェクト進行上回避したほうが良いです。

そこで、これまでの経験した中で、炎上を回避するポイントをいくつか挙げてみました。
これからプロジェクトのリーダーを行う予定の人は、一読いただければと思います。

当たり前のことだと思うかもしれませんが、
炎上しているプロジェクトは、決まってこの部分がフワッとしています。
「いつまでに何をしないといけないの？」というマイルストーン・WBSが引けていないため、リリースギリギリで「あれが足りない」、「ここがおかしい」というタスクが積み上がり、炎上します。

マイルストーンを引くために
マイルストーンの引き方として、ゴールから逆算するということが重要です。
案件の立上げであれば、ゴール = リリース日と捉えましょう。
ゴールの日付と現在の日付の中で、必要タスク、必要時間等を洗い出し、スケジュール上に引いていきます。
初めはざっくりで構いません。
※「要件定義」「設計」「開発」「テスト」など

常にスケジュールは更新しよう
計画通りに行ければそれがベストですが、時にはタスクの遅れが生じることがあります。
そのため、定期的にマイルストーンは更新していきましょう。
今の地点をプロジェクト全体で把握して、ボトルネックに対して早いタイミングで手を打つことで、後々の炎上を防ぐことができます。

小さな事であっても必ず資料を残しておきましょう。
相手の理解度の向上や、認識の齟齬が発生しづらくなります。
また何かあった際でも、この資料が根拠となります。
口頭でのみのやりとりはやめましょう。
口頭のみでのやり取りは、「言った・言わない」論争に発展します。
※一番不毛な状態です

もう1点メリットとして、急遽別プロジェクトのメンバーをアサインせざるを得ない場合、プロジェクトの概要が資料にまとまっていると、「これ読んでおいて」と言うだけでよくなり、お互いのコストを削減ができます。
※引継ぎのコストは結構高いですよね…

「○○という想定」「たぶん○○」というような曖昧な状態にしないようにしましょう。
ほとんどの場合、その想定は外れていることが多いです。
特に連携会社先の仕様などは、このままにすると相手先にも迷惑をかけるため、
少々面倒かもしれませんが、メール・電話による確認をしてみたり、打合せをセッティングして、不明な点が無い状態を目指しましょう。

要件定義・設計を曖昧にした状態で進めると、ほとんどの確率で手戻りやバグが発生し、想定外のコストがかかります。
この手戻りやバグの原因のほとんどは、上流工程における要件漏れ、確認漏れ、影響範囲が網羅できていないなどが影響して発生します。
曖昧な部分があるのであれば、必ず解決してから下流の工程に進みましょう。

社内のいろいろな人と仲良くなっておこう
不測の事態が発生した際に、手を差し伸べてくれる方や相談できる方は周りにいますか？
プロジェクトは1人では進められません。もちろん、プロジェクトメンバーはいますが、時にはプロジェクト外の方のアドバイスやサポートが必要になる場面があります。

社員同士に一定の関係値が無いと、相談をしづらいという心理から、1人でタスクを抱えてしまう方が多いように思います。
普段から、社内のメンバーとは会話するようにしておきましょう。

自分は、「技術のことならこの人！」「プロジェクト進行のことならこの人！」という相談先をある程度決めており、
その人がプロジェクトにアサインされていない場合でも、普段の会話などで相談したりしています。

最後に、以下書籍を紹介します。

本のタイトル：小さな「チーム」「プロジェクト」のウマい仕切り方

プロジェクトの進行を行う上で、とても参考にしている本です。
「あぁ確かに。」と思える事例がいくつもあり、自分もとても参考になりました！
ぜひ、一読してみてください。