estimation

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: スコープと前提を固める

1. 見積もり対象（機能一覧・要件・チケット）を確認する。曖昧なら確認する
2. 単位を決める: 人日 / 人時 / ストーリーポイント。コスト換算が要るなら単価を確認する
3. 前提を洗い出す: 対象範囲・除外範囲・依存（他チーム/外部API）・体制/スキル・環境
4. 既存の 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%）かを必ず示す。要件が粗いのに精密値を出さない
前提依存	前提が未確定なら「前提次第」と明記し、確定後の再見積もりを促す
単一値の禁止	原則レンジで出す。単一値を求められたら期待値＋リスク注記を添える
体制依存	工数(人日)と期間(暦日)は別物。要員数・並行可否で期間が変わる点を明示する