マリオやゼルダの生みの親の宮本茂さんの発言に「ゲームは2度作ると良くなる」というものがあるそうです。一度作ると、「もっとこうすればよかった」という点が見えやすく、2度目を作ると改善しやすいということです。「ゼルダの伝説 風のタクト」のリメイクのインタビューで、当時の任天堂社長の岩田聡さんがこの発言を紹介しています。
これはSaaSの立ち上げでも同じだなあと思い、しかも今のAI開発時代にやりやすい話ではないかと思います。自分の経験をもとに「プロダクトを2度作る」ことのよさを紹介してみます。
3度作った去年の話
1度目の実装
あるSaaSの新規プロダクトに去年携わっていました。通常、新規プロダクトはユーザーヒアリングをしてから方向性を決めて開発にかかります。
しかし、世に出すまでの期間を短縮したかったのでユーザーヒアリングの前にプロトタイプ開発に着手してみました。ある程度、業務SaaSであればこのあたりが価値になるだろうという仮説を持ってプロトタイプ機能を一気に作りました。具体的には、streamlitという、サーバーサイドもフロントエンドも1ファイルで完結するpythonのプロトタイプ用フレームワークで実装しました。3日で10機能ほど作ったかと思います。当時はCursorと対話をしながら高速実装を行いました。
作った10機能あるプロトタイプを持って、ユーザー対象になりそうな人達にデモしにいきました。このような機能は有用でしょうか、イマイチですか、でらこちらはどうですか…とあてにいきます。そうすると、例えば経営企画の人はA,Bの機能を興味持ってくれる。経理の人はB,Cの機能は興味を持ってくれる、D以降の機能はあまり興味を持たれない…というようにプロトタイプ機能の「あたり具合」が1週目のユーザーヒアリングでは分かりました。
次は、興味を持たれたA,B,Cの機能をブラッシュアップします。加えて、ユーザーヒアリングで得られた情報を元にD'のような少し違った角度の機能を作り出してみます。全く興味を持たれなかった機能は「仮説の外れ」として削除します。そのような改善を繰り返すことで、価値のある機能と、刺さるユーザー対象が徐々に見えてきます。判明する価値がMVP(Minimum Valuable Product)の目玉機能の元になります。
2度目の実装
さて、価値のある機能がわかってきたら、簡易的なフレームワークで作ったstreamlitのプロダクトは破棄します。代わりに、要件をドキュメントでまとめて、本番を想定したフロントエンド（Next.js）をベースに作り直します。これでUIが大分モダンになり、本番を意識した機能として実装がしやすくなります。
ここでは要件が明確になっていたのでClaude Codeを使いました。1度目のプロトタイプ開発で分かった機能要件、画面要件ドキュメントをClaude Codeから参照させて、価値があると分かった機能を移植します。
そうして2度目のプロトタイプを持ってまたユーザーヒアリングに赴きます。新しい技術で作り直したプロダクトは見た目が変わったり、できることが増えてユーザーヒアリングでまた新しい示唆を得られます。2度目のプロトタイプは完成度も上がっているので、ユーザーヒアリングもより多く、幅広に行います。そうすると、やっぱりこういう機能が良いんではないか、こういう方向性はどうか、という話が出てくるのでまたClaude Codeを活用して機能を変更、追加します。この時点ではコードの綺麗さは気にしません。ローカルでデモするだけなら保守性やセキュリティも一旦脇に置いておきます。
そして、より精度の高い価値仮説が判明して、2番目のプロトタイプが完成します。
3番目の実装
最後に、本番想定のフレームワークに載せ替えます。フロントエンドとサーバーサイドの分離、クリーンアーキテクチャの導入、セキュリティの強化など、長く使う前提での基盤に移植していきます。
この時点では、かなり高い精度の価値仮説が生まれているはずなので、営業資料なども並行して作成することも有効です。完成イメージは2番目のプロトタイプをスクリーンショットすれば良いのです。
そうして、3番目の実装でMVPが完成しました。
新規プロダクトをAIで何度も作り直すことが可能になった
これまでの開発は、希少なソフトウェアエンジニアのリソースを有効活用するため、少しずつ作る、無駄なものを作らない、という少し進んでは方向を変える、小まめなピボットをしながらMVPに到達することが主流でした。
しかし、CursorやClaude CodeなどAIコーディングが可能になったことでエンジニアリングのリソースが突然10倍以上になったような感覚があります。（プロトタイプ作りならv0もそうですね）
こうすると、少しずつ作るよりも、全方面のアイデアを実装したで、ただしそうな方向をユーザーヒアリングで見定める、という物量攻めの新規開発が可能になります。
まとめ: リーンにおける「紙芝居」がプロトタイプに
リーンスタートアップでは、プロトタイプを作る前にスライドなどで「紙芝居」を作って、ユーザーヒアリングで価値検証を行いましょうという方法論がかかれています。今でもこれは有効だと思いますが、AIコーディングが主流になった2025年以降は、紙芝居を作るコストとプロトタイプを作るコストがどんどん拮抗していくのだと思います。エンジニアでなくとも、Claude Code等のコーディングエージェントでプロトタイプを作ることが主流になるでしょう。
またスライドの紙芝居ではなく、作ってみて分かることもやはりあります。おそらくゲームなんかはこの傾向が顕著で、作ってみたら面白いか面白くないかが分かる要素がたくさんあるのでしょう。だからこそ「ゲームは2度作るとよくなる」ということが語られるのだと思います。世界的クリエイターの宮本茂さんですら2度作ってよくなると言うのなら、私たちは何度も作り直して、何度もよくしていく価値はあるのでしょう。
