MVPとは|実用最小限の製品。2人の提唱者で定義が違う

mvp-towa 図解

ビジネスの会議で「まずMVPを作りましょう」と言われて、野球の表彰を思い浮かべた人は、実は少なくありません。同じ3文字ですが、別の言葉です。スポーツのMVPはMost Valuable Player(最優秀選手)、ビジネスのMVPはMinimum Viable Product。この記事は後者、新規事業やプロダクト開発で使うMVPの話をしていこうと思います。

① MVPとは

MVP(Minimum Viable Product)とは、仮説を確かめるために必要な最小限の機能だけを備えた製品のことです。日本語では実用最小限の製品と訳されます。完成品を作り込む前に、小さく作って市場に出し、本当に使われるか・売れるかを確かめるための道具です。

なぜこの考え方が求められるかというと、新しい製品の失敗の多くが「作り込んでから、要らなかったと分かる」形で起きるからです。時間とお金を使い切ったあとに市場の答えを聞くのではなく、答えを先に聞くために出す最初の一手がMVPです。

得られるものは4つに整理できます。

  1. 失敗のコストが下がる。間違いが数か月分ではなく数週間分で済む。
  2. 本物の答えが手に入る。アンケートの「買いたい」ではなく、実際の申込と支払いで確かめられる。
  3. 作る物が減る。使われる機能だけが残り、想像で足した機能を作らずに済む。
  4. 社内の議論が数字になる。「売れると思う」の水掛け論が、仮申込10件という事実に変わる。

覚え方として、豆知識をひとつ。MVPという言葉は2001年、米国のコンサルタントであるフランク・ロビンソンが提唱しました。その10年後の2011年、エリック・リースが著書『リーン・スタートアップ』で広めて、世界の共通語になります。面白いのは、2人の定義が微妙に違うことです。

人物定義の中心MVPは何のためのもの
ロビンソン(2001年・提唱)「リスクあたりのリターンを最大化する」製品。採用と満足と販売を起こす、売り物としての最小。
リース(2011年・普及)「検証による学習」を最大化する製品。顧客について最小の労力で最大に学ぶための、実験としての最小。

売り物の最小か、実験の最小か。実は、現場でMVPの議論が噛み合わないときは、たいていこの2つの定義が混ざっています。どちらの意味で使っているかを先に揃えるだけで、MVPの範囲の議論は一気に短くなります。

② プロトタイプ・PoCとの違い

似た言葉との違いは、「誰に届けて、何を確かめるか」で線を引くと一度で覚えられます。

用語誰に届けるか確かめること
プロトタイプ(試作品)社内・関係者。形にするとどうなるか。操作感や見た目。
PoC(実証実験)社内・限定環境。技術的に本当に動くか。
MVP実際の市場・実際の顧客。使われるか。お金を払うか。
製品版市場全体。事業として回るか。

ここで大事なのは、MVPだけが実際の顧客に届くという点です。これが決定的な違いです。社内で見せるだけの試作をMVPと呼ぶと、市場の答えを聞かないまま「検証した」ことになってしまいます。

順路としては、机上の調査で埋められる不確かさを先に潰し、技術の不確かさを実証実験で潰し、市場の不確かさをMVPで潰します。実証実験の実録は実証実験では出ない0.1%の話に、MVPを4週間で回す実録はMVP検証の話に書いてあります。

③ MVPの7つの型と、古典になった2つの実例

mvp-towa 図解

MVPは「小さい製品」とは限りません。確かめたい仮説に合わせて、作らない選択肢まで含めた型があります。開発量とかかる期間の目安まで含めて7つ並べます。

中身向いている仮説開発量・期間の目安
LP型紹介ページと申込ボタンだけを作る。そもそも欲しい人がいるか。ほぼゼロ。数日。
動画型動くデモの映像だけを作って公開する。説明を見て欲しくなるか。ゼロ。数日。
プレオーダー型先行予約や前払いを受け付ける。実際にお金を払うか。ほぼゼロ。数日〜数週間。
コンシェルジュ型裏側を全部人力でやり、サービスとして提供する。お金を払う価値があるか。ゼロ。運用の人手のみ。
オズの魔法使い型表は自動に見せ、裏は人が処理する。自動化する価値があるか。画面のみ。数週間。
ノーコード型既製ツールの組み合わせで動くものを出す。業務として回るか。少。数日〜数週間。
単機能型中核の1機能だけを実装して出す。その機能だけで使い続けられるか。中。数週間〜。

