ウォーターフォール型開発プロセスでは、作業を複数のタスクに分解してリソースに割り当てて計画を立てる。各タスクに開始予定日と終了予定日を決める。ガントチャートで状況を可視化して進捗を管理する。そうするとスケジュールは遅れ始める。
スキルの高い開発者は、終了予定日にあわせて作業を調整してしまう。余裕があるので自分のスキルアップのために、今までとは違ったやり方を試したり、気になる事柄の調査を始める。本来は終了予定日より前倒しで完了できたはずなのに、与えられた期間はすべて使い果たしてしまう。
初心者はやみくもに作業を始める。作業期間に余裕がなくなってくるとリーダーが危険に気づきテコ入れをする。終了予定日にはなんとか間に合うか、少し遅れて終了する。
マネージャーから作業計画や期間を与えられると、人間は「その通りにやることを期待されている」と誤解してしまう。本来は個々人が最適・最短期間で作業すべきということは計画からは伝わりにくい。
アジャイル開発プロセスでは細かな計画は与えられない。計画は自分たちで考えることになっている。いかに最適・最短期間で作業を終えるかを皆が考え実行する。前詰めとなるようにバイアスがかかっている。『早く終わることはいいことだ』
ウォーターフォール型開発プロセスでは、意図的にバイアスをかけないとタスクはすべて後詰めになってしまう。『オンスケジュールであれば問題ない』というのは、実際には問題だ。
一番簡単な対策は、全てのタスクの作業期間を半分(50%)にしてしまうことだ。
ただし、カットした分の期間を合計したものをプロジェクト全体の遅延バッファとして工程の後半に置き、全体の作業期間は変えないこと。また、プロジェクトメンバーには見かけの作業終了日を守れなくても良いという事を伝える。各タスクは倍の期間(つまり当初の作業期間)かけて作業をしても、問題にはならない。
当初のスケジュール(半分にする前)の見積もりがある程度妥当な場合、この仕掛けはうまくいく。
- 熟練者は半分の期間という高めのハードルを実際に越えて作業を終える。前倒しで作業を終えた熟練者は、他のタスクのフォローにまわすことができる。
- 中級者～初心者の作業は半分の期間では終わらないが、各タスクの終盤50%を「終了予定日」ではなく「あとどれくらいで終わるのか」という観点での管理にすりかえる事ができる。
- 「あとどれくらい(何日、何時間)で作業が終わるのか」 という問いかけは、『オンスケジュール』の安心感を産みにくい。 最適・最短期間で作業を終える為の強いバイアスをかけることができる。
