実装前にAIへ要件を「詰めさせる」——grillingという6問の実例
この記事は連載「AIと作る、ひとりの開発OS」の一部です。単体で読めますが、全体像はこちらのハブ記事にまとめています。
前回までPhase1として、3体のAIエージェントを動かす仕組みそのものを書いてきた。ここからはPhase2、仕組みの外側——どう考えて判断しているか、という方法論の話に移る。
最初に書くのは`grilling`というスキルだ。以前の記事で、これはGitHub（mattpocock/skills）から移植したものだと書いた。今回は出自の話ではなく、実際に使うと何が起きるかを、具体例で見せる。
grillingとは何か（おさらい）
実装前に、AIに要件を一問一答で詰めさせる手法だ。骨子は単純で、質問は必ず1つずつ、回答を待ってから次へ進み、質問だけでなく推奨案もセットで出す。コードベースに答えがあるなら聞かずに調べる。決定が依存関係を持つ場合は、上流から順に潰していく。
止め時の基準も決めてある。すべてを聞き尽くすことではなく、「これで実装を始めても手戻りが起きない」という確信が持てた時点で終わる。
なぜ一気に全部聞かないのか。複数の質問を並べると、答える側（人間）の思考が分割されて、1つ1つの判断が浅くなる。それに、後の質問の答えが前の質問の結果に依存していることが多い。土台が決まっていない状態で先の質問をしても、答えがすぐにひっくり返る。
実例A：新規ゲーム企画の6問
以前、新しいゲーム企画を起案した時のことだ。企画書の段階で、「実装はgrilling後にPhase 0判断」と最初から宣言してあった。要件が固まりきらないまま手を動かしても、後で全部やり直すことになると分かっていたからだ。
実際にgrillingを実施したところ、6つの論点が一度に確定した。
ターゲット層の定義（競合作の購買層をベンチマークにする）
コア要素の規模（プロトタイプで可変にして、実機で比較しながら詰める前提にする）
判定の許容幅（3段階のレンジを初期値として仮固定する）
プラットフォーム方針（対応形態を1つに絞り、他の対応は「別物」として扱う）
名称（既存作とのかぶりを避けるため、この時点では保留にする）
体制分担（技術検証と実機確認で役割を分け、他のプロジェクトを止めない配分にする）
grillingが終わった直後、技術検証が動き出した。同日中に、目に見える進捗が大きく進んだ。もしこの6つを曖昧なまま作り始めていたら、判定の甘さに後から気づいて数値を作り直したり、対応プラットフォームを広げすぎて実装が膨らんだり、という往復が起きていたと思う。着手前に片付けたことで、それが起きなかった。
実例B：良いパターンでも、そのまま輸入しない
もう1つ、性質の違う例がある。外部のヒット作を分解して、良い設計パターンを見つけたことがあった。それを自分の別のゲームに応用できないか、という話になった時、「既存の設計思想と矛盾しうるため要grilling」という判断が入った。
ここでのgrillingは、要件を聞き出すための質問というより、採用していいかどうかを検証するための質問だった。4つの論点——どこに適用するか、どのくらいの頻度で出すか、どういう操作方式にするか、既存のシステムとどう接続するか——を1つずつ確定させていく中で、「このゲームの核となる要素には、絶対に手を加えない」という不可侵条件が明確になった。
良いパターンを見つけることと、それを自分の作品に使っていいと判断することは、別の作業だ。外から見て魅力的でも、今作っているものの核と衝突するなら、輸入しないほうがいい。grillingは、その見極めにも使える。
なぜ一問一答にこだわるのか
複数の論点を同時に聞かれると、人間は無意識にどれかを優先し、残りを適当に流してしまう。1つずつ聞かれると、その論点だけに集中できる。
そして、決定木の上流から順に潰していく設計になっているのもポイントだ。土台になる判断（実例Aで言えば、ターゲット層や対応プラットフォーム）が先に決まっていれば、後続の質問（判定の数値をどう詰めるか、体制をどう分けるか）は、その土台の上で考えればいい。順番を守らずに末端の質問から聞くと、後で土台がひっくり返った時に、末端の答えも全部やり直しになる。
まとめ
grillingは、要件を詰める手続きであると同時に、良いアイデアをそのまま採用しないためのブレーキとしても機能している。「聞き出す」ためだけの道具ではなく、「本当にこれでいいか」を確かめるための道具でもある。
今回は「実際どう機能したか」の話にとどめた。自分の環境にどう導入するかは、また別の記事で書くつもりでいる。
次回は、判断そのものの基準——実装中に何を見て、何を疑うか、という話を書く。
