メインコンテンツまでスキップ

工数を見積もる

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 行で不確実性を隠す
  • 期間と工数を混同して会話する