はじめに
この記事では、実務で使いやすい工数見積もりの考え方とコツを整理します。
前提:単位の定義
-
1人日(1営)= 6時間
- 8時間稼働の想定でも、会議・調べ物・差し込み対応などを考慮して、実作業時間は6時間で見積もります
| 作業時間 | 人日換算 |
|---|---|
| 1時間 | 約0.17人日 |
| 3時間 | 0.5人日 |
| 6時間 | 1人日 |
| 12時間 | 2人日 |
| 30時間 | 5人日(1週間) |
三点見積もり(最短・最高・バッファ)
1つの数字で見積もると、必ずどちらかに外れます。そのため 最短・最高・バッファ の3つを出し、そこから見積もりを決めるのが基本です。
それぞれの意味
- 最短見積もり:何も問題が起きず、完全に集中して作業できた場合の時間
- 最高見積もり:仕様の解釈違い、環境トラブル、設計のやり直しなど、現実的に起こりうる問題を織り込んだ時間
- バッファ:予期しない事態(急な仕様変更、体調不良、他タスクの割り込みなど)への保険
計算式(PERT法の簡易版)
見積もり工数 = (最短 + 4 × 最頻値 + 最高) / 6
最頻値(最も起こりそうな時間)を中心に、最短と最高で幅を持たせて平均を取る方法です。感覚だけで「たぶん3日」と言うより、根拠のある数字になります。
具体例
「APIのエンドポイントを1つ追加する」タスクの場合:
| 項目 | 時間 | 人日換算 |
|---|---|---|
| 最短 | 4時間 | 0.67人日 |
| 最頻値 | 6時間 | 1.0人日 |
| 最高 | 10時間 | 1.67人日 |
| PERT見積もり | (4+24+10)/6 = 6.3時間 | 約1.05人日 |
| バッファ(20%) | +1.3時間 | 約1.25人日 |
バッファは案件の不確実性に応じて 10〜30% を上乗せするのが目安です。要件が固まっていない場合や初めて触る技術領域では多めに(30%前後)、慣れた作業では少なめに(10%程度)します。
設計をしながら進める場合の見積もり
実装しながら設計を詰めていくスタイル(詳細設計書を先に作らないケース)では、見積もりが甘くなりがちです。以下の工程を必ず分解して見積もりに含めます。
工程の分解例
- 設計検討:データ構造、API仕様、画面遷移などをコードに落とし込む前に考える時間
- 実装:実際にコードを書く時間
- コードレビュー対応:レビュー依頼〜指摘対応〜再レビューまでの時間
- テスト仕様書作成:単体テスト・結合テストの項目を洗い出し、ドキュメント化する時間
- 単体テスト実装・実行
- バグ修正・調整バッファ
見積もりテーブル例(1機能あたり)
| 工程 | 最短 | 最高 | バッファ込み見積もり |
|---|---|---|---|
| 設計検討 | 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人日) |
設計をしながら進める場合、「実装工数」の中に設計検討を混ぜ込んでしまうケースが多いですが、別工程として切り出すことで、後から「なぜ想定より時間がかかったか」を振り返りやすくなります。
コードレビューのバッファを軽視しない
コードレビューは見積もりから漏れがちな工程です。以下を考慮してバッファを積みます。
- レビュアーの対応が翌日以降になる可能性(待ち時間も工数に含めるかはチームのルール次第ですが、少なくとも指摘対応の時間は必ず見積もりに入れる)
- 指摘の量に応じて1〜3往復発生する前提で、1往復あたり30分〜1時間を目安にバッファを確保
- 設計方針から差し戻しになるケースもあるため、大きめの機能では「設計レビュー」の工程を別途設けるのも有効
テスト仕様書作成を見積もりに入れる
テスト仕様書の作成は「実装が終わってから片手間で」となりがちですが、以下の理由で独立した工数として見積もるべきです。
- テスト観点の洗い出し自体が仕様の見落としを発見する重要な工程
- ドキュメント化の時間は実装のスピード感とは別物(考える時間 + 書く時間)
- レビューが必要な場合はそのレビュー対応時間も含める
目安として、実装工数の 15〜25% をテスト仕様書作成に充てると現実的な数字になりやすいです。
見積もり精度を上げるための実践的コツ
-
タスクは半日(3時間)以下に分解する
1人日を超えるタスクは見積もりの誤差が大きくなります。分解できないタスクは「わかっていない部分がある」サインです。 -
過去の実績と突き合わせる
見積もり時間と実績時間を記録し、次回の見積もりの補正係数として使う(例:自分は見積もりの1.3倍かかる傾向がある、など)。 -
不確実性の高い部分を先に洗い出す
「初めて使うライブラリ」「外部APIとの連携」「仕様が確定していない箇所」は、そこだけ多めにバッファを積む。 -
見積もりに「調査時間」を明示的に含める
調べ物の時間は実装時間に埋もれさせず、別項目として切り出す。 -
バッファは合計に対してではなく、リスクの高い工程に重点的に積む
全工程に一律で20%乗せるより、不確実性の高い工程(設計検討・外部連携部分など)に厚くバッファを積んだほうが精度が上がる。
まとめ
- 1人日 = 6時間で計算し、現実的な稼働時間を基準にする
- 最短・最高・バッファの3点で見積もり、PERT法などで根拠のある数字にする
- 設計をしながら進める場合も、設計検討・実装・コードレビュー・テスト仕様書作成を工程として分解する
- コードレビューとテスト仕様書作成は見積もりから漏れやすいので、必ず独立項目として計上する
- 見積もりと実績を記録し、自分やチームの傾向を次の見積もりに反映する
JISOUのメンバー募集中！
プログラミングコーチングJISOUでは、新たなメンバーを募集しています。日本一のアウトプットコミュニティでキャリアアップしませんか？
興味のある方は、ぜひホームページをのぞいてみてください！