task-estimation

タスク見積もり

スコープが雑然としている作業を、適切な期間、正直な不確実性、次の一手を含む1つの見積もりパケットにまとめる場合に、このスキルを使用します。

task-estimation が担当する内容：

• コミットメント前の相対的なサイズ見積もり
• 信頼できる範囲で最も簡潔な見積もり単位の選択
• 確信度／不確実性を伝える表現
• 分割するか、スパイクを実施するかの判断
• 予測の安全性を保つための簡潔な翻訳メモ
• リリースやゲーム開発における、部門横断的な作業負荷の可視化

通常とは異なるケースや、依頼の範囲が広がり始めた場合は、以下の補足ドキュメントを参照してください：

• references/estimation-modes.md
• references/intake-packets-and-route-outs.md
• references/boundary-guide.md

このスキルを使用する場合

• ユーザーが「これはどのくらいの規模？」「どれくらいリスクがある？」「どう見積もればいい？」と尋ねている場合。
• チームがスプリントやマイルストーンの相談に向けて、ストーリーポイント、Tシャツサイズ、プランニングポーカーの準備、または確信度の整理を必要としている場合。
• ロードマップ項目、バグのまとまり、リリース作業、またはゲームのマイルストーンについて、スケジュール上安全だと装わずに見積もりが必要な場合。
• 作業が複雑に入り組んでおり、最初に役立つ成果物が、分割／スパイクの指針を含む見積もりパケットである場合。
• コード作業だけでなく、依存関係、承認、QA、リリース、コンテンツ、ライブオペレーションの負荷も見積もりに反映する必要がある場合。

このスキルを使用しない場合

• 主な作業が、実行可能な単位への分解である場合 → task-planning。
• 主な作業が、日々の進捗、ブロッカー、またはチームの同期である場合 → standup-meeting。
• 主な作業が、納品後にプロセスを振り返ることである場合 → sprint-retrospective。
• ユーザーが不確実性に関する表現を一切含まない、確定したリリース日、固定のコミットメント、または経営層への約束を求めている場合。
• 正直に見積もれるのが調査作業そのものだけである場合。その場合は、最終実装を空想で見積もるのではなく、スパイク／プロトタイプ／バーティカルスライスの作業を見積もってください。

手順

ステップ 1：主要な見積もりモードを1つ分類する

数値を割り当てる前に、依頼の内容を整理してください。

estimation_intake:
  primary_mode: coarse-triage | sprint-candidate | forecast-support | discovery-spike | milestone-cross-functional
  domain: developer-workflow | web-fullstack | product-ops | marketing-gtm | game-development | mixed
  source_material: issue-spec | roadmap-note | launch-packet | gdd-playtest | bug-cluster | chat-context | unknown
  novelty: low | medium | high
  confidence: high | medium | low
  output_shape: estimate-packet | comparison-table | spike-brief | unknown

実行ごとに主要モードを1つ使用してください：

• coarse-triage — 受付、バックログ整理、またはロードマップ比較のための大まかなサイズ見積もり
• sprint-candidate — 直近の作業に対する相対的なサイズ見積もり
• forecast-support — スコープ／日程に関する相談のための、範囲と前提条件の整理
• discovery-spike — 最終的な納品ではなく、調査／プロトタイプ作業の見積もり
• milestone-cross-functional — エンジニアリングが負荷の一部にすぎない作業

複数の主要モードを1つの回答に混在させないでください。

ステップ 2：信頼できる最小限の証拠パケットを集める

正直な見積もりを裏付けるために必要な証拠だけを集めてください：

• 項目の概要と目指す成果
• 現在の成果物：課題、PRD、仕様書、メモのまとめ、プレイテストの記録、バグ一覧、リリースメモ
• 対象となるシステム：フロントエンド、バックエンド、データ、インフラ、QA、分析、コンテンツ、ストア／リリース、ライブオペレーション
• 依存関係、承認、または外部制約
• 見積もりを大きく左右する、判明している不確定要素

証拠が不十分な場合は、すぐに確信度を下げるか、discovery-spike に切り替えてください。

ステップ 3：最も簡潔な見積もり単位を選ぶ

references/intake-packets-and-route-outs.md を使用してください。

デフォルトの選択：

• Tシャツサイズ／大まかな分類：受付やロードマップ比較向け
• ストーリーポイント／相対スケール：スプリント候補の相談向け
• 範囲＋前提条件：予測支援パケット向け
• スパイク見積もり：不確実性が支配的な場合

ルール：

• 時間を尋ねられた場合でも、相対的なサイズを明示してください。
• 前提条件を示してから、時間に換算してください。
• 調査と納品が混在している場合は、それぞれを分けて見積もってください。

ステップ 4：基準と負荷に照らして調整する

何も基準にせず見積もらないでください。

可能であれば、2～3 件の基準と比較します。

• 小規模で、なじみのある項目を 1 件
• 中規模で、一般的な項目を 1 件
• 通常は分割が必要になる大規模な項目を 1 件

負荷を明示的に確認します。

