MVP とは：小さく作って確かめる開発の進め方と、よくある3つの誤解
MVP（Minimum Viable Product）は、「機能を削った安い版」のことではありません。いちばん少ない手間で、お客さまについていちばん多くを学ぶための、最初の形です。何を確かめたいかを先に決めると、作らなくてよい部分が見えてきます。この記事では、MVP の本来の意味とよくある3つの誤解、Dropbox と Zappos が作らずに確かめた例、作る前に確かめる方法、進め方の5つの手順と型紙、開発会社に頼むときの契約の考え方を、クリーヴァの自社プロダクトの例とあわせてまとめます。
新しいサービスや社内システムを作るとき、「まずは MVP で小さく始めましょう」という言葉をよく聞きます。ところが、話を進めてみると、人によって MVP の意味がかなり違います。
「とりあえず最低限の機能で作ること」と考える人もいれば、「お試し版だから多少雑でもいい」と考える人もいます。この違いが、開発会社との認識のずれや、作ったのに何も分からなかった、という結果につながります。
この記事では、MVP の言葉の意味をもう一度確かめたうえで、発注する側が押さえておくべき進め方を整理します。
MVP とは：最小の製品ではなく、最小の手間で学ぶための形
MVP は、Minimum Viable Product の頭文字です。この考え方を広めたエリック・リース氏は、2009年のブログで、MVP を次のように定義しています（Minimum Viable Product: a guide）。
最小の手間で、お客さまについての「検証された学び」を最大限に集められる、新しい製品の版（筆者訳）
ポイントは、**目的が「学ぶこと」**だという点です。作ったものが売れるか、使われるか、お金を払ってもらえるか。まだ分からないことを、実際の反応で確かめるために作るのが MVP です。
そのため、MVP の大きさは「機能がいくつあるか」では決まりません。何を確かめたいかで決まります。確かめたいことが「この業務に、そもそも困っている人がいるか」なら、システムを作る前に確かめられるかもしれません。確かめたいことが「毎日使い続けてもらえるか」なら、実際に毎日使える形が必要です。
MVP は「作る・測る・学ぶ」の最初の一周
リース氏が広めた「リーン・スタートアップ」という考え方では、新しい事業を「作る → 測る → 学ぶ」の繰り返しとして進めます。MVP は、この繰り返しを、できるだけ早く始めるための最初の一周です（The Lean Startup：Principles）。
測った結果、事業の前提がうまく動いていないと分かったら、進む方向を変えます。これを「ピボット（方向転換）」と呼び、方向を変えるか、そのまま続けるかを、測った結果をもとに決めます（同ページ）。リース氏は別の記事で「MVP の目的は、学びを始めることであって、終わらせることではない」とも書いています（TechCrunch への寄稿、2011年10月19日）。
つまり MVP は、1回作って終わりの「お試し版」ではありません。学びを積み重ねるための、繰り返しの1回目です。
作らずに確かめた、有名な MVP の例
MVP の考え方をよく表している例を2つ紹介します。どちらも、システムを作り込む前に、お客さまの反応を確かめています。
Dropbox：動画で需要を確かめた
ファイルを複数のパソコンで同期するサービスの Dropbox は、製品を作る前に、約3分の説明動画を公開しました。同期の仕組みを作るには大きな技術的な壁があり、試作品で見せることができなかったためです。創業者のドリュー・ハウストン氏は、動画のあと「ベータ版の順番待ちの登録が、5,000人から75,000人に、文字どおり一晩で増えた」と話しています（TechCrunch：Eric Ries 寄稿）。
リース氏はこの例を、「動画そのものが MVP だった」と説明しています。確かめたかったのは「作れるか」ではなく、「欲しい人がいるか」だったからです。
Zappos：人の手で代わりにやって確かめた
靴の通販サイトの Zappos は、1999年、在庫を持たずに始まりました。創業者のニック・スウィンマーン氏は、地元の靴店に「靴の写真を撮ってネットに載せさせてほしい。売れたら、その靴を定価で買い取る」と持ちかけ、注文が入るたびに店で靴を買って送っていました（Fortune、2012年9月5日）。
在庫の管理や物流の仕組みを作る前に、「靴をネットで買う人がいるか」を、人の手で確かめたことになります。
2つの例に共通するのは、いちばん自信のない前提（欲しい人がいるか）を、いちばん手間の少ない方法で確かめたことです。作るのが難しい部分ほど、作る前に確かめる価値があります。
MVP でよくある3つの誤解
1. 「機能を削った安い版」のこと
いちばん多い誤解です。リース氏自身も、同じ記事の中で「MVP は、その名前に反して、最小の製品を作ることではない」と書いています（同記事）。
機能を削ることは、MVP の結果としてそうなることはあっても、目的ではありません。機能を削った結果、確かめたいことが確かめられなくなっているなら、それは MVP としては失敗です。
2. 「お試しだから、品質は低くてよい」
確かめたいことに関わる部分の品質は、落としてはいけません。たとえば、「この申込の流れで申し込んでもらえるか」を確かめたいのに、申込のボタンが押しにくかったり、途中でエラーが出たりすれば、申込が少なかった理由が「需要がない」のか「作りが悪い」のか分からなくなります。
手を抜いてよいのは、確かめたいことに関わらない部分です。たとえば、最初の数十件なら、管理画面を作らずに、担当者が表計算ソフトで処理しても構いません。
3. 「作れば分かる」
作っただけでは、何も分かりません。リース氏も、MVP には「最初の版から何かを学ばなければならない」という余計な手間がかかり、お客さまと話したり、数字を見たりする必要があると書いています（同記事）。
作る前に「何が起きたら、続けると判断するか」を決めておかないと、公開したあとに数字を見ても、良いのか悪いのか判断できません。結果として、「もう少し機能を足してみよう」が続き、いつまでも MVP から抜け出せなくなります。
作る前に確かめられることも多い
MVP は、必ずしもシステムである必要はありません。確かめたいことによっては、作る前に、もっと安く確かめられます。
リース氏は同じ記事で、誰も欲しがらない機能に2週間を使ってしまった経験を振り返り、検索広告を出して反応を見る簡単なテストをしていれば、需要がないことにもっと早く気づけたと書いています（同記事）。
| 確かめ方 | 分かること | 分からないこと |
|---|---|---|
| 説明のページを作り、広告で人を集めて、申込や資料請求の数を見る | 興味を持つ人がどれくらいいるか、どんな言葉に反応するか | 実際に使い続けてもらえるか |
| システムを作らず、人の手で代わりにやってみる | お客さまが本当に欲しいものは何か、どの作業に時間がかかるか | 人数が増えたときに回るか |
| 画面の試作を見せて、操作してもらう | 画面の流れが分かりやすいか、足りない情報は何か | お金を払ってもらえるか |
| 表計算ソフトやフォームなど、今ある道具を組み合わせて運用してみる | 業務の流れとして成り立つか、どこで手間が出るか | システムにしたときの使い心地 |
| 一部の機能だけを作り、少人数に使ってもらう | 毎日使ってもらえるか、使い続ける理由は何か | 大勢に広げたときの反応 |
上から順に、かかる手間が大きくなります。確かめたいことを確かめられる中で、いちばん上の方法を選ぶのが基本です。
画面の試作で確かめるときの、人数と期間の目安
画面の試作を見せて確かめる方法は、社内システムでも新しいサービスでも使いやすい方法です。人数と期間には、よく知られた目安があります。
- 人数は5人ずつ：使いやすさの研究で知られるヤコブ・ニールセン氏は、似た立場の利用者5人に試してもらえば、使いにくい所の約85%が見つかると説明しています。そのうえで、15人に1回試すより、5人ずつ3回に分けて、直しながら試すほうがよいと勧めています。ただし、立場の大きく違う利用者が何種類もいる場合は、種類ごとに3〜4人に試してもらう必要があります（Nielsen Norman Group、2000年3月18日）。
- 期間は1週間でも足りる：Google の投資部門 GV が公開している「デザインスプリント」は、月曜に課題を決め、木曜に試作を作り、金曜に実際のお客さまに試してもらう、5日間の進め方です。試作は、お客さまから見える表側だけを本物らしく作れば十分で、1日で作り終えられるとしています（GV：The Design Sprint）。
社内システムなら、「経理の担当者5人」「営業の担当者5人」のように、使う立場ごとに分けて試してもらうと、立場による使いにくさの違いが見えてきます。
MVP の進め方：5つの手順
MVP を始める前に決めておきたいことを、5つの手順にまとめます。最後に、そのまま埋めて使える型紙も載せます。
- いちばん自信のない前提を書き出す：「この業務に困っている人が多い」「月額で払ってもらえる」「現場の人が毎日入力してくれる」など、外れたら計画そのものが崩れる前提を書き出し、その中で、いちばん根拠が弱いものを選びます。
- 正しいとみなす数字を決める：「説明のページを見た人の5%以上が資料を請求する」「試した部署の8割が、2週間後も毎日使っている」のように、何が起きたら前提が正しかったと言えるかを、数字で決めます。
- 確かめられる最小の形を選ぶ：前の表から、その前提を確かめられる、いちばん手間の少ない方法を選びます。
- 判断の基準と、判断する日を決める：数字が基準を超えたら続ける、届かなかったら変える、大きく下回ったら止める、という基準と、それを判断する日を先に決めて、関係者の予定に入れます。
- 作って、測って、決める：決めた日に、決めた基準で判断します。基準を後から緩めたくなったら、それ自体が「前提が外れている」という学びです。
埋めて使う型紙
| 項目 | 記入例（社内の問い合わせ管理を新しくする場合） |
|---|---|
| 確かめたい前提 | 担当者は、メールではなく新しい画面で問い合わせを管理してくれる |
| 正しいとみなす数字 | 試した3人が、2週間後も問い合わせの9割以上を新しい画面で処理している |
| 最小の形 | 一覧と担当者の割り当てだけの画面。通知や集計は作らない |
| 判断の基準 | 9割以上なら機能を足す。5割から9割なら、使われない理由を聞いて直す。5割未満なら、進め方を考え直す |
| 判断する日 | 使い始めてから2週間後の定例会 |
この5行が埋まっていれば、開発会社とも「何のために、どこまで作るか」を同じ言葉で話せます。
判断に使える数字の選び方
手順2で決める数字は、選び方を間違えると、判断の役に立ちません。リース氏は、見た目は大きく伸びていても判断に使えない数字を「見かけの数字（vanity metrics）」と呼び、注意を促しています。別の記事では、アクセス数のような全体の合計ではなく、1人あたりで見ること、そして変化が何によって起きたのかを説明できる数字を判断に使うことを勧めています（Why vanity metrics are dangerous、2009年12月23日）。
MVP でよく使われる数字を、この考え方で分けると次のようになります。
| 見かけの数字（合計で増えていく） | 判断に使える数字（1人あたり・割合） |
|---|---|
| ページの表示回数の合計 | ページを見た人のうち、申込や資料請求をした人の割合 |
| 登録した人の合計 | 登録した人のうち、2週間後もまだ使っている人の割合 |
| 作った機能の数 | 1人が1週間にその機能を使った回数 |
| 問い合わせの件数の合計 | 問い合わせのうち、商談や契約に進んだ割合 |
合計の数字は、広告を増やしたり、期間を延ばしたりするだけで増えます。そのため、前提が正しかったかどうかは分かりません。判断の基準には、右側のような割合や1人あたりの数字を選んでください。
もう一つ大切なのは、比べる相手を用意することです。変更の前後や、試した部署と試していない部署で比べられるようにしておくと、数字が動いた理由を説明しやすくなります。
基準に届かなかったときの3つの選択肢
判断する日に数字が基準に届かなかったとき、選べる道は3つです。
| 選択肢 | 選ぶとき | 次にやること |
|---|---|---|
| 続ける（形を直す） | 前提は正しそうだが、使いにくさなど作りの問題で数字が伸びていない | 使った人に話を聞き、つまずいた所だけを直して、もう一度測る |
| 変える（ピボット） | 使った人の反応から、別の前提のほうが正しそうだと分かった | 新しい前提で、手順1からやり直す。対象の人や、解決する困りごとを変える |
| 止める | どの前提も外れていて、続ける理由が見つからない | 分かったことを記録して、投資を止める。止めるのも、MVP の立派な成果 |
どれを選ぶにしても、数字だけで決めず、使った人の声と合わせて判断することが大切です。数字は「何が起きたか」を教えてくれますが、「なぜ起きたか」は、使った人に聞かないと分かりません。
MVP が向いている場面と、向いていない場面
MVP は便利な考え方ですが、どんな開発にも合うわけではありません。
向いている場面
- 新しいサービスで、お客さまが本当にお金を払うか、使い続けるかが分からない
- 社内の新しい仕組みで、現場の人が使ってくれるかが分からない
- 似たサービスがなく、何が正解か、誰にも分からない
向いていない場面
- 法律や取引先との約束で、満たすべき要件が最初から決まっている
- 今あるシステムの置き換えで、必要な機能が分かっていて、すべてそろわないと業務が止まる
- 一度公開したら、途中で作りを変えることが難しい
向いていない場面でも、「画面の試作を見せて、操作に迷う所がないかを確かめる」のように、一部だけ MVP の考え方を取り入れることはできます。全部を MVP で進めるか、使わないかの二択ではありません。
クリーヴァの例：自社プロダクト mediup を、社内から順に広げている
クリーヴァは、AI がホームページの記事を企画して書き、公開後の数字を見て直し方まで提案する「mediup（メディアップ）」というプロダクトを作っています。AI が書いたものは、人が承認したものだけが公開される仕組みです（mediup の紹介記事）。
mediup は、いきなり多くのお客さまに売り出すのではなく、次の順番で使う人を広げています。
- まず、自分たちとグループ会社のメディアで使う
- 次に、ご紹介いただいたお客さまに、テストとして使っていただく
- その声をもとに、プロダクトを直し続ける
最初の段階で、自分たちで使って分かったことがあります。止まっていたのは AI ではなく、承認する人のほうでした。紹介記事では、AI が記事を書き終えてから8日間、承認されないまま待っていた画面を、そのまま載せています（同記事）。
これは、作る前の打ち合わせでは出てこなかった種類の学びです。「AI がよい記事を書けるか」だけを確かめていたら、気づけませんでした。実際に使う人の手元で動かして初めて、本当の詰まりどころが分かります。MVP で確かめるべきなのは、作る側が気にしていることではなく、使う人の毎日の中で何が起きるかです。
開発会社に MVP を頼むときに決めておくこと
MVP を開発会社に頼む場合は、作るものの一覧より先に、次の5つを共有してください。
| 決めること | なぜ必要か |
|---|---|
| 確かめたい前提と、正しいとみなす数字 | 開発会社が「どこに手間をかけ、どこを省くか」を判断できる |
| 数字を測る仕組み | アクセス解析や、申込・利用の記録がないと、公開しても判断できない。最初の範囲に入れる |
| 判断する日と、判断する人 | 決める人がいないと、「もう少し機能を足す」が続く |
| 続けると決めたときの作り直しの範囲 | MVP は、確かめたいこと以外の部分を簡単に作っていることが多い。本番として使い続けるなら、どこを作り直すかを決める |
| 進め方と契約の形 | 途中で作るものが変わる前提なので、最初にすべてを決めて金額を固める進め方と合うかを、最初に相談する |
とくに最後の2つは、後から話すと揉めやすいところです。MVP で作ったものを、そのまま本番として使い続けると、安全面や作りの面で問題が残ることがあります。最初の打ち合わせで、「確かめたあとにどうするか」まで話しておくことをおすすめします。
契約の形は、IPA のモデル契約が参考になる
途中で作るものが変わる開発の契約については、独立行政法人 情報処理推進機構（IPA）が「情報システム・モデル取引・契約書（アジャイル開発版）」を公開しています（IPA、2020年3月31日公開）。発注する側が知っておきたい点は、次の3つです。
- 準委任契約を前提にしている：完成した成果物に対価を払う請負契約ではなく、開発会社が専門家として仕事をすること自体に対価を払う準委任契約を前提にしています。理由として、機能の追加や変更、優先順位の入れ替えに柔軟に対応する進め方だから、と説明されています。
- 「何を作るか」に責任を持つ人は、発注する側から出す：プロダクトの方向性と中身に責任を持つ「プロダクトオーナー」は、発注する側の会社が選ぶことになっています。MVP で「続けるか、変えるか、止めるか」を決めるのも、この人です。
- 契約の前に確かめるチェックリストがある：プロジェクトの目的やゴール、プロダクトのビジョンがはっきりしているかなどを、発注する側と開発会社の両方で確かめるためのチェックリストが、契約書のひな型と一緒に公開されています。
MVP は、まさに「途中で作るものが変わる」開発です。最初にすべてを決めて金額を固める契約で始めると、学んだことを反映するたびに契約の変更が必要になります。どの契約の形が合うかは、開発会社と最初に相談してください。
よくある質問
MVP とプロトタイプは、どう違いますか？
一般に、プロトタイプは「形や操作感を確かめるための試作」、MVP は「実際に使ってもらい、お客さまの反応から学ぶための最初の版」として使い分けられます。画面の試作を見せることも、確かめたいことによっては MVP の一つの形になります。
MVP には、どのくらいの期間と費用がかかりますか？
確かめたいことによって大きく変わります。広告と説明のページで需要を確かめるだけなら、システムを作る必要はありません。毎日使い続けてもらえるかを確かめるなら、実際に使える画面が必要です。先に「確かめたい前提」を1つに絞ると、見積もりの幅も狭くなります。
社内システムでも MVP の考え方は使えますか？
使えます。社内システムの場合、「お客さま」は社内で使う人です。全社に一度に入れるのではなく、1つの部署や数人で先に使ってもらい、使い続けてもらえるかを確かめてから広げると、作り直しを減らせます。
作っている途中で、機能を足したくなったら？
まず、その機能が「確かめたい前提」に関わるかどうかを考えてください。関わらないなら、判断する日のあとに回します。関わるなら、足す代わりに何を削るか、判断する日をずらすかを、開発会社と一緒に決めます。途中で機能を足し続けると、判断する日が来ないまま費用だけが増えていきます。足したい機能の一覧は捨てずに残しておき、「続ける」と決めたときの最初の候補にしてください。
MVP で作ったものを、そのまま本番で使ってもよいですか？
確かめたいこと以外の部分を、簡単に作っている場合が多いので、そのままはおすすめしません。とくに、社外の人が使う、個人情報を扱う、お金が動く、といった場合は、本番の前にエンジニアに見てもらってください。判断の目安は、Claude Code を非エンジニアが業務で使うの「エンジニアに頼るべき6つの場面」でも紹介しています。
まとめ
- MVP は「機能を削った安い版」ではなく、最小の手間で、お客さまについての学びを最大限に集めるための最初の形
- よくある誤解は3つ。最小の製品のことではない、確かめたいことに関わる品質は落とさない、作っただけでは分からない
- 説明のページと広告、人の手での代行、画面の試作など、作る前に確かめられることも多い。Dropbox は動画で、Zappos は人の手で、欲しい人がいるかを先に確かめた
- 画面の試作は、立場の似た5人ずつ、直しながら繰り返し試すのが目安
- 進め方は、いちばん自信のない前提を選ぶ → 正しいとみなす数字を決める → 最小の形を選ぶ → 判断の基準と日を決める → 作って測って決める
- 判断には、合計の数字ではなく、割合や1人あたりの数字を使う。数字が届かなかったら、続ける・変える・止めるを、使った人の声と合わせて決める
- 開発会社に頼むときは、作るものの一覧より先に、確かめたいこと、測る仕組み、判断する日、確かめたあとの作り直しを共有する。契約の形は、IPA のアジャイル開発版のモデル契約が参考になる
小さく作ることそのものより、作る前に「何を確かめるか」を決めることのほうが大切です。最初の打ち合わせに、ぜひこの5つの手順の型紙を持っていってください。
