brainstorming

ブレインストーミング

このスキルでは、どのようなものを作るかを明確にしてから、どのように作るかを検討する、効果的なブレインストーミングセッションのための詳細なプロセス知識を提供します。

このスキルを使う場面

ブレインストーミングが有効なのは、次のような場合です。

• 要件が不明確、または曖昧である
• 問題を解決する方法が複数考えられる
• ユーザーとトレードオフを検討する必要がある
• ユーザーが求めるものを十分に言語化できていない
• 機能の範囲を絞り込む必要がある

次のような場合は、ブレインストーミングを省略できます。

• 要件が明確かつ詳細である
• ユーザーが求めるものを正確に把握している
• タスクが単純なバグ修正、または明確に定義された変更である

基本的なプロセス

フェーズ 0：要件の明確さを評価する

質問を始める前に、ブレインストーミングが必要かどうかを評価します。

要件が明確であることを示す兆候：

• ユーザーが具体的な受け入れ基準を提示している
• 従うべき既存のパターンを挙げている
• 期待する動作を正確に説明している
• 範囲が限定され、明確に定義されている

ブレインストーミングが必要であることを示す兆候：

• ユーザーが曖昧な表現（「もっと良くして」「何か似たようなものを追加して」など）を使っている
• 妥当な解釈が複数ある
• トレードオフがまだ議論されていない
• ユーザーが進め方に迷っているように見える

要件が明確な場合は、次のように提案します。「要件は明確なようです。計画または実装に直接進むことをご検討ください。」

フェーズ 1：アイデアを理解する

ユーザーの意図を把握するため、一度に 1 つずつ質問します。複数の質問を一度に投げかけて、相手を圧倒しないようにします。

質問のテクニック：

1. 自然な選択肢がある場合は、選択式の質問を優先する

   • 良い例：「通知はどの形式にしますか？（a）メールのみ、（b）アプリ内のみ、（c）両方」
   • 避ける例：「ユーザーへの通知方法はどうしますか？」

2. 大まかな質問から始め、徐々に絞り込む

   • 最初に：中心となる目的は何ですか？
   • 次に：ユーザーは誰ですか？
   • 最後に：どのような制約がありますか？

3. 前提を明示的に確認する

   • 「ユーザーはログインしているものと想定しています。合っていますか？」

4. 早い段階で成功基準について尋ねる

   • 「この機能がうまく動作しているか、どのように判断しますか？」

検討すべき主なトピック：

トピック	質問の例
目的	これはどのような問題を解決しますか？動機は何ですか？
ユーザー	誰が使いますか？どのような状況で使いますか？
制約	技術的な制限はありますか？期限は？依存関係は？
成功	成功をどのように測定しますか？理想的な利用の流れは何ですか？
エッジケース	どのようなことが起きてはいけませんか？考慮すべきエラー状態はありますか？
既存のパターン	コードベース内に参考にできる類似機能はありますか？

終了条件： アイデアが明確になるまで続けるか、ユーザーが「進めて」または「次に進みましょう」と言うまで続けます。

フェーズ 2：アプローチを検討する

アイデアを理解したら、具体的なアプローチを 2～3 個提案します。

各アプローチの構成：

### Approach A: [Name]

[2-3 sentence description]

**Pros:**
- [Benefit 1]
- [Benefit 2]

**Cons:**
- [Drawback 1]
- [Drawback 2]

**Best when:** [Circumstances where this approach shines]

ガイドライン：

• 推奨案を最初に示し、その理由を説明する
• トレードオフを率直に説明する
• YAGNI を考慮する。通常はシンプルな方法が最善です
• 関連する場合は、コードベースのパターンを参照する

フェーズ 3：設計をまとめる

重要な決定事項を、構造化された形式で要約します。

設計ドキュメントの構成：

---
date: YYYY-MM-DD
topic: <kebab-case-topic>
---

# <Topic Title>

## What We're Building
[Concise description—1-2 paragraphs max]

## Why This Approach
[Brief explanation of approaches considered and why this one was chosen]

## Key Decisions
- [Decision 1]: [Rationale]
- [Decision 2]: [Rationale]

## Open Questions
- [Any unresolved questions for the planning phase]

## Next Steps
→ `/ce:plan` for implementation details

出力先： docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md

フェーズ 4：次のステップに引き継ぐ

次に何をするか、明確な選択肢を提示します。

1. 計画に進む → /ce:plan を実行する
2. さらに調整する → 設計の検討を続ける
3. 今回はここまでにする → ユーザーは後で再開する

YAGNI の原則

ブレインストーミング中は、複雑さを積極的に避けます。

• 仮定に基づく将来の要件に備えて設計しない
• 提示された問題を解決できる最もシンプルな方法を選ぶ
• 巧妙な解決策より、実績のある堅実なパターンを優先する
• 複雑さが生じたら、「本当にこれが必要ですか？」と尋ねる
• 今決める必要のないことは、決定を先送りする

段階的な検証

各セクションは短く、最大200～300語に収めます。各セクションの出力後に一旦止まり、理解が合っているかを確認します。

• 「これはお考えに合っていますか？」
• 「続ける前に調整したい点はありますか？」
• 「この方向で進めてよいですか？」

これにより、認識がずれたまま作業を進めてしまうことを防げます。

避けるべきアンチパターン

アンチパターン	より良いアプローチ
一度に5つの質問をする	1つずつ尋ねる
実装の詳細に飛びつく	HOWではなく、WHATに焦点を当てる
複雑すぎる解決策を提案する	シンプルに始め、必要な場合にのみ複雑さを加える
既存のコードベースのパターンを無視する	まず既存の内容を調べる
検証せずに前提を置く	前提を明示し、確認する
長大な設計ドキュメントを作成する	簡潔にまとめ、詳細は計画に記載する

計画との連携

ブレインストーミングでは、何を作るか（WHAT）を決めます。

• 要件と受け入れ基準
• 選択したアプローチとその理由
• 重要な決定事項とトレードオフ

計画では、どのように作るか（HOW）を決めます。

• 実装手順と変更するファイル
• 技術的な詳細とコードパターン
• テスト戦略と検証方法

ブレインストーミングの出力がある場合、/ce:planはそれを検出して入力として使用し、独自のアイデア洗練フェーズを省略する必要があります。