MVP開発とは｜進め方5ステップと、プロトタイプ・PoCとの違い

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

① MVPとは

MVPの定義をすでにご存じの方は、② プロトタイプ・PoCとの違いから読み進められます。

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

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

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

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

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

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

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

MVP開発とは

MVP開発とは、確かめたい仮説を先に決めて、それを確かめるのに必要な機能だけを作って市場に出す開発の進め方です。作るものを小さくするのが目的ではなく、答えを早く受け取るために範囲を絞るのが目的になります。

「小さく作る」と「小さく確かめる」は別です。機能を削っただけで、確かめたいことが決まっていないMVPは、出しても何も分かりません。

MVP開発と通常のソフトウェア開発の違い

	出発点	完成の条件	出したあと
通常の開発	決まった要件	要件を満たしたら完成	運用と保守に入る
MVP開発	確かめたい仮説	仮説の答えが取れたら役目が終わる	作り直すことも、捨てることもある

この違いは、契約と評価にそのまま出ます。完成の定義が「要件を満たすこと」だと、答えが取れたのに作り続けることになります。何が分かったら終わりかを、着手前に文章にしてください。

MVP開発とアジャイル開発の違い

アジャイル開発は作り方（短い周期で作って直す進め方）、MVPは何を作るか（確かめるための最小の範囲）の話です。層が違うので、対立しません。

実務では組み合わせます。MVPで範囲を決め、アジャイル（スクラムなど）で回す形です。ただしアジャイルで回しているだけでは、範囲は絞られません。「今回のスプリントで何を確かめるのか」が無いと、短い周期で機能が増え続けることになります。

リーンスタートアップ・PMFとの関係

• リーンスタートアップ — 「作る → 測る → 学ぶ」を速く回す考え方。MVPはこの輪の入口の道具
• PMF（プロダクトマーケットフィット） — 製品が市場に噛み合った状態。MVPはPMFに近づけているかを測るための一手
• アジャイル開発 — 作り方の側の話。MVPで決めた範囲を回す

MVPを出すこと自体はゴールではありません。出した結果で「進む・変える・やめる」のどれかを決めるところまでが1周です。決めないまま次の機能に進むと、輪が回らずに、ただ機能が増えていきます。

MVP開発の目的

• 失敗のコストを下げる — 間違いが数か月分ではなく数週間分で済む
• 本物の反応を得る — 「買いたい」ではなく、実際の申込と支払いで確かめる
• 作る量を減らす — 使われる機能だけが残る
• 社内の議論を数字にする — 「売れると思う」を事実に置き換える
• 早く収益の入口を作る — 完成を待たずに提供を始められる

どれを主目的にするかで、作る範囲が変わります。反応を得ることが目的なら機能は最小で足りますが、収益の入口まで作るなら決済と請求が要ります。目的を1つに絞ってから、範囲を決めてください。

MVP開発のメリット1｜失敗したときの損失が小さい

作り込む前に市場の答えを聞くため、外れたときに捨てるものが少なくて済みます。

効くのは金額より時間です。半年かけて外すのと、3週間で外すのとでは、次の仮説を試せる回数が変わります。

メリット2｜作る量が減り、開発が効率化する

想像で足した機能を作らずに済みます。使われなかった機能は、保守の対象としても残り続けません。

減るのは初期の開発だけではありません。機能が少ないほど、後の改修と検証にかかる時間も小さくなります。

メリット3｜市場に出るのが早くなる

完成を待たずに提供を始められるため、先に顧客との関係を作れます。

早さが効くのは、競合がいる領域だけではありません。まだ誰もやっていない領域ほど、「本当に欲しい人がいるのか」を早く知る価値が大きくなります。

メリット4｜ユーザーの反応をもとに優先順位を決められる

実際に使われた機能と、使われなかった機能が分かります。次に作るものを、社内の声ではなく利用の記録で決められます。

そのためには、記録を取る仕組みを最初から入れてください。反応が取れないMVPは、出しても判断材料になりません。

MVP開発のデメリット1｜作りが粗いと、反応を読み違える

確かめたいのは「価値があるか」なのに、使いにくさが理由で離脱されると、価値の有無が判定できません。

削ってよいのは機能の数で、削ってはいけないのは「その機能が成立する水準」です。申し込みができないほど分かりにくい画面では、申し込まれなかった理由を特定できません。

デメリット2｜集まった意見の扱い方を誤ると、迷走する

MVPを出すと、要望が集まります。全部を反映すると、誰のためのものか分からない製品になります。

反映するかどうかは、「最初に決めた仮説に関係するか」で判断してください。関係しない要望は、記録だけして持ち越します。

デメリット3｜検証に費用と手間がかかりすぎることがある

確かめる相手を集める、動かす、記録する。この工程は、作る工程とは別に費用がかかります。

作る費用だけを見積もると、ここで足が出ます。検証にかかる期間と人の時間も、最初から見込んでください。

MVP開発が向いているケース・向いていないケース

	状況
向いている	顧客がいるかどうかが分かっていない／使われ方が読めない／作る前に確かめたいことが1文で書ける
向いていない	要件が確定していて、確かめることが残っていない／安全や法令の要件で、最小構成では出せない領域／既存業務の置き換えで、途中の状態では業務が回らない

向いていない場面で無理にMVPにすると、「出せないものを小さく作った」だけになります。確かめることが残っていないなら、普通に作るほうが速く終わります。

MVP開発の進め方（5ステップ）

	やること	終わったと言える状態
