Task breakdown

タスク定義・分解

目的

大きな機能要件を「半日〜2日で完結し、完了を検証できる」タスク単位に分割する。 適切な粒度に分解することで、AIエージェントへの並列委譲・進捗の可視化・手戻りの局所化を実現する。

使うタイミング

• アーキテクチャ設計・詳細設計が完了し、実装に着手する前
• スプリント計画でバックログをタスクに落とし込むとき
• 機能が大きくて「どこから手をつけるか」が不明確なとき
• AIエージェントへの並列委譲を計画するとき

進め方

1. 機能一覧を洗い出す 設計ドキュメント・画面設計・要件定義を読み、ユーザーに見える機能を列挙する。 この時点では粒度を気にせず、まず網羅することを優先する。

2. 縦切りで分割する 「DB層→API層→UI層」の横切りではなく、1つのユーザー操作が端から端まで動く縦切りを基本単位とする。 横切り分割は最後まで何も動かないため、進捗確認・デモ・早期フィードバックができない。

3. 最初のタスクを「歩くスケルトン」にする 全層を貫通する最小限の動くものを最初のタスクとする。 例: ログイン機能なら「ハードコードした資格情報で/homeにリダイレクトできる」だけでよい。 スケルトンが動けば、以降のタスクは並列化・委譲が容易になる。

4. 不確実な部分をスパイクとして先行させる 外部APIの仕様・パフォーマンス特性・未知ライブラリの挙動など、見積もりが立たない箇所は **時間枠を切った調査タスク(スパイク)**として先行させる。スパイクの成果物は「判断材料」であり、実装コードではない。 スパイク完了後に後続タスクの見積もりを確定させる。

5. タスクサイズを調整する

   • 半日未満: 隣接タスクと統合を検討
   • 半日〜2日: 適切
   • 2日超: さらに分解する タスクが大きいほど完了条件が曖昧になりやすく、委譲プロンプトの品質も下がる。

6. 各タスクに必須要素を記入する 後述のテンプレートを使い、目的・完了条件・受け入れ基準・依存・想定ファイルを明記する。 完了条件はテスト/コマンド/画面操作で検証可能な形にする。「実装する」は完了条件ではない。

7. 依存関係とクリティカルパスを整理する タスク間の依存を depends_on に記載し、依存がないタスクを並列候補として識別する。 クリティカルパス(最長の依存チェーン)上のタスクを優先着手する。

8. AIエージェント委譲を見据えたインターフェース固定 並列委譲するタスク間では、型・APIシグネチャ・ファイルパスをタスク着手前に固定する。 互いのファイルを触らない独立タスクに割り当てることで、コンフリクトなく並列実行できる。 [[orchestration]] の並列化パターンと組み合わせて使う。

成果物テンプレート

# タスク定義票
id: TASK-001
title: "歩くスケルトン: 認証フローの全層疎通"
type: implementation  # implementation / spike / design / test

目的: >
  全層(DB/API/UI)を貫通する最小の動くものを作り、以降のタスクを並列化できる状態にする。

作業内容:
  - ハードコードした資格情報でPOST /auth/loginを受け付けるエンドポイントを作成
  - フロントエンドのログインフォームが上記エンドポイントを呼び、/homeへ遷移できるようにする
  - DBマイグレーションでusersテーブルを作成(カラムはid/email/created_atのみ)

完了条件:
  - `npm test -- auth` がパスする
  - ローカルで http://localhost:3000/login にアクセスし、フォーム送信後に /home が表示される

受け入れ基準:
  - ハードコード資格情報以外での認証は不要(次タスクで実装)
  - エラーハンドリング・バリデーションは最低限で可

depends_on: []  # 最初のタスクのため依存なし

想定変更ファイル:
  - src/auth/auth.controller.ts (新規)
  - src/auth/auth.service.ts (新規)
  - db/migrations/001_create_users.sql (新規)
  - src/pages/login.tsx (変更)

