plan-first-development

計画

概要

実装を始める前に、時間の80％以上を計画に費やす、計画優先の開発手法です。計画のトークンは実装のトークンより安価であり、モデルは広大なコードベースよりも、コンテキストウィンドウに収まる詳細な計画について、より適切に推論できます。

使用する場面： 新しいプロジェクトの開始、大規模な機能の追加、複雑な作業のフェーズ分割、コンテキストがクリアされた後の作業再開、複数セッションにわたる実装の管理、同じコードベースで作業する複数のエージェントの連携。

使用しない場面： 迅速なバグ修正、1ファイルだけの変更、要件が不明な探索的プロトタイピング、変更内容が明らかな簡単なリファクタリング。

クイックリファレンス

計画フェーズ	説明
1. 初期計画	目標、意図、ワークフロー、技術スタックを記述する
2. 反復的な改善	提案が出尽くすまで4～5回レビューする
3. 複数モデルの統合	競合する計画を作成し、最善の要素を組み合わせる
4. タスクへの変換	依存関係を整理した独立して実行できるタスク
5. タスクの仕上げ	6回以上、モデル間でレビューする

フェーズの種類	範囲	最大ファイル数	所要時間
インフラ	足場の構築、ビルド設定、デプロイ	3-5	1-3 hours
データベース	マイグレーション、スキーマ、シードデータ	2-4	2-4 hours
API	ルート、ミドルウェア、バリデーション	3-6	3-6 hours
UI	コンポーネント、フォーム、状態、スタイル	4-8	4-8 hours
統合	サードパーティサービス、Webhook	2-4	3-5 hours
テスト	E2Eテスト、統合テスト	さまざま	3-6 hours

パターン	目的	主なポイント
計画と構築の使い分け	複雑さの指標に基づく判断ツリー	計画の深さをタスクの複雑さに合わせる
リスク評価	発生確率 × 影響度のマトリックス	高リスク項目を優先する

セッションのライフサイクル	アクション
開始	SESSION.md を読み、「Next Action」を確認して続行する
作業	実装、検証、デバッグを繰り返す
チェックポイント	定められた形式で Git にコミットし、SESSION.md のハッシュを更新する
終了	SESSION.md を更新し、Git にチェックポイントを作成して、具体的な「Next Action」を設定する
再開	SESSION.md と計画ドキュメントを読み、「Next Action」から続行する

ドキュメント	生成するタイミング
実装フェーズ	常に生成する――すべてのプロジェクトの中核となる計画ドキュメント
セッションの追跡	常に生成する――進捗を確認するためのナビゲーションハブ
データベーススキーマ	テーブルが3つ以上ある場合
API エンドポイント	エンドポイントが5つ以上ある場合
アーキテクチャ概要	複数のサービスがある場合、またはシステム境界が複雑な場合
重要なワークフロー	複雑なセットアップ手順や、順序に依存するワークフロー

良い計画	優れた計画
構築するものを説明する	なぜそれを構築するのかを説明する
機能を列挙する	ユーザーのワークフローと操作を詳しく説明する
技術スタックに言及する	トレードオフを踏まえて技術選定の理由を説明する
タスクがある	依存関係と根拠を示したタスクがある
約500行	改善後は約3,500行以上

よくある間違い

間違い	正しいパターン
計画が完了する前に実装を始める	時間の80％以上を計画に費やし、コードを書く前にすべての改善ラウンドを終える
「API 作業を続ける」のように曖昧な次のアクションを書く	具体的に記述する：「src/routes/tasks.ts:47 で PATCH /api/tasks/:id を実装する」
セッション管理ドキュメントが200行を超える	完了したフェーズは要約にまとめ、詳細は計画ドキュメントを参照する
10個以上のファイルを含むフェーズを作成する	5～8個のファイルからなるサブフェーズに自動分割し、1回の2～4時間のセッションに収まるようにする
1回だけの計画レビュー	提案が出尽くすまで4～5回繰り返し、新たな視点を得るために複数モデルを組み合わせる
セッションドキュメントにコードをコピーする	コードを貼り付ける代わりに、ファイルパスと行番号を参照する
セッションドキュメントに計画ドキュメントの内容を重複して記載する	アンカーで該当セクションにリンクする。セッションドキュメントはナビゲーションハブとして使う
フェーズに検証基準がない	すべてのフェーズに、具体的でテスト可能な終了基準（ステータスコード、ユーザーフロー、制約）を設ける
計画を作成する前にスケルトン優先でコーディングする	段階的なスケルトン優先のコーディングより、徹底した計画を1つ作成するほうがよい
不慣れな技術を試作せずに計画する	不慣れなフレームワークでは、まずスパイクを実施してから計画を作成する
単純なタスクを過剰に計画する	複雑さに応じて計画の深さを調整し、些細な作業では省略する
前提条件を早い段階で検証しない	最もリスクの高い前提条件について、まずスパイクを実施する

委任

• アーキテクチャの決定に向けて既存のコードベースを調査する：計画を立てる前に、Explore エージェントを使ってファイル構成、パターン、依存関係を調査します
• 検証を伴うフェーズの実装を実行する：Task エージェントを使って個々のフェーズを実装し、検証基準を実行して、チェックポイントのコミットを作成します
• アーキテクチャを設計し、フェーズに分解する：Plan エージェントを使って、依存関係の順序とゲート基準を含む実装フェーズを作成します

参考資料

• 計画プロセスと反復的な改善
• セッション管理とコンテキストの追跡
• フェーズベースの実装計画
• レビューワークフローと複数モデルの組み合わせ
• 意思決定の追跡と条件付きドキュメント
• 計画ドキュメントのテンプレート