Skip to main content

工数を見積もる

Overview​

この手順は、依頼内容や施策に対して、説明可能な形で工数を見積もるための最小構成。

前提​

  • 目的は「ぴったり当てる」ことではなく、判断材料を揃えること
  • 見積もり結果だけでなく、前提条件と不確実性も一緒に扱う
  • 単位は人時または人日で統一する

手順​

  1. 完了条件を 1-3 行で定義する
  2. 作業を、調査、設計、実装、レビュー、確認、調整に分解する
  3. 各作業ごとに、既知部分と不確実な部分を分ける
  4. 類似案件の実績があれば先に当てる
  5. 不確実な作業にはバッファではなくレンジを付ける
  6. 依存待ちや承認待ちは、工数と期間を分けて記録する
  7. 合計値とあわせて、見積もりが崩れる条件を明記する

コツ​

  • タスク名ではなく、成果物ベースで分解する
  • 実装工数だけでなく、認識合わせやレビューの往復も含める
  • 初見領域は、調査工数を独立させる
  • 見積もりに迷ったら、最小、通常、最大の 3 点で置く
  • 1 人日を超える塊は、さらに分解できないか確認する

ざっくりした見積もり例​

作業工数
要件確認0.5 人日
調査1.0 人日
実装2.0 人日
レビュー対応0.5 人日
動作確認・共有0.5 人日
合計4.5 人日

実務向けの具体例​

開発タスクを見積もる​

作業工数
要件確認0.5 人日
設計0.5 人日
実装1.5 人日
レビュー対応0.5 人日
動作確認0.5 人日
合計3.5 人日

調査タスクを見積もる​

作業工数
調査観点の整理0.5 人日
情報収集1.0 人日
比較検討0.5 人日
結論整理0.5 人日
共有0.5 人日
合計3.0 人日

資料作成タスクを見積もる​

作業工数
構成案作成0.5 人日
素材収集0.5 人日
本文作成1.0 人日
レビュー反映0.5 人日
最終調整0.5 人日
合計3.0 人日

見積もりメモの型​

以下の型で残すと、後で予実差分を振り返りやすい。

項目記載例
依頼内容API の認証方式を変更する
完了条件本番反映後にログイン成功率が既存同等
見積もり単位人日
見積もり値最小 2.5 / 通常 3.5 / 最大 5.0
不確実性外部 API 仕様変更の可能性
崩れる条件追加要件、承認待ち、障害調査の発生

チェックポイント​

  • 完了条件が明文化されている
  • 調査やレビューが別枠で入っている
  • 不確実な箇所にレンジまたは注記がある
  • 他者に説明したとき、なぜその数字かを言える

避けたい進め方​

  • 過去案件の数字だけをそのまま流用する
  • 実装だけ見て見積もる
  • バッファという 1 行で不確実性を隠す
  • 期間と工数を混同して会話する