はじめに

この記事では、実務で使いやすい工数見積もりの考え方とコツを整理します。

前提:単位の定義

1つの数字で見積もると、必ずどちらかに外れます。そのため 最短・最高・バッファ の3つを出し、そこから見積もりを決めるのが基本です。

見積もり工数 = (最短 + 4 × 最頻値 + 最高) / 6

最頻値(最も起こりそうな時間)を中心に、最短と最高で幅を持たせて平均を取る方法です。感覚だけで「たぶん3日」と言うより、根拠のある数字になります。

「APIのエンドポイントを1つ追加する」タスクの場合:

バッファは案件の不確実性に応じて 10〜30% を上乗せするのが目安です。要件が固まっていない場合や初めて触る技術領域では多めに(30%前後)、慣れた作業では少なめに(10%程度)します。

実装しながら設計を詰めていくスタイル(詳細設計書を先に作らないケース)では、見積もりが甘くなりがちです。以下の工程を必ず分解して見積もりに含めます。

工程	最短	最高	バッファ込み見積もり
設計検討	2時間	4時間	3時間
実装	6時間	12時間	9時間
コードレビュー対応	1時間	3時間	2時間
テスト仕様書作成	1時間	2時間	1.5時間
単体テスト実装・実行	2時間	4時間	3時間
バグ修正	1時間	3時間	2時間
合計	13時間	28時間	20.5時間(約3.4人日)

設計をしながら進める場合、「実装工数」の中に設計検討を混ぜ込んでしまうケースが多いですが、別工程として切り出すことで、後から「なぜ想定より時間がかかったか」を振り返りやすくなります。

コードレビューは見積もりから漏れがちな工程です。以下を考慮してバッファを積みます。

テスト仕様書の作成は「実装が終わってから片手間で」となりがちですが、以下の理由で独立した工数として見積もるべきです。

目安として、実装工数の 15〜25% をテスト仕様書作成に充てると現実的な数字になりやすいです。

タスクは半日(3時間)以下に分解する
1人日を超えるタスクは見積もりの誤差が大きくなります。分解できないタスクは「わかっていない部分がある」サインです。
過去の実績と突き合わせる
見積もり時間と実績時間を記録し、次回の見積もりの補正係数として使う(例:自分は見積もりの1.3倍かかる傾向がある、など)。
不確実性の高い部分を先に洗い出す
「初めて使うライブラリ」「外部APIとの連携」「仕様が確定していない箇所」は、そこだけ多めにバッファを積む。
見積もりに「調査時間」を明示的に含める
調べ物の時間は実装時間に埋もれさせず、別項目として切り出す。
バッファは合計に対してではなく、リスクの高い工程に重点的に積む
全工程に一律で20%乗せるより、不確実性の高い工程(設計検討・外部連携部分など)に厚くバッファを積んだほうが精度が上がる。

プログラミングコーチングJISOUでは、新たなメンバーを募集しています。
日本一のアウトプットコミュニティでキャリアアップしませんか？
興味のある方は、ぜひホームページをのぞいてみてください！