フェーズ3: 計画

目的

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

Before / After

Before: 従来のやり方

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

After: ツール活用後

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

レベル別アプローチ

Beginner

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 でタスクを2-5分単位に分解
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. リスク評価とコンティンジェンシープランを含める

利用可能なコマンド・スキル

Claude Code 単体 {data-tool="claude-code"}

コマンド / ツール	説明
--permission-mode plan	読み取り専用の計画モード
TodoWrite	タスクリストの作成・管理
EnterPlanMode	対話中に Plan Mode に移行
/model	計画策定用にモデルを変更
Agent	計画専用のサブエージェントを起動

Superpowers {data-tool="superpowers"}

スキル	説明
writing-plans	タスク分解（2-5分/タスク）、ファイル構造マッピング
subagent-driven-development	タスクごとのサブエージェント実行計画
dispatching-parallel-agents	並列実行可能タスクの特定とディスパッチ
using-git-worktrees	計画実行用の独立環境作成

OMC {data-tool="omc"}

スキル / エージェント	説明
planner エージェント	opus で実装青写真を作成
architect エージェント	システム設計・境界・トレードオフ
critic エージェント	計画にダメ出しする悪魔の代弁者
/ralplan	反復型コンセンサス計画
/omc-plan	構造化された計画ワークフロー
/team	チームパイプライン: plan → prd → exec → verify → fix
/autopilot	計画から実装まで一気通貫で自律実行

ECC {data-tool="ecc"}

スキル / コマンド	説明
/plan	実装計画の生成
/multi-plan	マルチエージェントでの計画分解
/orchestrate	マルチエージェントの協調
autonomous-loops スキル	自律ループパターン（逐次・DAG・PR）

ベストプラクティス

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

よくある罠

計画の粒度が粗すぎる

「ユーザー管理画面を実装する」は1つのタスクとしては大きすぎる。Superpowers は「2-5分で完了する」粒度を基準とする。ECC の /multi-plan で自動分解も可能。

プレースホルダーを放置

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

依存関係の循環

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

楽観的な見積もり

「1時間で終わる」が実際には半日かかる。各タスクの想定時間を2-5分に抑えることで、見積もりの精度が上がる。

計画を見直さない

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