1. はじめに
新規開発やリニューアルプロジェクトにおいて、要件定義やディスカバリー（探索）のフェーズが想定以上に長引いてしまう経験はないでしょうか？
ドキュメントを整備し、FigmaなどでUIデザインを見ながら議論を重ねているにもかかわらず、どこか話が噛み合わない、いわゆる 「空中戦」 が続いてしまうような状況です。
こうした停滞が起きてしまう原因は様々な要因が考えられると思いますが、一つの大きなボトルネックとして、「同じメンタルモデル」がない状態で、複雑な仕様の合意形成を図ろうとしている点が挙げられるのではないでしょうか。
ドキュメントのような静的な情報だけで認識を統一しようとすることには、どうしても限界が伴います。
この記事では、この課題に対して自分が実際に試してみたAIを活用したアプローチについて共有したいと思います。
2. なぜFigmaやドキュメントでは限界があるのか
開発の初期段階ではドキュメントによる要件定義や、Figmaなどを用いたプロトタイピングが行われるのが一般的です。
これらは情報の整理やビジュアルの共有には非常に有効です。
しかし、複雑な業務フローを伴うプロダクトの新規開発やリニューアルなど影響範囲の大きい開発においては、いくつかの構造的な限界が存在します。
「描かれていない不便さ」は見えない
もちろん、Figmaでも詳細なプロトタイプを作り込めば、画面遷移や体験の連続性を検証することは可能です。
しかし、プロトタイプを作り込んだとしてもFigmaで検証できるのは、あくまで意図してプロトタイプに組み込んだ理想形になってしまいます。
そのため、実際に業務データに近い量を入力してみたときに、「スクロール量が多すぎてストレスを感じる。」「多少窮屈でも一画面ですべて確認したい。」といったような実際に使って初めて出てくるような不満が出てくることがありえます。
このような経験をしたことがある方は沢山いらっしゃるのではないでしょうか？
(自分は何度も経験してきました。)
こうした「実際に使ってみて初めて感じる身体的なストレス」や「描かれていない隙間の不便さ」は、静的なカンプや、ハッピーパスだけを繋いだプロトタイプでは、どうしても見落とされがちです。
影響範囲の網羅が困難
仕様変更が発生した際、その影響範囲をドキュメントやすべてのデザインカンプ上で網羅的に追跡するのはかなり難しいと思います。
ある機能を変更したとき、ドキュメントの記述は修正できても、それに関連する別の機能への副作用までは、静的な資料だけで完全に見通すこと困難なのは共感いただけると思います。
その結果、リリースして初めて、「あ、ここの整合性が取れていない」と気づき、バグに繋がることもあります。
3. AIを活用して、捨てる前提で爆速実装する
前セクションで触れたドキュメントやFigmaの構造的な限界を突破するために試したアプローチが、 「AIを活用して、捨てる前提で爆速実装する」 という手法です。
「とにかく動く状態」を最短距離で作り上げる
このアプローチで重要なのは、「とにかく動く状態」 を最短距離で作り上げることです。
通常の実装ではコードレビュー、テスト設計、細かなリファクタリング、テスト実施などの「品質担保のための工程」は必須となると思います。
しかし、捨てる前提で作るため一切行いません。
エラーが出ればAIに修正させ、動きが確認できれば良しとします。
目的はプロダクトとしての完成度を高めることではなく、議論のたたき台となる 「動く設計図」 を作ることだからです。
AIの実装は想像以上に早い
「コードを書くよりFigmaの方が早い」というのは、過去の常識になりつつあります。
Claude CodeやCodex、CursorといったAIツールの進化は目覚ましく、そのコーディング能力は日々向上しています。
実際に自分がこれらのツールを使ってこの手法を試した際、複雑な要件を含む機能のプロトタイプを、わずか半日足らずで作り上げることができてしまいました。
(ベースが既に存在している前提です)
これまでは、Figmaなどでプロトタイプを作るのが、イメージを共有する最速の手段だと考えられてきたと思います。
しかし、AIを活用すれば、裏側のロジックも含めた「動く画面」が瞬時に生成されます。
そのスピードは従来のコーディングの常識を覆すもので、場合によってはデザインツールで画面を作り込むのと遜色ない、あるいはそれ以上の速さで「動くもの」が手に入ってしまうのです。
デザインもAIが考えてくれるので、エンジニアが「作れる！」と思い立ってから完成にまでにかかる時間はかなり短縮されているように感じます。
実装すること自体が「検証」になる
こうして爆速で作られた 「動く設計図」 は、多くの気づきを与えてくれます。 実際にブラウザでデータを入力してみることで、「この操作フローは手間がかかりすぎる」「一画面で完結させないと運用が回らない」といった、実際に触れないと分からないUXの課題を見つけることができます。
また、AIに実装させる過程で、データ構造の矛盾やエッジケースがエラーとして顕在化します。
人間が頭を悩ませて考慮事項を洗い出さなくても、「実装しようとする行為」そのものが、仕様の穴を見つける最強のテストのインプットになるのです。
「捨てる」モノを作ることは無駄ではないか？
「工数かけて動くところまで作ったのに捨ててしまうのは工数の無駄では？」と思うかもしれません。
しかし、。このプロセスが置き換えているのは「ディスカバリー」のフェーズであり、「何を作るべきか（What）」がを明確にするフェーズです。
モノを作る開発のプロセスを置き換えているわけではなく、ディスカバリーを超高解像度に行った状態で、改めてゼロから設計し、実装し直すという考え方です。
4. 先行事例：世界も「動く実体」での対話にシフトしている
「動くものをとりあえず作って、検証して、捨てる」。 このアプローチは、AIの登場によって突如生まれたものではありません。
ソフトウェアエンジニアリングの巨人が提唱していた理想が、技術の進化によってようやく「コストに見合う現実的な解」になったのです。
人月の神話:「一つは捨てるつもりで作れ」
ソフトウェア工学の金字塔『人月の神話』の著者、フレデリック・ブルックスは、50年も前にこう提唱しています。 「一つは捨てるつもりで作れ。どうせ捨てることになるのだから（Plan to throw one away; you will, anyhow.）」
彼は、最初から完璧な設計など不可能であり、一度作ってみて初めて分かる問題があるため、最初のバージョンは「学習のための捨て石」にすべきだと説きました。
これまで、この格言は「理想論」でした。
実際のその後の章ではインクリメンタルに作ろうというふうに書いてあります。捨てるために人間がコードを書くのは、あまりにコストが高いし、ユーザーが触れる頃には後戻りできなくなっていることが大半だからです。
しかし、AIの進化がこのコスト構造を大幅に変えていると思っています。
出典: Frederick P. Brooks Jr., The Mythical Man-Month, Addison-Wesley, 1975, Chapter 11.
AI時代の新概念「One-shot Software（使い捨てソフトウェア）」
Webフレームワーク「Django」の共同創造者であり、現在AIエンジニアリングの論客として知られるSimon Willison氏は、AIによって 「One-shot Software（一回限りの使い捨てソフトウェア）」 が可能になったと提唱しています。
彼は自身のブログで、「これまでは維持管理する価値のあるものしか開発されなかったが、AI（LLM）によって開発コストがゼロに近づいたため、特定の課題を解決するためだけにコードを書き、用が済んだら捨てることが正当化されるようになった」と語っています。
この考え方は、まさに私たちがディスカバリーで行おうとしている「検証のためだけに作り、捨てる」というアプローチを、現代的な視点で裏付けるものです。
出典: Simon Willison, "One-shot software" (simonwillison.net), Mar 2024.
Cursor開発チームの「PdMレス」開発
「Cursor」を開発するAnysphere社の事例も突きつけていて面白いです。
CEOのMichael Truell氏はインタビューで、彼らが専任のPdM（プロダクトマネージャー）を置かず、エンジニアが仕様策定から実装までを一貫して担う体制をとっていると語っています。
彼らにとってコードは「実装のゴール」ではなく、 「思考し、議論するためのツール」 なのです。
ドキュメントやFigmaを書くよりも、AIを使って即座に動くプロトタイプを作り、「これでいいか？」と問うことで、彼らの圧倒的な開発スピードが実現されているのだと思われます。
出典: Lenny's Podcast, "The rise of Cursor (with Michael Truell)", September 2024.
5. おわりに
記事の中で、複雑化する要件定義やディスカバリーフェーズにおける「空中戦」を回避する手段として、AIを活用した「捨てる前提の実装」を使って "動く設計図" を作る方法について説明してきました。
実際にこの手法をやってみている所感としては、QAを捨てることでかなり高速な実装が実現できています。
また、アイディアを試すというのがかなり高速にできるようになっていると感じます。
数時間や数日かけて議論するよりも、「一旦そのアイディアでやってみよう！」と決めてしまって、1,2時間程度で作ってフィードバックサイクルを回すほうが圧倒的に早いのではないか？と感じるほどです。
このようにAI時代に適した開発スタイルを引き続き模索していこうと思います。
ログラスアドベントカレンダーを引き続きお楽しみください！
Discussion