Intent Storming ── コーディングに入る前に行う作業

課題: アイデアから一足飛びにコードへ

能力の高いモデルがあると、アイデアからプロンプト、そして動くコードへ一直線に進みたくなります。半日はそれでうまくいきます。けれど六週間後には、なぜそのトレードオフを選んだのか誰も覚えておらず、エージェントはいつの間にか別の問題を解いていて、spec を書いていたとしても、それはもう存在しないシステムを語っています。「なぜ」と「何を達成したいか」が一度も構造化されなかったので、作業がつなぎ留まる先がなかったのです。

提案: 最初の成果物を「意図」にする

私たちは、Intent Storming を作業の冒頭に置く「明示的で名前のついたステップ」として扱うことを提案します ── キックオフや設計レビューを当たり前に行うのと同じように。そのステップの成果物は、しまい込まれるドキュメントではありません。以後のすべてのスライスが受け継ぐ、辿れる意図ツリー（Purpose / User Context / Means）です。コードより前に意図を固めるのは、drift を取り除く最も安いタイミングです ── まだ間違った前提の上に何も積み上がっていないからです。

二つの形: チームのワークショップ、または AI との一人作業

ワークショップとして行う場合は、プロダクトオーナーとエンジニア（UI が論点ならデザイナーも）が同じ場に集まり、ツリーが求める問いに答えていきます ── なぜこれをやるのか、誰のためか、MVP は何ができれば良いのか、どのトレードオフはすでに受け入れているか。あるいは一人でも行えます ── 一人がプロダクトオーナーを務め、AI がヒアリングします。未決定の論点ごとに、背景・選択肢・それぞれの利点と欠点・推奨を提示してから質問する。どちらの場合も、あなたはヒアリングを受けるプロダクトオーナーであり、答えはそのまま Purpose / User Context / Means のノードとしてツリーに書き込まれます。

セッションの流れ

1. 目的とアーキテクチャを、プロダクトオーナーの言葉で普通に述べる ── 何を作るのか、なぜか、すでに分かっているスタックや制約は何か。
2. AI がそれを構造化されたインタビューに変える: 未決定の論点ごとに、背景 → 選択肢 → 利点と欠点 → 推奨、そして質問。こだわりのある所だけ自分で答え、それ以外は推奨を採用する。
3. 答えはそのまま Purpose / User Context / Means のノードとしてツリーに書き込まれ、昇格状態（inferred → clarified → canonical）が確度を明示する。
4. 必要な粒度 ── 画面の一要素からプロダクト全体のコンセプトまで ── でツリーが固まったら止める。最初は少数の要点から始め、どうしても守ってほしい詳細は後から意図として足していけばよい。

正直なスコープ: 判断できるプロダクトオーナーが要る

これは「技術力が要らない」という話ではありません。スタックを選ぶこと、AI が並べた選択肢を判断すること、意図がドリフトし始めたと気づくこと ── どれも本物のエンジニアリングとプロダクトの判断を必要とします。裏を返せば心強い点もあります（実際に確認できています）: 技術力のある人であれば、ツールの経験がまったくなくても、初回からしっかり構造化された意図をまとめられる ── 方法はガイダンスが運び、思考は本人の AI が担うからです。Intent Storming は、判断できる人の天井を上げます。判断そのものを不要にするわけではありません。

「コードを書くことから始めない。プロダクトオーナーになることから始め、作業を意図のツリーとして歩み出させる。」 まず Intent Storming を行い、下流のすべてにそれを受け継がせましょう。

特定のプロダクトに依存しない

Intent Storming は機能ではなくプラクティスです。すでに使っている AI と、ツリー用の素の markdown フォルダがあれば実践できます。Intent-System の中では具現化されていて ── intent-cli がインタビューの構造とツリー形式を供給します ── が、プラクティス自体は単体で成立し、どんなツールチェーンの上流にも置けます。