planning-and-task-breakdown

計画とタスクの分割

概要

作業を、受け入れ基準が明確な、小さく検証可能なタスクに分解します。適切なタスク分割こそが、作業を確実に完了するエージェントと、複雑に入り組んだ成果物を生み出すエージェントの違いです。各タスクは、1 回の集中したセッションで実装、テスト、検証できる規模にします。

使用するタイミング

• 仕様書があり、実装可能な単位に分割する必要があるとき
• タスクが大きすぎる、または曖昧すぎて着手できないとき
• 複数のエージェントやセッションで作業を並行化する必要があるとき
• 作業範囲を人に伝える必要があるとき
• 実装順序が明確でないとき

使用しない場合： 範囲が明確な単一ファイルの変更や、仕様書にすでに明確に定義されたタスクが含まれている場合。

計画のプロセス

ステップ 1：計画モードに入る

コードを書く前に、読み取り専用モードで作業します。

• 仕様書と関連するコードベースの箇所を読む
• 既存のパターンや規約を特定する
• コンポーネント間の依存関係を整理する
• リスクと不明点を記録する

計画中にコードを書かないでください。 成果物は、tasks/plan.md に保存する計画書と、タスクリストの保存先（「出力ファイル」を参照。デフォルトは tasks/todo.md）に記録するタスクリストであり、実装ではありません。

ステップ 2：依存関係グラフを特定する

何が何に依存しているかを整理します。

Database schema
    │
    ├── API models/types
    │       │
    │       ├── API endpoints
    │       │       │
    │       │       └── Frontend API client
    │       │               │
    │       │               └── UI components
    │       │
    │       └── Validation logic
    │
    └── Seed data / migrations

実装の順序は依存関係グラフを下から上へたどります。まず基盤を構築します。

ステップ 3：垂直に分割する

データベース全体、次に API 全体、最後に UI 全体を構築するのではなく、一度に 1 つの完全な機能パスを構築します。

悪い例（水平分割）：

Task 1: Build entire database schema
Task 2: Build all API endpoints
Task 3: Build all UI components
Task 4: Connect everything

良い例（垂直分割）：

Task 1: User can create an account (schema + API + UI for registration)
Task 2: User can log in (auth schema + API + UI for login)
Task 3: User can create a task (task schema + API + UI for creation)
Task 4: User can view task list (query + API + UI for list view)

垂直分割の各単位で、動作し、テスト可能な機能を提供します。

ステップ 4：タスクを作成する

タスクは、Markdown のタスクリストに記載する場合でも、外部トラッカーの項目として登録する場合でも（「出力ファイル」を参照）、次の構成にします。

## Task [N]: [Short descriptive title]

**Description:** One paragraph explaining what this task accomplishes.

**Acceptance criteria:**
- [ ] [Specific, testable condition]
- [ ] [Specific, testable condition]

