MVPの範囲は「何を作るか」ではなく「何を確かめたいか」から決まります。この12項目を順に埋めると、削るべき機能が自然に見えてきます。
1. 検証したい仮説を一文で書く
MVPの目的は機能を揃えることではなく、事業の前提となる仮説を確かめることです。仮説が一文で書けないうちは、機能の取捨選択もできません。「誰が」「どんな課題に対して」「何を使って」「どう変わる」の4つが入っているかを確認します。
2. 仮説が外れたときの判断を先に決める
検証は、結果を見てから判断基準を決めると、都合のよい解釈に流れます。作る前に「どうなったら仮説は外れたと言えるか」と「そのときに何をやめるか」を決めておきます。
3. 検証に必要な「体験の中核」を特定する
顧客が価値を感じる瞬間はどこか、その瞬間に至るまでに最低限必要な操作は何かを書き出します。ここに含まれない機能は、原則としてMVPには入れません。
4. 機能候補をすべて書き出す
削る前に、まず思いついた機能をすべて並べます。この段階では良し悪しを判断せず、チームの頭の中にあるものを出し切ることが目的です。後の項目で優先順位をつけます。
5. 「無いと検証できない」機能だけを残す
書き出した機能を3つに分けます。基準は「便利かどうか」ではなく「これが無いと仮説を検証できないかどうか」です。迷ったものは、いったん後回しに分類します。
6. 作らずに済ませられる部分を探す
「必須」に分類した機能でも、システムとして作らずに代替できることがあります。最初は人の手やスプレッドシート、既存のサービスで代替し、検証結果が出てから作り込むほうが、資金と時間を節約できます。
7. 管理画面の範囲を決める
顧客向けの画面に比べて、管理画面は後回しにされがちですが、無いと運営が回らないことがあります。一方で、最初から作り込むと工数が大きく膨らみます。検証期間中に運営が最低限必要とする操作だけを洗い出します。
8. 対象の端末と利用環境を絞る
PC・スマートフォン・タブレットのすべてに対応すると、画面の設計とテストの工数が増えます。想定顧客が主に使う環境をひとつ決め、検証期間はそこに集中します。
9. 会員登録・決済・通知の扱いを決める
多くのプロダクトに共通して登場するこの3つは、実装の手間が大きく、しかも検証に必ずしも必要とは限りません。それぞれ、検証に必要かどうかを個別に判断します。
10. 検証のために計測する項目を決める
作ってから「何を見ればいいのか」を考えると、必要なデータが記録されていないことが起こります。仮説に対応する観察項目を、実装前に決めます。
11. 作り直す前提の部分と残す部分を分ける
MVPは検証の結果によって大きく変わる可能性があります。すべてを丁寧に作ると時間がかかり、すべてを雑に作ると当たったときに土台になりません。どこを暫定にして、どこを残す前提で作るかを開発パートナーと合意します。
12. 開発パートナーと共有する
ここまでの11項目が埋まっていれば、開発パートナーへの依頼内容はほぼ固まっています。最後に、範囲の外側も含めて共有し、認識のずれを防ぎます。
関連するインサイト
- MVP開発とは — 最小限の機能で市場検証を始める方法MVP（実用最小限の製品）の定義と、検証したい仮説から逆算して機能を絞る設計の考え方、作らずに検証する手段との使い分け、MVP後の拡張を見据えた技術判断までを経営者・事業責任者向けに整理します。
- 資金調達前に整えておきたいプロダクトと技術面の準備投資家による技術デューデリジェンスを見据え、資金調達前に整えておきたい準備を手順化。プロダクトの現状説明資料、指標の整理、技術的負債の可視化、セキュリティと個人情報の基本対応、ソースコードの権利、開発体制の説明を解説します。
- PMFをどう見極めるか — 指標と判断の考え方PMFの定義と、継続率やチャーンなどの定量シグナル、利用者の声に表れる定性シグナルの読み方、PMF前に投資してはいけないもの、誤認しやすいパターン、PMF後に変わる開発の優先順位を整理します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開