Task Refinement

2. タスク粒度の適正化

大きすぎるタスクを分割し、小さすぎるタスクを統合する。

適正粒度の基準:

• S (Small): 1-2時間、単一ファイルの変更、明確な完了条件
• M (Medium): 2-4時間、2-3ファイルの変更、テスト含む
• L (Large): 4-8時間、複数ファイル・複数コンポーネント → 分割を検討
• XL: 8時間以上 → 必ず分割

分割の判断基準:

1. 複数の独立した AC を含むタスクは分割
2. フロントエンド + バックエンドの変更を含むタスクは分割
3. テストを別タスクにする必要は通常ない（実装タスクに含める）
4. DB マイグレーション + Edge Function + フロントエンドは3タスクに分割

3. 依存関係の検証

タスク間の依存関係が正しく設定されているか検証する。

検証項目:

• 循環依存がないか
• 暗黙の依存（shared/ の型変更など）が明示されているか
• クリティカルパス上のタスクが特定されているか
• 並列実行可能なタスクが正しく識別されているか

出力フォーマット:

## 依存関係グラフ

T001 ──→ T003 ──→ T005
  │               ↗
  └──→ T004 ──┘
T002 ──→ T006 (並列可)

### クリティカルパス: T001 → T003 → T005
### 並列実行可能: {T003, T004} / {T005, T006}
### 問題:
- T007 が T003 に依存しているが明示されていない（shared/types/ を変更するため）

4. 受け入れ条件の明確化

曖昧な完了条件を具体的・テスト可能な形に書き換える。

曖昧な例:

❌ "チャットが動作する"
❌ "パフォーマンスが良い"
❌ "エラーハンドリングがある"

明確な例:

✅ "ユーザーがメッセージを送信すると、1秒以内にAIの応答ストリーミングが開始される"
✅ "100件のチャット履歴をスクロールしても60fps以上を維持する"
✅ "ネットワーク切断時にオフラインバナーが表示され、再接続後に未送信メッセージが自動送信される"

テスト可能性チェック:

• 数値で計測できるか（時間、回数、パーセント）
• 特定の操作で再現できるか（ステップ1→2→3→期待結果）
• 境界値が定義されているか（最大文字数、最大件数）

5. Agent 担当割り当ての最適化

各タスクの Agent 割り当てが適切か検証する。

検証項目:

• Agent の担当範囲（features/ 内のディレクトリ）とタスクが一致するか
• shared/ への変更を含むタスクが適切にフラグされているか
• Agent 間のタスク量バランスが適切か
• ブロッカータスクが特定の Agent に集中していないか

精査ワークフロー

1. 仕様書を全て読み込む（specs/）
2. 現在のタスク一覧を取得
3. 整合性チェック実行
4. 粒度チェック実行
5. 依存関係チェック実行
6. AC 明確性チェック実行
7. Agent 割り当てチェック実行
8. レポート出力
9. 修正提案（自動修正 or ユーザー確認）

参照

• references/refinement-checklist.md — 精査チェックリスト
• specs/ — 仕様書ディレクトリ