見積もり: 1日

委譲先モデル案: Sonnet
委譲時の注意: src/CLAUDE.md の命名規約を必ず読ませること

# スパイクタスクの例
id: SPIKE-001
title: "決済API レート制限とリトライ戦略の調査"
type: spike

目的: >
  外部決済APIのレート制限仕様を把握し、TASK-012の実装方針を確定する。

作業内容:
  - 決済APIのドキュメントでレート制限の上限・ウィンドウを確認
  - サンドボックス環境で429レスポンスを意図的に発生させ、Retry-Afterヘッダの挙動を確認
  - exponential backoff の実装例を2〜3案比較

完了条件:
  - レート制限の数値(上限・ウィンドウ)をドキュメントに記録済み
  - リトライ戦略の推奨案を1つ選定し、選定理由を記載

タイムボックス: 半日(超えたら中断して現状報告)

depends_on: []

見積もり: 半日

委譲先モデル案: Opus

チェックリスト

• 最初のタスクが歩くスケルトン(全層疎通)になっている
• すべてのタスクに検証可能な完了条件がある
• タスクサイズが半日〜2日の範囲に収まっている
• 依存関係が depends_on に明記されている
• クリティカルパス上のタスクを特定し、優先順位に反映している
• 並列委譲するタスク間のインターフェース(型/API/ファイルパス)が事前に固定されている
• 不確実性の高い箇所にスパイクタスクを配置している
• 横切り分割(DB層だけ/API層だけ)になっていない
• 各タスクの 想定変更ファイル にファイルパスが具体的に記載されている

アンチパターン

「○○機能一式」タスク 完了条件が曖昧になり、委譲プロンプトも書けない。必ず縦切りで複数タスクに分割する。

完了条件のないタスク 「実装する」「対応する」は完了条件ではない。テストコマンドや操作手順で検証できる形にする。

横切り分割 「DB層実装」→「API層実装」→「UI層実装」の順に直列で進めると、最後まで何も動かない。 進捗確認・デモ・ブロッカーの早期発見ができなくなる。

依存を無視した並列着手 依存関係を整理せずに複数タスクを同時に進めると、同一ファイルへの競合書き込みが発生する。 並列化する前に 想定変更ファイル の重複を確認し、重複がある場合は直列化かworktree分離を行う。

スパイクなしの未知領域への突入 見積もりが立たない部分を推測で実装タスクに入れると、工数が3〜5倍になることがある。 不確実性が高い箇所は必ずスパイクを先行させる。

過細分割 1〜2時間で終わるタスクを大量に作ると、チケット管理コストの方が高くなる。半日未満のタスクは統合する。

モデル委譲ガイド

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

モデル	タスク定義・分解における役割
司令塔	分割方針の決定・依存関係の設計・並列化計画・クリティカルパス判断
Opus	複雑な機能の分解レビュー・スパイク結果のアーキテクチャへの統合判断
Sonnet	タスク票のドラフト作成・既存コードからの影響範囲調査・想定変更ファイルの列挙
Haiku	関連ファイルの洗い出し・依存モジュールの列挙・既存テストの一覧化

委譲時の注意: タスク票のドラフトをSonnetに委譲する場合、設計ドキュメントの絶対パスと 「縦切り・歩くスケルトン優先」の原則を必ずプロンプトに含める。

関連スキル

• [[orchestration]] — AIエージェント並列委譲の共通プロトコル
• [[requirements-definition]] — タスク分解の入力となる要件定義
• [[architecture-design]] — システム構成がタスクの依存関係に影響する
• [[detailed-design]] — 詳細設計完了後にタスク票を確定する
• [[implementation]] — タスク票を受け取り実装を進めるフェーズ
• [[estimation]] — タスクサイズの見積もりと工数管理
• [[project-management]] — タスク一覧をスプリントに割り当てる
• [[mvp-development]] — MVPスコープでの優先タスク選定