一方で、上の4つはほとんど開発をしません。MVPの本質が「作ること」ではなく「確かめること」にある証拠です。

古典になった実例が2つあります。1つ目はオズの魔法使い型の元祖、靴のECのZappos(ザッポス)です。創業者は1999年、在庫を1足も持たずに、近所の靴屋で撮った写真をサイトに並べました。注文が入ったら店で買って発送する。物流もシステムも作る前に、「靴をネットで買う人がいるか」だけを確かめたわけです。2つ目は動画型のDropbox(ドロップボックス)。製品が完成する前に約4分(当初は3分版)のデモ動画を公開したところ、ベータ版の待機リストが一晩で5,000人から75,000人に跳ねました。コードを1行も追加せずに、需要の存在が証明されたことになります。

型の選び方は、機能からではなく仮説から逆算します。

いちばん危ない仮説選ぶ型
欲しい人がいるか分からない。LP型・動画型。
欲しがるが、払うかは分からない。プレオーダー型・コンシェルジュ型。
払うが、仕組みで回るかは分からない。オズの魔法使い型・ノーコード型。
回るが、使い続けるかは分からない。単機能型。

④ 現場に置き換える|造園会社の定期便で考える

mvp-towa 図解

定義だけでは使えるようにならないので、架空の場面に置き換えます。地方の造園会社が、個人宅向けに「庭の剪定の定期便」を始めるか迷っているとします。

完成形を想像すると、予約アプリ、担当者のスケジュール管理、決済、写真での報告機能、と作る物が並びます。ところが、いちばん危ない仮説は「毎年頼むほどの需要が、この地域にあるか」です。これを確かめるMVPは、アプリではありません。紹介ページ1枚と電話番号、つまりLP型で足ります。チラシを300枚配って、仮申込が10件入るかを見る。入らなければ、アプリを作る前に仮説のほうを直します。

このように、MVPの設計は「何を作るか」ではなく「どの仮説がいちばん危ないか」から逆算します。作る物の一覧から考え始めたら、それはMVPではなく、小さめの完成品です。

⑤ 欠陥と潮流|Minimumだけ読まれて、Viableが落ちる

MVPという言葉には、使われ方の欠陥があります。Minimum(最小)だけが読まれて、Viable(実用に耐える)が落ちるのです。未完成品を出す言い訳にMVPが使われると、顧客には「雑な製品」しか残らず、学びも信頼も得られません。実用に耐える線を守った上での最小、という順番が本来の意味です。

ただ、欠陥はもうひとつあります。学習の設計がないMVPです。何が起きたら仮説が正しくて、何が起きたら間違いなのかを先に決めずに出すと、結果の数字をどうとでも解釈できてしまいます。確かめる条件を先に1行書いてから出す。この規律はフレームワーク全般と同じで、失敗の検出器としてフレームワークを選び直す話に詳しく書きました。

潮流の話もしておきます。生成AIの支援で、動くものを作るコストは急落しました。かつて数か月かかったMVPが、数週間、場合によっては数日で形になります。すると、MVPの価値の置き場所が変わります。作ること自体は誰でも速くなったので、差が出るのは「どの仮説を、どの順番で確かめるか」の設計側です。作れる時代のMVP論は、入口からではなく出口から作る話で掘り下げています。

⑥ 実例|MVPが商用受注まで育った

mvp-towa 図解

自社プロダクトohbag(オーバッグ)の実例です。訪日客がホテルから荷物を預けて送れるサービスで、大企業との共創事業としてMVPから始めました。

ただし、MVPといっても、決済も配送も本物です。デモ画面ではなく、実際にお金が動き、実際に荷物が届く最小構成から出発しました。市場に届けない試作では、「預けたい人がいるか」「ホテルの現場が回せるか」という危ない仮説を確かめられないからです。

開発の記録は数字で残っています。2026年5月から7月までに2,126コミット、モバイルアプリは約10.5万行、自動テストは174本。そして検証を続けたまま、2026年7月に初回の商用受注に至りました。MVPが検証で終わらず、そのまま事業に育った形です。作るコストが下がった時代のMVPは、検証の器と本番の器を分けなくてよくなりつつある、というのが現場からの実感です。

⑦ 一緒に覚えておきたい概念

mvp-towa 図解

MVPは、確かめる工程の最後の一段です。前後の概念とセットで覚えると、順路として使えます。

