やばい！間に合わない！工数見積を見誤ったときのリカバリ方法3選
まぁ、ありますよね、、、。
「あ、やばいっ！」てこと。
同じようなことをいつもやっている定常的な業務であれば工数見積もりは正確にできますが、新規性・不確実性を伴うプロジェクトの工数は「見積もり」というよりも「予測」的な要素が強まります。
そんな状況であっても、可能な限り初期の計画通りに物事を進めるのがプロマネが背負う使命。
工数見積もりを見誤ってしまった際には、どうやってリカバリーすればよいのでしょうか？
リカバリーの方法は3つしかない
完了期日と開発スコープを変更せずにプロジェクトを進めるためには、以下の3つの方法しかありません。
- クラッシング
- ファストトラッキング
- バッファを使う
気合いだけでは生産性は（少しだけしか）上がりませんので、間違っても精神論で乗り切ろうとしてはダメ。
精神論で戦っても自分もメンバーも疲弊するだけなので、この3つの方法論を上手に使ってプロジェクトの軌道修正をしましょう。
１．リソースを追加投入して解決する「クラッシング」
ひとつめの方法は、クラッシングです。
クラッシングとは、リソースを追加投入してスケジュールを短縮することを意味します。
最も確実なリソース追加方法は、担当メンバーへの残業や休日出勤の依頼です。
一時的な残業で済むようであれば、プロジェクトの内容を把握している既存メンバーが対応すれば速やかにリカバリーできるはずです。
なお、仮に工数を見積もったのが残業した本人であっても、計画を見誤ったのはPMの責任です。
残業への感謝の気持ちは忘れずに。
尊敬すべき僕の先輩は「とりあえず女子にはチョコさえ与えとけば大丈夫や」なんて言っていました。敬意をもって意訳すると、「大事なのは感謝の気持ちだけど、気持ちだけでは伝わらないから時には身銭切ってモノで示めしたほうがいいよ」ということでしょう。
冗談はさておき、一時的な残業で済めばよいのですが、計画と実績の乖離が大きく、それでは済まない場合もあります。
恒常的な残業はメンバーのモチベーション低下や肉体的疲労につながり、生産性を落としてしまうため避けなければなりません。
そんな場合に考えるべきはリソースの再配置です。
クリティカルパス上にないタスクに割り当てられているリソースのうち、再配置可能なリソースがないか探してみましょう。
うまく再配置できれば、プロジェクト全体のスケジュールを変更することなくリカバーすることが可能です。
それでもだめなら、新メンバーの追加を考えることになります。
但し、新規メンバーを追加する際はブルックスの法則を念頭に置く必要があります。
Adding manpower to a late software project makes it later. （遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけだ）
名著「人月の神話」の中で書かれたもので、ソフトウェア開発に関わる方であればご存じの方が多いのではないでしょうか。
ブルックスの法則は、新メンバーがプロジェクトに貢献するまでには一定の時間がかかること、人数が増えれば増えるほどコミュニケーションコストが上昇することを根拠としています。
ですから、新メンバーを追加する際は、この2点を克服できるかどうかを予め検討する必要があります。
プロジェクト初期段階であれば比較的克服しやすいものですが、プロジェクト後半に差し掛かっている場合は、(単純な人件費以外の)コストと効果をしっかりと天秤にかけて考えるようにしましょう。
２．ファストトラッキングは、やむを得ない見切り発車
クラッシングで対応できない場合は、ファストトラッキングと呼ばれる方法を検討します。
これは、本来前工程が完了してから着手すべき作業を、前工程完了前に着手して全体のスケジュールを縮めることを言います。
例えば、デザインがFIXする前にコーディングに着手することがファストトラッキングにあたります。
要は、見切り発車です。
うまくいけば大幅にスケジュールを短縮できる可能性がある一方で、前工程の状況によっては大幅な手戻りを発生させてしまうリスクもつきまとう方法です。
従って、ファストトラッキングは手戻りのリスクを受容できる場合にのみ適用すべきです。
３－１．バッファを使う前に、覚悟を決めて依頼者とスコープやスケジュールの調整を
クラッシングとファストトラッキングを適用してもリカバリーできないことがわかったら、悩んでいても仕方ありません。
依頼者とスコープやスケジュールの調整をしましょう。
そりゃー怒られますよ、でもしょうがないんです、それがプロマネの仕事です。
３－２．最後の最後は、バッファを食いつぶして微調整
そして、最後の最後の手段がバッファを食いつぶすことです。
重要なのでもう1回言います。
最後の最後の手段がバッファを食いつぶすことです。
炎上に突入する典型的なケースが、最初にバッファを食いつぶしてしまうことです。
バッファは、最後の最後まで残しておかなければいけないんです。
本当に万策尽きたときにしか、バッファを使ってはいけないんです。
バッファを食いつぶす前に、必ずスケジュールやスコープの調整にチャレンジしましょう。
怒られても、恨まれても、バッファは最後まで死守することが、最終的にプロジェクトを幸せに完了させるポイントです。
プロジェクトは最後の最後まで何があるかわかりませんからね。
僕がPMを担当するプロジェクトではバッファは最後まで使わずに、メンバーへの感謝の気持ちに休暇にするつもりでやっています。
（それでも、実際に休暇にできるプロジェクトは全体の半分くらいですが・・・涙）
リカバリーは、「率」ではなく「量」をコントロールする
これら3つの方法は、いずれも「率」ではなく「量」をコントロールしていることがポイントです。
クラッシングは、単純にリソースの量を増やします。
ファストトラッキングも、剰余リソースを稼働できる工数に変化させることでリソースの量を増やしています。
バッファを使うことは、作業日の量を増やします。
もちろん、メンバーを鼓舞したり、チケットを整理して残作業を見える化したりすることで効率を上げるなどもやらなければいけませんが、率を上げるには限界があります。
どうにかして量をコントロールしようとすることが、確実にプロジェクトをリカバリーするための考え方です。
▼こちらの記事もオススメです▼
