「まずプロトタイプを」と「MVP を出しましょう」が、同じ会議で同じものを指すつもりで飛び交うことがあります。片方は数日で捨てる画面を思い浮かべていて、もう片方は課金まで通る製品を思い浮かべている。どこまで作る話なのかが噛み合わないまま、見積もりだけが先に出てきます。
2つの語は、確かめたい対象が違います。MVP の方は、提唱された時点の定義と現場での使われ方がずれたまま流通しています。出どころまで遡ると、誰が言い出したのかという帰属自体も割れています。
プロトタイプと MVP は、確かめたい対象が違う
プロトタイプは、アイデアが成立するか、技術的に実現できるかを確かめるために作ります。壊してよい前提で、見せる相手は社内や関係者です。MVP は、実際の顧客に使ってもらって市場で成立するかを確かめるもので、機能として使える水準が要り、公開が前提になります。日本語の解説記事は、この対比でほぼ一致しています。
| プロトタイプ | MVP | |
|---|---|---|
| 確かめること | アイデアが成立するか、技術的に実現できるか | 市場で成立するか |
| 見せる相手 | 社内・関係者 | 実際の顧客 |
| 作ったあと | 破棄する前提 | 改善を続ける前提 |
| 期間の目安 | 数日から数週間 | 数週間から数か月 |
PoC を加えた3分類もあります。作れるかを見るのが PoC、使えるかを見るのがプロトタイプ、売れるか使われるかを見るのが MVP、という切り分けです。
ここまでは争いが少ない。噛み合わなくなるのは MVP の側です。
MVP は誰が言い出した言葉なのか
一次資料で辿れるのは、Eric Ries が2009年8月3日に自身のブログに書いた定義までです。書籍『The Lean Startup』（2011年）より前になります。では造語したのは誰かという問いに移った途端、説明が割れます。
- 日本語の解説記事には、MVP の起源を「起業家のスティーブ・ブランクとエリック・リースによって提唱された」と説明し、それ以前に触れないものがあります
- 英語圏の記事と Wikipedia は、2001年に Frank Robinson（SyncDev の共同創業者）が造語し、ブランクとリースが広めた、という順序で説明します
- その Robinson 側の会社である SyncDev の公式ページは、2026年8月時点で MVP を「ソフトウェアの歴史の中で洗練されてきた概念」とだけ説明していて、Robinson の名前も2001年という年も出していません
いちばん流通している「2001年に Frank Robinson が造語した」という説は、当事者の一次情報ではなく、第三者の回顧記事を経由して広がっています。その回顧記事は Robinson の定義を、対顧客と対自社の双方で ROI をリスクで割った値が最大になる、適正なサイズの製品、と説明しています。機能を減らす話ではなく、大きさを決める話として書かれている点は覚えておく価値があります。
Robinson が先行していたこと自体は、本人に近い人物の発信で裏が取れます。Steve Blank は2012年の自身のブログで、Lean Startup も Business Model Canvas も Customer Development も生まれるずっと前に、既に同じことを理解していた人物がカリフォルニア州サンタバーバラにいた、と書いています。ただしこれは、2001年に語そのものが作られたことの証明にはなりません。
日本語圏では、この帰属の話自体がほとんど流通していません。2026年8月時点で「MVP 提唱者 フランク・ロビンソン 2001」と検索して返ってくるのは、同姓同名の元メジャーリーガーの情報です。
「最小限の製品を作る」は、提唱者側が否定している
Ries の2009年の定義はこうです。最小の労力で、顧客について検証された学びを最大量集められる、新製品のバージョン。中心にあるのは学びであって、機能の少なさではありません。
Ries の組織の公式サイトは、もっと直接的に書いています。MVP はその名前にもかかわらず、最小限の製品を作ることについての話ではない。小さく作った製品という理解は、公式に誤解として否定されています。
それでも語は独り歩きしました。Wikipedia は、MVP の使われ方があいまいになり、プロトタイプに近いものから完全に市場対応した製品まで、広い範囲を指すために使われていると指摘しています。
広めた側の当事者も、このずれを認めています。スケートボードから始めて車に至るあの図を描いた Henrik Kniberg は、2016年1月25日の自身のブログで、MVP という語そのものが混乱と不安の原因になっていると書きました。同じ記事には、顧客の間で MVP が "Minimum Releasable Crap" と揶揄されるという話も出てきます。そのうえで、Earliest Testable Product、Earliest Usable Product、Earliest Lovable Product という言い換えを提案しています。
会議で MVP という語が噛み合わないのは、参加者の理解不足というより、語がこの状態にあるからです。
どこまで作るかは、捨てる前提かどうかで変わる
捨てる前提のものは、割り切って作れます。割り切ったぶん、続けると決まったときに土台として使えないことがあります。どこまで作るかを決めるのは、この対価をどこまで払うかを選ぶことです。
Nue が提供している AI受託開発 は、2週間という期間を先に固定しています。開始条件は1つだけで、解決したいことが1つ決まっていること。要件書は前提にしません。2週間で出すのは、動いて人に触ってもらえるものです。作り込んだ製品ではなく、確かめたい一点が動けば十分だと考えています。2週間で動くところまで行けるのは、実装の多くをAIコーディングが担っているからです。設計とレビューがどう変わるかはAIコーディングとは何かの記事に書きました。
範囲を先に決めてから期間を見積もる順序だと、範囲が膨らんだぶんだけ期間が延びます。期間を先に固定すると順序が逆になり、2週間に収まるように確かめたい一点を絞る力が働きます。確かめたいことが2つ以上あると、2週間では終わりません。
プロトタイプはそのまま MVP に育つのか
育たないこともあります。続けると決まった場合でも、Nue はプロトタイプを土台に進むとは限らず、作り直した方が早ければそう伝えています。検証のために割り切って作っているので、そのまま育てられないことがあるからです。
止める判断も成果として扱っています。2週間で止まるなら、それは成功です。企画書だけで半年進めて、作ってから気づく方が高くつきます。
合格条件は、作る前に決める
どこまで作るかの線は、何ができたら次に進むかが決まらないと引けません。合格条件が後出しになっている案件では、機能がいつまでも足され続けます。
対象、成功の定義、合格ライン、間違えたときの手順の4点を先に文章にする。この決め方は 生成AIのPoCが本番に行かない理由の記事にまとめました。ここでは繰り返しません。
作りすぎのサイン
- 確かめたい一点を1文で言えない。 2つ以上あるまま進んでいるなら、どちらも中途半端になります
- いま足そうとしている機能が動いても、続けるか止めるかの判断は変わらない。 Ries の定義に照らすと、学びが増えない部分は MVP の中身ではありません
- 何ができたら次に進むかが決まっていない。 基準がないので、いつまでも「もう少し」が続きます
- 捨てる前提のものに作り込みが入っている。 確かめたい一点が動けば十分な段階です
2つの語より先に決めること
作るものがまだ決まっていない段階では、プロトタイプと MVP のどちらの話をしても進みません。何を作るかを決める工程と、どこまで作るかを決める工程は別です。
Nue はサービスをこの境界で切り分けています。作るものが決まっていないなら プロダクト開発支援 の4週間、決まっているなら AI受託開発 の2週間。前者で何を作るかが決まってから、後者でどこまで作るかを決めます。
社内で語の定義が食い違っているなら、語を使うのを一度やめる手もあります。誰に見せるのか、何が言えたら次に進むのか、捨てる前提か育てる前提か。この3つが揃えば、プロトタイプと呼ぶか MVP と呼ぶかが決まらなくても、どこまで作るかは決まります。Kniberg の提案も、MVP という1語を手放して、どの段階かを名前で言い分ける形でした。