MVP は Minimum Viable Product の略で、学びを得るために必要最小限の形で作る製品やサービスの初期版です。
日本語では「実用最小限の製品」と説明されることがありますが、単に機能を削った未完成品という意味ではありません。
まず押さえたいポイント
- 目的は、最小工数で顧客から学ぶこと
- 完成版の縮小コピーではなく、検証したい仮説に絞った初期版
- サービス開発、SaaS、アプリ、社内ツール、業務改善で使われる
- 作って終わりではなく、反応を見て次を判断するためのもの
- 低品質なものを出す言い訳ではない
何を検証するものか
MVPで検証したいのは、主に 本当に困っている人がいるか、その解決策に価値を感じるか、使い続ける理由や支払う理由があるか です。
たとえば、予約管理サービスを作るなら、最初から請求、分析、権限管理、連携APIまで作るのではなく、まず「予約の抜け漏れを減らせるか」を確認できる最小構成に絞る考え方です。
Eric Ries のMVP解説でも、MVPは顧客について最大限の学びを得るための最小限の努力として説明されています。
つまり、目的は機能を減らすことではなく、早く学習することです。
よくある誤解
MVPは「雑に作って出すもの」ではありません。
検証に必要な体験が壊れていると、顧客が反応しない理由が 課題が弱いから なのか 品質が低すぎるから なのか分からなくなります。
また、MVPを作る前にできる検証もあります。
顧客ヒアリング、手作業での代行、ランディングページ、フォーム、デモ動画、既存ツールでの簡易運用などで、コードを書かずに仮説を確かめられる場合もあります。
実務で見るポイント
MVPを考えるときは、最初に 何を学びたいのか を1つに絞ると扱いやすいです。
利用者が登録するかを見たいのか、毎週使うかを見たいのか、有料で申し込むかを見たいのかで、作るものは変わります。
詳しい進め方は、新しいサービスを生み出すコツとは？課題発見・MVP・検証の進め方 で整理しています。