agentsclimarketplace

Estimation

Skill tdyzzsp47/claude-skills/skills/estimation

システム開発・個人開発の全工程(企画〜設計〜実装〜運用〜マネタイズ)をカバーするClaude Code用スキル集

Install
npx -y skills add tdyzzsp47/claude-skills --skill estimation

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

ソフトウェア開発の工数・期間を見積もるスキル。要件定義・設計・実装・テスト各フェーズの着手前、またはステークホルダーへの計画提示時に使う。

SKILL.md

9.6 KB, as published. Nobody here has run it

見積もり

目的

開発工数と期間を根拠のある数字で提示し、プロジェクト計画の意思決定を支援する。 数字の正確さより「前提と不確実性を明示した納得感のある見積もり」を最優先とする。

使うタイミング

  • 要件定義後、開発着手前に計画を立てるとき
  • ステークホルダーへの予算・スケジュール提案が必要なとき
  • フェーズ境界(設計完了後、実装完了後)で再見積もりするとき
  • スコープ変更が発生し、影響評価が求められるとき

進め方

  1. 前提条件の文書化 見積もり開始前に「何を含み何を含まないか」「依存する外部要因」を箇条書きで確定する。 前提が崩れた時点で再見積もりする契約を関係者と共有する。

  2. タスク分解 [[task-breakdown]] と連携し、見積もり単位を1〜3人日以下に細分化する。 大きいまま見積もると必ず楽観に倒れる。分解してから見積もるが第一原則。

  3. 三点見積もりの適用 各タスクに楽観値(O)・最頻値(M)・悲観値(P)を設定する。 期待値 E = (O + 4M + P) / 6 標準偏差 σ = (P - O) / 6 で不確実性を定量化する。

  4. 実装以外の工数を明示計上 テスト・レビュー・修正・環境構築・ドキュメント・コミュニケーションは 実装工数の1.5〜2倍になる。個別に行として見積もりシートに記載する。

  5. 相対見積もりと絶対見積もりの使い分け

    • ストーリーポイント(相対): スプリント計画、優先順位比較、チームのベロシティ管理
    • 人日(絶対): 契約・予算提示、外部との調整、ガントチャート作成 チーム内ではストーリーポイントで議論し、対外発表時に人日へ換算する。

  6. AI時代の多視点見積もり(見積もりポーカー的手法) 複数のエージェントに独立して見積もらせ、乖離箇所を議論する。

    • Sonnet にタスク分解の下書きと初回見積もりを作成させる
    • Opus に技術的難易度・未知領域のリスクを独立評価させる
    • 乖離が30%超のタスクは根拠を掘り下げ、前提の違いを特定する

  7. 全体バッファの設定 個別タスクに隠しバッファを積まない。全体合計に対してリスクバッファをまとめて置く。 バッファの消費状況を週次で可視化し、燃焼率を管理する。 目安: リスクが低いプロジェクト10〜15%、中程度20〜25%、高リスク30〜40%。

  8. 不確実性コーンによる精度レンジの提示 要件定義前: ±4倍のぶれを想定し、数字より「レンジ」で提示する。 基本設計完了後: ±2倍、詳細設計完了後: ±1.25倍が目安。 フェーズごとに再見積もりする前提を計画に組み込む。

  9. 見積もりレビューと合意 数字を単独で出さず、前提条件・精度レンジ・主要リスクをセットで提示する。 関係者が前提を確認・承認した記録を残す。

成果物テンプレート

# 見積もりシート: [プロジェクト名]
作成日: YYYY-MM-DD  作成者: [名前]  バージョン: 1.0

## 前提条件
- 含む: [例] フロントエンド実装、単体テスト、結合テスト、デプロイ手順書
- 含まない: [例] インフラ構築、負荷テスト、運用保守
- 外部依存: [例] デザインカンプ納品: MM-DD、外部API仕様確定: MM-DD
- チーム構成: [例] フロントエンド2名、バックエンド1名
- 精度レンジ: [例] 詳細設計完了前のため ±50% (不確実性コーン)

## タスク別見積もり

