task-planning

タスク計画

雑然としたコンテキストを、チームが実際に行動に移せる小さな計画パケットにまとめる仕事には、このスキルを使用します。

task-planning は、見積もり、ボード、レビュー、実行の前に、バックログの整理、機能の分解、スプリント候補の準備、リリースの切り分け、マイルストーンパケットの作成、ロードマップから実行への翻訳を行う、PM 向けの入口です。

主なリファレンス：

• references/intake-packets-and-route-outs.md
• references/packet-shapes.md
• references/readiness-checklist.md
• references/planning-patterns.md
• references/sprint-planning-recipe.md — パケットがスプリント候補で、チームにベロシティの履歴がある場合

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

• 依頼が曖昧すぎる、大きすぎる、または多くの要素が混在していて、そのまま実装に着手できない。
• バックログを整理して、準備完了と未準備の作業に分ける必要がある。
• ロードマップ項目、機能、バグのまとまり、ローンチ施策、プレイテストの結果を実行可能な単位に分割する必要がある。
• 依存関係、ブロッカー、受け入れ基準を明記した、コンパクトなパケットが必要である。
• パケットが複数の分野にまたがる。フロントエンド／バックエンド、PM／運用、GTM／コンテンツ、またはコード／コンテンツ／ビルド／プレイテスト作業など。
• 重要な問いが「どれくらいの規模か？」「どのボードを使うべきか？」ではなく、「次に実際に何をすべきか？」である。

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

• 主な作業が規模の見積もり、予測、ストーリーポイントの表現である → task-estimation。
• 作業はすでに存在し、実際の作業がイシューの状態遷移である → triage。
• 計画はすでに存在し、実際の作業がレビュー／承認または差分への注釈である → plannotator。
• 主な作業が日々の状況調整である → standup-meeting。
• 主な作業が完了した作業の振り返りである → sprint-retrospective。
• 作業がまだコンセプトの策定、スコープの調整、または分解前のゲーム制作の調整段階である → まず bmad、bmad-idea、または bmad-gds を使用します。

手順

ステップ 1：インテークパケットを 1 つ選ぶ

references/intake-packets-and-route-outs.md を参照し、主要なパケットを 1 つだけ選びます。

task_planning_packet:
  packet: backlog-cleanup | feature-slice | sprint-candidate | release-packet | milestone-packet | discovery-first
  domain: developer-workflow | web-fullstack | product-ops | marketing-gtm | game-development | mixed
  source_material: repo/issues | prd/spec | gdd/playtest | launch-notes | chat-context | mixed | unknown
  readiness_state: mostly-ready | mixed | mostly-fuzzy
  output_shape: single-packet | slice-table-plus-not-ready | release-packet | milestone-packet | discovery-packet

パケットの意味：

• backlog-cleanup — 作業を明確化して重複を取り除き、準備完了と未準備に分けます。
• feature-slice — 1 つの機能またはバグのまとまりを、割り当て可能な単位に分割します。
• sprint-candidate — 次のイテレーションに向けて、準備完了の作業を用意します。
• release-packet — ローンチ、ロールアウト、キャンペーン、または本番稼働に向けた作業を整理します。
• milestone-packet — 分野横断のマイルストーンまたはデモの作業を調整します。特にゲームの場合に適しています。
• discovery-first — 実装の準備ができていると見なす前に、不明点を洗い出します。

ステップ 2：信頼できる最小限の根拠を集める

雰囲気だけで計画を立てないでください。分解を裏付ける最小限のパケットを集めます。

• 目標または問題の説明
• ユーザー、ビジネス、チーム、またはプレイヤーにとっての成果
• 現在の資料：イシュー、仕様／PRD、GDD、ローンチノート、プレイテストのメモ、バグ一覧、またはチャットのコンテキスト
• タイムラインまたは契機：スプリント、リリース、マイルストーン、イベント、または依存関係の期間
• 明らかな制約：担当者、プラットフォーム、環境、承認、外部依存関係
• パケットが準備完了に見えても、実際にはそうでない状態にしてしまう可能性のある不足情報

根拠が乏しい場合はそのことを明記し、確実性を捏造するのではなく、discovery-first を選びます。

ステップ 3：早い段階でディスカバリーとデリバリーを分ける

作業単位を書く前に、次の項目を分けます。

1. ディスカバリー — 未回答の質問、検証、不足している判断
2. 基盤 — セットアップ、アーキテクチャ、共有アセット、ツール、環境
3. デリバリー — ユーザー向けまたはシステム向けの実装単位
4. 検証 — QA、分析、レビュー、スモークテスト、プレイテスト、ローンチ前の確認
5. フォローアップ — ドキュメント、導入支援、ロールアウト、報告、モニタリング、配布

調査や未解決の判断を、ビルドチケットの中に埋もれさせないでください。

ステップ 4：最小のパケット形式を選ぶ

references/packet-shapes.md を使用します。

ルール：

• ユーザーが次に行うアクションを 1 セット必要としている場合は、単一のパケットを優先します。
• 主なニーズが準備完了／未準備のトリアージである場合は、スライステーブルと未準備項目のリストを使用します。
• 作業がリリース期間に紐づいている場合は、リリースパケットを使用します。
• 作業に多くのマイルストーンがあり、複数分野にまたがる場合は、マイルストーンパケットを使用します。
• パケットが分解、見積もり、ボード管理、レビュー、セレモニーを一度に行うようになった場合は、責任を分割して外部にルーティングします。

ステップ 5：準備状況の項目を含めてスライスを作成する

各スライスには次の項目を含めます。

