brainstorming

アイデアをデザインに落とし込むブレインストーミング

概要

ブレインストーミングでは、構造化された共同対話を通じて、漠然としたアイデアを検証済みのデザインへと変換します。「X が欲しい」という段階から、計画スキルに引き継げる具体的なデザインへとつなぎます。この強化版では自己学習スキルと連携し、既知のプロジェクトコンテキストを活用して、すでに回答済みの質問を繰り返さないようにします。

開始時に伝えること：「ブレインストーミングスキルを使ってこのアイデアを検討し、実装前にデザインを作成します。」

トリガー条件

• ユーザーが新しい機能のアイデアや目標を説明する
• ユーザーが「X はどのように構築すればよいですか？」と尋ねる
• 創造的な作業で、計画の前にデザインの検討が必要となる
• /brainstorm コマンドが呼び出される
• 漠然とした要件を構造化されたデザインに移行する必要がある

---

フェーズ 1：コンテキストの読み込み

**目標：**ユーザーに質問する前に、プロジェクトについて既知の情報をすべて読み込みます。

1. メモリファイル（project-context.md、learned-patterns.md、decisions-log.md）を確認し、既知のパターン、スタック、規約を把握します
2. 関連する既存のコード、ドキュメント、最近のコミットを読みます
3. docs/plans/ にある既存のデザインを確認し、関連する過去の作業を把握します
4. 既存のアーキテクチャによる制約を特定します
5. すでに把握している内容を書き留めます。調べれば分かる情報をユーザーに再質問してはいけません

コンテキストソースの優先順位

ソース	抽出する内容	優先度
メモリファイル	スタック、規約、過去の決定	最高
CLAUDE.md	プロジェクト構成、必須条件	高
既存のコード	現在のパターン、アーキテクチャ	高
最近のコミット	開発の方向性	中
docs/plans/	過去のデザインと決定	中

停止 — 次の条件を満たすまでフェーズ 2 に進んではいけません：

• メモリファイルを確認した
• 関連するコードベースの領域を調査した
• この領域についてすでに把握していることを要約できる

---

フェーズ 2：アイデアの検討

**目標：**一度に一つずつ、要点を絞った質問をして、ユーザーの意図を理解します。

1. 1 回のメッセージにつき質問は 1 つだけにします。複数の質問をしてはいけません
2. 可能な場合は選択式の質問を優先します
3. 目的、制約、成功基準の理解に重点を置きます
4. フェーズ 1 で読み込んだコンテキストを活用し、すでに回答できる質問は省きます
5. 曖昧な回答を、具体的で検証可能な基準に変換します

質問フローの判断表

知る必要があること	質問の種類	例
主な目的	自由回答形式	「これによってユーザーのどのような問題を解決できますか？」
範囲の境界	選択式	「対象にするのは、（A）ログイン済みユーザーのみ、（B）すべてのユーザー、（C）ロールによって異なる、のどれですか？」
技術的な制約	はい／いいえ＋追加質問	「オフラインでも動作する必要がありますか？」
優先順位のトレードオフ	順位付け	「速度、正確性、シンプルさを順位付けしてください」
成功基準	測定可能な目標	「『動作している』とはどのような状態ですか？正常系の流れを説明できますか？」
対象外	明示的な除外	「今回の反復では、明示的に何を構築しないようにしますか？」

質問のルール

ルール	理由
1 回のメッセージにつき質問は 1 つ	認知的な負荷を防ぐため
選択式を優先する	回答が速くなり、曖昧さを減らせるため
質問する前に調査する	ユーザーの時間を尊重するため
メモリを活用する	既知の内容を再質問しないため
検証可能な結果を求める	成功基準が曖昧だと、デザインも曖昧になるため

停止 — 次の条件を満たすまでフェーズ 3 に進んではいけません：

• 主な目的と、誰のためのものかを理解している
• 制約（技術、スケジュール、範囲）を把握している
• 成功基準と対象外の事項を特定している
• 意図に関する重大な曖昧さが残っていない

---

フェーズ 3：アプローチの検討

目標： トレードオフを示したうえで、異なるアプローチを 2～3 個提案し、明確な推奨案を提示します。

