MVP要件とは、最小限の製品で顧客価値や事業仮説を検証するために、満たすべき条件です。必要な機能に加え、対象ユーザー、安全に使える品質、計測方法、検証を終えて判断する条件を含みます。「MVP要件」という言葉に、すべての製品へ共通する固定の機能一覧があるわけではありません。
MVPの要件定義は、これらの条件を関係者で合意し、文書化する作業です。通常の開発でも価値や成果の合意は重要ですが、MVPでは特に「どの仮説を、どの最小範囲で確かめるか」を明示します。開発全体の流れはMVP開発とはを参照してください。
この記事のポイント
- MVPの要件定義は、機能一覧ではなく「検証の設計書」
- 中心は検証仮説・判断基準・対象範囲の3点。機能はそこから逆算する
- 対象外(作らないもの)と終了条件(いつ判定するか)を明文化する
- 非機能要件は「対象範囲で安全に実利用できる最低条件」に絞る
- 「作り直す部分」と「育てる部分」を開発前に分けておく
MVP要件・スコープ・受け入れ条件の違い
| 用語 | 意味 | 問い合わせ分類サービスの例 |
|---|---|---|
| MVP要件 | 検証のために満たす条件 | 担当者が分類結果を確認・修正できる |
| MVPスコープ | 今回扱う範囲と対象外 | 一部署の日本語の問い合わせだけを対象にする |
| 受け入れ条件 | 実装が要件を満たすか確認する条件 | 修正した分類が保存され、再表示しても反映されている |
| 仮説の成功条件 | 顧客価値が支持されたと判断する条件 | 修正負担を含めても業務で継続利用される |
「動作確認に合格した」と「顧客に価値があった」は別の判断です。受け入れ条件と仮説の成功条件を分けると、開発完了だけで検証成功と結論づけることを防げます。範囲の絞り方はMVPスコープの決め方で解説しています。
一般的な要件定義との違い
MVPでも、機能・品質・運用の条件は合意します。そのうえで、完成像を網羅することより、今回の学習に必要な範囲を明確にすることへ重点を置きます。
| 観点 | MVPの要件定義で明示すること |
|---|---|
| 目的 | 今回確かめる仮説と、次に行う事業判断 |
| 対象範囲 | 今回提供する体験と、提供しない機能・利用場面 |
| 完了の定義 | 開発の受け入れ条件と、検証を終了する条件の両方 |
| 変更の扱い | 学習に伴う変更の判断者と、計測への影響 |
| 品質 | 限定した対象範囲で安全に利用・評価できる条件 |
| 成果物の寿命 | 検証後に作り直す部分と、継続して使う部分 |
文書の分量を減らすだけでは、判断基準・計測・終了条件が抜け落ちます。機能一覧を作る前に、何を学びたいかを合意してください。
MVP要件定義書に書く10項目
- 検証仮説 — 外れたら事業が成立しない問いを一つに絞る。「誰が・どの場面で・何をするか」を含む文にする
- 対象ユーザー — 属性ではなく、行動で特定できる範囲(例: 毎日問い合わせを振り分けている担当者)
- 対象業務・利用場面 — 一つの利用場面が最初から最後まで完結する範囲
- 対象外 — 今回は作らない・検証しないと明記する範囲。書かれていないものは「未定」ではなく「対象外」とする
- 成功条件 — 何が観測されたら仮説が支持されたと判断するか
- 終了条件 — いつ・何をもって検証を終え、継続・変更・撤退を判定するか(判定日と責任者)
- 機能要件 — 仮説の検証に必要な機能だけを、価値・安全・計測の分類付きで列挙する
- 非機能要件 — 対象範囲で安全に実利用できる最低条件(認証、データ保護、エラー時の振る舞い)
- 計測イベント — どの行動を、どのタイミングで、どうやって記録するか
- 運用方法 — 利用者の募集・案内、サポート窓口、データの扱い、作り直す部分と育てる部分の区別
1〜3が決まらないうちに7(機能要件)から書き始めると、機能一覧が仮説より先に固定されます。順番どおりに書くこと自体が、スコープを守る仕組みになります。
機能要件は4分類で逆算する
機能要件は要望の一覧ではなく、検証仮説からの逆算で決めます。候補を「価値・安全・計測・保留」の4つに分類し、保留以外だけを要件にします。
| 分類 | 判断する問い | 要件に入れるか |
|---|---|---|
| 価値 | ないと中心価値を体験できないか | 入れる |
| 安全 | ないと実業務で安全に使えないか | 入れる |
| 計測 | ないと仮説の成否を観測できないか | 入れる |
| 保留 | 仮説が通った後に追加できるか | 対象外に明記 |
この分類の詳しい使い方はMVPの機能はどこまで絞るべきかで解説しています。
非機能要件は「最低条件」に絞る
MVPでも省略できないのは、対象範囲での安全性です。ただし、全社システム並みの非機能要件を課すと、MVPの意味がなくなります。
- 必須にするもの — 認証・権限(対象ユーザーに限定する仕組み)、個人情報・機密データの保護、誤動作時に人が検知・停止できること
- 限定してよいもの — 同時利用者数(招待制なら少数でよい)、稼働時間(業務時間内のみ等)、対応環境(一つのブラウザ・端末でよい)
- 後回しにできるもの — 大量アクセス対応、多言語、全社SSO連携、監査要件(対象範囲に含まれない場合)
「限定してよいもの」は、要件定義書に限定した事実そのものを書きます。書いておけば、検証結果を解釈するときに「性能が理由で使われなかったのか」を切り分けられます。
記入例 — 問い合わせ分類サービスの場合
以下は仮想例です。利用日数の割合や期間は共通の推奨値ではなく、対象業務の頻度と意思決定に必要な情報量に合わせて設定します。
| 項目 | 記入例 |
|---|---|
| 検証仮説 | 毎日振り分けを行う担当者は、確認・修正を含めても手作業より価値を感じ、継続利用する |
| 対象ユーザー | 共有メールボックスの振り分けを毎日行っている担当者(1部署) |
| 対象業務 | 問い合わせメールの分類 → 確認・修正 → 担当部署への引き渡し |
| 対象外 | 経営ダッシュボード、多言語、全社権限管理、完全自動送信 |
| 成功条件 | 検証期間中、対象業務日の8割以上でMVPが使われ、担当者が継続利用を希望する |
| 終了条件 | 公開から4週間後に判定。責任者は事業担当役員 |
| 計測イベント | 日次の利用有無、分類の修正発生箇所、手作業に戻った日とその理由 |
| 運用方法 | 担当者へ直接案内、問い合わせはチャットで受付、検証データは検証終了後に扱いを判断 |
MVP要件定義書テンプレート
そのままコピーして使えるテンプレートです。
# MVP要件定義書: (プロジェクト名)
## 1. 検証仮説
- (誰が)(どの場面で)(何をするか) → 外れたら事業が成立しない問い
## 2. 判断基準
- 成功条件:
- 保留条件:
- 撤退条件:
- 判定日: / 判定責任者:
## 3. 対象範囲
- 対象ユーザー:
- 対象業務・利用場面:
- 対象外(今回作らない・検証しないもの):
## 4. 機能要件(価値/安全/計測の分類付き)
| 機能 | 分類 | 理由 |
| ---- | ---- | ---- |
## 5. 非機能要件(対象範囲での最低条件)
- 認証・権限:
- データ保護:
- 限定する条件(利用者数・稼働時間・環境):
## 6. 計測イベント
| 観測する行動 | 記録方法 | 確認頻度 |
| ------------ | -------- | -------- |
## 7. 運用
- 利用者の募集・案内:
- サポート窓口:
- 作り直す部分 / 育てる部分:
よくある失敗
機能一覧から書き始める
要望を並べた一覧は、どの仮説を検証するかを決めてくれません。検証仮説と判断基準を先に固定し、機能はそこから逆算します。
対象外を書かない
「書いていないもの」は、関係者ごとに解釈が分かれます。対象外を明記しないと、開発中に少しずつ範囲が広がり、期間と費用が膨らみます。
判定日を決めずに公開する
終了条件がないMVPは、いつまでも「様子見」が続きます。結果を見る前に判定日と責任者を決め、要件定義書に書きます。
よくある質問
MVPの要件定義にはどれくらい時間をかけるべきですか
一律の期間はありません。検証仮説・判断基準・対象範囲の3点から着手し、データの扱いや外部連携、関係者との合意に必要な時間を見積もります。小規模なMVPでも、利用者の保護や運用条件の確認を省略しないでください。
要件定義書は誰が書くべきですか
検証結果で継続・変更・撤退を判断する人(事業側の責任者)が仮説と判断基準を書き、開発側が機能・非機能・計測を具体化する分担が実務的です。開発会社に外注する場合も、仮説と判断基準は発注側が持ちます。
検証の途中で要件を変えてもよいですか
変更できますが、理由・判断者・適用日を記録します。結果を都合よく成功に見せるための基準変更は避けてください。仮説や成功条件を変える必要があるなら、別の検証として区切り、変更前後のデータを混ぜずに評価します。
