フェーズ 1: 要件理解

目的

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

開始条件

• 課題、利用者、期待する結果のいずれかを説明できる依頼がある
• 要件の判断者、または未決事項の確認先が分かる

入力成果物

• 依頼文、課題メモ、既存仕様
• 継続案件では docs/workflow/next-intake.md

実行手順

1. 課題、利用者、期待する結果を確認する
2. 対象範囲・対象外・制約・未決事項を分ける
3. 受入条件を観測可能な表現にする
4. 矛盾を解消し、判断者の合意を記録する

期待成果物

• docs/workflow/requirements.md
• 目的、対象範囲、対象外、制約、受入条件、未決事項と判断者

終了条件

• 要件書の受入条件が観測可能で、調査を止める未決事項がない
• 依頼者が要件書を確認し、調査へ進むことに合意している

失敗時の戻り先

• 目的を説明できない場合は依頼受付へ戻る
• 判断者が不在なら進行を止め、必要な判断を明記して確認を依頼する
• 技術的な不明点は仮定として記録し、調査フェーズへ渡す

Before / After

Before: 従来のやり方

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

After: ツール活用後

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

レベル別アプローチ

Beginner

Level 1 プレイブック

入力例

依頼: 各フェーズの開始可否と完了可否を判断できるようにしたい。
利用者: 実装担当者。制約: 既存URLを変えない。

コマンド / プロンプト

claude --permission-mode plan

実装せずに依頼を要件定義してください。目的、対象範囲、対象外、制約、
観測可能な受入条件、未決事項と判断者を整理し、
docs/workflow/requirements.md 用の Markdown を出力してください。

生成物例

# 要件
## 受入条件
- 詳細ページに開始条件と終了条件が表示される。
- 一覧、前後ナビ、マップが同じ順序になる。
## 未決事項
なし。

検証

test -s docs/workflow/requirements.md
rg -n '^## (目的|対象範囲|対象外|制約|受入条件|未決事項)$' docs/workflow/requirements.md

出口判定

• 受入条件を観測でき、ブロッキング未決事項がない
• 依頼者が調査へ進むことに合意した

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 に永続化

ベストプラクティス

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 で既存の解決策を調べてから要件を確定すると、無駄な実装を防げる。