MVP開発の進め方｜検証する仮説と最小機能の決め方

MVP開発で最初に決めるのは、画面数でも開発期間でもありません。誰のどの課題について、何が分かれば次の投資を判断できるかです。その答えを得るために必要な最小限の体験を作り、実際の利用から学ぶのがMVP開発です。

MVPは「安価な完成品」や「品質を落とした製品」の言い換えではありません。検証に不要な機能は外しますが、対象にした利用者が目的を達成できること、預かったデータを適切に扱えること、結果を測れることは必要です。本記事では、発注者が仮説、機能、評価方法を一つの計画へまとめる手順を解説します。

MVP開発とは、次の判断に必要な証拠を作ること

MVPはMinimum Viable Productの略です。実用可能な最小限の製品を利用者へ提供し、反応をもとに継続、修正、中止を判断します。プロダクトの価値を保ちながら、一度に検証する範囲を最小化します。

たとえば「営業担当者が商談メモから提案書の初稿を作れるAIサービス」を考えます。初回から顧客管理、請求、権限管理、スマートフォンアプリまで作る必要はありません。一方、架空の画面だけでは、提案書作成に使えるか、出力をどの程度直すか、機密情報を安全に扱えるかを確かめられません。

最初の検証カードを、次の5項目で作ります。

この5項目を埋められなければ、機能一覧を作る前に利用者への聞き取りが必要です。デジタル庁も、利用者の目的、タスク、利用環境を踏まえてサービスを設計することを、利用者中心の考え方として示しています。

プロトタイプ、PoC、MVPを使い分ける

検証手段は、必ずしも動く製品である必要はありません。知りたいことに合わせて手段を選びます。

画面の理解だけを確かめたい段階なら、プロトタイプの方が速いことがあります。AIの精度や外部APIとの接続可否が最大の不確実性なら、先にPoCを行います。MVPは、技術の実験を終えたことではなく、利用者が一連の目的を達成し、その結果を評価できる状態です。

MVP開発を6つの手順で進める

1. 事業判断を一文にする

「誰のどの行動が確認できたら、何へ投資するか」を一文にします。「MVPを作りたい」だけでは、公開後の判断につながりません。

法人営業5名のうち3名以上が4週間継続し、提案書初稿の作成時間が半分になれば、顧客管理連携の開発へ進む。

数値は正解を当てるためではありません。公開後に都合よく成功条件を変えないための基準です。利用頻度が低い業務なら4週間、日常的な業務なら週単位など、行動が観測できる期間も決めます。

2. 現在の業務を最初から最後まで書く

利用者が目的を達成するまでの行動、使う資料、判断する人、例外を並べます。「提案書を作る」という一語だけでは、入力データも完了条件も分かりません。

1. 商談メモと顧客情報を集める
2. 提案の論点と構成を決める
3. 過去資料を探す
4. 初稿を作る
5. 上長が事実と表現を確認する
6. 顧客へ提出できる形式に整える

この中から、最も負担が大きく、MVPで変化を測れる箇所を選びます。前後の工程を無視すると、生成は速くても確認作業が増え、全体では遅くなることがあります。

3. 機能を「今作る・後で作る・作らない」に分ける

各機能を、検証仮説との関係で分類します。

「競合にあるから」「将来必要そうだから」は、初回に入れる根拠になりません。入れたい機能には、どの仮説をどう確かめるのかを書き添えます。説明できなければ、後の候補へ移します。

4. 完了条件と非機能要件を決める

機能が少なくても、品質条件は消えません。少なくとも次を決めます。

• 利用者と権限：誰がログインし、誰のデータを閲覧・編集できるか
• データ：何を保存し、いつ削除し、外部サービスへ何を送るか
• 受け入れ条件：どの入力で、どの結果になれば機能完了とするか
• 障害時の対応：失敗をどう表示し、再実行や問い合わせをどう行うか
• 計測：利用開始、処理完了、離脱、評価をどのイベントで記録するか
• 運用：問い合わせ、監視、バックアップ、アカウント停止を誰が担うか

IPAのアジャイル型開発に関する資料でも、ユーザーストーリーの具体的な受け入れ条件を明らかにし、プロダクトオーナーと開発者が会話しながら洗い出す考え方が示されています。MVPでも「動いたら完了」にはしません。

5. 小さく公開し、事実を同じ形式で記録する

最初の利用者、期間、問い合わせ窓口を限定します。観察するのはアクセス数だけではありません。

