ブレーンストーミング

このスキルは、構築の方法に入る前に何を構築するかを明確にする、効果的なブレーンストーミングセッションの詳細なプロセス知識を提供します。

このスキルを使用するタイミング

ブレーンストーミングは以下の場合に有価値です:

• 要件が不明確またはあいまいな場合
• 複数のアプローチで問題を解決できる場合
• ユーザーと一緒にトレードオフを探索する必要がある場合
• ユーザーがまだ望むものを十分に説明していない場合
• 機能のスコープを絞り込む必要がある場合

以下の場合はブレーンストーミングをスキップできます:

• 要件が明確で詳細な場合
• ユーザーが正確に望むものを知っている場合
• タスクが単純なバグ修正または十分に定義された変更である場合

コアプロセス

フェーズ0: 要件の明確性を評価する

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

要件が明確な兆候:

• ユーザーが具体的な受け入れ基準を提供した
• ユーザーが従うべき既存パターンを参照した
• ユーザーが期待される正確な動作を説明した
• スコープが制限され、十分に定義されている

ブレーンストーミングが必要な兆候:

• ユーザーが曖昧な用語を使用した(「より良くする」「何か追加する」など)
• 複数の合理的な解釈が存在する
• トレードオフについてまだ議論されていない
• ユーザーがアプローチについて確信していない

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

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

ユーザーの意図を理解するために、一度に1つの質問をします。複数の質問で圧倒しないようにしてください。

質問技法:

1. 自然な選択肢が存在する場合は複数選択肢を優先する

   • 良い例: 「通知は(a)メールのみ、(b)アプリ内のみ、(c)両方のどれにしますか?」
   • 避ける: 「ユーザーにどのように通知しますか?」

2. 広くから狭く進める

   • まず: 中心的な目的は何か?
   • 次に: ユーザーは誰か?
   • 最後に: 制約は何か?

3. 仮定を明確に検証する

   • 「ユーザーはログインしていると想定しています。これで正しいですか?」

4. 早期に成功基準について質問する

   • 「この機能がうまく機能していることをどのようにして知りますか?」

探索する主要なトピック:

トピック	質問例
目的	これは何の問題を解決しますか? モチベーションは何ですか?
ユーザー	誰がこれを使用しますか? ユーザーのコンテキストは何ですか?
制約	技術的な制限はありますか? タイムラインはありますか? 依存関係はありますか?
成功	成功をどのように測定しますか? ハッピーパスは何ですか?
エッジケース	何が起こってはいけませんか? 考慮すべきエラー状態はありますか?
既存パターン	コードベースに従うべき同様の機能はありますか?

終了条件: アイデアが明確になるまで、またはユーザーが「進める」または「次に進もう」と言うまで続けます

フェーズ2: アプローチを探索する

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

各アプローチの構造:

### アプローチA: [名前]

[2～3文の説明]

**メリット:**
- [利点1]
- [利点2]

**デメリット:**
- [欠点1]
- [欠点2]

**最適な場合:** [このアプローチが優れている状況]

ガイドライン:

• 推奨事項をリードし、その理由を説明する
• トレードオフについて正直である
• YAGNIを検討する — シンプルな方が通常は優れている
• 関連する場合はコードベースパターンを参照する

フェーズ3: デザインをキャプチャする

主要な決定を構造化された形式で要約します。

デザインドック構造:

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

# <トピックタイトル>

## 構築するもの
[簡潔な説明 — 最大1～2段落]

## なぜこのアプローチか
[検討したアプローチと、このアプローチが選ばれた理由の簡潔な説明]

## 主要な決定
- [決定1]: [根拠]
- [決定2]: [根拠]

## 未解決の質問
- [計画フェーズに向けた未解決の質問]

## 次のステップ
→ 実装の詳細については `/workflows:plan` へ

出力場所: docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md

フェーズ4: ハンドオフ

次に何をするかについて明確な選択肢を提示します:

1. 計画に進む → /workflows:plan を実行
2. さらに絞り込む → デザインの探索を継続
3. 今のところは完了 → ユーザーは後で戻る

YAGNIの原則

ブレーンストーミング中、複雑さに積極的に抵抗します:

• 仮説的な将来の要件に対して設計しない
• 述べられた問題を解決する最もシンプルなアプローチを選択する
• 巧妙なソリューションより退屈で実証済みのパターンを優先する
• 複雑さが生じたときに「本当に必要ですか?」と質問する
• 今意思決定する必要がない決定を先送りにする

インクリメンタル検証

セクションを短く — 最大200～300単語。出力の各セクションの後、一時停止して理解を検証します:

• 「これはあなたが思い描いていたものと一致していますか?」
• 「継続する前に調整はありますか?」
• 「この方向に進みたいですか?」

これは、ずれたデザインに対する無駄な取り組みを防ぎます。

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

アンチパターン	より良いアプローチ
一度に5つの質問をする	一度に1つ質問する
実装の詳細にジャンプする	「何を」に焦点を保つ、「どのように」ではなく
過度に複雑なソリューションを提案する	シンプルから始める、必要な場合のみ複雑さを追加する
既存コードベースパターンを無視する	まず存在するものを調査する
仮定を検証せずに行う	仮定を明示的に述べて確認する
長いデザインドキュメントを作成する	簡潔に保つ — 詳細は計画に含める

マイクロサービスモード

フォーカスされたサービスがアクティブなマルチサービスモノレポで作業する場合:

• フェーズ1中に質問のスコープをフォーカスされたサービスに限定する
• ブレーンストームドキュメントに ## Services セクションを含める(フェーズ3) 影響を受けるサービスとそれぞれの役割をリストします
• クロスサービス機能の場合でも、ブレーンストームを単一のドキュメントとして保つ — ブレーンストームをファイル間で分割するとそれらが読みにくくなります
• <focus_context> ブロックを渡す ブレーンストーム中にスポーンされた任意のサブエージェントに

Services セクションは /workflows:plan がスコープを自動検出し、サービスごとの計画ファイルを生成することを可能にします。

計画との統合

ブレーンストーミングは何を構築するかに答えます:

• 要件と受け入れ基準
• 選択したアプローチと根拠
• 主要な決定とトレードオフ

計画はどのように構築するかに答えます:

• 実装ステップとファイル変更
• 技術的な詳細とコードパターン
• テスト戦略と検証

ブレーンストーム出力が存在する場合、/workflows:plan はそれを検出して入力として使用し、独自のアイデア絞り込みフェーズをスキップする必要があります。