フェーズ1: 要件理解

目的

プロジェクトの「何を」作るかを明確にし、実装前に要件の曖昧さを排除する。AIエージェントとの対話を通じて、暗黙の前提を顕在化し、後戻りコストを最小化する。

Before / After

Before: 従来のやり方

• ユーザーが概要だけ伝えて即座に実装を開始
• 実装途中で要件の矛盾に気づき、大幅な手戻りが発生
• 「そんなつもりじゃなかった」という認識のズレが後発見
• 要件の境界条件や例外ケースが未定義のまま進行

After: ツール活用後

• AIエージェントがソクラテス式質問で要件を深掘り
• 構造化された仕様書が自動生成され、合意形成が明示的
• 境界条件・例外ケース・非機能要件が実装前に洗い出される
• 要件の重み付け（加重ディメンション）で優先順位が明確

レベル別アプローチ

Beginner

Claude Code 単体で要件を整理する基本的なアプローチ。

# 基本的な要件確認プロンプト
Claude Code > 以下のプロジェクトを開発したいです。実装を始める前に、
              要件について確認させてください: [プロジェクト概要]

# /init でプロジェクトコンテキストを設定
/init

# Plan Mode で検討
> /model  # 必要に応じてモデル選択
> この機能について、実装前に確認すべきことをリストアップして

手順:

1. /init で CLAUDE.md を生成し、プロジェクトコンテキストを確立
2. Plan Mode (--permission-mode plan) で実装前に検討
3. 要件のチェックリストを TodoWrite で管理
4. CLAUDE.md の #memory ショートカット（# プレフィックス）で要件を記録

Intermediate

Superpowers の brainstorming スキルと OMC の deep-interview を活用。

# Superpowers: brainstorming（設計前に必須）
> 新しいタスク管理アプリを作りたい
# 自動的に brainstorming スキルが起動
# 1質問ずつ、選択肢付きで要件を深掘り
# 設計書が docs/superpowers/specs/ に自動保存

# OMC: deep-interview（加重ディメンションで要件を定量化）
/oh-my-claudecode:deep-interview
> タスク管理アプリを開発したい
# 曖昧さゲート: 要件が十分明確になるまで質問が継続
# 重み付きディメンションで要件の優先度を数値化

手順:

1. Superpowers brainstorming で 2-3 のアプローチを提案
2. ユーザーが承認した設計を spec ドキュメントとして保存
3. OMC deep-interview で暗黙の前提を顕在化
4. 仕様書のセルフレビュー（プレースホルダー検出、整合性チェック）

Advanced

OMC ralplan（コンセンサス型計画）と ECC の multi-plan で複数視点から要件を検証。

# OMC: ralplan（反復型コンセンサス計画）
ralplan この機能について要件を整理して
# critic エージェントが設計にダメ出し
# コンセンサスに達するまで反復

# ECC: multi-plan（マルチエージェントで要件分解）
/multi-plan "タスク管理アプリの要件定義"
# 複数エージェントが独立して要件を分析
# 結果を統合して包括的な要件書を生成

# ECC: requirement-analyzer（要件分析専用コマンド）
/requirement-analyzer

手順:

1. OMC ralplan で critic エージェントによる設計レビュー
2. ECC multi-plan で複数視点からの要件分解
3. ECC requirement-analyzer で構造化された要件書を生成
4. OMC analyst エージェント（opus）で隠れた制約を特定
5. 最終要件書を CLAUDE.md と project memory に永続化

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

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

コマンド / 機能	説明
/init	CLAUDE.md 生成でプロジェクトコンテキスト確立
# プレフィックス	クイックメモリに要件を記録
--permission-mode plan	読み取り専用で要件確認
/model	分析用モデルの選択
TodoWrite	要件チェックリストの管理

Superpowers {data-tool="superpowers"}

スキル	説明
brainstorming	設計前の必須プロセス。1質問ずつ深掘り、設計書を自動保存
writing-plans	承認済み設計書から実装計画を生成
using-superpowers	セッション開始時にスキル選択フローchart を提供

OMC {data-tool="omc"}

スキル / エージェント	説明
/deep-interview	ソクラテス式の曖昧さゲート付き要件確認
ralplan	反復型コンセンサス計画。critic が設計にダメ出し
analyst エージェント	opus で隠れた制約とリスクを特定
planner エージェント	実装計画の順序付け
/omc-plan	構造化された計画ワークフロー
/learner	セッションから再利用可能なパターンを抽出

ECC {data-tool="ecc"}

スキル / コマンド	説明
/plan	実装計画の生成
/multi-plan	マルチエージェントでの要件分解
/requirement-analyzer	要件分析専用コマンド
/search-first	実装前のリサーチファーストワークフロー
/learn	セッション中にパターンを抽出

ベストプラクティス

1. 実装前に必ず要件を確認する -- コードを書き始める前に、何を作るかの合意を形成する。Superpowers の brainstorming は HARD-GATE で実装をブロックする
2. 1質問ずつ、選択肢付きで -- 複数の質問を同時に行うと、ユーザーが見落とす。Superpowers は「one question at a time, multiple choice preferred」を原則とする
3. 仕様書はプレースホルダー禁止 -- TBD、TODO、あいまいな記述は仕様書の失敗。具体的な内容で埋めるか、未決定事項として明示する
4. メモリに要件を永続化 -- CLAUDE.md や project memory に要件を記録し、セッションをまたいで参照可能にする
5. 暗黙の前提を顕在化 -- 「当たり前」だと思っていることは書き出す。OMC deep-interview の加重ディメンションはこれをシステム化している
6. スコープ评估を行う -- マルチサブシステムにまたがる場合は、サブプロジェクトに分解してから要件定義する

よくある罠

「これは簡単だから設計不要」

Superpowers は「This Is Too Simple To Need A Design」をアンチパターンとして明示的に防止している。小さな変更でも、境界条件や影響範囲の確認は必須。

AIが勝手に実装を開始する

Plan Mode（--permission-mode plan）を使用せずに要件確認を行うと、AIが確認と同時に実装を始めてしまう。Superpowers の brainstorming は HARD-GATE でこれを防止する。

要件の非機能要件が漏れる

パフォーマンス、セキュリティ、スケーラビリティの要件を忘れがち。OMC analyst エージェントは隠れた制約を自動的に特定する。

要件がセッション間で失われる

セッションを終了すると要件の文脈が失われる。CLAUDE.md や OMC project memory に永続化しないと、次回のセッションでゼロからやり直しになる。

「ユーザーが言ったから正しい」バイアス

ユーザーの要件をそのまま鵜呑みにせず、技術的な懸念があれば指摘する。ECC の /search-first で既存の解決策を調べてから要件を確定すると、無駄な実装を防げる。