火を噴かないためのプロジェクトマネジメント
誰だってプロジェクトは予算通りで納期が守られることを願います。
クライアントもプロマネも開発者もデザイナーも。
でも火を噴くんですよねー。
みんなが望んでない方向になぜか行くんです。
で、火を噴かないためにはどうしたらよいか。
・クライアントとの信頼関係を日頃から築いておく
・要件/仕様を明確にするためにドキュメントに落とす
・テストは1人で担当せず、必ずダブルチェックを行う
といったことは大前提(あたりまえ)です。
火を噴くプロジェクトはいきなり噴火するのではなく、たいてい「予兆」
があります。
この「予兆」をプロマネが見抜くことができれば、消火活動へ早く動けます。
火を噴くかどうかの予兆を見極め、すばやく行動するためには、
１．自分なりのマイルストーン
２．自分なりの判断基準
３．上記１と２が満たされなかった場合の解決策
の３つを常に考える必要があります。
具体的に説明をしていきます。
１．自分なりのマイルストーン
例えばプロジェクトの期間が1月1日～3月31日の3ヶ月で、
4月1日にリリース予定の場合、中間の2月15日の段階で
「何がどこまでできていなければならないか」
を予め定義しておくことができます。
3月1日、3月15日といった節目となる日付でも同様です。
このマイルストーンがあれば、機能とスケジュールの両方から
チェックすることで、火を噴く可能性を客観的に判断することができます。
２．自分なりの判断基準
・結合テストでバグが20個以上出たら危ない
・徐々に遅れている開発が今日までに完了しなければ危ない
・中間報告会でクライアントの承認がもらえなければ危ない
といったように、プロジェクトの健康状態を自分なりに判断する基準を
持つべきだと考えています。
この判断をせずに色んなことを先延ばしすると、メラメラと燃える炎が見えてきます。
３．上記１と２が満たされなかった場合の解決策
この３つめが一番大切です。
絶対に火を噴かないと言い切れるプロジェクトなんてありません。
僕もいつか噴くかもしれないと思いながら日々過ごしてます。
ただし、
・火が噴いているのに解決策が思い当たらない
・火が噴き始めたが解決策は準備してある
の２つでは大きな差があります。
解決策はたいてい
・人を投入する、人を入れ替える、人を再配置する
・追加予算を申請する、開発機能を削減する
・スケジュールを見直す
といったように、非常にシンプルです。
（この解決策をクライアントに通すために日頃の信頼関係が超大事！）
火を噴きそうだったけど予兆を見極めて何とか乗り越えた、
という感覚は自分しか分かりませんが、それを感じられたら
火を噴く可能性を低くするマネジメント力はかなりついていると思います。
–
