Minimum Viable Product — 学習と検証に必要な最小限の機能だけを備えた、最初に市場・ユーザーに出す製品形態。
概要
MVP の本質は「最も速く学ぶ」こと。完成度の高い製品を作ってから検証するのではなく、 仮説検証に必要な最小限の機能だけ でユーザーに届け、フィードバックを得てから次の投資を決める。Eric Ries が『リーン・スタートアップ』で提唱し広まった概念。
誤解されやすい MVP
| 誤解 | 実像 |
|---|---|
| 「とりあえず動く簡易版」 | 仮説検証に必要な機能は削らない |
| 「品質が低くても良い」 | 使い物にならなければ学びにならない |
| 「プロトタイプと同じ」 | プロトタイプは内部検証、MVP は市場投入 |
| 「作って終わり」 | ビルド→計測→学習のループの 1 イテレーション |
ビルド→計測→学習ループ
MVP は単発のリリースではなく、仮説検証サイクルの 1 周目として設計する。
仮説
↓
ビルド(MVP)
↓
計測(ユーザー行動 / KPI)
↓
学習(仮説の採否)
↓
仮説を更新 → 次のイテレーションへ
各サイクルを短くすることが競争力になる。AI コーディングツールの台頭により、このサイクル時間は数週間単位から数日単位に短縮できる余地が広がった。
スコープ設計のチェックポイント
MVP のスコープは「足りないもの」より「外すもの」の判断が難しい。
- 検証したい仮説は何か(1 つに絞る)
- 仮説検証に必須の機能だけに絞ったか
- 「あったら便利」は次のイテレーションに回したか
- 成功 / 失敗の判定基準(KPI)を事前に定義したか
- ユーザーが実際に使える品質は担保したか
ステアリング駆動開発との関係
MVP のスコープ設計は、壁打ち・規模判定編の In Scope / Out of Scope 観点と一致する。ステアリング駆動開発では、MVP の仮説検証に必要な最小限を requirements.md に明示し、スコープ外を明記することで「機能の膨張」を構造的に防ぐ。
関連記事
- Web サイト構築の技術選定ガイド — MVP を高速に立ち上げる技術選定
- 壁打ち・規模判定編 — MVP のスコープ設計に活きる 5 観点
関連用語
- SSoT — MVP でもデータの正規表現は 1 箇所に集約する