MVP・新規事業
MVPとは？最初から大きなシステムを作らない理由と機能の絞り込み方
新規事業の立ち上げでよく耳にする「MVP」。言葉は知っていても、いざ自社のサービスに当てはめようとすると、「どこまで削ってよいのか」「削りすぎて使われなかったらどうするのか」と迷うものです。MVPの考え方と、機能を絞り込むための具体的な手順を整理します。
MVPは「小さな完成品」ではない
MVPは、Minimum Viable Productの略で、日本語では「実用最小限の製品」などと訳されます。ここで大切なのは、MVPの目的が事業の仮説を確かめることにある点です。
| 小さな完成品 | MVP | |
|---|---|---|
| 目的 | 機能を減らした製品を提供する | 仮説が正しいかを確かめる |
| 機能の選び方 | 全体から重要な機能を選ぶ | 検証に必要な機能だけを選ぶ |
| 公開後 | 完成として運用する | 結果を見て、続ける・変える・やめるを判断する |
この違いを意識しないと、「全部の機能を少しずつ作る」ことになり、どの仮説も確かめられないMVPになってしまいます。
最初から大きく作らないほうがよい理由
- 仮説が外れたときの損失が大きい：作り込んだ機能ほど、方向転換で無駄になる
- 検証を始めるまでに時間がかかる：開発期間が長いほど、市場や資金の状況が変わる
- 何が効いたのか分からない：機能が多いと、利用者がどこに価値を感じたのかを判断しにくい
- 変更しにくくなる：作ったものが多いほど、検証結果を反映する改修も大きくなる
新規事業では、最初の仮説がそのまま当たることは多くありません。外れたときに素早く修正できる状態を保つことが、MVPを小さく作る大きな理由です。
機能を絞り込む手順
ステップ1：検証したい仮説を一文にする
まず、このMVPで確かめたいことを一文で書きます。「中小企業の総務担当者は、設備点検の予約を電話からWebに切り替えたいと考えている」のように、誰が、何に、どう反応するかを含めるのがポイントです。
ステップ2：利用者の行動の流れを書き出す
利用者がサービスを知ってから、目的を達成するまでの流れを順番に書き出します。
利用者の行動の流れ（書き出しの例）
- サービスを知る
- 内容を確認する
- 申し込む・予約する
- サービスを受ける
- 支払う
- また使う・人に勧める
上は流れを書き出す際の例です。サービスによって段階は異なります。
ステップ3：検証に関係する段階を選ぶ
書き出した流れのうち、ステップ1の仮説を確かめるために欠かせない段階を選びます。たとえば「Webで予約したいか」を確かめたいなら、「申し込む・予約する」の段階は作り込む必要がありますが、「支払う」は請求書払いで代用できるかもしれません。
ステップ4：機能を3つに分ける
| 分類 | 考え方 | 例 |
|---|---|---|
| 作る | 検証の中心で、利用者が直接使う部分 | 予約画面、予約内容の確認 |
| 代用する | 運営の手作業や既存サービスで補える部分 | 予約確定の連絡はメールで手動、支払いは請求書 |
| 後回し | 検証の結果が出てから判断できる部分 | 会員のマイページ、レビュー、ポイント |
「代用する」に入れられる機能が多いほど、作る範囲は小さくなります。利用者が少ない検証段階では、運営の手作業は大きな負担になりにくく、むしろ利用者の反応を直接知る機会にもなります。
絞り込むときに迷いやすいポイント
ログインや会員登録は必要か
利用者を識別する必要がなければ、最初は会員登録なしで申し込めるようにする方法もあります。登録の手間が減る分、検証したい行動に集中してもらえます。
管理画面はどこまで必要か
運営側が使う画面は、最低限の一覧と編集で十分なことが多くあります。集計や分析の画面は、検証の数字を見るのに必要な範囲に絞ります。
デザインはどこまで作り込むか
信頼感や分かりやすさが検証結果に影響するサービスでは、一定の品質は必要です。一方で、細部の作り込みは検証後でも遅くありません。
検証の結果を見る準備もしておく
MVPを作ったあと、何をもって仮説が正しかったとするかを、開発前に決めておきましょう。見るべき数字（申込数、継続して使う人の割合など）が決まっていれば、それを記録する仕組みも最初の版に入れておけます。検証後の判断についてはMVPを作ったあとはどうする？で解説しています。
外注で進める場合の注意点はMVP開発を外注するときの進め方、予算の考え方はスタートアップのMVP開発費用はどう考える？もあわせてご覧ください。
絞り込みすぎて失敗しないために
機能を絞ることは大切ですが、絞りすぎて検証そのものができなくなっては意味がありません。次の点は、MVPでも押さえておきたい部分です。
- 利用者が目的を最後まで達成できる流れが、一通りつながっている
- サービスを信頼してもらうための最低限の情報（運営者、利用規約、問い合わせ先）がある
- 利用者の個人情報を扱う場合の、基本的な安全対策がある
- 検証に必要な数字を記録できる
「一部の機能は運営が手作業で代用する」ことと、「利用者から見て途中で行き止まりになる」ことは違います。代用する部分があっても、利用者の体験としては最後までつながっていることが大切です。
絞り込みに迷ったときの問い
- この機能がなかったら、検証したいことは確かめられないか
- この機能は、最初の利用者が10人のときにも必要か
- システムで作らず、運営の手作業で代用できないか
- この機能を後から追加すると、大きな作り直しが必要になるか
最後の問いに「はい」と答える機能は、データの持ち方などに関わる部分であることが多く、最初から考えておく価値があります。それ以外は、後回しにしても大きな問題にならないことがほとんどです。
関係者と範囲を共有する
絞り込んだ範囲は、共同創業者や出資者など、関係者と共有しておきましょう。「なぜこの機能は入れないのか」を説明できるようにしておくと、後から範囲が膨らむのを防げます。
思いついている機能の一覧をお持ちください
機能の一覧と検証したい仮説があれば、「作る」「代用する」「後回し」の3つに分ける作業を一緒に進められます。Tailboneは、自社でもWebアプリの企画・開発・運用を行っており、小さく作って改善する進め方を大切にしています。
よくあるご質問
MVPとプロトタイプは何が違いますか？
使い方によって意味が重なることもありますが、プロトタイプは画面や操作の流れを確認するための試作品を指すことが多く、実際の利用者が使うことを前提にしていない場合もあります。MVPは、実際の利用者に使ってもらい、事業の仮説を確かめることを目的にしている点が特徴です。
機能が少ないと、利用者に評価されないのではありませんか？
機能が少ないこと自体より、利用者が目的を達成できるかどうかが重要です。検証したい体験の中心がしっかり使えれば、周辺の機能が少なくても、仮説が正しいかどうかは確かめられます。
どのくらいの期間で作るのが目安ですか？
検証したい内容と範囲によって変わります。重要なのは期間の長さより、検証を始めるまでの時間を短くすることです。要件が明確でシンプルな構成であれば、短期間で初回の版を形にできる場合もあります。