**Verification:**
- [ ] Tests pass: [the repository's focused-test command]
- [ ] Build succeeds: [the repository's build command]
- [ ] Manual check: [description of what to verify]

**Dependencies:** [Task numbers this depends on, or "None"]

**Files likely touched:**
- `src/path/to/file.ts`
- `tests/path/to/test.ts`

**Estimated scope:** [Small: 1-2 files | Medium: 3-5 files | Large: 5+ files]

ステップ 5：順序を決め、チェックポイントを設ける

タスクは次のように並べます。

1. 依存関係を満たす（まず基盤を構築する）
2. 各タスクの完了後、システムが動作する状態を保つ
3. 2～3 件のタスクごとに検証チェックポイントを設ける
4. リスクの高いタスクを早めに行う（迅速に問題を見つける）

タスクリストの保存先に、明示的なチェックポイントを追加します。

## Checkpoint: After Tasks 1-3
- [ ] All tests pass
- [ ] Application builds without errors
- [ ] Core user flow works end-to-end
- [ ] Review with human before proceeding

タスクの規模に関するガイドライン

規模	ファイル数	範囲	例
XS	1	単一関数または設定の変更	検証ルールの追加
S	1-2	1 つのコンポーネントまたはエンドポイント	新しい API エンドポイントの追加
M	3-5	1 つの機能スライス	ユーザー登録フロー
L	5-8	複数コンポーネントにまたがる機能	フィルタリングとページネーションに対応した検索
XL	8+	大きすぎます。さらに分割してください	—

タスクが L 以上の場合は、より小さなタスクに分割します。エージェントは S と M のタスクで最も力を発揮します。

タスクをさらに分割する場合：

• 集中したセッションが 1 回では終わらない（エージェントの作業でおよそ 2 時間以上かかる）
• 受け入れ基準を箇条書き 3 項目以内で説明できない
• 独立したサブシステムが 2 つ以上関わる（例：認証と請求処理）
• タスクのタイトルに「および」と書きたくなる（2 つのタスクに分ける必要がある兆候）

出力ファイル

• 計画ドキュメント： 実装計画を tasks/plan.md に保存します。これは常に Markdown ファイルです。設計上の決定、リスク、未解決の質問は、個別のトラッカーの課題にうまく当てはまりません。
• タスクリスト： 各タスクをタスクリストの保存先（以下で定義）に記録します。

tasks/ ディレクトリが存在しない場合は作成してください。

未完了の計画を上書きしないでください。 tasks/plan.md または tasks/todo.md を書き込む前に、ファイルがすでに存在し、未チェックのタスクが残っているか確認してください。

• 同じ作業を再計画する場合（ユーザーがこの計画の修正または拡張を依頼した場合）→ 既存のファイルをそのまま更新します。
• 別の作業の場合 → 中断して確認してください。 未チェックのタスクは、別のセッションで作業中の可能性があります。既存のファイルを自分の判断で削除、上書き、名前変更しないでください。競合を提示し、ユーザーの判断を仰いでください（古い計画を先に完了する、明示的に破棄する、新しい計画の保存先を指示する）。

同じルールは外部タスクリストの保存先にも適用されます。新しいタスク用の場所を空けるために、別の計画の未完了トラッカー項目を一括でクローズまたは削除してはいけません。

タスクリストの保存先

タスクリストの保存先には、タスクとチェックポイントを記録します。保存先はここで一度だけ定義します。このスキル内の他の箇所での言及は、すべてこの定義に従います。

• デフォルト： tasks/todo.md にチェックリスト形式の Markdown ファイルを作成します。/build コマンドやその他の後続ツールが想定する慣例です。プロジェクトから別の指示がない限り、これを使用してください。
• 外部トラッカー： プロジェクトのエージェントルール（CLAUDE.md、AGENTS.md など）またはユーザーが、課題トラッカー（GitHub Issues、Jira、Linear、bd/beads など）を指定している場合は、tasks/todo.md に書き込む代わりに、タスクごとにトラッカー項目を1つ作成します。ステップ4の構成をトラッカーのフィールドに対応させます。受け入れ基準と検証手順は項目の本文に記載し、依存関係はトラッカーのリンク機能（bd dep add、「blocked by」など）で設定します。ステップ5のチェックポイントもトラッカー項目として記録します。トラッカーに自然な形で対応する項目がない場合は、計画ドキュメントのチェックリストとして記載します。

外部トラッカーを使用する場合は、後続のステップや今後のセッションで参照できるよう、tasks/plan.md に記載してください（例：「タスクは Linear プロジェクト FOO で管理」）。また、計画ドキュメントの「タスクリスト」セクションには、チェックリストを重複して記載せず、トラッカー項目の ID またはリンクを順序付きで一覧にします。

計画ドキュメントのテンプレート

# Implementation Plan: [Feature/Project Name]

## Overview
[One paragraph summary of what we're building]

## Architecture Decisions
- [Key decision 1 and rationale]
- [Key decision 2 and rationale]

## Task List

### Phase 1: Foundation
- [ ] Task 1: ...
- [ ] Task 2: ...

### Checkpoint: Foundation
- [ ] Tests pass, builds clean

### Phase 2: Core Features
- [ ] Task 3: ...
- [ ] Task 4: ...

### Checkpoint: Core Features
- [ ] End-to-end flow works

### Phase 3: Polish
- [ ] Task 5: ...
- [ ] Task 6: ...

### Checkpoint: Complete
- [ ] All acceptance criteria met
- [ ] Ready for review

## Risks and Mitigations
| Risk | Impact | Mitigation |
|------|--------|------------|
| [Risk] | [High/Med/Low] | [Strategy] |

## Open Questions
- [Question needing human input]

タスクを外部トラッカーで管理する場合は、上記の「タスクリスト」セクションにチェックリストを重複して記載せず、トラッカー項目の ID またはリンクを順序付きで一覧にします。

並列化の機会

複数のエージェントまたはセッションを利用できる場合：

• 並列化しても安全： 独立した機能の実装、すでに実装済みの機能のテスト、ドキュメント
• 順次実行が必須： データベースのマイグレーション、共有状態の変更、依存関係の連鎖
• 調整が必要： 同じ API コントラクトを共有する機能（先にコントラクトを定義してから、並列化してください）

よくある自己正当化

自己正当化	実際のところ
「進めながら考えればいい」	そうすると、収拾のつかない混乱と手戻りにつながります。10分の計画で何時間も節約できます。
「タスクは明らかだ」	それでも書き出してください。タスクを明確にすると、隠れた依存関係や見落としたエッジケースが明らかになります。
「計画は余計な手間だ」	計画を立てることもタスクの一部です。計画なしの実装は、ただ入力しているだけです。
「すべて頭の中で覚えておける」	コンテキストウィンドウには限りがあります。計画を文書に残せば、セッションの切り替えやコンテキストの圧縮後も引き継げます。
「古い tasks/plan.md は古くなっているから、そのまま置き換えよう」	未チェックのタスクは、別のセッションで作業中の可能性があります。上書きすると、他に記録されていない作業状態が失われます。中断して確認してください。

要注意の兆候

• タスクリストを文書化せずに実装を開始する
• 別の作業に関する未完了タスクが残っているのに、確認せずに tasks/plan.md または tasks/todo.md を上書きする
• プロジェクトで外部トラッカーを指定しているのに tasks/todo.md を作成する（または、両方にタスクを分散させる）
• 受け入れ基準のない「機能を実装する」といったタスク
• 計画に検証手順がない
• すべてのタスクが XL サイズである
• タスク間にチェックポイントがない
• 依存関係の順序が考慮されていない

検証

実装を開始する前に、次の点を確認してください。

• すべてのタスクに受け入れ基準がある
• すべてのタスクに検証手順がある
• タスクの依存関係が特定され、適切な順序に並んでいる
• タスクがタスクリストの保存先（既定では tasks/todo.md）に記録されている
• ユーザーの明示的な確認なしに、既存の未完了の計画が上書きされていない
• 5 個を超えるファイルに触れるタスクがない
• 主要なフェーズ間にチェックポイントがある
• 人間が計画を確認し、承認している

関連項目

受け入れ基準はタスクごとに定め、「正しいものを作れたか？」に答えるものです。プロジェクト全体の Definition of Done に加えて定められ、すべてのタスクが完了とみなされる前に満たすべき基準です。../../references/definition-of-done.md を参照してください。