• タイトル
• 成果
• 担当者の役割
• 依存関係
• 必要な入力
• 受け入れ基準
• リスク／不確実性
• 準備完了？ はい／いいえ
• 未準備の場合、不足しているものは何か

短く、検証可能な受け入れ基準を使用します。「より良く動作する」や「リリース準備完了」のような曖昧な表現は避けてください。

ステップ 6：順序とブロッカーを明示する

次の項目を明確に記載します。

• 並行して進められる作業
• 順番に進める必要がある作業
• ブロックされている作業
• 後回しにすべき作業

references/readiness-checklist.md のブロッカー分類を使用します。

• missing-scope
• missing-design
• missing-data
• external-dependency
• environment-access
• approval-needed
• cross-team-handoff

ステップ 7：外部ルーティングの確認を行う

以下のすべてを確認します。

1. 選択したパケットが、実際の計画業務に合っていること。
2. 確度が低い場合、調査と実装が分離されていること。
3. パケットが、見積もり、ボード管理、計画レビュー、スタンドアップ、レトロスペクティブを暗黙のうちに取り込んでいないこと。
4. チュートリアルのような出力にならずに、分野横断的な詳細が保たれていること。
5. パケットの最後に、明確な次の一手が 1 つ示されていること。

明示しておく外部ルーティング：

• 見積もり → task-estimation
• 課題の状態遷移 → triage
• 計画のレビュー／承認 → plannotator
• 日々の調整 → standup-meeting
• 完了した作業の振り返り → sprint-retrospective
• コンセプトの策定／戦略の具体化 → bmad、bmad-idea、bmad-gds

ステップ 8：概要または最終パケットを返す

本格的なドラフトを作成する前の、推奨される概要形式：

# Task Planning Brief

## Packet choice
- Packet:
- Domain:
- Why it fits:
- Output shape:

## Source material used
- Main evidence:
- Constraints / dependencies:
- Assumptions / gaps:

## Planned slices
1. slice
2. slice
3. slice

## Route-out notes
- Out of scope:
- Not-ready work kept separate:
- Recommended next move:

ユーザーがすでに最終成果物を求めている場合は、簡潔な計画パケットを直接返します。

出力形式

デフォルトのパケット形式：

# Planning Packet

## Planning horizon
- Packet:
- Domain:
- Confidence: high | medium | low

## Goal
- ...

## Assumptions
- ...

## Work slices
| Slice | Outcome | Owner role | Dependencies | Ready? |
|------|---------|------------|--------------|--------|
| ... | ... | ... | ... | yes/no |

## Slice details
### 1. [Slice name]
- Inputs required:
- Acceptance criteria:
  - [ ] ...
- Risks / uncertainty:
- Notes:

## Sequencing
1. ...
2. ...

## Blockers / not-ready items
- Bucket:
- Missing:
- Next action:

## Recommended next move
- start implementation | run discovery first | groom with owners | estimate now | defer until dependency clears

例

例 1：フルスタック機能のスライス分割

入力

SaaS アプリの新しいチーム招待フローを分解してください。スプリント計画の前に、メールでの招待、招待の承諾、管理者向けの可視性が必要です。

望ましい出力の方向性

• パケット：sprint-candidate
• 分野：web-fullstack
• バックエンド／データ、招待の承諾フロー、管理者向けの可視性、検証、フォローアップに分ける
• ストーリーポイントは対象外とする

例 2：バックログの整理

入力

オンボーディングに関する曖昧なバックログ項目がたくさんあります。来週、実際に何が準備できているのか分かるように整理してください。

望ましい出力の方向性

• パケット：backlog-cleanup
• 出力形式：slice-table-plus-not-ready
• 不足しているスコープ、担当者、承認を明示する
• 調査チケットと実装チケットを分ける

例 3：マーケティング／リリースパケット

入力

B2B のローンチに向けた次のリリース施策を計画してください。ランディングページの更新、メールシーケンス、アトリビューションの確認、ローンチ当日のレポートが必要です。

望ましい出力の方向性

• パケット：release-packet
• 分野：marketing-gtm
• アセットの作成、レビュー／承認、配信、測定、レポートを分ける
• 詳細なコピーライティング／キャンペーン実行は marketing-automation にルーティングする

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

入力

ローグライクのデモに向けた次のマイルストーンを計画してください。チュートリアルの改善、コントローラー対応、配信者向けビルドが必要です。

望ましい出力の方向性

• パケット：milestone-packet
• 分野：game-development
• コード／システム作業、コンテンツ／仕上げ、ビルド／QA、プレイテスト／配信に関する作業を分ける
• 必要に応じて、より広範なゲーム制作の調整は bmad-gds にルーティングする

ベストプラクティス

1. 作業を分解する前に、主要なパケットを1つ選びます。
2. 要件が不安定な場合は、ディスカバリーとデリバリーを分けます。
3. 大まかな作業カテゴリよりも、小さくレビューしやすい単位を優先します。
4. ブロッカーや不足している入力情報は、メモに埋もれさせず明示します。
5. 開発者のワークフロー、Web／フルスタック、プロダクト／オペレーション、マーケティング／GTM、ゲーム開発それぞれの領域固有のニュアンスを保ちつつ、入り口を肥大化させないようにします。
6. サイジング、ボード管理、レビュー、日次の進行、振り返りはスキルの範囲を広げず、別の場所に切り分けます。
7. チームがすぐに着手できるだけの簡潔さを保ちます。
8. 役割の表現が大きく変わった場合は、簡潔版とマニフェストのディスカバリー情報を更新します。

参考資料

• Atlassian — バックログのリファインメント
• Atlassian — スプリント計画
• GitHub Docs — Projects について
• GitHub Docs — マイルストーンについて
• HacknPlan Docs