MVP開発・PoC

MVPの要件定義の進め方：検証に必要な範囲だけを決めて合意する

MVPの要件定義で決めるべきことは、検証したい仮説を確かめるのに必要な範囲と、その範囲が完成したと判断する基準です。すべての機能を事前に決め切ろうとするのではなく、「作るもの」「作らないもの」「受け入れの基準」を短い文書にまとめ、発注側と開発側で合意することが要件定義のゴールになります。

要件定義は発注側の仕事

IPA（情報処理推進機構）の「ユーザのための要件定義ガイド 第2版」の案内では、システムの要件を定義する責任は、構築されたシステムを利用してビジネスに貢献する役目を負うユーザにあると言われている、と述べています。IPAのDX SQUAREの解説も、開発会社に支援を受ける場合でも、要件定義の成果物に対する責任はユーザー企業にあると説明しています。

MVPでも同じです。開発会社は作り方の専門家ですが、何を確かめるために何を作るかは、事業を担う側が決めなければなりません。外注先に「おすすめの機能で」と任せると、検証に不要な機能が増えたり、確かめたいことが確かめられない製品ができたりします。

同じ解説では、要件定義の大まかな流れとして、業務の観点からの要求（ビジネス要求）を定義し、それをもとにシステムへの要求（機能面と非機能面）を整理し、関係者と合意して「要件」にする、という順序が示されています。MVPではこれを小さく、速く回します。

進め方の手順

1. 検証する仮説と合格ラインを書く

最初に、このMVPで何を確かめるかを1〜3文で書きます。「中小の小売店が、在庫の自動発注の提案を週1回以上使うか」「月額料金を払って継続利用するか」などです。あわせて、どの数字がどこまで行けば仮説が支持されたと判断するかも決めます。PoC・プロトタイプとの違いはPoC・プロトタイプ・MVPの違いと進め方で解説しています。

合格ラインが決まると、それを測るために必要な機能と計測の仕組みが決まります。逆に、合格ラインの判断に関係しない機能は、今回は作らない候補になります。

2. 主な利用者と、中心となる利用の流れを1本に絞る

対象ユーザーを具体的に決め、その人が製品を使う中心の流れを1本書きます。「店長が朝、提案一覧を開き、発注する商品を選んで確定する」といった形です。例外的な使い方や、別の種類の利用者の流れは、中心の流れが検証できてから広げます。

3. 機能をユーザーの言葉で書く

機能は画面や技術の言葉ではなく、「誰が、何のために、何をできるか」の形で書くと、開発側と誤解なく共有しやすくなります。

  • 店長として、発注候補の一覧を見たい。発注漏れを防ぐため
  • 店長として、提案された数量を変更して確定したい。店の事情を反映するため
  • 運営者として、各店舗が提案を開いた回数と確定した回数を見たい。利用が定着しているかを判断するため

最後の例のように、検証のための計測も要件として書きます。計測を後回しにすると、MVPを出しても判断材料が集まりません。

4. 「作る」「後回し」「作らない」に分ける

書き出した機能を3つに分けます。

  • 作る：仮説の検証に欠かせないもの
  • 後回し：検証の結果が良ければ次に作るもの
  • 作らない（手作業で代替する）：運営側が手作業で対応できるもの。たとえば請求書の発行、アカウントの登録、データの取り込みなど

「作らない」を明記しておくことが重要です。書いていない機能は、開発の途中で「当然あるもの」として追加されやすいからです。

5. 非機能要件の最低ラインを決める

非機能要件は、業務には直接現れないものの、機能を実現するために必要な事項です。稼働率、応答時間、セキュリティなどが該当します。DX SQUAREの解説では、非機能面はビジネス要求には表れにくいため、システム部門が主体になって業務部門から要求を聞き出すのが効率的だとしています。

MVPでは高い水準は求めませんが、次の点は最初に決めておきます。

  • 扱うデータの種類（個人情報や取引先の機密情報を扱うか）と、その保護の方法
  • 利用者の人数と、同時に使う人数の目安
  • 利用する端末とブラウザ
  • 止まった場合の許容範囲（営業時間中に止まってよいか）
  • ログインの方法とアカウントの管理

