brainstorming

ブレインストーミング

基本原則

コードを書く前に設計します。必ずです。

実装に飛びつかないでください。まず会話を通じて仕様を明確にします。

ブレインストーミングのプロセス

ステップ 1：目標を理解する

確認の質問をします。

• どのような問題を解決しますか？
• ユーザーは誰ですか？
• 成功とはどのような状態ですか？
• 制約は何ですか？

質問は一度に一つだけにします。複数の質問で相手を圧倒しないでください。

ステップ 2：選択肢を検討する

• どのようなアプローチが考えられますか？
• トレードオフは何ですか？
• 類似した問題にはどのようなものがありますか？
• どのパターンが当てはまりますか？

ステップ 3：代替案を提示する

決定する前に、必ず2～3 個のアプローチを提示します。

## Option A: [Name]
- Pros: ...
- Cons: ...
- Best when: ...

## Option B: [Name]
- Pros: ...
- Cons: ...
- Best when: ...

## Option C: [Name]
- Pros: ...
- Cons: ...
- Best when: ...

**Recommendation:** Option [X] because...

ステップ 4：段階的に検証する

設計を理解しやすい単位に分けて提示します。

• 一度に一つのセクションを提示する
• 次に進む前に承認を得る
• 途中で修正できるようにする

ステップ 5：設計を文書化する

保存先：docs/plans/YYYY-MM-DD-<topic>-design.md

YAGNI を徹底する

ブレインストーミングでは、次の要素を積極的に削ります。

• 「あると便利かもしれない」機能
• 「起こるかもしれない」エッジケース
• 「将来の柔軟性」のための抽象化
• 「必要になるかもしれない規模」に向けた最適化

こう尋ねます。「MVP にこれが必要ですか？」

質問のテクニック

選択式を優先する

次のように尋ねるのではなく、「エラーはどのように処理すべきですか？」 次のように尋ねます。「エラー処理には、A）エラーコードを返す、B）例外をスローする、C）Result 型を使う、のどれがよいですか？」

選択肢を絞った質問

次のように尋ねるのではなく、「API はどのような形にすべきですか？」 次のように尋ねます。「REST、GraphQL、RPC のどれにしますか？」

前提を明らかにする

• 「X を前提にしています。合っていますか？」
• 「これは Y に依存します。利用できますか？」
• 「制約は Z のようです。そうでしょうか？」

出力：設計ドキュメント

# [Feature Name] Design

## Problem Statement
What problem are we solving?

## Goals
- Goal 1
- Goal 2

## Non-Goals
- Explicitly out of scope item 1
- Explicitly out of scope item 2

## Proposed Solution
Overview of the approach

## Alternatives Considered
Why we didn't choose other approaches

## Technical Design
### Component A
...
### Component B
...

## Open Questions
- Question 1
- Question 2

## Next Steps
1. Step 1
2. Step 2

実装への移行

設計が承認された後：

1. 「実装の準備を始めてもよいですか？」と尋ねます。
2. using-git-worktrees スキルを使って、分離されたワークスペースを作成します。
3. writing-plans スキルを使って、詳細な実装計画を作成します。

アンチパターン

避けること

• 設計が明確になる前にコーディングを始める
• 選択肢を一つしか提示しない
• 具体的な質問で済む場面で、自由回答形式の質問をする
• 各セクションの検証を省略する
• 要件がすべてそろっていると思い込む
• 最初の設計を過剰に作り込む