動くもので考え、動くもので合意する：AI時代のプロトタイピング環境
はじめに
ソフトウェア開発でもっとも難しいのは、どう作るかではなく、何を作るかを決めるところです。AIコーディングエージェントによってコードが容易に書けるようになったぶん、この難しさは相対的に大きくなりました。プロトタイピングは、動くものを触りながら何を作るかを決めていく手段であり、AIを最も活かせるユースケースの一つです。
さらに、以前の記事で触れたとおり、プロトタイピングには開発のリードタイムを縮める効果もあります。
では、AIでプロトタイプを作れると何がよいのか、また、そのために開発環境の側に何が揃っている必要があるのか、見ていきましょう。
要件定義は距離を埋めるための工程だった
何を作るかを決めるのは、なぜ難しいのでしょうか。なかなか決まらないと、決めるべき人の考えが足りないように見えるかもしれません。しかし、そうとは限りません。むしろ、業務や顧客を知っている人と、それをソフトウェアの形にできる人が別人であることのほうが大きな理由です。いままでは、知っている側は自分で作れず、作れる側は何が必要かを知りませんでした。この二人のあいだの距離を越えて意図を運ぶためには、片方が言葉にし、もう片方がそれを読んで解釈する、という橋渡しが要ります。
要件定義という工程は、その橋渡しのために置かれています。受託開発なら発注者と開発者のあいだに、自社サービスならプロダクトマネージャと開発者のあいだに、同じ構造があります。仕様書やチケットは、言葉にした意図を相手へ渡すための入れ物です。
この工程が重くなる理由は、書く手間そのものではありません。言葉にすると意図の一部は必ず落ちますが、何が落ちたかは、たいてい動くものができてから分かります。そのため、書いて、読んで、作って、違うと分かって、また書く、という往復が生まれます。また実作業だけではなく、待ち時間も発生します。要件定義が重いのは、これが何往復も必要だからです。
一人で回せる試行のループ
作るべきものは、机の上で言葉を練っているときより、動くものを触っているときのほうがよく見つかります。画面を開いて初めて、項目の並び順が実際の作業の順番と合っていないと分かります。一覧を眺めて初めて、この機能はそもそも要らなかったと分かります。
この気づきから次の試作までのあいだに、これまでは開発者への依頼が挟まっていました。業務を知っている側が思いついたことを書いて開発者に渡し、自分の依頼の順番が来るのを待ち、作られたものを触り、また気づく、という往復です。一往復に数時間から数日かかるので、思いついたことの大半は、試される前に忘れられるか、優先度の低い要望として消えていきます。
発注者やプロダクトマネージャが、AIコーディングエージェントを使って自分で作れるようになると、この往復は開発者への依頼を挟まない一人のループに変わります。思いついたその場で直してすぐ触れるので、なぜそう思ったのかという文脈を脳内に保ったまま次の試行に入れます。開発者に説明する手間も、説明のために考えを整理し直す手間もかかりません。また、相手の空き時間を待つ必要もなくなります。
ここで変わっているのは、合意の速さではなく試行の回数です。何を作るべきかが分からない段階では、答えは考えることよりも、作って触ることから出てきます。これを高速に繰り返すことで、気づきが次の気づきを呼び、何を作るべきかの理解が一気に進みます。
動くもので合意する
試行のためのコミュニケーションとはまた別に、ステークホルダー間で認識を合わせるためのコミュニケーションもあります。例えば、新しい動作を実際にシステムを操作するエンドユーザーに説明する場合などです。プロトタイプがあると、このやりとりの対象が文章から動作に移ります。仕様書を書いて読み合わせるかわりに、動くものを見せて、違うところを指してもらえます。言葉で説明すると抜け落ちやすい動作の細部が、その場で共有されます。
ただし、この合意の形が成り立つのは、変更を手軽に行えるときに限ります。指摘を受けて直したものを見せるまでに一週間かかるようでは、手戻りの重さは仕様書で合意していた頃と変わりません。動くものを見せるという形だけを真似ても、やりとり一回あたりの費用が下がっていなければ効果は出ません。
ここまでの二つのループ（一人で回す試行と、動くものによる合意）は、どちらも同じ条件の上に成り立っています。思いついてから実際にソフトウェアを触れるようになるまでが短いことと、何度でも作り直せることです。
思いつきをコードに変換する部分は、AIコーディングエージェントによってすでにそれなりに速くなりました。残っているのは、書いたコードを触れる状態にするまでの手間です。この手間を削るために開発環境へ求める条件は、三つに分けられます。
開発者以外が、セットアップ手順を自力でたどれるか
一つめは、発注者やプロダクトマネージャが、自分のPCでアプリケーションを動かせることです。デモを見せてもらうのと、自分で触るのとでは、気づける量が違います。自分の手元にあれば、思いついたらいつでも試せます。
この条件が満たされるかどうかは、セットアップ手順が簡単で再現性があるかにかかっています。
まず、大前提として手順が文書になっていなければなりません。そして、その文書がいまのコードで通用する必要があります。依存関係の追加や設定の変更に伴い、手順書は書いた直後から古びていきます。開発者であれば、手順が実際と多少ずれていても自力で解決できますが、開発者以外の人にはそれも困難です。手順が最新であることを人力で保証し続けることは難しいので、AIレビュアーにセットアップ手順の更新漏れを確認させましょう。
さらに、その手順は十分に短い必要があります。文書があって最新に保たれていても、二十項目を踏まないと起動しないなら、開発者以外が最後までたどり着ける見込みは下がります。目指すのは、手順を丁寧に説明することではなく、スクリプト化するなどして手順の数を減らすことです。説明を厚くするほど、最新に保つ対象も増えていきます。
意外に詰まりやすいのは、コードの外にある準備です。外部サービスのAPIキー、クラウドの権限、社内システムへの接続情報は、リポジトリを取得しても手に入りません。発行を誰かに依頼して、返ってくるまで待つことになります。他の部署が絡むこともあり、簡単ではありませんが、できる限りワンストップで手続きがすむよう体制を整備しましょう。
コマンド一つで、触れる状態まで到達するか
二つめは、アプリケーションを修正したあとの手間です。初回のセットアップを越えられても、ビルドするたびに同じだけの手間がかかるなら、試せる回数は増えません。
Joel Spolskyが2000年に公開した「The Joel Test」は、開発チームの状態を12個の質問で診断するものです。その2番目が「Can you make a build in one step?」です。最新のソースから出荷できるビルドを作るのに何手かかるか、良いチームならコマンド一つで済む、という問いです。
26年前の問いですが、AI時代にはむしろ重みが増しています。一手でビルドできることの受益者が増えたからです。以前は、一手でビルドできることの価値は、人間が手順を思い出す手間を省くところにありました。いまは、AIエージェント自身がその手順を踏みます。再現しない手順や、書かれていない前提に依存する手順は、エージェントの試行をその場で止めます。止まったことに気づいて助けるのは人間なので、一回止まるたびに、せっかく消したはずの人を待つ時間が戻ってきます。
そのうえで、この問いの範囲を広げる必要があります。試行を増やすためには、作ったプロトタイプを捨てて何度もやり直さなければなりません。そのためには、容易に最初の状態に戻せるかどうか、すなわちビルドだけでなくスクラップが簡単かどうかを問うべきです。
まず、環境は簡単に捨てて作り直せるべきです。例えば、データベースの列の変更、試しに追加したライブラリとその依存、キャッシュに残った新フォーマットのデータなどを考えてみてください。こういった変更を正しく戻すオペレーションは複雑で、またプロトタイプで実証したいことではないでしょう。気づかないまま微妙に壊れかけた環境をそのまま使い続け、原因の分からない不具合に悩まされるのは本筋ではありません。であれば、消して作り直すのが確実です。また、システムを触って確かめられる状態にするには、それらしいデータが入っている必要があります。環境を作り直すたびにテストデータを手作業で投入しなければいけないのであれば、気軽に捨てることはできません。
その日のうちに他人に見せられるか
三つめは、作ったものを他の人に見せるまでの手間です。プロトタイプが手元で動くだけでは、動くものを介した合意までは進みません。相手にURLなどを送り、触ってもらって初めて意見が返ってきます。
ここで詰まるのは、共有用の環境が一つしかない場合です。検証環境が一つきりで、誰かが使っているあいだは他の人が使えないなら、順番待ちが発生します。見せるまでに数日空くと、そのあいだに議論のほうが先へ進んでしまい、確かめたかった点が宙に浮きます。
理想は、（特定の命名規則をもった）ブランチやプルリクエストを作成するたびにプレビュー環境が自動で立ち上がる形です。ホスティングサービスにはこの仕組みを標準で備えたものがあり（VercelやAWS Amplifyなど）、自前の基盤でも同じ形を目指せます。環境が要求に応じて増えるなら、順番を待つ理由自体がなくなります。
とはいえ、環境を無制限に増やせば、その分の費用がかかります。そのため、使った分だけ課金されるサービスを選んだり、複数の環境でリソースを共有したりして、一環境あたりの費用を軽くする設計になります。たとえば、常時起動のサーバを立てるかわりにコンテナ化して需要に応じて増減させたり、環境ごとにデータベースを立てずスキーマで切り替えたりする形です。また、使われなくなった環境を一定時間で止める、本番の複製ではなく縮小したデータ一式を使う、重い依存はモックに置き換える、といった手もありますが、そのぶんプロトタイプで確かめられる範囲は狭まります。どこまで削ってよいかは、その環境で何を確かめたいかによって変わります。操作の流れを確かめるだけなら大きく削れますが、性能を見るならそうはいきません。アプリケーションのどこを頻繁に直すのかを考え、そこを確かめられるだけの再現度は残す、という判断をすることになります。
プロトタイプの限界
ここまでの話は、「要件定義が要らなくなる」ことを意味しません。プロトタイプで確かめられる範囲には、はっきりした境界があります。
プロトタイプが強いのは、使う人がシステムを操作すればすぐに理解できる部分です。画面の流れ、操作の手数、出力の見え方、その機能がそもそも要るのかどうか、といったところです。これらは言葉で議論するより、触ってもらったほうが速く決まります。
一方で、いわゆる非機能要件は、触るだけでは決められません。想定する利用者数での応答時間、障害時にどこまで止まってよいか、誰がどのデータを見てよいか、業務上の例外をどう扱うか、規制や監査で求められる記録は何か、他システムとどういう取り決めを結ぶか、といったものです。これらはプロトタイプの動作には現れないので、言葉で書いて合意するしかありません。
また、プロトタイプのコードは、長期的にメンテナンスしていくのは困難なことが多いでしょう。今後改善する可能性はありますが、現在のAIモデルでは、それなりの仕組みや開発者の細い指示なしに、保守性の高いコードは出力されません。あくまでも仮の実装であり、場合によっては一から書き直さなければいけないということは、認識しておく必要があります。
自分たちの環境を確かめる
いまの開発環境がどこまで整っているかは、次の五つの問いで大まかに分かります。
セットアップ手順が文書になっていて、白紙の環境でいまも通るか
セットアップ手順は、誰でも独力で実行できるぐらい簡素化されているか
システムのビルドが、コマンド一つで済むか
環境を捨てて作り直すことを、気軽に何度でも繰り返せるか
他人に見せるための環境を、誰かと調整せずに増やせるか
どれも、AIを使うようになる前から言われてきたことです。違うのは、以前はこれらが揃っていなくても、開発者が手順を覚えていれば開発が回っていたところです。プロトタイプを何度も作り直す前提に立つと、手順を覚えている開発者しか環境を立ち上げられないため、その属人的な手順がそのまま試行回数の上限になります。
まとめ
何を作るかを決める作業は、決める人と作る人が別であることによって重くなっていました。プロトタイプを作る費用が下がると、この構造は二か所で変わります。決める人が自分で試行を繰り返せるようになり、他の人との合意も動くものを介して進みます。どちらも、思いついてから触れるまでが短く、何度でも作り直せるという条件の上に成り立ちます。
コードを書く速さは、モデルの進歩がある程度まで引き上げてくれます。しかし、環境を立ち上げる手間と、作ったものを見せるまでの待ちは、自分たちで削るしかありません。まずは上の五つを自分たちの環境に当てはめて、どこで止まっているかを確かめてみてください。
株式会社エレクトリック・シープでは、AI開発とAI導入の支援を行っています。プロトタイピングを回せる開発環境の整備や、その先の開発プロセスの組み替えに踏み込んだ支援が必要であれば、ご相談ください。
