実用最小限の製品（MVP）は、2026年にAIプラットフォームで開発するすべての人にとって悪いアドバイスです。厳密に言えば間違ったアドバイスではなく——もはや存在しない世界からのアドバイスであり、それでも韻を踏み、スライドに収まるという理由だけで繰り返されているのです。
エリック・リースは2011年、ボトルネックがエンジニアの工数であったチーム向けにMVPの概念を書きました。ある機能の実装に3週間かかり、それを誰かが欲しがるかどうか確信が持てないなら、スコープを最小化することが唯一の合理的な選択でした——本当に希少な資源を配分していたのです。この制約こそが、そのフレーズの中で「最小限」が重要な意味を持っていた理由です。それはプロダクトの美学に関する哲学ではありませんでした。構築にコストがかかり、まず少なく作ることによってのみ検証が安くつくというコスト構造の下でのトリアージだったのです。
コスト構造は逆転した
スプリントボードではなく、チャットから計画、実行へと進むパイプラインを通じて開発する場合、限界機能のコストは3週間ではありません。プロンプト一つと検証作業程度です。かつて高コストだったもの——コードを書くこと——は今やほぼ無料に近くなっています。今も本当に高コストなのは、何を作るべきかを見極めることと、公開後のノイズだらけのユーザー行動から意味のあるシグナルを読み取ることです。MVP理論は最初の制約を最適化していました。AIプラットフォームで開発している人のほとんどは、もはやそのボトルネックに縛られていません。
だから、創業者がログイン画面と一つの機能だけを出荷して「素早く学ぶために」MVPと呼ぶとき、たいていの場合、彼らは何かを配分しているわけではありません。異なる経済状況に合わせて作られたアドバイスにパターンマッチしているだけであり、その過程で本当のシグナルを生み出すには薄すぎるものを出荷しています。5人が一機能だけのアプリを試し、3人がすぐに離脱すれば、削ぎ落とされたアプリは削ぎ落とされたように感じられるという以外、ほとんど何も学べません。それは無駄のなさではありません。ただ小さいだけです。
| 2011年の制約 | 2026年の制約（AIビルダー） | |
|---|---|---|
| 希少な資源 | コードを書いてテストするエンジニアの工数 | 適切なスコープを定義し、結果を読み取る時間 |
| 限界機能コスト | 数日から数週間 | ビルド1サイクル、おおよそ数分から数時間 |
| 作りすぎるリスク | 高い——間違っていた場合の埋没コスト | 低い——削除や作り直しのコストは追加のコストとほぼ同じ |
| 作らなさすぎるリスク | 低い——次のスプリントで再度出荷できる | 高い——薄いアプリは薄く曖昧なシグナルしか生まない |
| 「最小限」が守っていたもの | あなたのチームの時間 | もう何も——今やそれはデータ品質というコストになる |
最後の行をもう一度読んでほしい。ミニマリズムを正当化していた理由は、今のあなたにとって希少ではないリソースを守ることだった。あなたは古いルールのコストを払い続けている——テストの範囲が狭くなり、リテンションのシグナルが弱まり、アイデアが悪かったからではなく未完成に見えたからユーザーが離脱する——それでいて、かつてそのコストが買っていたはずのメリットは何も得ていない。
「幅広く作る」が実際に意味すること
想像できるものを何でも作れという意味ではない。ユーザーを探しに行く前に、そのプロダクトの当たり前の全体像を作り込むという意味だ——オンボーディング、コアループ、そのカテゴリの誰もが備えている隣接機能一つ、そしてプロトタイプではなくソフトウェアだと感じさせる設定画面。習慣トラッカーを作っているなら、それはストリーク単体ではなく、ストリークとリマインダーと履歴ビューだ。ニッチなマーケットプレイスを作っているなら、それは問い合わせフォームを付けただけの出品情報ではなく、出品情報とメッセージング、そして信頼シグナル(レビュー、認証、何かしら)だ。
テストすべきなのは「どこまで小さくできるか」ではない。「見知らぬ人が完成品と見間違えるほど最小限の版はどれか」だ。これは異なる基準であり、通常は機能1つではなく3~4個分の幅が必要になる。それぞれの機能が採用の意思決定ではなく計画のステップと検証の一巡で済むプラットフォームなら、初週でその基準に到達することは、2011年当時とは違い、現実的な話だ。
これについては昔痛い目にあったことがある。友人のスタジオ向けに小さなツールを作った——画面は1つ、機能も1つ、素早く仕上げた、まさにMVPだ。誰も使わなかったし、それを市場の声だと自分に言い聞かせた。しかし違った。ワークフローの他のツールが持つ3つのタブに比べて未完成に見えたため、誰も習慣にするほど信頼しなかったのだ。アイデア自体は悪くなかった。形が失敗であり、しかも私は薄いことが美徳だと思ってわざと薄く出したのだ。
批判派が正しい部分
これに反論する人たちには一理あるが、それはエンジニアリングコストの話ではなく、注意力の話だ。5つの機能を作ることはもはや開発者の工数を食わないが、意思決定の工数は食うし、ユーザーの理解コストも食う。幅広い最初のバージョンは、検証すべき表面積が増え、バグが隠れる場所が増え、書くべきオンボーディングが増え、コアループが腑に落ちるまでに新規ユーザーが学ぶべきことが増えるということだ。幅広く作ってコアループが間違っていた場合、今度は1機能ではなく5機能にまたがってシグナルが混乱してしまい、どれがリテンションを殺したのか解きほぐすのに、単一のクリーンなテストより時間がかかる。スコープの規律は依然として重要だ——ただし今は違う対象に向けられている。旧来のMVPはビルド時間を律していた。この経済に適した版は意思決定時間を律する。プロダクトを本物らしく感じさせる一握りの機能だけを選び、それを超えるものは容赦なく削り、追加が安いからという理由だけで追加し続けたい誘惑に抗うことだ。作るのが安いことは、何かが壊れたときにそれを保守したり説明したり理解したりするのが無料であることと同じではない。
だから、本能が告げるよりも幅広く作ろう。「最小限」を正しい言葉にしていた制約はもう存在しないのだから。しかしMVPを良いアイデアたらしめていた規律は保とう——ただし、それを最初のバージョンではなく、ローンチ後のスコープクリープに向けるのだ。
