/note/tech

エンジニア出身PMのための開発見積もり入門

要約:

■ 1. 見積もりが難しい理由

  • 見積もりは未経験・未確定の事柄を数値化する行為であり本質的に精度が低い
  • 人は無意識に最良シナリオを基準とする楽観バイアスを持つ
  • 「早くしてほしい」という圧力に根拠なく応じるとバッファのない計画が生まれ破綻時にエンジニアが責任を問われる
  • 見積もりは「予測であって約束ではない」とステークホルダーと共有することがPMの重要な役割

■ 2. 代表的な見積もり手法

  • ストーリーポイント:
    • スクラム開発で使用し工数を時間ではなく複雑さ・不確実性の相対値で表現する
    • フィボナッチ数列(1・2・3・5・8・13・21)を使用する
    • チームのスプリント消化ポイント数(ベロシティ)を計測しスケジュール予測精度を向上させる
    • プランニングポーカーで全員が同時にカードを出すことで認識齟齬を検出し議論する
  • 三点見積もり(PERT見積もり):
    • 楽観値・最頻値・悲観値の3シナリオから期待値を算出する
    • 計算式は「(楽観値 + 4×最頻値 + 悲観値)÷ 6」
    • リスクを織り込んだ結果が得られるためステークホルダー説明やスケジュール表作成に適する
  • 類推見積もり:
    • 過去の類似タスク実績をもとに見積もる
    • 見積もりと実績の継続記録が精度向上の前提となる

■ 3. バッファとスコープ管理

  • バッファは水増しではなく仕様認識齟齬・外部API変更・レビュー修正など想定外事象へのリスク対策
  • MoSCoW法で要件をMust have・Should have・Could have・Won't haveの4分類に整理する
  • プロジェクト開始時にステークホルダーと分類を合意しておくことで圧縮要求に対してスコープ取捨選択で応じられる
  • 圧縮要求への対応方針:
    • スコープ削減交渉として「工数削減は困難だが特定機能をフェーズ2に回すことで納期短縮できる」と提示する
    • リスク明示として「短縮にはレビュー簡略化が必要であり品質リスクが上昇する」と許容可否を確認する

■ 4. 見積もり精度を上げるコツ

  • タスクを1〜2日以内の小単位に分解することで不確実性を低下させる
  • 見積もり後に実際の工数を記録しスプリント振り返りで差分を分析して次回精度を向上させる
  • プロジェクト開始時に不確実性の高いタスクを早期特定しスパイク(調査タスク)を先行して実施する

■ 5. 手法の使い分け

  • ストーリーポイント: スクラムなどイテレーション開発・チームベロシティ管理に向く
  • 三点見積もり: 納期重視・ステークホルダー説明が必要な場面に向く
  • 類推見積もり: 過去実績あり・素早く概算を出したい場面に向く
  • 見積もりは「当てるものではなく不確実性を管理するためのツール」であり外れることを前提にバッファを持ち実績記録で精度を継続改善することがPMに求められる