--- title: "MVP開発とは？進め方5ステップとPoC・プロトタイプの違い・範囲の決め方" url: "https://www.issoh.co.jp/column/details/7849/" published: 2025-07-24 updated: 2026-09-05 categories: ["Webシステム"] publisher: "株式会社一創" --- # MVP開発とは？進め方5ステップとPoC・プロトタイプの違い・範囲の決め方 MVP開発は、検証したい仮説に答えられる最小限の製品を先に出し、実際のユーザーの反応から次の投資判断を下す進め方です。「機能を削って安く作る」手法だと理解されがちですが、原典の定義が置いている重心は費用ではなく学びの量にあります。この記事では、定義を一次情報で確認したうえで、PoC・プロトタイプとの違い、検証内容から逆算する5つの型、進め方の5ステップ、そして実務でいちばん揉める「どこまでをMVPに入れるか」の決め方を整理します。 ## まとめ：MVP開発の要点 - **定義**：エリック・リースは2009年に、MVPを「顧客についての検証された学びを、最小の労力で最大限に集められる新製品の版」と定義しています。安く早く作ることは目的ではありません。 - **誤解**：同じ記事でリース自身が「MVPは名前に反して、最小限の製品を作ることではない」と書いています。マーティ・ケーガンは実験と製品の混同を、ヘンリック・クニバーグは品質を落とした版をそのまま出してしまうことを、それぞれ失敗形として指摘しています。 - **違い**：PoCは技術的に実現できるか、プロトタイプは体験が成立するか、MVPは顧客が価値を認めて使うかを問います。問いが違うので順番を誤ると手戻りが出ます。 - **型**：動画型・ランディングページ型・コンシェルジュ型・オズの魔法使い型・単機能プロダクト型の5つがあり、検証したい仮説によって作るものが変わります。Dropboxは動画、Zapposはオズの魔法使い型でした。 - **範囲**：MoSCoWのMust Haveは「必ず届ける最小限の使える部分集合（Minimum Usable SubseT）」です。Agile Business ConsortiumはMust Haveを工数の60%以内に抑え、Could Haveを20%程度の削り代として確保することを推奨しています。 - **失敗条件**：学びの設計がない試作、虚栄の指標での判断、固定スコープの請負契約、会計処理の後追いの4つが、MVP開発を止める典型的な要因です。 以下では、定義の原典から範囲の決め方まで順に見ていきます。 ## MVP開発の定義と「最小限の製品」という誤解 ### 原典は2009年のリースの定義 MVP（Minimum Viable Product）の定義として最も引用されるのは、エリック・リースが2009年8月3日にブログ「Startup Lessons Learned」で示した一文です。原文は「the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort」で、日本語にすれば「顧客についての検証された学びを、最小の労力で最大限に集められる新製品の版」となります。 この定義の主語は製品ではなく学びです。何を学びたいのかが決まっていなければ、どこまで削ってよいかも決まりません。MVP開発が「とりあえず小さく作る」で終わってしまう現場では、この順序が逆になっています。リーン・スタートアップ全体の考え方は[リーンスタートアップとは何か？不確実性に対応する新規事業立ち上げ手法の定義と基本概念をわかりやすく徹底解説](https://www.issoh.co.jp/column/details/9236/)で整理しています。 ### ケーガンとクニバーグが指摘する2つの失敗形 リースは同じ記事の中で「MVP, despite the name, is not about creating minimal products（MVPは、その名前に反して、最小限の製品を作ることではない）」とも書いています。それでも誤解が広がったため、後年に2つの角度から補足がなされました。 1つ目はマーティ・ケーガンによる整理です。2011年8月24日のSVPGの記事で、ケーガンはMVPを「valuable・usable・feasible の3条件を満たす最小の製品」と定義し、リースが広めた「仮説を検証するための最小の実験」については「MVPテスト」と呼び分けると述べています。実験を製品と混同しないための線引きです。実験のつもりで作ったものを製品として顧客に売ると、期待値の齟齬が起きます。 2つ目はヘンリック・クニバーグによる指摘です。2016年1月25日の記事で、クニバーグは「Minimum と Viable は人によって意味が違い、それが問題を起こす」と述べ、顧客からはMRC（Minimum Releasable Crap、出せる最低限のガラクタ）と受け取られる状況を挙げています。そのうえで、MVPという1語ではなく Earliest Testable Product（顧客が実際に何かできる最初の版）・Earliest Usable Product（アーリーアダプターが自発的に使う最初の版）・Earliest Lovable Product（顧客が気に入って人に薦め、対価を払ってもよいと思う最初の版）と段階を分けることを提案しました。社内で「MVPの品質基準」が揉めるときは、この3段階のどこを狙うのかを先に合意すると議論が収束します。 ### MVPという略語の4つの意味 MVPという略語は複数の分野で使われるため、社内の会話でも検索でも意味がすれ違います。混同しやすいのは次の4つです。 | 正式名 | 意味 | 使われる場面 | | -------------------------- | ------------- | ----------------- | | Minimum Viable Product | 実用最小限の製品 | 新規事業・プロダクト開発（本記事） | | Most Valuable Player | 最優秀選手 | スポーツ・社内表彰 | | Model-View-Presenter | 画面周りの設計パターン | アプリケーション設計 | | Most Valuable Professional | Microsoft MVP | 技術コミュニティへの貢献者表彰 | Model-View-Presenter はMVCやMVVMと並ぶ設計パターンで、製品開発手法のMVPとは無関係です。設計パターンとしてのMVPを調べている場合は[MVCとは？MVVM・MVPとの違いと使い分けを整理【2026年最新】](https://www.issoh.co.jp/tech/details/7040/)を参照してください。以降は Minimum Viable Product の意味で用います。 ## PoC・プロトタイプ・β版との違い ### 4手法が答える問いと成果物の対比 MVPが他の手法と混ざりやすいのは、どれも「本番前に小さく作る」点が共通しているからです。区別する軸は、作る大きさではなく答えたい問いです。 | 手法 | 答えたい問い | 主な成果物 | 判断すること | | --------- | ------------ | ---------- | ----------- | | PoC（概念実証） | 技術的に実現できるか | 検証コード・実験環境 | その方式で作れるか | | プロトタイプ | その体験は成立するか | 画面モック・試作 | 使い勝手と仕様の妥当性 | | MVP | 顧客は価値を認めて使うか | 使える最小限の製品 | 事業として続けるか | | β版 | 本番運用に耐えるか | 機能がほぼ揃った製品 | 正式リリースの可否 | PoCとプロトタイプは社内で完結しても成立しますが、MVPは外の顧客に届かないと結論が出ません。ここが最大の違いです。PoCの進め方は[PoCとは？意味・進め方・プロトタイプとの違いをわかりやすく解説](https://www.issoh.co.jp/column/details/5223/)、試作の作り分けは[プロトタイピングとは何か？概要や定義をわかりやすく解説](https://www.issoh.co.jp/column/details/6627/)で詳しく扱っています。 ### PoCとMVPの前後関係を誤ったときの2つの手戻り 1つ目は、技術的な不確実性が高いのにPoCを省いてMVPに進んだ場合です。顧客の反応を測るはずの検証が、性能や連携の不具合の切り分けに費やされ、仮説の答えが出ないまま期間を使い切ります。 2つ目は、逆に技術検証だけを繰り返して顧客に出さない場合です。実現できることは分かったが売れるかは分からない状態が続き、次の投資判断ができません。技術的な不確実性が低いテーマでは、PoCを省いてMVPから始めるほうが早く答えが出ます。どちらを先に置くかは、案件ごとに不確実性が大きいのは技術側か需要側かで決めます。 ## 検証したい仮説で決まるMVPの5つの型 ### 実装を伴わない3つの型 MVPは必ずしも動くソフトウェアである必要がありません。需要そのものを確かめたい段階では、実装のない型のほうが速く安く答えが出ます。 | 型 | 作るもの | 検証できること | 限界 | | ---------- | ------------ | ----------- | ----------- | | 動画型 | 使い方を見せる紹介動画 | コンセプトへの関心 | 継続利用は分からない | | ランディングページ型 | 説明ページと申込フォーム | 登録・事前予約の転換率 | 支払い意思は不確か | | コンシェルジュ型 | 人手で提供するサービス | 提供価値と業務の勘所 | 顧客ごとに対応が変わる | 動画型の代表例がDropboxです。エリック・リースが2011年10月19日にTechCrunchへ寄稿した記事によると、創業者のドリュー・ヒューストンが作った3分程度のデモ動画は24時間で1万件を超えるDiggを集め、ヒューストン自身の言葉として「ベータ版の待機リストは、文字どおり一晩で5,000人から75,000人になった」と紹介されています。製品はまだ完成していない段階でした。 コンシェルジュ型は、後で自動化する処理を最初は担当者が手作業で回す型です。業務システムやBtoBサービスでは、初期の数社を人手で支援しながら要件の勘所を掴めるため、そのまま要件定義の材料になります。 ### 実装を伴う2つの型 需要の確度が上がってきたら、実際に動くものを作る型へ移ります。この2つは検証の精度が上がる代わりに、作り始める前の準備が必要になります。 | 型 | 作るもの | 検証できること | 限界 | | --------- | -------------- | ----------- | ----------- | | オズの魔法使い型 | 自動に見えて裏は人手の仕組み | 需要と運用フローの成立 | 人手のため件数に上限 | | 単機能プロダクト型 | 中核機能だけの製品 | 継続利用・課金・定着 | 作るための投資が大きい | オズの魔法使い型の例としてよく挙げられるのが、リースが『リーン・スタートアップ』で紹介したザッポスの立ち上げです。創業者のニック・スウィンマーンは在庫を持たず、近隣の靴店で撮影した商品写真をサイトに掲載し、注文が入るたびに店舗で購入して発送していました。顧客から見れば通常のECサイトですが、裏側は手作業です。これで「試着せずに靴をオンラインで買う人がいるか」という需要側の仮説に答えを出しました。 単機能プロダクト型は、動画型からオズの魔法使い型までの4つで需要の確度が上がった後に選ぶ型です。ここで初めて本格的な実装に入るため、後述する範囲の決め方が効いてきます。 ## MVP開発の進め方5ステップ MVP開発は、作る前に2つ、作った後に1つの意思決定が入る点が通常の開発と違います。全体像は次の5段階です。 | STEP | やること | 残す成果物 | | ---- | -------------- | ---------- | | 1 | 検証する仮説を1つに絞る | 仮説の記述 | | 2 | 継続・中止の判断基準を決める | 合格水準と指標 | | 3 | 型を選び範囲を切って作る | MVPと対象外の一覧 | | 4 | 実際の利用者に届けて計測する | 利用データ | | 5 | 継続・方向転換・中止を決める | 判断の記録 | ### STEP1からSTEP2：仮説と判断基準の先出し STEP1は、検証したい仮説を1つに絞る作業です。「誰の」「どんな状況の」「どの課題を」「どう解決すると」「どうなるはず」という形で言語化し、外れたら事業の前提が崩れる仮説を先頭に置きます。複数の仮説を1回のMVPで同時に検証しようとすると、結果が出ても原因を特定できません。 STEP2は、MVPを作り始める前に判断基準を決める作業です。「登録した人の何割が2週目も使えば続行」といった水準を、関係者の合意を取って先に書いておきます。作った後に基準を決めると、出た数字に合わせて解釈が動き、中止の判断ができなくなります。 ### STEP3からSTEP5：構築・計測・意思決定のサイクル STEP3は、決めた仮説に答えられる最小の形を選んで作る作業です。型の選択と範囲の切り方がここに当たります。STEP4は実際の利用者に届けて計測する作業で、社内の関係者だけの評価は検証になりません。 STEP5は、STEP2で決めた基準に照らして、継続・方向転換・中止のいずれかを決める作業です。判断の材料と結論を記録に残しておくと、次のMVPで同じ検証を繰り返さずに済みます。反復の進め方や要件の扱いは[アジャイル開発の要件定義とは？進め方の5ステップとウォーターフォールとの違い](https://www.issoh.co.jp/column/details/16313/)と合わせて設計すると、開発チーム側の運用に落とし込めます。 ## MVPの範囲の決め方とMoSCoWの60%ルール ### Must Have＝Minimum Usable SubseT MVPの範囲で揉めるのは、優先順位を「重要度」で議論してしまうためです。重要でない機能を挙げる人はいないので、全部がMust Haveになります。これを避ける実務的な道具がMoSCoWによる優先順位付けです。 MoSCoWは Must Have・Should Have・Could Have・Won’t Have this time の4分類です。DSDMを策定するAgile Business Consortiumは、Must Haveを「プロジェクトが必ず提供することを保証する、最小限の使える部分集合（Minimum Usable SubseT、MUST）」と定義しています。判定の基準は「それが無ければプロジェクト自体を中止するか」であり、この問いに「中止しない」と答えられるものはMust Haveではありません。MVPの範囲とは、この最小限の使える部分集合そのものです。 ### Must Have 60%以内・Could Have 20%の工数配分 分類しただけでは範囲は決まりません。同コンソーシアムは、分類ごとの工数の割合にも目安を置いています。 | 分類 | 意味 | 工数の目安 | | -------------------- | ------------ | ----- | | Must Have | 無ければ中止する要件 | 60%以内 | | Should Have | 重要だが回避策がある要件 | 明示なし | | Could Have | あれば望ましい要件 | 20%程度 | | Won’t Have this time | 今回は対象外の要件 | 対象外 | Agile Business Consortiumは、Must Haveは工数の60%を超えないこと、Could Haveは20%程度を確保することを推奨しています。Could Haveは「余裕があればやること」ではなく、遅延が起きたときに削る余白としてあらかじめ積んでおくものです。Must Haveが8割を占める計画は、遅れた瞬間に削る先が無く、期限か品質のどちらかが崩れやすくなります。 ### 「今回はやらない」の明文化 4分類のうち実務で効くのが Won’t Have this time です。対象外を書き残さないと、同じ要望が検証のたびに再浮上し、そのつど議論をやり直すことになります。除外した理由と、どの条件が満たされたら再検討するかを併記しておくと、次の反復での判断が速くなります。 ## MVP開発が失敗する4つの条件 ### 学びの設計がない「安い試作」への転落 最も多いのが、検証したい仮説と判断基準が無いまま小さく作るケースです。リースの定義が学びを主語に置いていたことを思い出すと、学びの設計が無いMVPは定義上MVPではありません。クニバーグの言うMRCは、この状態で顧客に届いたときに起こります。 ### 虚栄の指標での判断 累計登録数や総ページビューのように、増えることはあっても減らない指標だけを見ると、仮説が支持されたかどうかを判断できません。リースが虚栄の指標（vanity metrics）と呼ぶのがこの種の数値です。継続率・転換率・単位あたりの収支のように、母数で割った比率や実際の支払いに近い指標を、STEP2の段階で選んでおきます。 ### システム開発の請負契約との相性 受託でMVPを進める場合、契約形態が障害になることがあります。検証の結果として範囲が変わるのがMVPの前提である一方、民法632条の請負は仕事の完成を目的とするため、範囲と金額を先に固定する形になじむからです。仮説検証の段階は同法656条の準委任として期間と体制を決め、範囲が確定してから請負に切り替える形にすると、変更のたびに契約変更を挟む状態を避けられます。 ### 会計処理の後追い 自社で開発する場合、MVPにかけた費用を研究開発費として費用処理するのか、ソフトウェアとして資産計上するのかで、単年度の損益への影響が変わります。研究開発費等に係る会計基準では、自社利用のソフトウェアについて、将来の収益獲得または費用削減が確実と認められる場合に資産計上するとされています。検証段階と本開発段階の境目を記録に残しておく必要があるのはこのためです。詳しくは[経理担当者が押さえるべき自社開発ソフトウェア資産計上の会計基準と判定条件](https://www.issoh.co.jp/column/details/11038/)で解説しています。 ## よくある質問 ### MVPは何の略ですか？ 製品開発の文脈では Minimum Viable Product（実用最小限の製品）の略です。スポーツの Most Valuable Player、設計パターンの Model-View-Presenter、マイクロソフトの表彰制度である Microsoft MVP も同じ略語のため、文脈で区別してください。 ### MVPとPoCの違いは何ですか？ 答えたい問いが違います。PoCは「技術的に実現できるか」を社内で確かめる検証で、MVPは「顧客が価値を認めて使うか」を実際の利用者に問う版です。PoCが成功しても需要があるとは限らず、MVPが成功しても大規模運用に耐えるとは限りません。 ### MVP開発の期間はどれくらいが目安ですか？ 期間は機能の量ではなく、絞った仮説に答えが出るまでの長さで決まります。動画型やランディングページ型なら数日から数週間、単機能プロダクト型なら数か月かかることもあります。見積りを受け取ったときは、金額の水準よりも「どの仮説にいつ答えが出るか」が書かれているかを確認してください。 ### MVP開発の費用はどのように決まりますか？ 費用は機能数ではなく、選んだ型と、仮説に答えが出るまでの体制と期間の掛け算で決まります。同じ「MVP開発」でも、ランディングページ型と単機能プロダクト型では必要な工数の桁が変わるため、公開されている相場をそのまま自社に当てはめても意味がありません。相見積りを比べるときは、金額よりも前提として置かれた型・検証範囲・Must Haveの内訳が揃っているかを見てください。 ### MVP開発とアジャイル開発はどう関係しますか？ MVPは何を作るかを決める考え方、アジャイル開発はどう作るかの進め方です。MVPで絞った範囲を短い反復で作り、計測結果を次の反復に戻す形で組み合わせます。アジャイル開発を採用していても、仮説と判断基準が無ければMVPにはなりません。 ### MVPキャンバスとは何ですか？ 仮説・検証の目的・検証方法・必要なデータ・合格基準などを1枚のシートに整理するフレームワークです。ビジネスモデルキャンバスと同じく記入欄を埋める形式ですが、項目の数や名称は提供元によって異なり、標準化された1つの版があるわけではありません。社内で使う場合は、STEP1とSTEP2で決める内容が全て欄に含まれているかを基準に、1つの様式へ固定して運用するのが実務的です。 ## 関連記事 - [PoCとは？意味・進め方・プロトタイプとの違いをわかりやすく解説](https://www.issoh.co.jp/column/details/5223/) - [プロトタイピングとは何か？概要や定義をわかりやすく解説](https://www.issoh.co.jp/column/details/6627/) - [リーンスタートアップとは何か？不確実性に対応する新規事業立ち上げ手法の定義と基本概念をわかりやすく徹底解説](https://www.issoh.co.jp/column/details/9236/) - [アジャイル開発の要件定義とは？進め方の5ステップとウォーターフォールとの違い](https://www.issoh.co.jp/column/details/16313/) - [MVCとは？MVVM・MVPとの違いと使い分けを整理【2026年最新】](https://www.issoh.co.jp/tech/details/7040/) --- 出典: [MVP開発とは？進め方5ステップとPoC・プロトタイプの違い・範囲の決め方]()（株式会社一創）