「デモ止まり」を抜け出す方法——プロトタイプを3ヶ月放置していませんか

プロトタイプは動いている。デモを見せたら「いいね」と言われた。投資家にも見せた。知人にも見せた。

でも、まだリリースしていない。

それが1週間なら問題ない。1ヶ月でもまだわかる。でも3ヶ月が経っていたら、それはもう「あとちょっと」ではない。デモ止まりという状態に入っている。

この記事は、デモ止まりの正体を分解し、最短で抜け出す方法を示す。

「デモ止まり」とは何か

デモ止まりとは、プロトタイプが完成しているにもかかわらず、本番公開に至っていない状態のことだ。

特徴的なのは、外から見ると「ほぼ完成している」ように見えること。画面はある。基本機能も動く。データベースにも繋がっている。デモを見せれば「もう公開できるのでは？」と言われる。

しかし当事者の頭の中には、漠然とした不安がある。「これ、そのまま出して大丈夫なのか？」

その不安は正しい。AIが生成したコードの45%にセキュリティ脆弱性が含まれるという調査結果がある。直感的に「何か足りない」と感じているなら、実際に足りていない。

問題は、何が足りないのかが言語化できないことだ。言語化できないから、対処のしようがない。対処できないから、止まる。

なぜ止まるのか——3つの構造的な原因

デモ止まりは意志の弱さではない。構造的な問題だ。

原因1: 「完成度の錯覚」

AIコーディングツールの最大の功績は、見た目が整ったUIを短時間で作れるようにしたことだ。しかしこれが裏目に出る。

画面が綺麗に動いていると、「90%完成している」と感じる。実際には、セキュリティ・インフラ・運用設計が丸ごと残っていて、**完成度は60〜70%**だ。

「あと10%」だと思っているから、「来週やろう」と思える。でも実際は30%残っている。来週では終わらない。次の来週も終わらない。こうして「もう少し」が3ヶ月続く。

原因2: 「次に何をすればいいかわからない」

UI開発中は、やるべきことが明確だ。「ログイン画面を作る」「一覧ページを作る」「詳細画面を作る」——目に見えるゴールがある。

ところが本番化フェーズに入ると、やるべきことが急に抽象的になる。「セキュリティを確認する」「インフラを整える」「運用設計をする」——具体的に何をすればいいのか、どこから手をつければいいのか、わからない。

わからないことは先延ばしされる。これは人間として自然な反応だ。

原因3: 「失敗のコストが急に見える」

プロトタイプを作っている間は、失敗しても自分しか困らない。しかしリリースすると、ユーザーの目に晒される。セキュリティ事故が起きたら責任を取る必要がある。

「出さなければ失敗しない」という心理が無意識に働く。完璧になるまで出さない——これは合理的に見えて、実は最も高コストな判断だ。出さない間にも時間と機会が失われている。

デモ止まりの「本当のコスト」

3ヶ月止まっていることの代償を計算してみる。

時間コスト: 仮に自分の時間を時給3,000円で換算すると、週10時間×12週＝36万円分の時間が「止まっている」ことに費やされている。しかも成果はゼロだ。

機会損失: 3ヶ月あれば、最初のユーザー10人からフィードバックをもらい、2回はピボットできる。市場の仮説検証が3ヶ月遅れている。

モチベーション: 止まっている期間が長くなるほど、プロジェクトへの情熱が冷める。これが最も大きな損失だ。3ヶ月前の熱量は今もあるか？

「完璧にしてからリリースする」より「不完全でもリリースして改善する」方が、ほぼすべてのケースで正しい。ただし、セキュリティだけは例外だ。ユーザーのデータを危険に晒すことは許されない。

デモ止まりから抜け出す4ステップ

Step 1: 「何が足りないか」をリストにする

まず、漠然とした不安を具体的な項目に変換する。

自分のプロダクトに対して、以下の質問に答えてみてほしい。

• ログインなしで見えてはいけないページが、本当に保護されているか
• 別のユーザーとしてログインしたとき、他人のデータが見えないか
• APIキーがコードに直書きされていないか
• 本番用のデータベースと開発用が分離されているか
• エラーが起きたとき、自分に通知が来る仕組みがあるか

「はい」と即答できない項目が、あなたの「残り30%」だ。技術的に何が必要かの全体像は、「最後の30%」完全ガイドにまとめている。

Step 2: 「公開の条件」を3つに絞る

「完璧にしてから出す」をやめる。代わりに、公開のための最低条件を3つだけ決める。

例:

1. ログイン認証が正しく動いている
2. 他ユーザーのデータが見えない状態になっている
3. 独自ドメインでHTTPS接続できる

この3つが満たされたら公開する。それ以外の改善は、公開後にやる。

条件を3つに絞るのが難しいと感じるなら、それ自体がデモ止まりの症状だ。リリースを阻む7つのブロッカーを読んで、自分のプロジェクトに当てはまるものを特定するところから始めてほしい。

Step 3: 期限を決める

「来週公開する」と誰かに宣言する。SNSでもいい。知人でもいい。投資家でもいい。

期限がないタスクは永遠に完了しない。これはプロダクト開発に限った話ではないが、デモ止まりの文脈では特に顕著だ。

ある調査では、2〜4週間で本番公開できる条件を満たしているプロジェクトが、実際にリリースまで数ヶ月かかるケースが多い。技術的には準備ができているのに、期限がないから動かない。

Step 4: 自分でやるか、仕上げを任せるか決める

Step 1で出したリストを見て、判断する。

自分でやる場合: セキュリティやインフラの基礎知識がある、または学ぶ時間がある。目安として、リスト全体を2週間以内にクリアできる見通しがあるか。

仕上げを任せる場合: セキュリティやインフラに自信がない、または時間を使いたくない。AIが作った70%をそのまま活かして、残り30%だけを専門家に依頼する。

どちらが正しいということはない。ただし「自分でやる」を選んで3ヶ月止まっているなら、そのアプローチは機能していない。費用の比較は本番化の費用比較を参照してほしい。

「出してから直す」が正解になる条件

「不完全でもリリースしろ」は、無条件に正しいわけではない。以下の条件を満たしている場合に限り、有効な戦略だ。

出していい条件:

• セキュリティの最低ラインをクリアしている（認証・RLS・APIキー管理）
• 最初のユーザーが限定的（10人以下のベータ版）
• 問題が起きたときに自分で対応できる体制がある

出してはいけない条件:

• 他人のデータが見える状態のまま
• 決済機能があるのにテスト環境の設定のまま
• 個人情報を扱うのにセキュリティ未確認

セキュリティに関して不安が残る場合は、Vibe Codingで最低限やるべきセキュリティ対策を確認してから判断してほしい。

デモは見せた。次は届ける番だ

デモ止まりの本質は、「完成しているのに届いていない」という矛盾だ。

あなたのプロダクトを待っている人がいる。少なくとも、デモを見て「いいね」と言った人がいる。その人たちに使ってもらえていない1日1日が、機会の損失だ。

デモで見せられる状態まで作れたということは、プロダクトの70%はすでに完成している。残り30%は、適切な順序で取り組めば、2〜4週間で片付く。

止まっている時間が一番もったいない。

→ 何が足りないかの全体像を知りたい方は「最後の30%」完全ガイドへ