各アプローチについて、次の項目を示します。

セクション	内容
名前	短く、内容がわかるラベル
アーキテクチャの概要	2～3 文
主なトレードオフ	メリットとデメリット
複雑さ	低／中／高
リスク	起こりうる問題
評価	推奨するかどうか、その理由

アプローチ比較テンプレート

## Approach A: [Name] (Recommended)
**Summary:** [2-3 sentences]
**Pros:** [list]
**Cons:** [list]
**Complexity:** [Low/Medium/High]
**Risk:** [What could go wrong]
**Why recommended:** [1-2 sentences]

## Approach B: [Name]
...

## Approach C: [Name] (if needed)
...

推奨するアプローチから先に提示し、フェーズ 2 で検討した制約に照らして最適な理由を説明してください。

停止 — 次の条件を満たすまでフェーズ 4 に進まないでください。

• 少なくとも 2 つのアプローチを提案している
• 各アプローチのトレードオフを明示している
• 明確な推奨案を示している
• ユーザーがどのアプローチを進めるかを示している

---

フェーズ 4：設計の提示

目標： 詳細設計をセクションごとに提示し、段階的に承認を得ます。

1. 複雑さに応じて、設計を論理的なセクションに分けて提示します
2. 各セクションの後で、ここまでの内容に問題がないか確認します
3. フィードバックに応じて、どのセクションも見直せるようにします
4. 関連する設計の観点をすべて網羅します

複雑さ別の設計セクション

複雑さ	必須セクション	任意のセクション
シンプル（1～3 件のタスク）	アーキテクチャ、コンポーネント	—
中程度（4～10 件のタスク）	アーキテクチャ、コンポーネント、データフロー、エラー処理	テスト戦略
複雑（10 件以上のタスク）	アーキテクチャ、コンポーネント、データフロー、エラー処理、テスト戦略、パフォーマンス、セキュリティ	移行計画

セクションの提示順序

1. アーキテクチャ — 全体構成と主な決定事項
2. コンポーネント — どの要素が存在し、どう関連するか
3. データフロー — システム内でデータがどのように流れるか
4. エラー処理 — 起こりうる問題とその対処方法
5. テスト戦略 — 正しさを検証する方法
6. パフォーマンス — 関連する制約がある場合のみ
7. セキュリティ — 機密データまたは認証を扱う場合のみ

一度に 1 つのセクションを提示します。次に進む前に、ユーザーの確認を待ちます。

停止 — 次の条件を満たすまでフェーズ 5 に進まないでください。

• 関連する設計セクションをすべて提示している
• ユーザーが各セクションを承認している（または修正が反映されている）
• 設計全体に一貫性があり、すべての要件に対応している

---

フェーズ 5：ドキュメント化と引き継ぎ

目標： 設計を保存し、計画スキルに引き継ぎます。

1. 検証済みの設計を docs/plans/YYYY-MM-DD-<topic>-design.md に書き込みます
2. 設計ドキュメントをコミットします
3. 自己学習用メモリーを更新します。
   • memory/decisions-log.md — 決定したアーキテクチャ上の判断事項
   • memory/learned-patterns.md — 新たに話し合った規約
4. planning スキルを呼び出し、詳細な実装計画を作成します

設計ドキュメントのテンプレート

# [Topic] Design Document

**Date:** YYYY-MM-DD
**Status:** Approved
**Approach:** [Which approach was chosen]

## Problem Statement
[What problem this solves and for whom]

## Design

### Architecture
[High-level structure]

### Components
[Key pieces and their relationships]

### Data Flow
[How data moves through the system]

### Error Handling
[What can go wrong and how it is handled]

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

## Non-Goals
- [What was explicitly excluded and why]

## Next Steps
Invoke planning skill to create implementation plan.

停止 — 次の条件を満たすまで先に進まないでください。

• 設計ドキュメントが docs/plans/ に保存されている
• 新たな決定事項やパターンがメモリーファイルに反映されている
• ユーザーが設計の完成を確認している

---

アンチパターン／よくある間違い