• 対象者のうち何人が使い始めたか
• 目的の操作を何人が完了したか
• 途中で止まった画面と理由は何か
• 作業時間や手戻りは以前からどう変わったか
• 出力をそのまま使えず、どこを直したか
• 再び使った人と、使わなかった人の理由は何か

操作ログだけでは理由が分からず、インタビューだけでは実際の行動を見誤ります。行動データ、成果物、利用者の発言を同じ期間で集めます。個人情報や機密情報を計測基盤へ送らないよう、記録項目も公開前に確認してください。

6. 継続、修正、中止を判断する

結果を、事前に決めた基準と比べます。

• 継続：価値の仮説が支持され、対象者や連携を広げる
• 修正：課題はあるが、体験や対象者の仮説が違っていた
• 中止：課題が弱い、代替手段で十分、運用負担が価値を上回る

中止は開発の失敗とは限りません。大きな投資の前に、仮説が成立しないと分かった成果です。判断を先送りして機能追加を続けると、MVPが単なる長期開発の第1期になります。

発注前に用意する7つの成果物

開発会社へ相談するときは、詳細な仕様書を完成させる必要はありません。次の7点があると、提案の前提をそろえやすくなります。

1. 事業判断の一文
2. 最初の利用者と現在の業務フロー
3. 検証する仮説と成功・中止の基準
4. 今作る・後で作る・作らない機能の表
5. 利用するデータと外部サービス
6. 権限、セキュリティ、運用の最低条件
7. 公開希望時期と予算の上限

画面案があれば添えます。ただし、画面案に合わせて課題を後付けしないでください。複数社へ見積もりを頼む場合は、同じ成果物を渡し、企画、設計、実装、テスト、公開、保守のどこまで含むかを比べます。総額を考えるときは、システム開発の費用相場も参照してください。

見積もりでは「作る量」以外も確認する

MVPの見積もりは、機能数だけで決まりません。仮説整理や利用者調査を誰が行うか、デザイン案を何回検証するか、既存データを移すか、計測や運用をどこまで作るかで変わります。

提案書では次を分けて確認します。

• 仮説・要件を整理する期間と参加者
• 初回リリースに含む機能と対象外
• ソースコード、デザイン、クラウド環境の引き渡し範囲
• 受け入れテストと不具合修正の条件
• 外部サービス利用料と公開後の保守費
• 仕様変更の決め方と追加費用
• 途中で中止するときの成果物と精算方法

MVPだから準委任、完成品だから請負と一律には決まりません。未確定な仮説を一緒に整理する工程と、受け入れ条件を明確にした実装工程で契約を分ける方法もあります。自社の小さな案件に合う相談先は、小規模システム開発会社の選び方で確認できます。

よくある失敗は、機能の多さより判断の曖昧さにある

最初から全利用者を対象にする

部署ごとに業務と権限が違うため、要件が膨らみます。最初は一つの役割と一つの主要業務へ絞り、他部署への展開条件を後で決めます。

ログインできた人数だけで成功とする

登録は価値を得た証拠ではありません。対象の仕事を完了したか、時間や品質が変わったか、再利用したかを測ります。

手作業を一切認めない

初回から管理画面や自動連携をすべて作ると、検証前の投資が増えます。安全に代替できる裏側の作業は手動にし、利用者が受け取る主要な体験へ開発を集中できます。

セキュリティを正式版まで後回しにする

実データを扱うなら、MVPでも権限、保存、削除、委託先、ログの条件が必要です。利用者を限定することは、管理を不要にする理由にはなりません。

公開後も成功条件を決めない

改善要望が増えるほど、何を作るべきか迷います。最初の仮説と次の判断への影響を基準に、優先順位を付けます。

最小の学習単位を作る

MVP開発の中心は、機能を削る作業ではありません。対象者、課題、仮説、証拠、次の判断をつなぎ、その一周を小さくする作業です。

まず、事業判断を一文にします。次に現在の業務を見て、仮説の検証に必要な体験だけを残します。完了条件、データ、計測、運用を決めてから小さく公開し、継続、修正、中止を判断してください。この順番なら、初回リリースを急ぐことと、作る意味を確かめることを両立できます。

参考にした一次情報

• デジタル庁「サービスデザイン」
• IPA「情報システム・モデル取引・契約書（アジャイル開発版）」
• IPA「アジャイル型開発におけるプラクティス活用事例調査」

費用、期間、契約、法務・税務上の扱いは条件により異なります。記事の確認日とリンク先の一次情報を確認し、個別判断は専門家へご相談ください。

システム開発・発注ガイドへ戻る