工数見積もり：なぜ「だいたい三日」が三週間になるのか

見積もりが外れるのは楽観のせいばかりではありません。範囲の食い違いです。あなたは打鍵時間を出し、相手は納品時間を受け取っています。

抜け落ちる工程

機能はコーディング以外も食います。

工程	過小評価される理由
既存コードの読解	「このコードは知っている」は仮定です
結合	相手の API がまだできていない
レビュー後の修正	指摘内容は予測できません
試験と不具合修正	順調な経路しか見積もっていない
配備と確認	環境の問題一回で半日消えます

コーディング日数だけを出すのは、残り全部をゼロと宣言するのと同じです。

数値ではなく幅で出す

「三日」の情報量はゼロです。根拠付きの幅で出します。

2〜5 日。
2 日：API は準備済みで既存コードを再利用できる。
5 日：新しいテーブルが必要で、他チームとの結合も要る。

幅は曖昧さではなく、不確かさを口に出すことです。単一の数値は、賭けているか、危険を考えていないかのどちらかです。

半日以内に割る

二日を超える作業は未知が多すぎて見積もれません。半日未満に割ると誤差は大きく下がります。精度が上がったからではなく、各段階の未知が減ったからです。

× ユーザー書き出し機能を作る（5 日）
○ 書き出し API を足す（1 日）
  ダウンロードボタンを足す（0.5 日）
  大容量を分割転送（1 日、不確か）
  権限検査（0.5 日）

「不確か」と付けた行こそ、単独で議論すべき箇所です。

履歴で校正する

感覚は当てになりません。実測を記録して次に突き合わせます。

見積もり 2 日 → 実際 4 日
見積もり 1 日 → 実際 1.5 日
平均係数 ≈ 2

十数件も溜まれば、自分の安定した倍率が見えます。それを認めて掛ける方が、今度こそ正確にと誓うより役に立ちます。

見積もるべきでないもの

• 仕様が固まっていない機能：先に「仕様を確定させる時間」を見積もる
• 他チームの日程待ち：それは待ち時間で工数ではありません
• 未経験の技術：先に調査を一本入れる

三番目が特に重要です。やったことのないことに約束はできません。 約束できるのは「できるかどうかが分かるまでの時間」だけです。

見積もりは能力の問題ではなく情報の問題です。未知を小さく割り、幅で出し、履歴で校正すれば、残りは時間が処理します。