よくある質問

Q. MVPとは何の略ですか? A. ビジネスの文脈ではMinimum Viable Product(実用最小限の製品)の略です。仮説を確かめるために必要な最小限の機能だけを備えて、実際の市場に出す製品を指します。スポーツの表彰で使うMVP(Most Valuable Player)とは別の言葉です。

Q. プロトタイプとの違いは何ですか? A. 届ける相手が違います。プロトタイプは社内や関係者に見せて操作感や形を確かめる試作品で、MVPは実際の顧客に届けて「使われるか・お金を払うか」を確かめる製品です。市場に届くかどうかが線になります。

Q. MVPはどのくらいの期間で作るべきですか? A. 確かめたい仮説によります。LP型なら数日、単機能型でも数週間が目安です。生成AIの支援で開発のコストは下がっているので、期間よりも「何が起きたら仮説が正しいと言えるか」を先に決めることのほうが重要になっています。

Q. MVPで失敗する典型的なパターンは何ですか? A. 2つあります。Minimumだけを読んで実用に耐えない未完成品を出すことと、学習の設計をせずに出して結果をどうとでも解釈してしまうことです。実用の線を守った最小と、確かめる条件の1行を先に書くことが対策です。

Q. MVPとPoC(実証実験)の違いは何ですか? A. 届ける相手が違います。PoCは社内や限定環境で「技術的に動くか」を確かめる工程で、MVPは実際の市場に出して「使われるか・売れるか」を確かめる製品です。順番としてはPoCで技術の不確かさを潰してから、MVPで市場の不確かさを潰します。

Q. MVPの有名な事例にはどんなものがありますか? A. 靴のECのZapposは、在庫を持たずに店の靴の写真だけを載せ、注文が入ってから店で買って発送する形で需要を確かめました。Dropboxは製品完成前のデモ動画だけで、ベータ版の待機リストが一晩で5,000人から75,000人に増えています。どちらも「作る前に確かめた」古典です。

Q. リーンスタートアップとMVPの関係は? A. リーンスタートアップは、構築・計測・学習の輪を速く回して事業を育てる方法論の全体で、MVPはその輪の起点になる道具です。2011年のエリック・リースの著書がこの2つをセットで広めました。

Q. MVPの次は何をすればよいですか? A. 検証で得た学びをもとに、構築・計測・学習の輪を回し続け、市場に噛み合った状態(PMF)を目指します。MVPは作って終わりではなく、学習の起点です。

この記事を書いた会社について

アルチェコ(ARCHECO)は、UXデザイン・AI開発・新規事業開発を組み合わせた事業共創スタジオです。実例に出てきたohbagは、大企業との共創事業としてMVPから商用受注まで実際に育てたプロダクトで、この記事の数字はその開発記録から取っています。MVP・PoCの設計からの伴走は、新規事業コンサルティング(MVP・PoC支援)をご覧ください。

You May Also Like

AI機能を“足す”ほどプロダクトは使われなくなる ― 機能の数と価値は比例しない

競合に追いつこうとAI機能を足したのに、なぜかプロダクトが使われなくなる――その逆説を、実家のテレビのリモコンの話から、足し算ではなく引き算のAIプロダクト開発まで、ゆるっと書きました。AI機能の数と、プロダクトの価値は比例しないのです。
View Post

要件定義の書き方|正常系と異常系のあいだで静かに壊れる

要件定義書とは、何を作るかを発注側と開発側で合意する文書です。経費精算システムの刷新を題材に、教科書どおりに要件を書いて、動かして、数字が合わない日が来るまでを順に追います。抜けていたのは、正常系でも明示的な異常系でもなく、その「あいだ」でした。エラーが飛ばないので監視でも見つかりません。書き漏らしがどう現れるか、そして機能一覧の代わりに何を3列で書けばいいかを、そのまま使える表で置きます。
View Post

店舗DXの進め方|アプリを入れても、誰も触らなかった理由

店舗DXとは、店舗の業務や購買体験をデジタルで作り変える取り組みです。アパレル店舗に試着予約アプリを入れて、まったく使われなかったところから話を始めます。原因は機能ではなく、置いた場所の隣に店員が立っていたことでした。顧客が迷っている時間に伴走する設計へ切り替えると、同じ機能が動き出します。売場で何分迷っているかを測るところから、そのまま使えるチェックシートまで置きます。
View Post