simple

楽しいブレインストーミング

アイデアから実行可能な方向性へすばやく進むための、構造化されながらも軽量なブレインストーミングスキルです。意図の探索、トレードオフの評価、意思決定の検証といった共同設計の厳密さを保ちつつ、小規模から中規模のタスクでは不要なプロセス上の負担を省きます。

目標はシンプルです。ユーザーの要望を理解し、選択肢を一緒に検討し、方向性を決めて、作業を始めます。複数フェーズにわたる儀式も、必須の設計文書も、終わりのない確認のやり取りもありません。適切な判断を下すのに必要なだけの構造を設け、それ以上は加えません。

基本ルール

ユーザーが方向性を明示的に承認するまで、コードを書いたり、ファイルを作成したり、実装に着手したりしてはいけません。タスクが明白に見える場合でも同様です。ブレインストーミングの目的は、作り始める前に立ち止まって考えることです。この境界を守ってください。

プロセスの流れ

digraph fun_brainstorm {
    rankdir=TB
    node [shape=box style=rounded]

    Discover -> Propose
    Propose -> Converge
    Converge -> Approved [label="yes"]
    Converge -> Propose [label="no (max 2x)"]
    Approved [shape=diamond]
    Approved -> Capture
    Capture -> Implement
}

• 調査 — プロジェクトの背景（コードベース、規約、既存のパターン）を確認します。意図、制約、成功基準を明確にするため、焦点を絞った質問を最大3つまで行います（選択式を推奨）。関連する質問はまとめて提示します。依頼がすでに明確な場合は、すぐに提案へ進みます。

• 提案 — トレードオフを示しながら、2つのアプローチを提示します。推奨案を最初に示し、その理由を説明します。各案は短い段落にまとめます。タスクに応じて詳しさを調整し、簡単な作業なら数文、複雑な判断ならより詳しく説明します。

• 合意 — ユーザーから明示的な承認を得ます。却下された場合は修正して再提案します。やり直しは最大2回です。それでも合意に至らない場合は、ユーザーに希望を直接伝えてもらいます。ゆっくり完璧な方向性を選ぶより、適切な方向性をすばやく選ぶほうが有益です。

• 記録 — 選んだ方向性（内容、理由、重要な判断）を、最初に作成するファイルのインラインコメントとして記録するか、チャットで共有します。ユーザーから求められない限り、別途設計文書は作成しません。

原則

• 形式よりスピード — ブレインストーミングの価値は、成果物ではなく思考にあります。実質的な価値を加えない形式は省きます。適切な判断につながる短いやり取りは、判断を遅らせるだけの洗練された文書よりも有益です。

• YAGNI — 今必要なものだけを設計します。まだ存在しない要件のために、抽象化、拡張ポイント、柔軟性を持ち込まないでください。後で必要になったら、そのときに対処できます。先回りした設計は、解決する問題より多くの問題を生み出します。

• 行動を優先 — 2つの選択肢の質がほぼ同じなら、どちらかを選んで進めます。理論上最適な選択肢を探すために余計な時間をかけても、ほとんど報われません。進めることで明確になります。議論するより、作ってみるほうが多くを学べます。

• まとめて確認 — 確認の質問は、複数のメッセージに分けて1つずつではなく、まとめて行います。確認が長引くとユーザーの時間を浪費し、作業の流れを妨げます。必要な情報を一度に集め、先へ進みます。

• タスクに応じた深さ — プロセスの重さを、タスクの規模に合わせます。小さなバグ修正や設定変更なら、ステップ1と2を1つのメッセージで済ませられる場合があります。新しいサブシステムなら、ステップ2でより詳しく検討します。作業の複雑さに応じて、やり取りの複雑さを調整します。