| # | タスク               | O(楽観) | M(最頻) | P(悲観) | E(期待値) | σ   | 前提・リスク                     |
|---|----------------------|---------|---------|---------|-----------|-----|----------------------------------|
| 1 | 要件定義             | 1.0     | 2.0     | 4.0     | 2.2       | 0.5 | 関係者の合意取得に時間がかかる可能性 |
| 2 | 基本設計             | 2.0     | 3.0     | 6.0     | 3.3       | 0.7 | 外部API仕様が未確定              |
| 3 | 詳細設計             | 1.0     | 2.0     | 3.0     | 2.0       | 0.3 |                                  |
| 4 | フロントエンド実装   | 5.0     | 8.0     | 15.0    | 8.7       | 1.7 | デザインカンプの品質に依存        |
| 5 | バックエンド実装     | 3.0     | 5.0     | 10.0    | 5.5       | 1.2 | 外部API連携の複雑度次第           |
| 6 | 単体テスト           | 2.0     | 3.0     | 5.0     | 3.2       | 0.5 |                                  |
| 7 | 結合テスト・修正     | 2.0     | 4.0     | 8.0     | 4.3       | 1.0 |                                  |
| 8 | コードレビュー       | 1.0     | 2.0     | 3.0     | 2.0       | 0.3 |                                  |
| 9 | 環境構築・CI設定     | 1.0     | 2.0     | 4.0     | 2.2       | 0.5 |                                  |
|10 | ドキュメント・引き継ぎ| 1.0    | 1.5     | 3.0     | 1.7       | 0.3 |                                  |
|   | **小計**             |         |         |         | **35.1**  |     |                                  |

## バッファ計画

| 区分               | 工数(人日) | 備考                              |
|--------------------|------------|-----------------------------------|
| タスク合計(期待値) | 35.1       |                                   |
| リスクバッファ(20%)| 7.0        | 週次で消費状況を可視化             |
| **総計**           | **42.1**   | 約 **42人日**                     |

## カレンダー換算
- チーム有効稼働: 2.5名 × 稼働率80% = 2.0人/日
- 所要日数: 42.1 ÷ 2.0 ≒ 21営業日(約1ヶ月)
- 推奨期間レンジ: 1.0〜1.5ヶ月(精度レンジ ±50% 反映)

## バッファ消費ログ
| 日付       | 消費(人日) | 累計消費 | 残バッファ | 理由              |
|------------|------------|----------|------------|-------------------|
| YYYY-MM-DD | 0.5        | 0.5      | 6.5        | 外部API仕様変更対応|

チェックリスト

  • 前提条件(スコープイン/アウト・外部依存)を文書化した
  • タスクを1〜3人日以下に分解した
  • 三点見積もり(楽観/最頻/悲観)を全タスクに適用した
  • テスト・レビュー・環境構築・ドキュメントを個別計上した
  • 実装工数に対して非実装工数が1.5倍以上になっているか確認した
  • 個別タスクに隠しバッファを積んでいないか確認した
  • 全体リスクバッファをまとめて計上した
  • 精度レンジ(不確実性コーン)を添えて提示した
  • 関係者が前提条件を承認した記録がある
  • 次の再見積もりタイミングをスケジュールに入れた

アンチパターン

  • 希望納期からの逆算: 「3ヶ月でやれ」→「3ヶ月で収まる見積もり」は見積もりではなく服従。
  • 一発見積もりを最後まで使い続ける: フェーズが進んでも初回見積もりのまま運用し、遅延が「突然」発生する。
  • テスト・レビュー工数の計上漏れ: 「実装が終わったのに完成しない」の主因。非実装工数は実装の1.5〜2倍。
  • 前提を書かずに数字だけ出す: 数字が独り歩きし、スコープ追加が「無料」と誤解される。
  • 個別タスクへの隠しバッファ: パーキンソンの法則が働き、バッファが全て消費される。可視化できないため管理不能になる。
  • 全タスクを楽観値で合算する: 楽観値の合計は必ず外れる。期待値ベースで集計する。
  • 見積もりポーカーを省略して一人の数字を採用: 複数視点の欠如は大きな見落としにつながる。

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

役割担当モデル理由
前提設定・リスク係数の判断・最終見積もり承認司令塔プロジェクト全体の文脈把握と意思決定が必要
技術的難易度の評価・未知領域のリスク分析Opus深い技術知識と多角的なリスク推論が必要
タスク分解の下書き・類似実績の調査・三点見積もりの集計Sonnet繰り返し処理と情報収集・整理に適している
コードベース規模の計測・LOCカウント・ファイル数集計Haiku高速・低コストな定量計測タスク

関連スキル

  • [[task-breakdown]] — 見積もりの前提となるタスク分解
  • [[requirements-definition]] — スコープ確定のための要件定義
  • [[project-management]] — バッファ消費の追跡と進捗管理
  • [[orchestration]] — マルチエージェント委譲の共通原則
  • [[architecture-design]] — 技術的不確実性の評価に必要なアーキテクチャ把握
  • [[mvp-development]] — スコープを絞ってリスクを下げる開発戦略

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.