作業時間を割り出す

　設定された作業に対する「時間」を割り出すには、予想される「作業量」を単位時間あたりの作業量（基準値）で割ることで求められます。そのためには自分は１時間に何行のソースコードが書けるのか、何ページの仕様書が書けるのか、あるいは仕様書で述べられている内容を理解するために、それを１時間で何ページ進めるかを知っていなければなりません。これらの「分母」の値は人によって異なるでしょうが、「分母」に相当する値を持たないままでは、作業時間を見積もることはできません。

　これをいい加減にしたままでは、詳細スケジュールが“あてずっぽ”になってしまいます。スケジュールを少しでも正確に見積もろうとすれば、これらの基準値を手に入れる必要があると同時に、管理者もそれを知る必要があります。そうでなければ、当人から提出されたスケジュールの妥当性を判断することができません。仕事の経験の浅い人は、この基準値を手に入れながら作業を進めることになります。

　前段階で作業の「量」が見積もれていれば、それを「時間」に変換するのはそれほど難しいことではありません。それよりも、折角「量」をイメージしたのに、時間に変換する時にいい加減になってしまうことがあります。おそらく、「量」をイメージする行為と、時間を把握する行為が別々の「作業」となっているのでしょうが、これでは何の意味もありません。

　ところで、これまでで述べてきたように、ある程度経験を積んでいる人は、作業をブレークダウンして、その「量」を把握するときには、同時に「作業時間」の形でも認識しているものです。もちろん、「分母」の基準値が曖昧であれば、認識された「期間」も曖昧な部分が残るでしょうが、それでも、３０分から数時間の単位に作業が「分割」されたときには、自分の持つ基準値を正確に掴んでいない段階でも、ある程度は割り出せるものです。

　また、こうして立てられた詳細スケジュールを検証していく過程で、マネージャーやリーダーは、担当者にその「作業時間」を想定した根拠を質問してあげることで、彼は自分の基準値を認識するようになります。もちろんこの「基準値」は常に更新される必要があることは言うまでもありません。

　こうして、作業の「量」と、その結果としての「時間」が割り出されたとき、手元には、作業の項目と時間の「一覧表」が手に入っているはずです。そのなかで、基本作業と見なされる作業名のところには、見積もられた「量」も書き加えられています。ただし、この段階では未だスケジュールにはなっていません。

　ただ、できればこの段階で、作業の前後関係をその表に書き加えておくことをお勧めします。この後の作業で、これらの項目を時間軸に展開しますが、その際に、どの作業の前には、どの作業が終わっていなければならないのかが問題になってきます。もちろん、データフローが書かれていれば、作業の前後関係はそこで示されています。

　ちなみにエンジニア個人の生産性の「差」は、一般的な組織では数倍の開きがみられます。時には１０倍〜２０倍も開いてしまうこともあり、「基準値」の把握は、マネージャーにとっておろそかには出来ません。