エンジニアが仕事で成果を出すということはタスクの完了定義をDoneすることだけどDoneさせるにはタスクを時間で制御するんだよ

作業待ちのタスクは作業待ちにするときにはそのタスクがどんな成果物を期待しているのか、タスクの中の段取りは何を経ないといけないのか、正味どのくらいの時間でやれそうなのか、を明確にしてチームの中で合意してから着手すると、大体予定とおり進捗するものです。もちろん、タスクをToDoに入れてどのようなタスクなのかタスクのスペックを洗い出している最中にすべてが決まらないこともあってそれはそれで前提や仮説を置いておくことをタスクのチケットにポストイットを貼って忘れないようにしておくといいです。

実際、タスクがアサインされれば、次工程のDoingは担当するエンジニアに任されるわけで、そこからはエンジニアの裁量の中になるわけです。あとは期限までにDone＝タスクを完了基準を満たすように完了予定日までに仕上げればいいんです。“期限までに”ね。

どのようなやり方をしても、それはウォーターフォールでもスクラムでも、担当するエンジニアによって予定どおり進められる人もいればいつも同じようにスケジュールオーバーランしている人もいる。困ったことにタスクのスケジュールをオーバーランする人はそれを見越してスケジュールに「前回は見積もった日数の1.3倍で終わったから今回は計画を出してそれの1.3倍にしておこう。」と計画すると計画した元の1.3倍のスケジュールをペロッと消費してしまうんです。で、終わらない。

タスクが終わらないエンジニアは自分の基準で仕事をしている
ほんと、いつもそう思うんですよ。

「これ5時間で終わる？」
「5時間あれば終わると思いますよ。」
「これ、タスクの中身はどう考えてる？」
「資料調べて、整理して、パラメータ変更して、レビュー、ですね。」
「その資料は何使うつもり？」
「仮想サーバ一覧から該当するサーバを探しますよ。で、資料を作ります。」
「その資料、一から作るって感じに聞こえたんだけど？」
「そうですよ。あのサーバは変更するの初めてですから。」
「え？同じような変更作業を先週したじゃない。その資料は流用しないの？」
「いいえ。」

タスクを合意した時間で終わらそうと思うなら、そのタスクをスペックどおりに作り上げることがexitの大前提だけれど、もう一つ物事を判断する基準があって、それが“時間”です。タスクのスペックを決めるときに作業に掛けてよい時間を合意しているのだから、時間に間に合わせるのも仕事の内です。

ところが、スケジュールをオーバーランするエンジニアはそれを頭の中から追い出してしまう。タスクは納期もスペックなのに、です。

納期を頭の中から追い出してしまうこと自体、自分の判断基準で考えている証左と言ってもいいし、それならタスクのスペックを決めるときの完了予定日は何だったのか、と自分から計画の完了日を伝えないといけないのにしていないことに驚きを隠せないんですよ。

勿論、理想時間で見積もるし、仮説を前提にすることもあるからそうした確定要素が発現したらそれはタスクの完了予定日を見直さないといけない。それは担当するエンジニアからチームに共有する義務があるのはそのタスクを実施している主体者はそのエンジニアなのだから。

そのような状態は、そのタスクを担当するエンジニアの独りよがりな基準で仕事をしているから、なんですよ。

タスクを期限までに終わらせられるエンジニアは時間でスタートする
タスクを合意したdue dateまでにexitするためには、モノゴトの判断基準に“時間”を持っていないといけないです。時間という基準を持っているから、タスクの中の段取りを何時までに終わらせないとあとの余裕がなくなるとか、先にレビューの時間を確保するためにレビューアの身柄を予約で拘束する、とかするわけです。

タスクの段取りは言い換えればタスクの中のマイルストーンなんですよ。タスクを予定どおりに終わらすことが出来るエンジニアは、そのマイルストーンを迎えたときにタスクはどのような状態でいないといけないのかをイメージできるわけです。だから、マイルストーンごとの状態にdue dateから時間を逆算してプロットできるんですね。

それは、段取でどこに時間を取られそうか、どこに不確定要素があるか、どの程度の仕上がりになりそうか、仕上がりはタスクのスペックを確保しそうか、など、エンジニア自身が自分で算段しますが、すべての基準は合意したことであって自分のモノは別に必要ないことを知っているんですね。

だから、タスクのスペックと違うことが起きればチームに相談するし、前提が変わればスペックをスケジュールを含めて見直すことが出来るんです。

タスクをスペックどおりに完了させることが出来るエンジニアは当然ですが、時間軸という指標をもっているし、スケジュールオーバーランするエンジニアはそれも持っていないのです。