Create Plan from Fuzzy Requirements

経営層やステークホルダーが提示する曖昧な要件を、実装可能な具体的要件と計画にブレークダウンする。

概要

このスキルは以下の2フェーズで動作する:

1. 要件整理フェーズ: 曖昧な入力から機能要件・非機能要件を抽出し、不明点を解消した上で、番号付きリストとして提示する
2. 実装計画フェーズ: 承認された要件に基づき、コンポーネント/モジュール単位の実装計画を提案する

各フェーズはPlanモードで提示し、ユーザーの承認を得てから次に進む。

フェーズ1: 要件整理

Step 1: 入力の分析

ユーザーから受け取った曖昧なテキストを分析する。以下の観点で情報を抽出する:

• 目的・ゴール: なぜこの変更が必要なのか、ビジネス上の目的は何か
• 対象ユーザー/アクター: 誰がこの機能を使うのか
• 期待される振る舞い: 何ができるようになるべきか
• 制約・前提条件: 技術的制約、期限、依存関係など
• 暗黙の要件: テキストには明記されていないが、文脈から推測される要件

曖昧な表現（「いい感じに」「使いやすく」「すぐに」など）を見つけたら、それぞれ具体化が必要なポイントとしてマークする。

Step 2: コードベースの調査

要件の内容に応じて、適切な深さでコードベースを調査する。

調査すべき内容:

• プロジェクトの技術スタック（言語、フレームワーク、主要ライブラリ）
• ディレクトリ構成とモジュール構造
• 要件に関連する既存機能・コンポーネント
• 既存のパターンや規約（命名規則、アーキテクチャパターンなど）
• 設定ファイル（package.json, go.mod, Cargo.toml, docker-compose.yml等）

調査にはExploreエージェントやGlob/Grepツールを使う。要件が既存機能の拡張であれば深く調査し、全く新しい機能であれば技術スタックの把握程度にとどめる。

Step 3: 不明点の解消

曖昧な入力テキストとコードベースの調査結果を照合し、要件を具体化するために不足している情報を特定する。

AskUserQuestionツールで確認すべき典型的な項目:

• 優先度やスコープの判断（MVP機能 vs 将来対応でよい機能）
• 曖昧な表現の具体的な意味（「高速」→ 具体的なレスポンスタイム目標は？）
• 既存機能との関係（既存機能の置き換え？拡張？並行運用？）
• エッジケースの扱い（エラー時の振る舞い、未対応ケースの扱い）
• 対象環境やユーザー規模

質問は1回で2〜4問にまとめ、何度も聞き返さないようにする。ただし、根本的に方向性が不明な場合は段階的に聞いても良い。自明なことや、コードベースから推測できることは聞かない。

Step 4: 要件のPlanモード提示

EnterPlanModeを使用して、整理した要件をユーザーに提示する。

要件リストの形式:

## 要件整理: [要件タイトル]

### 背景・目的
[元の要件テキストの要約と、ビジネス上の目的の明確化]

### 機能要件

#### 必須（MVP）
1. **[要件名]**: [具体的な説明]
   - 詳細: [振る舞いの詳細、入出力の仕様など]
   - 根拠: [元テキストのどの部分から導出されたか、またはコードベースの調査結果]

2. **[要件名]**: [具体的な説明]
   - 詳細: [振る舞いの詳細]
   - 根拠: [導出根拠]

#### 推奨（品質向上）
3. **[要件名]**: [具体的な説明]
   - 詳細: [振る舞いの詳細]
   - 根拠: [導出根拠]

### 非機能要件
4. **[要件名]**: [具体的な説明]
   - 詳細: [具体的な基準値や制約]

### スコープ外（今回は対応しない）
- [明示的にスコープから除外するもの]

### 前提条件
- [技術的前提やビジネス上の前提]

### 未解決事項
- [まだ決まっていないがいずれ決める必要があること]

要件記述のポイント:

• 各要件は独立して検証可能な粒度にする
• 「何を」だけでなく「なぜ」も併記する（元テキストやコードベースからの根拠）
• 元の曖昧な表現がどう具体化されたかを透明にする
• 推測で補った部分は明示する（「元テキストには明記されていないが、○○から推測」）
• 必須と推奨を分けることで、スコープの議論をしやすくする

ユーザーの承認を待つ。修正要望があれば反映し、再度提示する。

フェーズ2: 実装計画

要件が承認された後、実装計画をPlanモードで提案する。

Step 5: 実装方針の設計

承認された要件とコードベースの調査結果をもとに、実装方針を設計する。

検討事項:

• 既存のアーキテクチャパターンに沿った設計にする
• 変更の影響範囲を最小化する
• 既存コードの再利用可能な部分を特定する
• 必要な新規コンポーネントを特定する

Step 6: 実装計画のPlanモード提示

EnterPlanModeを使用して、実装計画を提示する。

実装計画の形式:

## 実装計画: [要件タイトル]

### 技術方針
[全体的なアプローチの説明。なぜこのアプローチを選んだかの理由]

### 変更対象コンポーネント

#### 1. [コンポーネント/モジュール名]
- **目的**: [このコンポーネントで何を実現するか]
- **変更種別**: 新規作成 / 既存変更
- **主な変更内容**:
  - [変更内容1]
  - [変更内容2]
- **対応する要件**: #1, #3

#### 2. [コンポーネント/モジュール名]
- **目的**: [このコンポーネントで何を実現するか]
- **変更種別**: 新規作成 / 既存変更
- **主な変更内容**:
  - [変更内容1]
- **対応する要件**: #2

### 実装順序
1. [最初に着手すべきコンポーネントとその理由]
2. [次に着手すべきコンポーネント]
3. ...

### 影響範囲
- [既存機能への影響]
- [必要なテスト]

### リスク・注意点
- [技術的なリスクや注意が必要な箇所]

ユーザーの承認を待つ。承認後、実装に着手する。

注意事項

• 元の要件テキストを勝手に拡大解釈しない。推測で補う場合は必ず明示する
• ユーザーが承認していない要件を実装しない
• 「とりあえず全部やる」ではなく、優先度をつけてスコープを明確にする
• コードベースの既存パターンを尊重する。新しいパターンの導入は慎重に