プログラミングソフトウェア開発最大の難所と呼ばれる見積もり。見積もりに関する古典があるくらいにはやはり見積もりというのは難しい。自分もずっと見積もりを正しくするためにはどうすることがベストなのか、ということにずっと悩みを抱えていたが、社会人2年目ももう少しで終わろうかという、ここ最近ようやく自分の中でのパターンに気がついてきた。「所要工数の変更を追跡できていない」のふたつであった。1日作業は8時間相当ではない第一に、自分は1日の作業時間が8時間まるまるあると思い込んでいた。考えてみるとめちゃくちゃな話だが、1年目の自分は「見積もりをしましょう」というタイミングになると、1日8時間を基準に何人日自分の作業量では必要になるかを起算していた。まともな社会人になればすぐに分かることだがオフィスで過ごす8時間はまるまる8時間をプライマリの作業に当て込むことは不可能だ。定例ミーティング、突発のヘルプタスク、調査タスクなど実際に週の中で決まって発生しうる(あるいは発生することが高確率で予測できる)業務というのは作業可能時間からは抜いておかねばならない。自分はこれを勘案できておらず、常に1日の作業を残業で埋めることとなった。なることは当たり前で、なぜなら実際には隠れた定例業務がプラス1-2時間あれば8時間にその時間を足すことになるからだ。ここから学んだことはまず見積もりをする際には向こう2,3週間の自分のスケジュールを当て込んでブロックされる時間を弾いた上で使える時間を計算することであった。工数の変化を毎日追跡するその日の夕方の時点で、自分の作業がどこかでスタックしている状態なのか、それとも順調にオンスケジュールなのかを把握した上で、今の自分の作業状態が初期の見積もりで出された最終的な終了予定日(あるいは納品日)にどう影響を与えるのか、をなあなあにしていた。当初の予定以上に工数をとってしまうことというのはザラにあることだし、そのような「見積もり誤り」を絶対になくすというのは不可能である。ここで必要になるのは、PMなりチームのリードなりに「自分はいま遅れている、従って当初の見積もりで予定していた日付には間に合わない」というような通達をする必要がある。これは早ければ早いほどいい。ここで間に合わせる必要があれば、先回りして自分が作業するはずだった開発工数を他メンバにカバーしてもったり(クラッシング)あるいはリリースを延期するなどの意思決定が可能になる。これがリリース直前に発覚すると恐ろしいことになる。自分は1日が終わるとどこまで進捗が進んだかをしっかりタスク管理ツールなりにマークせずスタコラサッサと帰っていた。正しくは1日のおわりの夕方くらいに、自分の作業が予定に対してどこまで終わったか、次に影響を及ぼすような材料が何かあったか(実装上あとあと影響を及ぼしそうな作りになってしまった、そもそも予定工数以上に時間をつかってしまった、など)を記録しておくのがよい。22:47自分なりの作業工数見積もりのヒントTweet関連記事2019-09-29Amazonで買える海外のプロテインバー3選プロテインバーと呼ばれるものがある。大学の後期の期末試験を受けていた。(8)はてなブログをはじめよう!IzumiSyさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。