アンチパターン	失敗する理由	正しいアプローチ
「これはブレインストーミングするほど複雑ではない」	どのプロジェクトにも、たとえ簡単なものでも設計が必要です	設計は簡潔でもかまいませんが、必ず行う必要があります
「ユーザーはすでに自分の望むものをわかっている」	ユーザーがわかっているのは「何を」であり、「どのように」ではありません	アプローチを検討して「どのように」を探ります
「すぐにコーディングを始めればいい」	設計なしのコードは、最初の一行から技術的負債になります	まず設計し、その後にコーディングします
「ブレインストーミングをする時間がない」	不適切な前提からやり直す時間のほうがありません	ブレインストーミングにより、コストのかかる手戻りを防げます
「要件は明確です」	要件は設計ではありません。アプローチを検討する必要があります	要件が明確でも、トレードオフを検討します
一度に5つ質問する	ユーザーを圧倒し、浅い回答しか得られません	メッセージごとに質問は1つにします
コンテキストの読み込みを省略する	すでにわかっていることを再び質問してしまいます	まずメモリファイルを確認します
代替案を提示しない	最初のアイデアに固執し、より良い選択肢を見逃します	常に2～3つのアプローチを提示します
設計全体を一度に提示する	確認するには情報が多すぎて、ユーザーが流し読みしてしまいます	セクションごとに提示し、承認を得ます
決定事項を記録しない	今後のセッションで同じ話し合いが繰り返されます	メモリファイルを更新します

---

合理化を防ぐためのガード

設計を提示し、ユーザーから承認を得るまでは、実装スキルを呼び出したり、コードを書いたり、プロジェクトをスキャフォールドしたり、実装に関する行動を取ったりしてはいけません。これは、簡単だと思われるものも含め、すべてのプロジェクトに適用されます。

次のように考えていることに気づいたら：

• 「まずプロジェクトをスキャフォールドしよう……」— いいえ。まず設計です。
• 「設計は明らかだ……」— ならば、すぐに文書化できます。実行しましょう。
• 「ユーザーが焦っているようだ……」— 不十分な設計は、ブレインストーミングよりも時間を浪費します。

---

統合ポイント

スキル	関係	タイミング
self-learning	上流 — メモリからプロジェクトのコンテキストを提供します	フェーズ1：コンテキストの読み込み
planning	下流 — 承認済みの設計を受け取ります	フェーズ5：計画への移行
task-decomposition	補完的 — 設計を作業分解に落とし込みます	設計から複雑なスコープが明らかになったとき
spec-writing	補完的 — 設計を仕様として正式化できます	正式な仕様が必要なとき
verification-before-completion	下流 — 設計の完全性を検証します	設計が完了したと主張する前

---

具体例

例：シンプルな機能のブレインストーミング

User: "I want to add dark mode to the app"

Phase 1: [Check memory — React app, Tailwind CSS, no current theme system]
Phase 2: "Should dark mode (A) follow system preference automatically,
          (B) be a manual toggle only, or (C) both with manual override?"
Phase 3: Approach A: CSS variables + Tailwind dark: prefix
         Approach B: Theme context provider with CSS-in-JS
         Recommend A — aligns with existing Tailwind usage
Phase 4: Section 1: Architecture — Tailwind dark mode with class strategy
         Section 2: Components — ThemeToggle component, layout wrapper
Phase 5: Save design doc, invoke planning skill

例：計画への移行

Design approved and saved to docs/plans/2026-03-15-dark-mode-design.md.
Updated memory/decisions-log.md with theme system decision.
Invoking planning skill to create implementation plan.

---

主な原則

• 質問は一度に1つ — 相手を圧倒しない
• 選択式を優先 — 回答しやすくする
• YAGNIを徹底する — 不要な機能を取り除く
• 代替案を検討する — 常に2～3つのアプローチを提示する
• 段階的に検証する — セクションごとに提示し、承認を得る
• コンテキストを活用する — self-learningのメモリを使い、すでにわかっていることを再質問しない

---

スキルの種類

RIGID — このプロセスに厳密に従ってください。すべてのアイデアを5つのフェーズすべてに通します。シンプルなプロジェクトであれば設計は簡潔でもかまいませんが、実装を始める前に必ず文書化し、承認を得る必要があります。