brainstorming

Brainstorming

アイデアや曖昧な要件を、対話的なドリルダウンで設計書（PBI INPUT PACKAGE）に昇華する。

Iron Law

NO CODE WITHOUT APPROVED DESIGN FIRST

設計が承認されるまで、一切のコード実装を禁止する。「シンプルだから」「急いでいるから」は理由にならない。

Common Rationalizations

こう思ったら	現実
「シンプルだから設計不要」	シンプルなタスクほど設計が速い。省略する理由にならない
「前に似たことをやったから分かる」	コードベースは変化する。今の状態を調査しろ
「ユーザーが急いでいるから質問を省略」	曖昧なまま進めると手戻りの方が遅い

核心原則: コードを書く前に、ユーザーが本当に何を求めているかを確認する。

Philosophy

• 1質問ずつ: 一度に複数の質問をしない。ユーザーの回答を受けてから次の質問を決める
• YAGNI: 「将来必要になるかも」は削る。今必要な最小構成を設計する
• 代替案を提示: 最初のアイデアに飛びつかない。2-3のアプローチをトレードオフ付きで提示する
• 既存パターン優先: コードベースの既存実装を調査し、一般論ではなくプロジェクト固有のパターンに従う
• インクリメンタル承認: 各ステップでユーザーの承認を得てから次に進む

---

8ステップ プロセス

Step 1: プロジェクトコンテキスト探索

ユーザーのアイデアを聞いた後、まずコードベースを調査する。

調査対象:
□ 関連する既存コード（Grep/Globで検索）
□ 類似機能の実装パターン
□ アーキテクチャの制約
□ 関連するテストパターン

出力: 関連コードと制約の要約をユーザーに報告する。

Step 2: 明確化質問（1つずつ）

ユーザーの意図を正確に把握するため、1つずつ質問する。

質問の優先順位:

1. Why: なぜこの機能が必要か？（ユーザーの課題・目的）
2. Who: 誰が使うか？（エンドユーザー、管理者、API利用者）
3. What: 具体的に何ができるようになるか？（受入基準）
4. Scope: 何をやらないか？（明示的な除外範囲）
5. Constraints: 技術的制約、期限、依存関係は？

ルール:

• 回答から次の質問を導出する（スクリプト的に全質問を投げない）
• 3-5問で十分な理解が得られたら次のステップへ進む
• ユーザーが「もう十分」と言ったら即座に次へ

Step 3: アプローチ提案

2-3のアプローチを提示する。各アプローチには:

### アプローチ A: {名前}

**概要**: 1-2文で説明
**トレードオフ**:
- メリット
- デメリット・リスク
**変更範囲**: {影響するファイル数・領域}
**工数目安**: 小 / 中 / 大

ルール:

• 最もシンプルなアプローチを最初に提示する
• 各アプローチの「やらないこと」を明確にする
• ユーザーが選びやすいよう推奨を示す（ただし押し付けない）

Step 4: ユーザー承認チェックポイント

ユーザーにアプローチを選んでもらう。

「アプローチ A/B/C のどれで進めますか？
また、変更・追加したい点があれば教えてください。」

Step 5: 設計書ドラフト作成

選ばれたアプローチを基に、pbi-input.md形式の設計書を作成する。

# PBI INPUT PACKAGE: {タイトル}

> 生成日: YYYY-MM-DD
> 生成方法: brainstormingスキル

## Context / Why
{なぜやるか。ユーザーの課題・目的}

## What（Scope）

### In scope
{やること。具体的な機能・振る舞い}

### Out of scope
{やらないこと。明示的な除外範囲}

## 受入基準
- [ ] {基準1}
- [ ] {基準2}
- [ ] {基準3}

## Notes from Refinement
{議論で決まったこと。ブレスト中の意思決定を記録}

## Estimation Evidence

### Risks
{リスク}

### Unknowns
{不明点}

### Assumptions
{前提条件}