• 複雑さと新規性
• 不明点と依存関係の数
• テスト／QA／検証の負荷
• ロールアウト、移行、承認、または調整の作業
• GTM／ゲーム関連の場合のコンテンツ、ローカライズ、認証、またはライブ運営の負荷

基準がない場合は、その旨を伝え、確信があるふりをするのではなく、慎重さを高めてください。

ステップ 5：見積もりパケットを 1 つ作成する

すべての回答に、次の内容を含めてください。

• 見積もりモード
• 見積もり単位と値
• 確信度
• この規模と判断した理由
• 不確実性の要因
• 依存関係／承認
• 分割またはスパイクの推奨
• 予測に関する注記：この見積もりをどう使うべきか、どう使うべきでないか
• 次の作業が変わった場合の関連する引き継ぎ先

長いアジャイル入門ではなく、簡潔なパケットを 1 つ使います。

ステップ 6：分割またはスパイクの判断を早めに行う

次の場合は分割を推奨します。

• 見積もりが 13、XL、または同様の「大きすぎる」領域に達する
• 調査と実装がひとまとめになっている
• 1 つの項目に複数の担当者／システム／承認経路が隠れている
• 検証、移行、またはローンチの負荷が無視できない

次の場合はスパイクを推奨します。

• 重要な不明点が見積もりの大部分を占めている
• 外部 API、ベンダー、またはプラットフォームの挙動が不明確である
• プロダクト／ゲームの方向性がまだ検証中である
• そうしないと、見積もりが見せかけの精密さになる

ステップ 7：関連する作業の引き継ぎ先を明確にする

確定する前に、次の作業を明示します。

• スライス設計、受け入れ条件、担当者、実行パケットには task-planning を使います
• 次に必要なのが、すでに選定された作業の日々の調整である場合は standup-meeting を使います
• 次に必要なのが、見積もりプロセスが機能したかどうかの学習である場合は sprint-retrospective を使います
• このスキルをロードマップのコミットメント、進捗の見せかけ、またはボード管理に使わないでください

出力形式

# Estimate Packet

## Mode
- Primary mode:
- Domain:
- Why it fits:

## Evidence used
- Main artifacts:
- Systems / functions touched:
- Assumptions / gaps:

## Recommended estimate
- Unit:
- Estimate:
- Confidence:
- Comparable anchors:

## Why this size
- ...
- ...

## Uncertainty drivers
- ...

## Dependencies / approvals
- ...

## Split or spike recommendation
- Keep as-is | Split | Estimate the spike first
- Reason:

## Forecast note
- Safe use:
- Unsafe use:

## Adjacent handoff
- Next skill / process:

例

例 1：スプリント候補の SaaS 機能

入力

次のスプリントに Slack OAuth ログインとアカウント連携を追加する場合の見積もりをしてください。ユーザーアカウントはすでにあり、OAuth プロバイダーも 1 つ本番環境で稼働しています。

望ましい出力の方向性

• モード：sprint-candidate
• 単位：ストーリーポイント
• 見積もり：中程度の相対的な作業範囲、確信度は中程度
• 認証フローと検証の負荷を含める
• 最終的な作業分解は task-planning に引き継ぐ

例 2：不確実性の高いプロダクト／運用ロードマップ項目

入力

第 3 四半期に向けたクリエイター分析ダッシュボード全体の規模はどのくらいですか？指標、データソース、関係者間での定義がまだ曖昧です。

望ましい出力の方向性

• モード：coarse-triage または discovery-spike
• 単位：T シャツサイズまたはスパイク概要
• 確信度：低
• 確定日についての話し合いに使える段階の見積もりではないことを明示する

例 3：ゲームのマイルストーンパケット

入力

一般公開デモビルドの前に、チュートリアルのチェックポイントシステムを追加する場合の見積もりをしてください。セーブ状態、UI メッセージ、QA 回帰テスト、デモフローの仕上げに影響します。

望ましい出力の方向性

• モード：milestone-cross-functional
• QA／仕上げやリリース準備など、コーディング以外の負荷を含める
• チェックポイントのルールがまだ定義されていない場合は、分割またはスパイクを推奨する

ベストプラクティス

1. 夢のようなスコープ全体ではなく、現在の意思決定の対象範囲を見積もります。
2. 相対的な規模の評価と確定的なコミットメントを分けます。
3. 可能であれば、基準や類似する作業を使います。
4. 調査と納品を早い段階で分けます。
5. コーディング以外の負荷を 1 つのエンジニアリング数値に隠さず、明示します。
6. アジャイル理論の講義より、簡潔な見積もりパケットを 1 つ作ることを優先します。
7. 見積もりの確度が低い場合は、その旨を伝えます。

参考資料

• Scrum ガイド
• Atlassian：アジャイルにおけるストーリーポイントとは？見積もり方法を解説
• Scrum.org：ストーリーポイントで見積もるべきか、見積もらないべきか
• John Cutler：ストーリーポイントの使用をやめられますか？
• Rami Ismail：プロトタイプと垂直スライス
• Mountain Goat Software：スプリント計画にストーリーポイントを使わない理由