MVPスコープとは、事業仮説を検証するために、今回作って提供する範囲と対象外にする範囲です。機能数だけでなく、対象ユーザー、利用場面、対応環境、運用方法、検証期間まで含めて決めます。
「予算で作れる機能を並べる」だけでは、MVPのスコープは決まりません。誰のどの課題を解決するのか、どのような結果が得られれば次の投資を判断できるのかを先に決めます。
この記事のポイント
- MVPスコープでは、検証に必要な範囲と対象外にする範囲を合意する
- ユーザーと利用場面を絞っても、一連の体験は最後まで完結させる
- 価値を届ける機能、安全に使う条件、結果を測る仕組みを残す
- 追加要望を受けたら、仮説との関係と納期・費用への影響を確認して判断する
MVP要件とスコープの違い
要件は「満たすべき条件」、スコープは「今回扱う範囲」です。たとえば「予約が重複しない」は要件、「一店舗・一種類の予約だけに対応する」はスコープです。
| 項目 | 決めること | 予約サービスの例 |
|---|---|---|
| 仮説 | 確かめたいこと | 電話せずに予約できれば、利用者がWebを選ぶ |
| 要件 | 満たす条件 | 空き枠を選び、予約完了を確認できる |
| スコープ | 今回の対象と対象外 | 一店舗を対象にし、複数店舗の横断検索は除外する |
| 成功条件 | 結果を判断する基準 | 対象者の利用率や離脱理由から継続を判断する |
仮説や要件、スコープ、成功条件を文書にまとめて合意する手順とテンプレートはMVP要件とは・要件定義の書き方で扱っています。本記事では、文書にまとめる前に開発範囲をどう選ぶかを解説します。
MVPスコープを決める5つの手順
1. 今回確かめる仮説を一つ決める
「便利な予約システムを作る」だけでは、仮説が正しいかを判定できません。「営業時間外に予約したい利用者が、電話を待たずにWeb予約を完了する」のように、対象者・状況・行動を具体化します。
需要ではなく、技術的に実現できるかが最大の不明点なら、先にPoCとMVPの使い分けを確認します。検証する問いが違えば、必要な範囲も変わります。
2. ユーザーの行動を最初から最後まで書く
予約なら「空き枠を探す → 選ぶ → 必要情報を入力する → 確定を確認する」が一つの流れです。画面数を減らすために予約結果の表示を省くと、利用者は予約できたか分かりません。その状態では、サービスの価値を評価できません。
中心の流れに加え、取消や入力ミスなど、対象業務で避けられない例外を確認します。すべてを自動化する必要はありませんが、誰がどう対応するかを決める必要はあります。
3. ユーザーや利用場面でも範囲を絞る
| 絞る軸 | 初期の対象例 | 対象外の例 |
|---|---|---|
| ユーザー | 一店舗の既存顧客 | 全店舗の新規顧客 |
| 利用場面 | 通常の来店予約 | 団体・貸切予約 |
| 機能 | 空き枠確認と予約 | ポイント、クーポン |
| 対応環境 | 合意した端末・ブラウザ | 全環境への対応保証 |
| 運用 | 営業時間内の有人サポート | 24時間の即時対応 |
| 連携 | 一つの予約台帳 | 複数の外部サービス |
これは絞り方の例であり、どのサービスでも同じ制限が適切とは限りません。対象ユーザーが普段使わない環境に限定すると、需要ではなく、環境の制約による影響を測ることになります。
4. 価値・安全・計測で必要性を判定する
機能候補ごとに「なくても仮説を正しく検証できるか」を問います。
| 分類 | 判断する問い |
|---|---|
| 価値 | 中心の仕事を完了するために必要か |
| 安全 | 対象データや利用者を守り、誤処理を防ぐために必要か |
| 計測 | 利用・離脱・失敗の理由を把握するために必要か |
| 保留 | 仮説を確認した後でも追加できるか |
認証・権限や必要なデータ保護は、見た目に影響しないという理由で省いてはいけません。一方、毎日数件しか発生しない集計は、手作業で対応できるか検討できます。
5. 対象外と見直す条件を合意する
保留にした項目には、再検討する条件を添えます。「複数店舗対応は、最初の店舗で利用継続と運用負荷を確認した後」のように書くと、要望を忘れずに、当初決めた範囲で開発を進められます。
MVPスコープの記入例
以下は架空の予約サービスの例です。期間や人数は推奨値ではなく、実際には検証したい行動が起きる頻度に合わせて設計します。
| 項目 | 今回の合意例 |
|---|---|
| 仮説 | 営業時間外の予約希望者がWebで予約を完了する |
| 対象 | 一店舗の既存顧客に案内する通常予約 |
| 対象機能 | 空き枠表示、予約登録、完了通知、スタッフの確認 |
| 例外対応 | 取消は窓口で受付。台帳へ反映する担当者を決める |
| 安全・品質 | 重複予約の防止、管理画面のアクセス制限、通知失敗の検知 |
| 計測 | 案内人数、予約開始・完了、離脱箇所、問い合わせ理由 |
| 対象外 | 決済、ポイント、多店舗検索、ネイティブアプリ |
| 終了条件 | 4週間後に責任者が判定。利用機会が不足した場合は結論を保留する |
| 見直し条件 | 予約完了と現場運用を確認してから、対象店舗の拡大を検討する |
この表に加えて、成功・中止の数値基準、担当者、予算上限を決めます。指標の決め方はMVPの検証KPIを参照してください。
開発中のスコープ拡大を防ぐ
追加要望を受けたら、その場で実装せず、以下を記録します。
- どの仮説・利用場面に必要か
- 追加しないと検証できないのか、手作業で代替できるのか
- 納期・費用・計測への影響は何か
- 今回入れるなら、何を対象外にするか
- 誰が判断し、どの版から適用するか
実利用で見つかった不具合やデータ保護の問題は、便利な機能の追加とは分けて、優先して対応するかを判断します。範囲を変更した場合は記録を残し、変更前後の利用データを区別して評価します。
よくある失敗
機能数や工数だけで最小限かどうかを判断する
3機能でも、利用者の仕事が途中で止まれば検証できません。機能の数よりも、仮説を判定するために必要な操作や業務を最後まで行えるかを確認します。
手作業のコストを無視する
裏側を人が処理する方法も有効ですが、処理時間と対応件数を記録します。利用価値が確認できても、手作業のまま事業が成立するとは限りません。
公開後の計測を後回しにする
アクセス数だけでは、課題が解決したか分かりません。完了・継続・支払いなど、仮説に対応する行動と失敗理由を公開時から記録できるようにします。
よくある質問
MVPに必要な機能数は何個ですか
固定の数はありません。中心となる価値を届け、安全に利用でき、結果も測れる最小限の機能を選びます。同じ予約サービスでも、対象業務や既存システムによって必要な機能は変わります。
予算に収まらない場合は何を削りますか
対象ユーザー、業務、連携先、対応環境を狭められるか検討します。必要な品質を保てないなら、プロトタイプなど別の検証方法に切り替える判断も必要です。
手作業を含んでもMVPと呼べますか
はい。自動化の有無より、顧客の行動から仮説を検証できるかが重要です。ただし、人手による待ち時間や対応上限が評価に影響するため、運用条件を記録してください。
