MVP開発とは？
MVPは Minimum Viable Product の略で、「実用最小限の製品」と訳されます。新しい製品について、顧客からの学びを最小の労力で最大限に得るための最初の版です。エリック・リースが著書『リーン・スタートアップ』で広めました。
目的は仮説を確かめることです。「利用者はこの問題に困っているはずだ」「この機能ならお金を払うはずだ」という仮説を、作り込む前に確かめます。当たっていれば作り込み、外れていれば方向を変えます。
MVP開発は、次の「作る→測る→学ぶ」の繰り返しの最初の一歩です。
- 1
仮説を立てる
誰の、どんな問題を、どう解くと価値があるか
- 2
作る
仮説を確かめられる最小の形を作る
- 3
測る
利用者の反応や数字を集める
- 4
学ぶ
続けるか、方向を変える（ピボット）かを決める
学ぶのあと、仮説を立てるに戻って繰り返す
1周を短くするほど、少ない費用で多くを学べます。
MVPはどう作る？（5つの手順）
作り方は、次の5つの手順で考えると迷いません（当サイトの整理）。
- 1
1. 仮説を書き出す
誰の、どんな問題を、どう解くと、何が起きるか
- 2
2. 一番危ない仮説を選ぶ
外れたら全部が無駄になる仮説から確かめる
- 3
3. 成功の基準を決める
「何がいくつなら続けるか」を作る前に数字で決める
- 4
4. 最小の型を選ぶ
その仮説を一番安く・早く確かめられる形にする
- 5
5. 測って判断する
続ける・方向を変える・やめるを基準に照らして決める
手順3を飛ばすと、どんな結果も都合よく解釈できてしまいます。
MVP開発の例は？
共働き家庭向けに、夕食の献立と食材を届けるサービスを考えている場合で、5つの手順を当てはめてみます。
| 手順 | この例での中身 |
|---|---|
| 1. 仮説 | 共働き家庭は献立を考える手間に困っており、月額でお金を払う |
| 2. 一番危ない仮説 | 「お金を払う」かどうか（困っていても、払うとは限らない） |
| 3. 成功の基準 | 2週間で説明ページから50世帯が申し込み、その20%（10世帯）が有料の初回注文をする |
| 4. 型 | 説明ページ＋手作業の代行。献立はスタッフが手で作り、食材は近くの店から届ける |
| 5. 判断 | 基準を超えたら注文の仕組みを開発する。下回ったら申し込んだ人に理由を聞き、方向を見直す |
この例では、注文のシステムを作らずに、一番危ない仮説を確かめています。開発に何か月もかける前に、2週間で「進むか・変えるか」を判断できます。
成功の基準は、作る前に関係者と合意しておきます。基準があれば、結果が悪くても「どこが外れたか」を冷静に話し合えます。基準がないままだと、スポンサーの期待と結果の受け止め方がずれる原因になりがちです。
MVPにはどんな型がある？
MVPは、ソフトウェアを作ることに限りません。仮説を確かめられるなら、次のような型があります。英語由来の呼び名は、他の資料を読むときの手がかりになります。
| 型（よく使われる呼び名） | やり方 | 確かめやすいこと |
|---|---|---|
| 説明ページ（ランディングページ） | 製品の説明と申し込みボタンだけのページを公開する | 興味を持つ人がどれくらいいるか |
| 紹介動画（デモ動画） | 使っている様子を短い動画で見せ、反応を集める | 説明だけで価値が伝わるか |
| 予約販売（プレオーダー） | 完成前に予約や前払いを受け付ける | 実際にお金を払う人がいるか |
| 手作業の代行（コンシェルジュ型） | システムを作らず、人が手作業でサービスを提供する。利用者も人の対応だと知っている | 利用者がその結果を本当に求めているか |
| 見せかけの自動化（オズの魔法使い型） | 利用者には自動に見えるが、裏で人が処理する | 使い方や流れが受け入れられるか |
| 画面の試作品（プロトタイプ型） | 画面の絵や動かない試作品を触ってもらう | 操作の分かりやすさ・必要な機能 |
| 1機能だけの製品 | 一番大事な1つの機能だけを作って出す | その機能に時間やお金を使ってもらえるか |
型は、確かめたい仮説に合わせて選びます。たとえば「お金を払うか」を確かめたいなら、説明ページより予約販売の方が確かな答えが出ます。興味を示すことと、実際に払うことは別だからです。
MVPとMMF・PoC・プロトタイプはどう違う？
MVPと混同しやすい言葉を並べます。違いは「何を確かめるか、何を届けるか」です。
| 言葉 | 確かめる・届けるもの | 形の例 | 主に使う時期 |
|---|---|---|---|
| MVP（実用最小限の製品） | 利用者に求められるか（市場の仮説） | 説明ページ・手作業の代行・1機能の製品 | 新しい製品や事業の初め |
| PoC（概念実証） | 技術的に実現できるか | 社内だけで動かす検証用の仕組み | 技術の見通しが立たないとき |
| プロトタイプ（試作品） | 形・操作・使い勝手 | 画面の絵、動く試作品 | 設計を固める前 |
| MMF（最小市場化機能） | 単体で利用者に価値がある最小の機能を届ける | 利用者が実際に使える機能 | 方向が見えた後、リリースを重ねる段階 |
MMF（Minimum Marketable Feature）の考え方は、2003年の著書『Software by Numbers』で示されました。著者はマーク・デンとジェーン・クレランド＝ホアンです。ソフトウェアを価値の出る単位に分けて順に届け、投資を早く回収することを狙います。
MMFを組み合わせた、最初に市場に出せる製品を MMP（Minimum Marketable Product）と呼ぶこともあります。MVPは学びの単位、MMFは価値を届ける単位と覚えると区別しやすくなります。
プロトタイプをMVPとして使うこともあります。物の形ではなく、何を確かめるために使うかで呼び名が変わる、と考えると整理できます。
MVPでよくある誤解は？
MVPは言葉が広まったぶん、意味がずれて使われることもあります。試験でも実務でも、次の誤解に注意します。
| よくある誤解 | 正しい考え方 |
|---|---|
| MVPは機能が少ない完成品 | 学ぶための最小の形。説明ページや手作業の代行でもよい |
| 最小なら品質も下げてよい | 削るのは範囲。安全・法令・個人情報の基準は守る（Viable＝実用に足ることを忘れない） |
| 出したら終わり | 測って判断するまでがMVP。結果を次の判断につなげる |
| 反応が悪かったら失敗 | 仮説が外れたと早く分かったことが学び。方向を見直す材料にする |
| 早い利用者の声はすべて取り入れる | 成功の基準と仮説に照らして判断する。声の大きい少数に振り回されない |
| 大きなプロジェクトには使えない | 全体は計画どおりに進め、不確かな部分だけをMVPで確かめる方法もある |
最後の行のように、予測型の計画の中で一部だけを小さく確かめる進め方は、ハイブリッド開発の一つの形です。品質の基準と「完了」の関係は完了の定義（DoD）とは？で扱います。
段階的に価値を届けるとは？
MVPで方向が見えたら、MMFの単位で価値を順に届けます。全部を作ってから一度に出す場合と比べると、次の違いがあります。
最後に一度に届ける
- 価値が出る時期価値が出るのは最後だけ
- 外れたとき外れていたら全部作り直し
- 途中で止めたとき途中で止めると何も残らない
- 学び最後まで分からない
段階的に届ける
- 価値が出る時期最初のリリースから価値が出始める
- 外れたとき早く分かるので小さく直せる
- 途中で止めたとき途中で止めても届けた分は残る
- 学び毎回の反応で次を決められる
新ECO（2026年版）の Process のタスク3は「価値に基づく提供」です。価値を段階的に届ける機会を評価することや、価値を示す提供方法を評価することが含まれます。MVPとMMFは、このタスクの中心にある考え方です。詳しくは価値に基づく提供で扱います。
PMP試験ではどう問われる？
典型的な場面と、正解になりやすい行動を当サイトで整理すると次のとおりです。
- 新しい製品の需要がはっきりしない → 全部作る前に、MVPで仮説を確かめることを提案する
- スポンサーが全機能をそろえてから出したいと言う → 段階的に届ける利点を説明し、最初のリリースの範囲を話し合う
- MVPの反応が悪かった → 失敗として隠さず、学びとして共有し、方向を見直す
- MVPなので品質を下げたいと言われた → 安全や法令の基準は省かない。省くのは機能の範囲
- MVPの成功の基準がない → 作る前に、何が分かれば成功かを関係者と決める
リリースの範囲と進み具合は、バーンアップチャートで見せると伝わりやすくなります。読み方はバーンダウンチャートの見方で扱います。
確認問題1
需要がはっきりしない新サービス
（当サイトの独自問題）ある会社が、中小企業向けの経費精算サービスを新しく作る計画です。スポンサーは「機能をすべてそろえ、1年後に大きく発表したい」と考えています。しかし、どれだけの企業が乗り換えるかは誰にも分かっていません。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：2。需要という最大の不確かさを、作り込む前に小さく確かめるのがMVPの考え方です。何が分かれば成功かを先に決めて、スポンサーに提案します。
1：外れた場合、1年分の投資を失うおそれがあります。3：調査も役に立ちますが、利用者の実際の行動で確かめる機会を逃します。計画を止める理由にもなりません。4：競合の機能をなぞっても、自社の顧客の需要は確かめられません。
確認問題2
MVPの結果が予想と違った
（当サイトの独自問題）料理教室の予約アプリのMVPを2か月公開しました。予想していた「予約の便利さ」はあまり使われていません。代わりに「レシピの動画」がよく再生され、問い合わせもその内容に集中しています。スポンサーは結果に落胆しています。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：4。MVPの目的は学ぶことです。仮説が外れたことも、別の需要が見えたことも大きな学びです。方向の見直し（ピボット）を関係者と話し合います。
1：データが示す学びを生かしていません。2：別の需要が見えているのに中止を勧めるのは早すぎます。3：判断を先送りし、学びの周期を遅くします。
確認問題3
MVPだから品質を下げたい
（当サイトの独自問題）医療機関向けの予約システムのMVPを作っています。開発者の一人が「MVPなのだから、個人情報の暗号化やアクセスの記録は後回しにして、早く出そう」と提案しました。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：1。MVPで小さくするのは機能の範囲で、安全や法令に関わる品質ではありません。必要な基準を守ったまま、範囲を絞って早く出す方法をチームと話し合います。
2：個人情報の扱いは法令や組織の基準に関わり、省けません。3：MVPの利点を捨てる極端な判断です。4：基準を守らせるのは大切ですが、作り方はチームと話し合って決めます。
価値の届け方が問われる問題はタスク別ドリルの Process 3 で練習できます。