自分なりの作業工数見積もりのヒント

ソフトウェア開発最大の難所と呼ばれる見積もり。見積もりに関する古典があるくらいにはやはり見積もりというのは難しい。

自分もずっと見積もりを正しくするためにはどうすることがベストなのか、ということにずっと悩みを抱えていたが、社会人2年目ももう少しで終わろうかという、ここ最近ようやく自分の中でのパターンに気がついてきた。自分が見積もりを失敗してしまう理由には大きく分けてふたつあり、それは「1日の作業可能時間を見誤っている」 と「所要工数の変更を追跡できていない」のふたつであった。

1日作業は8時間相当ではない

第一に、自分は1日の作業時間が8時間まるまるあると思い込んでいた。改めて考えてみるとめちゃくちゃな話だが、1年目の自分は「見積もりをしましょう」というタイミングになると、1日8時間を基準に何人日自分の作業量では必要になるかを起算していた。しかし、まともな社会人になればすぐに分かることだがオフィスで過ごす8時間はまるまる8時間をプライマリの作業に当て込むことは不可能だ。定例ミーティング、突発のヘルプタスク、調査タスクなど実際に週の中で決まって発生しうる（あるいは発生することが高確率で予測できる）業務というのは作業可能時間からは抜いておかねばならない。

自分はこれを勘案できておらず、常に1日の作業を残業で埋めることとなった。もちろんこうなることは当たり前で、なぜなら実際には隠れた定例業務がプラス1-2時間あれば8時間にその時間を足すことになるからだ。つまり、ここから学んだことはまず見積もりをする際には向こう2,3週間の自分のスケジュールを当て込んでブロックされる時間を弾いた上で使える時間を計算することであった。

工数の変化を毎日追跡する

その日の夕方の時点で、自分の作業がどこかでスタックしている状態なのか、それとも順調にオンスケジュールなのかを把握した上で、今の自分の作業状態が初期の見積もりで出された最終的な終了予定日（あるいは納品日）にどう影響を与えるのか、をなあなあにしていた。もちろん、当初の予定以上に工数をとってしまうことというのはザラにあることだし、そのような「見積もり誤り」を絶対になくすというのは不可能である。

ここで必要になるのは、PMなりチームのリードなりに「自分はいま遅れている、従って当初の見積もりで予定していた日付には間に合わない」というような通達をする必要がある。そして、これは早ければ早いほどいい。もしここで間に合わせる必要があれば、先回りして自分が作業するはずだった開発工数を他メンバにカバーしてもったり（クラッシング）あるいはリリースを延期するなどの意思決定が可能になる。これがリリース直前に発覚すると恐ろしいことになる。

自分は1日が終わるとどこまで進捗が進んだかをしっかりタスク管理ツールなりにマークせずスタコラサッサと帰っていた。今思うとそりゃ工数管理がめちゃくちゃになって当然という感じはあるが... 正しくは1日のおわりの夕方くらいに、自分の作業が予定に対してどこまで終わったか、次に影響を及ぼすような材料が何かあったか（実装上あとあと影響を及ぼしそうな作りになってしまった、そもそも予定工数以上に時間をつかってしまった、など）を記録しておくのがよい。