| name | estimation |
| description | 開発タスク・機能・プロジェクトの工数・コストを見積もるスキル。WBS分解と三点見積もり（PERT）でレンジ付き見積もりを作り、前提・リスク・除外を明記する。「見積もって」「工数を出して」「何人日かかる？」「見積書を作成して」「規模を見積もって」「ストーリーポイントを付けて」などで発動する。requirements-definer/decomposition と連携する。 |
| metadata | {"version":"1.0.0","tier":"experimental","category":"planning","tags":["estimation","effort","wbs","pert","planning"]} |
estimation
タスク・機能・プロジェクトの工数とコストを、根拠とレンジ付きで見積もる。点ではなく幅で示し、前提を明文化することで、過小・過大見積もりと「言った言わない」を防ぐ。
原則
- 分解してから見積もる — 大きな塊を直接見積もらない。WBS に割ってから積み上げる
- 幅で出す — 単一の数値ではなく、楽観/最頻/悲観の三点とレンジを示す
- 前提を書く — 含むもの・含まないもの・依存・スキル前提を明記する。前提が崩れたら見積もりは無効
- 根拠を残す — なぜその工数かを一言添える。後から検証・調整できるようにする
ワークフロー
Step 1: スコープと前提を固める
- 見積もり対象（機能一覧・要件・チケット）を確認する。曖昧なら確認する
- 単位を決める: 人日 / 人時 / ストーリーポイント。コスト換算が要るなら単価を確認する
- 前提を洗い出す: 対象範囲・除外範囲・依存（他チーム/外部API）・体制/スキル・環境
- 既存の
requirements-definer / decomposition 成果物があれば入力に使う
Step 2: WBS に分解する
- 1タスクが「半日〜数日」に収まる粒度まで割る（大きすぎると誤差が増える）
- 実装だけでなく 設計・テスト・レビュー・結合・ドキュメント・環境構築 も項目に立てる
- 分解の網羅性が不安なら
decomposition スキルに委譲する
Step 3: 三点見積もり（PERT）する
各タスクに 楽観(O) / 最頻(M) / 悲観(P) を置き、期待値とばらつきを計算する。式は references/methods.md。
期待値 E = (O + 4M + P) / 6
標準偏差 SD = (P − O) / 6
- 合計の期待値 = 各 E の和
- 合計の標準偏差 = 各 SD の二乗和の平方根（√Σ SD²）
- 提示レンジ = 合計E ± SD（必要に応じ ±2SD で 95% レンジ）
Step 4: バッファ・係数を乗せる
- コンティンジェンシー（既知の不確実性）: タスクの不確実性に応じて加算
- マネジメント予備（未知）: プロジェクト全体に対し別枠で明示
- 非開発工数（会議・問い合わせ対応・手戻り）を係数または項目で見込む
係数を掛けた場合は「素の積み上げ」と「バッファ込み」を分けて示す。
Step 5: 見積もりを提示する
references/methods.md のテンプレートで出力:
- WBS と各タスクの O/M/P・期待値の表
- 合計（期待値・レンジ・バッファ込み）
- 前提・除外・リスク・精度（概算/詳細）の明記
ガードレール
| 制限 | 内容 |
|---|
| 精度の明示 | 概算（±50%）か詳細（±10%）かを必ず示す。要件が粗いのに精密値を出さない |
| 前提依存 | 前提が未確定なら「前提次第」と明記し、確定後の再見積もりを促す |
| 単一値の禁止 | 原則レンジで出す。単一値を求められたら期待値＋リスク注記を添える |
| 体制依存 | 工数(人日)と期間(暦日)は別物。要員数・並行可否で期間が変わる点を明示する |
