MVPの要件定義とは、「何を作るか」ではなく「何を検証するか」を文書化する作業です。一般的なシステム開発の要件定義が「完成させる機能の合意」を目的とするのに対し、MVPの要件定義は「事業仮説を検証できる最小範囲の合意」を目的とします。
この違いを押さえずに通常の要件定義書のフォーマットでMVPを定義すると、機能一覧だけが膨らみ、何を確かめるためのMVPなのかが曖昧になります。MVP開発全体の流れはMVP開発とはで解説しています。本記事はその中の「開発前に文書化する項目」を、書き方とテンプレートまで深掘りします。
この記事のポイント
- MVPの要件定義は、機能一覧ではなく「検証の設計書」
- 中心は検証仮説・判断基準・対象範囲の3点。機能はそこから逆算する
- 対象外(作らないもの)と終了条件(いつ判定するか)を明文化する
- 非機能要件は「対象範囲で安全に実利用できる最低条件」に絞る
- 「作り直す部分」と「育てる部分」を開発前に分けておく
一般的な要件定義との違い
| 観点 | 一般的なシステム要件定義 | 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点が合意できれば、残りは1〜2日で文書化できます。時間がかかる場合は、要件定義ではなく仮説の絞り込みが終わっていないことがほとんどです。
要件定義書は誰が書くべきですか
検証結果で継続・変更・撤退を判断する人(事業側の責任者)が仮説と判断基準を書き、開発側が機能・非機能・計測を具体化する分担が実務的です。開発会社に外注する場合も、仮説と判断基準は発注側が持ちます。
検証の途中で要件を変えてもよいですか
判断基準(成功・撤退条件)は変えません。結果を見てから基準を動かすと、検証になりません。一方、計測方法の改善や運用手順の修正は問題ありません。