1. 仮説を立てる	誰の、どの困りごとを、どう解くと売れるのか	仮説が1文で書けている
2. 必要最低限の機能を決める	仮説の検証に要る機能だけを選ぶ	外した機能と、外した理由が残っている
3. 作る	短い期間で形にする	実際の顧客に出せる状態
4. 出して、確かめる	使ってもらい、記録する	仮説が支持されたか棄却されたかが言える
5. 評価して、決める	進む・変える・やめるを判断する	次に確かめることが決まっている

4で取る指標を、3の前に決めてください。出してから「何を見れば良かったのか」を考え始めると、必要な記録が残っていない状態になります。

検証したい仮説を、1文にする

「◯◯な人は、△△のために、□□にお金を払う」の形で書きます。主語がぼやけていたら、まだ絞れていません。

1文にできない仮説は、MVPでも確かめられません。書けないときは、確かめたいことが複数混ざっています。いちばん外れたら困るものを1つ選んでください。

機能の選び方（価値とコストで分ける）

候補の機能を、仮説の検証への効き方と作る手間の2軸で並べます。

	作る手間 小	作る手間 大
検証に効く	最初に作る	削れないか工夫する（手作業で代替できないか）
検証に効かない	後回し	作らない

右上の枠がいちばん重要です。検証に効くけれど作るのが大変な機能は、裏側を人手で回して、表からは動いているように見せることで確かめられる場合があります。

MVPキャンバスで、作る前に埋めておく

MVPキャンバスは、作る前に決めておく項目を1枚にまとめる道具です。おおむね次のようなことを埋めます。

• 提案（何を届けるか）と、対象の顧客
• 検証する仮説と、確かめ方
• 成功と判断する基準（何がどれだけあれば進むか）
• 作る範囲と、作らないもの
• 期間、体制、必要な費用の目安
• 得られた結果をどう使うか

「成功と判断する基準」を空欄のまま始めないでください。基準が無いと、出た結果に合わせて基準のほうが後から動きます。

費用と期間の考え方

MVP開発の費用は、機能の数より「どこまでを本物として作るか」の粒度で決まります。

粒度	中身	向いている検証
紙・画面イメージのみ	動かない。見せて反応を聞く	欲しいと思うかどうか
一部を人手で回す	表は製品、裏は手作業	使い続けるかどうか
動くものを限定公開	実際に動作し、記録も取る	お金を払うかどうか

上から順に試すと、費用を抑えられます。いきなり3段目から始めると、1段目で分かったはずのことに費用をかけることになります。

外注する場合に、先に用意しておくもの

• 検証したい仮説（1文） — これが無いと、範囲を決められない
• 成功と判断する基準 — 検収の条件にもなる
• 作らないものの一覧 — 後から増えるのを防ぐ
• 出したあとの体制 — 誰が反応を見て、誰が次を決めるか

4つ目が抜けていると、納品されたあとに止まります。MVPは出してからが本番なので、受け取る側に判断できる人がいることが条件になります。

MVP開発でよくある失敗のしかた

失敗の型	何が起きるか	手前で防ぐ方法
確かめることを決めずに作る	出しても何も分からない	仮説を1文にする
機能を足し続ける	最小でなくなり、出るのが遅れる	作らないものを先に書く
社内だけで見せて終える	市場の答えを聞かないまま「検証した」ことになる	実際の顧客に出す
基準を決めずに評価する	結果に合わせて基準が動く	キャンバスの基準欄を埋める
やめる判断をしない	外れた仮説のまま作り続ける	撤退の線を先に決める

5つとも、作る前に防げます。MVP開発で難しいのは作ることではなく、作る前に決めておくことのほうです。

MVP開発についてよくある質問（基本編）

Q. MVP開発とは何ですか。
確かめたい仮説を先に決めて、それを確かめるのに必要な機能だけを作って市場に出す進め方です。通常の開発が「要件を満たしたら完成」なのに対し、MVP開発は「仮説の答えが取れたら役目が終わる」点が違います。

Q. MVP開発とアジャイル開発は何が違いますか。
アジャイルは作り方、MVPは何を作るかの話で、層が違います。実務では組み合わせますが、アジャイルで回しているだけでは範囲は絞られません。

Q. MVP開発の進め方を教えてください。
仮説の立案 → 必要最低限の機能の策定 → 作る → 出して確かめる → 評価して決める、の5段です。確かめるときに見る指標は、作り始める前に決めておいてください。

Q. MVP開発の費用は、何で決まりますか。
機能の数より、どこまでを本物として作るかの粒度で決まります。見せるだけ・裏を人手で回す・動くものを限定公開、の順に上げていくと費用を抑えながら確かめられます。あわせて、作る費用とは別に検証にかかる期間と人の時間を見込んでください。

Q. MVP開発が向いていないのは、どんなときですか。
要件が確定していて確かめることが残っていない場合、安全や法令の要件で最小構成では出せない領域、既存業務の置き換えで、途中の状態では業務が回らない場合です。

ここまでが、MVP開発の全体像です。目的、進め方、範囲の決め方、費用の考え方、そして詰まりやすい場所。

ここから先は、この言葉を現場で使うときの線引きの話をします。最初に扱うのは、よく並べて語られる3つの言葉との違いです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• PoC（実証実験） — 技術の不確かさを先に潰す段階。実証実験では出ない0.1%が、本番で最後に残る
• MVP検証の回し方 — 4週間の輪で学習を積む実務。完成度より学習の輪
• PMF — MVPの先で目指す状態。100回死んだのは0→1ではなかった
• 立ち上げの順番 — どこから作るかの議論。受けたものが現場の作業になる出口から作る

よくある質問

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支援）をご覧ください。