エンジニアなしで MVP を作る方法と、誰も最初に教えてくれないこと
構築することはボトルネックでなくなりました。それを計算に入れて計画を更新した人はほとんどいません。
私が聞かれる問いと、その下にある問いがあります。
聞かれる問い。エンジニアを雇わずに自分の製品を作れますか。はい。2026 年に AI のツールを持つ 1 人の創業者は、8 週から 16 週という古典的な MVP の日程に対しておよそ 1 週間で動くアプリを立ち上げられます。Altar.io のデータは平均を 4 か月近くに置き、最も一般的な日程は 3 か月です。
その下にある問い。それは機能するのか。そして正直な答えは、それが構築とまったく関係のないことに依存するということです。
CB Insights はベンチャー投資を受けた失敗した 431 社を分析し、43 パーセントが製品と市場の適合の弱さから失敗したことを見出しました。70 パーセントは「資本が尽きた」のですが、同じ分析はそれを原因ではなく症状として扱っています。お金が尽きることは本当の問題への道の途中で起きることです。
これらの失敗のどれも遅い開発によって引き起こされていません。つまり開発のボトルネックを取り除くこと自体は、その数字を動かしません。
正確に何が変わったか
「ソフトウェアは今簡単だ」ではありません。より狭くより有用な何かです。
アプリを生み出すコストは崩壊しました。アプリが何であるべきかを決めるコストはまったく動きませんでした。
20 年にわたって開発のボトルネックはその 2 番目のコストを隠していました。構築に 4 か月と 8 万ドルかかったとき、その 4 か月がある種の規律を強制していました。エンジニアリングが働く間に顧客と話す時間があり、費用が約束の前に考えさせたのです。
その 4 か月を取り去ると、考えることは今や任意になります。それが 2026 年の実際のリスクで、新しいリスクです。間違ったものを以前よりずっと速く作れて、それは間違っているのに印象的に完成して見えるでしょう。
何かをプロンプトする前に下す 4 つの決定
プロセスではありません。4 つの問いで、すべて 1 つの午後で答えられます。
1. これは正確に誰のためで、その人たちは今日代わりに何をしているか。
市場ではありません。1 人の人間と、その人の今の回避策です。表計算、WhatsApp のグループ、代理店、日曜の 3 時間。回避策に名前を付けられないなら、問題が本物かどうかまだ分かっていません。本当に痛む問題には誰もが回避策を持っているからです。
2. これがしなければならない 1 つのことは何か。
誰かの一日をより良くする 1 つの動作です。他のすべては第 2 版です。これは以前より今の方が重要です。AI のツールはあなたが説明した 9 つの機能すべてを喜んで作り、9 つの機能は誰も説明できない製品で終わる道だからです。
3. あなたの製品の中の物は何で、それらはどう関係しているか。
これは創業者が飛ばすもので、6 か月目を生き延びられるかを決めるものです。ユーザー、注文、プロジェクト、請求書。あなたの名詞が何であれです。どれがどれに属するか。何が一意でなければならないか。1 つが削除されたら何が起きるか。
技術的な語彙は必要ありません。「1 人の顧客は多くのプロジェクトを持てる、1 つのプロジェクトはちょうど 1 人の所有者を持つ、2 人の顧客はメールアドレスを共有できない」はデータモデルです。それを書くのは 15 分で、この取り組み全体で最もてこの効く 15 分です。語彙が馴染みないなら、技術用語集がそれらの用語を、既に知っていると前提せずに扱っています。
4. それが機能しているかをどう知るか。
リリースする前に数字を選んでください。リリースした後には励みになるように見える数字を見つけてしまうからです。登録数は通常間違ったものです。誰かが 2 度目に戻ってきたかどうかが通常正しいものです。
3 番目の問いがなぜ噛みつく問いなのか
それを飛ばしたときに何が起きるかのためです。
明示的に下さないあらゆる決定はやはり下されます。生成ツールが、生成の時点で、あなたの事業を含まない文脈から下します。ツールは止まって 2 人の顧客がメールアドレスを共有できるかを問いません。もっともらしい何かを選んで先へ進みます。
そして 4 か月目にチーム、課金、あるいは 2 番目のユーザータイプを追加する必要が生じ、最初の週に静かに選ばれた答えがその変更を追加ではなく再構築にしていることが判明します。あらゆる修正が別の何かを壊します。さらにプロンプトを重ねると悪化します。
つくり手はこれを 70 パーセント問題と呼びます。アプリがほぼ完成に達し、前進を止めます。塞いでいるものが欠けたコードであることは一度もありません。数百世代前に暗黙に下され、もう安く変えられない決定です。
これの業界水準の版は測定できます。DORA の 2025 年の調査は、高い AI の利用が上がるソフトウェアのデリバリーのスループットと上がる不安定さと同時に結びついていることを見出しました。より速く、より脆く、一緒にです。GitClear の 6 億 2300 万件のコード変更の分析は、2023 年の基準に対して重複したコードが 81 パーセント増、一方でコードを整理する活動が 2022 年の変更の 21 パーセントから 2026 年の 3.8 パーセントへ落ちたことを見出しました。
生成は安いです。一貫性は安くなく、それを偶然に生み出すものは何もありません。これに対処するために作られた実践が仕様駆動開発で、主張のアーキテクチャの版はこちらです。
実際に何をするか、この順序で
- 4 つの答えを書いてください。 1 ページです。どのツールも開く前にこれをしてください。3 番目の問いに答えられないなら、構築する準備ができていません。あと 2 人の顧客と話す準備ができています。
- この午後に何が起きるかではなく、6 か月目に何が起きるかでツールを選んでください。 このカテゴリのあらゆる選択肢は今日印象的な何かを生みます。後でまだ拡張できるかについて大きく分かれます。風景を正直に比較したもの。
- その 1 つのことを作ってください。 誰かが 1 つ目を 2 度使うまで 2 番目の機能に抵抗してください。機能の追加がほぼ無料であるとき、これは聞こえるよりずっと難しいことです。
- 50 人ではなく 5 人の本物の人の前に置いてください。 その問題を持つ 5 人は、礼儀正しくしている 50 人より多くを教えます。気に入ったか聞くのではなく、どこで止まるかを見てください。
- その数字について何をするか決めてください。 誰も戻ってこなかったなら、答えはより多くの機能ではありません。もう一度 1 番目の問いです。
本当にまだエンジニアが必要なこと
作り話を売るより、これについて率直でありたいと思います。
間違うことが高くつくあらゆること。 標準的な決済の流れを超える決済、健康のデータ、規制されたあらゆるもの。ツールがそれを生み出せないからではなく、生み出したものが安全かどうかを評価できないからで、それらの領域で「大丈夫そうに見えた」は基準ではありません。
負荷の下でのマイグレーション。 実際の顧客が乗った生きたデータの形を変えることは本当に難しく、静かにうまくいかなくなります。
それが機能する瞬間。 これは良い問題です。利用が増えたとき、システムを理解する誰かがそれを所有する必要があります。その採用を、避けるべきだった失敗ではなく成功の節目として計画してください。
おそらくエンジニアが必要でないこと。誰かがこれを欲しいかどうかを知る地点に到達することです。以前はエンジニアが必要でした。今は必要なく、それは活用する価値のある本物の変化です。
印象的なデモの罠
動く画面は、あなた自身も含めて、極めて説得力があります。
それを人々に見せると励ましてくれるでしょう。磨かれたインターフェースを見ることは、働き方を変えるよう求められることとは異なる反応を生むからです。励ましは証拠ではありません。デモは、あなたが部屋にいない状態で誰かが 2 度使ったときにだけ意味を持ちます。
醜い製品と 40 人の戻ってくるユーザーを持つ創業者を、美しい製品と 400 の登録があって 2 度目の訪問がない創業者より見たいと思います。2 番目の方がずっと手に入れやすく、ずっと立ち直りにくいのです。前進のように感じられるからです。
簡単にならなかった部分
その物を今は 1 週間で作れます。それは本物で、本当に新しく、そうでないと言う人は最近試していません。
しかしその 431 の失敗した会社の 43 パーセントは製品と市場の適合の弱さで死に、1 社も構築に時間がかかりすぎて死んではいません。ボトルネックは移りました。常に難しい部分であり、4 か月のエンジニアリングの背後に隠れていた部分へ移りました。
どの決定を、どの順序で、誰のために。それが今の仕事です。それは常に仕事でした。
構築することが、それを掻き消すほど騒がしかっただけです。
関連する読み物
特にアーキテクチャの決定について：技術的な背景のない創業者のための SaaS の開発。ツールが実際にいくらかかるかについて：トークン、クレジット、労力。
よくある質問
2026 年に本当にエンジニアなしでアプリを作れますか。 はい。技術的な背景のない創業者は、8 週から 16 週という古典的な MVP の日程に対して、AI アプリビルダーを使っておよそ 1 週間で動くアプリを公開できます。制約はもうそれを作れるかどうかではありません。始める前に正しいことを決めたかどうかです。
MVP を作るのにどれくらいかかりますか。 古典的には 8 週から 16 週で、データは平均を 4 か月近く、最も一般的な日程を 3 か月に置いています。AI のツールがあれば 1 人の創業者はおよそ 1 週間で動く製品に到達できますが、その速さは下にある決定が意識的に下されていたときにだけ役立ちます。
構築する前に何を決めるべきですか。 4 つです。誰のためで、その人たちが今日代わりに何をしているか。製品が支えなければならない 1 つの動作。あなたの製品の中の物が何で、それらが互いにどう関係しているか。そしてそれが機能しているかを告げる数字です。3 番目が創業者のほとんどが飛ばすもので、後で最も高くつく問題を引き起こすものです。
AI で作った MVP はなぜ数か月後に機能しなくなるのですか。 誰も明示的に下さなかった決定が生成ツールによって暗黙に下され、それらの決定がその後のすべてを制約するからです。これが 70 パーセント問題です。アプリがほぼ完成に達して止まります。塞いでいるものが欠けた機能ではなくアーキテクチャの選択だからです。
MVP を作るためにデータベースを理解する必要がありますか。 技術的な語彙は必要ありませんが、製品の中にどの物が存在しどう関係するかを言える必要があります。「1 人の顧客は多くのプロジェクトを持てる、1 つのプロジェクトは 1 人の所有者を持つ、2 人の顧客はメールアドレスを共有できない」は平易な日本語で表現されたデータモデルで、それを書くことはできる最も価値のあることの 1 つです。
実際にいつエンジニアを雇う必要がありますか。 間違うことが高くつくあらゆること（規制されたデータ、標準的な決済の流れを超える決済）のためです。出力が安全かどうか評価できないからです。負荷の下で生きたデータを移行するために。そして製品が機能し始めて誰かがシステムをきちんと所有する必要があるときに。この最後のものを成功の節目として扱ってください。
エンジニアなしで MVP を作るのにいくらかかりますか。 ツールはどれだけ反復するかに応じて無料枠から月に数百ドルまでで、古典的な構築より劇的に少ないです。創業者を捕まえるコストはリリース後のものです。利用が増えるにつれてのホスティングと、初期のアーキテクチャが次の機能を担えない場合の再構築です。
