メンバがタスクのを着手する前にタスクに必要な時間を見積もりし直さないといけない理由
WBSにタスクを分解して依存関係を結びつけるとき、無意識に、
「(タスクとタスクの間がピッタリと隙間なく続いてるようにしないと……。)」
って思っていませんか。そう組みますよね。それはそれで正しいんです。WBSでは、ですけれど。その後、タスクにリソースを割り当てたり、日程やマイルストーンをアンカーにして時間軸を入れると途端に崩れるんでしょね。あるところのタスクの数のピークができたり、逆に間があいて間延びしちゃったり。だから、山積みしたあと山馴らしして計画する人数とで調整するわけですが。
で、実際タスクをやろうとすると、着手前に何をしたらそのタスクがDoneするかという意味で作業のアウトプットの出来上がりのレベル感を決めて予定した作業をすることになるんですが、そのとき、意外と当初に見積もったタスクの作業時間ってそのままなんですよね。見積もったり、WBSに分解したりしたときからプロジェクトの進捗が進んでいけば、工程が変われば以降のタスクのインプット情報が更新されるのでより具体的なインプットの情報に変化するわけです。そうすれば、当初のWBSの見積もりを見直そうと思う方が自然で、見直しをせずにそのままタスクを実行するのは、例えば、想定より時間が掛かるとか逆に半分の時間で終わるとか、そうした情報を取らない、というリスクをテイクしているんだということ自体、恣意的に顔を背けているんじゃないかと思いたくなるんですよ。
具体的なタスクの仕様が決まっているなら、タスクの作業は担当するエンジニアが見積もりし直さないとその仕様のとおりにできるかどうかは判別できないです。見積もったときは、誰が担当するかなんて決まっていないんですから。
そのタスクを見積もったときのパフォーマンスと実際に担当するエンジニアのパフォーマンスは別な話です。だからこそ、作業直前にそのタスクを担当するエンジニアはその仕様で自分がやったらどのくらい時間が必要なのか、見積もってプロジェクトマネージャと合意しておかないといけないんです。
最新の情報でタスクの見直しをなければプロジェクトマネージャはエンジニアがスケジュールをオーバーランすれば「なにやっているんだ?」と思うし、早く終わってのんびりしていればそれはそれで「何やっているんだ?」って思うんだ。エンジニアだって自分で見積もりし直さなければそれは押し付けられたスケジュールでしかなく、それが後半日足らないと思ってもそれができなければ「無理なスケジュールを押し付けるな!」って思うし、ガバガバな日程なら〆切に合わせてしか作業をしない。夏休みの宿題と一緒だね。その上、日程をオーバーランする。
だから、タスクに着手する前にタスクは着する時点で見積もりをし直さなければならないんだ。それでそのタスクだけ、をやったらどれだけかかるか、集中してやったら何時間必要か、という観点でだけで見積もりし直さないといけない。その後に、朝会とか、レビューの時間と回数を加味するんだ。
そしてタスクの作業ボリュームを日程を見直すことで、プロジェクトマネージャはそれだけ必要だと認識し直すし、エンジニアは合意された日数に対してコミットするんだ。これでお互いの共通認識が持てるので、何か想定外のことが起きれば自然と双方で相談するようになるんだ。でないと、お互いに合意した前提が崩れてしまうからね。