brainstorminglisted

# Brainstorming アイデアや曖昧な要件を、対話的なドリルダウンで設計書（PBI INPUT PACKAGE）に昇華する。 ## Iron Law `NO CODE WITHOUT APPROVED DESIGN FIRST` 設計が承認されるまで、一切のコード実装を禁止する。「シンプルだから」「急いでいるから」は理由にならない。 ## Common Rationalizations | こう思ったら | 現実 | |---|---| | 「シンプルだから設計不要」 | シンプルなタスクほど設計が速い。省略する理由にならない | | 「前に似たことをやったから分かる」 | コードベースは変化する。今の状態を調査しろ | | 「ユーザーが急いでいるから質問を省略」 | 曖昧なまま進めると手戻りの方が遅い | **核心原則**: コードを書く前に、ユーザーが本当に何を求めているかを確認する。 ## Philosophy - **1質問ずつ**: 一度に複数の質問をしない。ユーザーの回答を受けてから次の質問を決める - **YAGNI**: 「将来必要になるかも」は削る。今必要な最小構成を設計する - **代替案を提示**: 最初のアイデアに飛びつかない。2-3のアプローチをトレードオフ付きで提示する - **既存パターン優先**: コードベースの既存実装を調査し、一般論ではなくプロジェクト固有のパターンに従う - **インクリメンタル承認**: 各ステップでユーザーの承認を得てから次に進む --- ## 8ステップ プロセス ### Step 1: プロジェクト��ンテキスト探索 ユーザーのアイデアを聞いた後、まずコードベースを調査する。 ```text 調査対象: □ 関連する既存コード（Grep/Globで検索） □ 類似機能の実装パターン □ アーキテクチャの制約 □ 関連するテストパターン ``` **出力**: 関連コードと制約の要約をユーザーに報告する。 ### Step 2: 明確化質問（1つずつ） ユーザーの意図を正確に把握するため、**1つずつ**質問する。 質問の優先順位: 1. **Why**: なぜこの機能が必要か？（ユーザーの課題・目的） 2. **Who**: 誰が使うか？（エンドユーザー、管理者、API利用者） 3. **What**: 具体的に何ができるようになるか？（受入基準） 4. **Scope**: 何をやらないか？（明示的な除外範囲） 5. **Constraints**: 技術的制約、期限、依存関係は？ **ルール**: - 回答から次の質問を導出する（スクリプト的に全質問を投げない） - 3-5問で十分な理解が得られたら次のステップへ進む - ユーザーが「もう十分」と言ったら即座に次へ ### Step 3: アプローチ提案 2-3のアプローチを提示する。各アプローチには: ```markdown ### アプローチ A: {名前} **概要**: 1-2文で説明 **トレードオフ**: - メリット - デメリット・リスク **変更範囲**: {影響するファイル数・領域} **工数目安**: 小 / 中 / 大 ``` **ルール**: - 最もシンプルなアプローチを最初に提示する - 各アプローチの「やらないこと」を明確にする - ユーザーが選びやすいよう推奨を示す（ただし押し付けない） ### Step 4: ユーザー承認チェックポイント