MVPの範囲を決めるチェックシート

MVPの範囲は「何を作るか」ではなく「何を確かめたいか」から決まります。この12項目を順に埋めると、削るべき機能が自然に見えてきます。

1. 検証したい仮説を一文で書く

MVPの目的は機能を揃えることではなく、事業の前提となる仮説を確かめることです。仮説が一文で書けないうちは、機能の取捨選択もできません。「誰が」「どんな課題に対して」「何を使って」「どう変わる」の4つが入っているかを確認します。

顧客は誰か（業種・役割・状況をひとつに絞る）
その顧客が今、何に困っていて、今はどう対処しているか
自社のプロダクトが提供する解決策は何か（一文で）
仮説が正しければ、顧客はどんな行動を取るはずか（登録する、繰り返し使う、支払うなど）

2. 仮説が外れたときの判断を先に決める

検証は、結果を見てから判断基準を決めると、都合のよい解釈に流れます。作る前に「どうなったら仮説は外れたと言えるか」と「そのときに何をやめるか」を決めておきます。

検証期間をいつからいつまでにするか
どの数値や反応が得られなければ仮説は外れたと判断するか
外れた場合に、方向転換するのか、対象顧客を変えるのか、やめるのか

3. 検証に必要な「体験の中核」を特定する

顧客が価値を感じる瞬間はどこか、その瞬間に至るまでに最低限必要な操作は何かを書き出します。ここに含まれない機能は、原則としてMVPには入れません。

顧客が「これは使える」と感じる瞬間（例: 探していた相手が見つかる、面倒な作業が終わる）
その瞬間に至るまでの操作の流れ（画面の数ではなく、行動の順番で）
流れの中で、省いても価値の判断に影響しない手順はないか

4. 機能候補をすべて書き出す

削る前に、まず思いついた機能をすべて並べます。この段階では良し悪しを判断せず、チームの頭の中にあるものを出し切ることが目的です。後の項目で優先順位をつけます。

顧客向けの機能（画面・操作）
運営側の機能（管理画面、承認、集計）
外部サービスとの連携（決済、通知、認証など）

5. 「無いと検証できない」機能だけを残す

書き出した機能を3つに分けます。基準は「便利かどうか」ではなく「これが無いと仮説を検証できないかどうか」です。迷ったものは、いったん後回しに分類します。

必須: これが無いと仮説の検証そのものができない
後回し: あると便利だが、検証には影響しない
対象外: 今回の仮説とは関係がない、または別の仮説に属する

6. 作らずに済ませられる部分を探す

「必須」に分類した機能でも、システムとして作らずに代替できることがあります。最初は人の手やスプレッドシート、既存のサービスで代替し、検証結果が出てから作り込むほうが、資金と時間を節約できます。

裏側を手作業で運用できないか（受付や集計を人が行い、画面だけ用意する）
既存のサービスや既製ツールで代替できないか（フォーム、決済、チャットなど）
ランディングページと申込フォームだけで反応を確かめられないか

7. 管理画面の範囲を決める

顧客向けの画面に比べて、管理画面は後回しにされがちですが、無いと運営が回らないことがあります。一方で、最初から作り込むと工数が大きく膨らみます。検証期間中に運営が最低限必要とする操作だけを洗い出します。

検証期間中に運営側が毎日行う操作は何か
データベースを直接見る・スプレッドシートに書き出すことで代替できる操作はどれか
顧客対応に必要な情報（登録内容、利用履歴）をどこで確認するか

8. 対象の端末と利用環境を絞る

PC・スマートフォン・タブレットのすべてに対応すると、画面の設計とテストの工数が増えます。想定顧客が主に使う環境をひとつ決め、検証期間はそこに集中します。

想定顧客はどの端末で、どんな場面で使うか
最初に対応する環境をひとつに絞れるか（例: スマートフォンのブラウザのみ）
ネイティブアプリが本当に必要か、Webで検証を始められないか

9. 会員登録・決済・通知の扱いを決める

多くのプロダクトに共通して登場するこの3つは、実装の手間が大きく、しかも検証に必ずしも必要とは限りません。それぞれ、検証に必要かどうかを個別に判断します。

会員登録: 検証に個人の識別が必要か。メールアドレスだけの簡易登録で足りないか
決済: 支払い意思を確かめるなら、請求書払いや外部の決済リンクで代替できないか
通知: メールやチャットの通知は、最初は手動送信で足りないか

10. 検証のために計測する項目を決める

作ってから「何を見ればいいのか」を考えると、必要なデータが記録されていないことが起こります。仮説に対応する観察項目を、実装前に決めます。

仮説が正しければ増えるはずの行動は何か（登録、繰り返し利用、紹介など）
その行動を記録する仕組みは、MVPの範囲に含まれているか
数値だけでなく、顧客に直接聞く機会（インタビュー、アンケート）を計画しているか

11. 作り直す前提の部分と残す部分を分ける

MVPは検証の結果によって大きく変わる可能性があります。すべてを丁寧に作ると時間がかかり、すべてを雑に作ると当たったときに土台になりません。どこを暫定にして、どこを残す前提で作るかを開発パートナーと合意します。

検証結果によって変わりそうな部分（画面の流れ、料金の仕組みなど）は暫定でよいか
変わりにくい部分（顧客データの構造、認証の仕組みなど）は残す前提で作るか
暫定にした部分を、後で作り直す判断を誰がいつ行うか

12. 開発パートナーと共有する

ここまでの11項目が埋まっていれば、開発パートナーへの依頼内容はほぼ固まっています。最後に、範囲の外側も含めて共有し、認識のずれを防ぎます。

仮説、判断基準、検証期間を伝えたか
「必須」「後回し」「対象外」のリストをそのまま共有したか
検証期間中に範囲を変えたくなったときの相談方法を決めたか
検証後の次の一手（拡張、方向転換、停止）ごとに、何を残しておく必要があるか確認したか

この内容で相談したい

チェックした内容をそのままフォームに貼り付けていただければ、そこから具体的な進め方と概算をお伝えします。

無料で相談する