フェーズ 3: 計画

目的

要件と調査結果をもとに、実行可能な実装計画を策定する。タスクを適切な粒度に分解し、依存関係を明示し、リスクを特定して、実装フェーズでの迷いをなくす。

開始条件

• docs/workflow/requirements.md と docs/workflow/research.md が揃っている
• 未解決リスクの判断者と扱い方が明記されている

入力成果物

• docs/workflow/requirements.md
• docs/workflow/research.md
• プロジェクト規約と検証コマンド

実行手順

1. 受入条件を実装タスクへ対応付ける
2. 各タスクに変更対象、先行確認、実装内容、検証方法を書く
3. 依存順序を決め、並行作業の編集境界を分ける
4. リスク、代替案、ロールバック方針を確認する

期待成果物

• docs/workflow/implementation-plan.md
• 受入条件とタスクの対応、変更対象、依存順序、検証、ロールバック

終了条件

• 全受入条件に変更対象・実装タスク・検証方法が対応している
• 未決の設計判断がなく、実装担当が計画を実行可能と確認している

失敗時の戻り先

• 根拠不足なら調査へ戻る
• 範囲や受入条件の変更が必要なら要件理解へ戻り、再承認を得る
• 検証不能なタスクは実装せず、受入条件と検証方法を組み直す

Before / After

Before: 従来のやり方

• 頭の中でざっくりとした計画を立てて実装開始
• タスクの粒度が粗すぎて、途中で方針変更が頻発
• 依存関係を考慮せずに作業順序を決定
• 見積もりが楽観的で、スケジュールが遅延

After: ツール活用後

• AIエージェントがファイル構造をマッピングし、タスクを自動分解
• 各タスクが短く検証可能な粒度に細分化
• 依存関係が DAG 形式で可視化され、最適な実行順序が決定
• 計画書がドキュメントとして保存され、進捗がトラッキング可能

レベル別アプローチ

Beginner

Level 1 プレイブック

入力例

要件: docs/workflow/requirements.md
調査: docs/workflow/research.md

コマンド / プロンプト

claude --permission-mode plan

要件書と調査報告を読み、受入条件ごとにタスクを作ってください。
各タスクへ変更対象、先行確認、実装、検証コマンド、依存、戻り先を記載し、
docs/workflow/implementation-plan.md 用の Markdown を出力してください。

生成物例

# 実装計画
## タスク: frontmatter 順序へ統一
- 変更対象: workflow の一覧、詳細、マップ
- 依存: なし
- 検証: npx tsc --noEmit
- 戻り先: 根拠不足なら調査

検証

test -s docs/workflow/implementation-plan.md
rg -n '変更対象|依存|実装|検証|戻り先' docs/workflow/implementation-plan.md

出口判定

• 全受入条件にタスクと検証が対応している
• 依存順序が明確で、未決の設計判断がない

Claude Code の Plan Mode で基本的な実装計画を立てる。

# Plan Mode で読み取り専用で計画
claude --permission-mode plan

# 基本的な計画プロンプト
Claude Code > この機能の実装計画を立てて。以下のステップで:
              1. 変更が必要なファイルをリストアップ
              2. 各ファイルの変更内容を説明
              3. 実装順序を提案

# TodoWrite でタスク管理
Claude Code > 計画を TodoWrite でタスクリストにして

手順:

1. --permission-mode plan で読み取り専用モードに入る
2. 現状のコードベースを確認（Glob, Grep, Read）
3. 変更対象ファイルと内容をリストアップ
4. TodoWrite でタスクリストを作成
5. 計画内容を CLAUDE.md に記録

Intermediate

Superpowers の writing-plans と OMC の planner エージェントを活用。

# Superpowers: writing-plans（構造化された実装計画）
# brainstorming が完了した後に自動遷移
# ファイル構造マッピング → タスク分解 → 自己レビュー
# 計画書: docs/superpowers/plans/YYYY-MM-DD-<feature>.md

# OMC: planner エージェント（opus で実装青写真を作成）
> この仕様書をもとに実装計画を立てて
# planner エージェントが最適な実行順序を提案

# OMC: omc-plan スキル
/oh-my-claudecode:omc-plan
# 構造化された計画ワークフロー

# Superpowers: subagent-driven-development の計画
# タスクごとに新鲜なコンテキストでサブエージェントをディスパッチ

手順:

1. Superpowers brainstorming の出力（仕様書）を入力とする
2. writing-plans でタスクを短く検証可能な単位に分解
3. 各タスクに具体的なファイルパスと完全なコードを記載
4. 自己レビュー（プレースホルダー検出、整合性チェック）
5. 実行方法の選択（サブエージェント or インライン）

Advanced

OMC ralplan（コンセンサス型計画）と ECC multi-plan（マルチエージェント計画）を活用。

# OMC: ralplan（反復型コンセンサス計画）
ralplan この機能の実装計画を立てて
# planner が計画を策定
# critic が計画にダメ出し
# コンセンサスに達するまで反復

# ECC: multi-plan（マルチエージェントで計画分解）
/multi-plan "認証リファクタリングの実装計画"
# 複数エージェントが独立して計画を策定
# 結果を統合して最適な計画を選択

# OMC: team パイプライン（チーム編成での計画）
/team 3:executor "TypeScript の型エラーを全て修正"
# team-plan → team-prd → team-exec → team-verify → team-fix

手順:

1. OMC ralplan で critic レビュー付きの計画を策定
2. ECC multi-plan で複数視点から計画を比較
3. OMC team パイプラインでチーム編成の計画に移行
4. 計画を OMC project memory と CLAUDE.md に永続化
5. リスク評価とコンティンジェンシープランを含める

ベストプラクティス

1. タスクは短く検証可能な粒度に分解 -- 大きすぎるタスクは途中で方針変更のリスクが高い
2. プレースホルダーを禁止 -- TBD、TODO、あいまいな記述は計画の失敗。具体的なコードとファイルパスを記載
3. critic レビューを入れる -- OMC ralplan の critic エージェントは、計画の盲点を指摘する。自分では気づかないリスクを発見
4. 依存関係を DAG で明示 -- OMC team パイプラインは Wave 形式で依存関係を管理。並列可能なタスクと直列必須のタスクを区別
5. 実行方法を選択 -- Superpowers はサブエージェント駆動（推奨）とインライン実行の選択肢を提示

よくある罠

計画の粒度が粗すぎる

「ユーザー管理画面を実装する」は単一のタスクとしては大きすぎる。独立して検証できる粒度へ分け、必要なら ECC の /multi-plan で分解する。

プレースホルダーを放置

「後で決める」「TBD」が残ったまま実装に入ると、実装中に迷走する。Superpowers の自己レビューはプレースホルダー検出を含む。

依存関係の循環

タスクAがタスクBに依存し、タスクBがタスクAに依存するような循環参照を見落とす。OMC team パイプラインの DAG 形式はこれを防止する。

楽観的な見積もり

大きなタスクを一括で見積もると不確実性が隠れる。独立して検証できる単位へ分け、依存とリスクを個別に見積もる。

計画を見直さない

一度立てた計画に固執し、実装中に判明した新情報を計画に反映しない。OMC ralplan の反復アプローチは、計画の継続的な見直しをサポートする。