plan-plus

Plan Plus — ブレインストーミングを強化した PDCA 計画

ブレインストーミングによる意図の発見と bkit PDCA の体系的な計画を組み合わせ、 協働的な対話を通じて、より質の高い Plan ドキュメントを作成します。

概要

Plan Plus は、ドキュメントを生成する前に 4 つのブレインストーミングフェーズを追加し、標準の /pdca plan を強化します。これにより、実装を始める前に、ユーザーの意図を十分に把握し、代替案を検討し、不要な機能を取り除けます。

/pdca plan の代わりに Plan Plus を使用する場合：

• 機能の要件が曖昧、または複雑な場合
• 複数の実装方法が考えられる場合
• 最初から YAGNI に準拠していることを確認したい場合
• 機能に重要なアーキテクチャ上の判断が伴う場合

厳格なゲート

このプロセス全体が完了し、ユーザーが Plan ドキュメントを承認するまで、コードの作成、プロジェクトのひな形の作成、実装スキルの呼び出しを行わないでください。 このルールは、複雑さの認識にかかわらず、すべての機能に適用されます。 「シンプルな」機能でも、このプロセスを経る必要があります。設計は短くてもかまいませんが、必ず提示して承認を得てください。

プロセスの流れ

Phase 0: Context Exploration (automatic)
    ↓
Phase 1: Intent Discovery (1 question at a time)
    ↓
Phase 2: Alternatives Exploration (2-3 approaches)
    ↓
Phase 3: YAGNI Review (multiSelect verification)
    ↓
Phase 4: Incremental Design Validation (section-by-section)
    ↓
Phase 5: Plan Document Generation (plan-plus.template.md)
    ↓
Phase 6: Next Steps → /pdca design {feature}

フェーズの詳細

フェーズ 0：プロジェクトコンテキストの確認（自動）

質問をする前に、現在のプロジェクトの状態を確認します。

1. CLAUDE.md、package.json、pom.xml などを読み、プロジェクト情報を確認します
2. 直近の git コミット 5 件を確認します（現在の作業の方向性を把握します）
3. 既存の docs/01-plan/ ドキュメントを確認します（重複を防ぎます）
4. .bkit-memory.json を確認します（進行中の PDCA ステータスを確認します）

確認結果を簡潔に共有します：「現在のプロジェクトの状態を確認しました：...」

フェーズ 1：意図の発見（ブレインストーミング形式）

原則：一度に質問は 1 つだけにし、選択式を優先します

AskUserQuestion ツールを使用し、次の項目を順番に確認します。

Q1. 主な目的

「この機能が解決する主な問題は何ですか？」

• プロジェクトのコンテキストから推測した選択肢を 3～4 個提示します
• 必ず自由入力の選択肢を含めます

Q2. 対象ユーザー

「主に誰がこの機能を使用しますか？」

• 管理者／エンドユーザー／開発者／外部システム

Q3. 成功基準

「この機能が成功したと判断する基準は何ですか？」

• 具体的で測定可能な基準を導き出します

Q4. 制約（必要な場合のみ）

既存システムとの競合、パフォーマンス要件、技術的制約など。

重要：質問は最小限にします。明確な機能であれば、Q1～Q2 だけで十分です。 曖昧な機能の場合のみ、Q3～Q4 に進みます。

フェーズ 2：代替案の検討（ブレインストーミングの中核）

トレードオフを添えて、常に 2～3 個のアプローチを提案します。

形式：

### Approach A: {name} — Recommended
- Pros: ...
- Cons: ...
- Best for: ...

### Approach B: {name}
- Pros: ...
- Cons: ...
- Best for: ...

### Approach C: {name} (optional)
- Pros: ...
- Cons: ...

推奨するアプローチを、明確な理由とともに最初に提示します。 AskUserQuestion を使用して、ユーザーに選択してもらいます。

フェーズ 3：YAGNI の見直し（ブレインストーミングの中核）

選択されたアプローチについて、YAGNI（You Ain't Gonna Need It）の見直しを行います。

multiSelect: true を指定して AskUserQuestion を使用します。 「最初のバージョンに不可欠なものだけを選択してください：」

すべての機能を一覧にし、選択されなかった項目は対象外に移します。

原則：3 行で実現できるものを抽象化しないでください。 仮定上の将来要件に備えた設計はしないでください。

フェーズ 4：段階的な設計の検証（ブレインストーミング形式）

設計をセクションごとに提示し、各セクションの後に承認を得ます。

1. アーキテクチャの概要 → 「この方向性でよさそうですか？」
2. 主要なコンポーネント／モジュール → 「この構成でよさそうですか？」
3. データフロー → 「この流れでよさそうですか？」

いずれかのセクションについてユーザーが「いいえ」と答えた場合は、そのセクションのみを修正して再提示します。

フェーズ 5：計画ドキュメントの生成

フェーズ 0～4 の結果を使用し、plan-plus.template.md に基づいて計画ドキュメントを生成します。

追加セクション（標準の plan.template.md にはありません）：

• ユーザー意図の把握 — フェーズ 1 で明らかになった主要な課題、対象ユーザー、成功基準
• 検討した代替案 — フェーズ 2 で比較したアプローチ
• YAGNI レビュー — フェーズ 3 で追加・延期・削除した項目
• ブレインストーミングログ — フェーズ 1～4 の主要な決定事項
• エグゼクティブサマリー -- フェーズ 1～4 の結果から、4 つの視点（課題／解決策／機能・UX への影響／中核的価値）の要約を自動生成します。番号付きセクションの前に、ドキュメントの冒頭に配置してください。
• エグゼクティブサマリーの回答 -- 必須：計画ドキュメントの生成後、回答にもエグゼクティブサマリーの表を出力し、ファイルを開かなくてもユーザーがすぐに概要を確認できるようにしてください。

出力先：docs/01-plan/features/{feature}.plan.md

ドキュメントの生成後、PDCA のステータスを更新します：

• タスクを作成：[Plan] {feature}
• .bkit-memory.json を更新：phase = "plan"

フェーズ 6：次のステップ

計画ドキュメントの生成後：

Plan Plus completed
Document: docs/01-plan/features/{feature}.plan.md
Next step: /pdca design {feature}

主要な原則

原則	出典	適用
一度に 1 つの質問	ブレインストーミング	AskUserQuestion による順次質問
代替案を検討する	ブレインストーミング	フェーズ 2 で 2～3 個のアプローチを必ず検討
YAGNI を徹底する	ブレインストーミング	フェーズ 3 で multiSelect による検証
段階的な検証	ブレインストーミング	フェーズ 4 でセクションごとに承認
HARD-GATE	ブレインストーミング	承認前のコード作成は禁止（全プロセス）
コンテキストを優先する	ブレインストーミング	フェーズ 0 で自動探索

PDCA との統合

Plan Plus は /pdca plan と同じ出力を生成し、標準的な PDCA サイクルにシームレスに引き継がれます：

/plan-plus {feature}     ← Enhanced planning with brainstorming
    ↓
/pdca design {feature}   ← Standard PDCA continues
    ↓
/pdca do {feature}
    ↓
/pdca analyze {feature}
    ↓
/pdca report {feature}

使用例

# Start brainstorming-enhanced planning
/plan-plus user-authentication

# After Plan Plus completes, continue with standard PDCA
/pdca design user-authentication
/pdca do user-authentication