IPAは、非機能要求についてユーザと開発者の認識の行き違いを防ぐための「非機能要求グレード」を公開しています。本格開発に進むときの確認項目として参考になります。

6. 受け入れ基準を決める

機能ごとに「どうなっていれば完成とするか」を決めます。「提案一覧に、在庫が設定値を下回った商品がすべて表示される」「数量を変更して確定すると、確定履歴に反映される」のように、確認できる形で書きます。受け入れ基準がないと、完成したかどうかの判断が人によって変わり、検収でもめる原因になります。

7. 変更の扱いを決める

MVPでは、開発の途中で優先順位が変わるのが普通です。誰が変更を決めるのか、変更したときに何を削るのか、費用や期間が増える場合は誰が承認するのかを決めておきます。請負と準委任で変更の扱いが大きく違うため、契約の考え方は開発会社との契約の注意点（請負と準委任）も参照してください。

要件シートの項目例

MVPの要件は、数ページのシートにまとめれば十分なことが多いです。

項目 書く内容
目的 検証する仮説と合格ライン
対象ユーザー 誰が使うか、何人くらいか
中心の利用の流れ 1本の流れを文章か簡単な図で
機能一覧 ユーザーの言葉で書いた機能と、作る・後回し・作らないの区分
計測 合格ラインを判断するために取るデータ
非機能の最低ライン データの扱い、利用規模、端末、停止の許容範囲、ログイン
受け入れ基準 機能ごとの完成の判断基準
前提と制約 期限、予算の上限、使う外部サービス、社内規程
変更の扱い 変更を決める人、承認の手順

請負で発注する場合とアジャイルで進める場合

作るものを確定させてから請負で発注する場合は、要件シートがそのまま見積もりと検収の基準になります。受け入れ基準まで具体的に書いておく必要があります。

アジャイル開発で進める場合は、要件シートの機能一覧が最初のバックログ（開発項目の一覧）になり、優先順位の高いものから詳しくしていきます。最初から全部を細かく書く必要はありませんが、目的、合格ライン、「作らない」の区分、非機能の最低ラインは開発前に合意しておきます。進め方はアジャイル開発の進め方と発注側の役割で解説しています。

大企業と起業家で異なる点

大企業の場合

社内の情報セキュリティ規程、個人情報の取り扱いの規程、ブランドの利用ルールなどが、非機能要件として事実上決まっていることがあります。MVPの段階で規程を満たせない部分があると、公開の直前に止まることになります。情報システム部門、法務、情報セキュリティの担当者には、要件定義の段階で相談し、MVPとして許される範囲を確認しておきます。

また、関係部署の要望をすべて取り込むと、MVPが大きくなります。「今回の検証に必要か」という基準で、後回しにする項目を関係者と合意することが、担当者の重要な仕事になります。

起業家の場合

創業者自身が要件を決める立場になります。顧客の声を聞くほど機能を足したくなりますが、合格ラインの判断に関係しない機能は後回しにします。技術に詳しくない場合は、要件シートを開発者に見せて、実現が難しい項目や、より簡単に確かめる方法がないかを相談します。

よくある失敗

  • 「今と同じ」「一般的な機能で」と書く：DX SQUAREの解説でも、「今と同じ」という要求はトラブルの元とされています。MVPでも、具体的に書いていない要件は伝わりません
  • 計測を要件に入れない：公開しても、仮説が支持されたかどうかを判断できません
  • 非機能要件を後回しにする：個人情報を扱うのに保護の方法を決めていない、利用規模を想定していない、などは公開直前の手戻りにつながります
  • 要件定義を開発会社に任せきりにする：開発会社の支援を受けるのは有効ですが、何を確かめたいかを決めるのは発注側です

参考資料

進め方に迷ったら、相談してください

起業家ポータル のメンバーが話を伺います。初回の相談は無料です。

相談する

同じ工程の記事