# MVPとは

MVP（Minimum Viable Product）は、新規の製品やサービスが利用されるかを、作り込みの前に実際の利用者で検証する最初の版です。反応を観測する体制がない場合や、需要と使い方が確認済みの刷新は、対象外です。

## MVPとは

MVPは新規の製品やサービスを顧客が必要とし、利用し、購入するかを最小の労力で検証する最初の版です。[顧客についての検証された学びを最小の労力で最大限に収集できる版](https://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html)が、リーン・スタートアップでの定義です。検証された学びとは利用者が使用し購入するかなどを[実験で仮説を検証して得られる知見](https://theleanstartup.com/principles)です。形は稼働する製品に限らず、[紹介ページだけの公開や、裏側を手作業で運営するサービス](https://agilealliance.org/glossary/mvp/)も含みます。紹介ページなら申込みのクリック数で需要を、予約システムなら受付だけを一部の店舗で提供し、予約の継続で検証します。新メニューを全店で提供する前に、1店舗で限定販売する進め方に近いです。

PoC（Proof of Concept）は技術的な実現性、MVPは利用者が価値を認めるかを検証します。一方、プロトタイプは画面や操作などの設計案を試験する試作で、本番提供は前提にしません。

![PoC、プロトタイプ、MVPの検証対象を比較した図。PoCは技術的に実現可能か、プロトタイプは画面や操作などの設計案、MVPは利用者が価値を認めるかが対象で、MVPだけが強調されている。](https://media.marketing.kdotdev-tunnel.org/glossary-mvp-42a534fec9153bbaaf80e375cb2607fbf3f65dee8a8774c9ac3b8911422edda3.png)

## なぜ必要か

全機能を開発してから公開すると、利用されないと分かるのは完成した後になります。製品を数か月から数年かけて作り込み、[見込み客に一度も提示しないまま失敗する例が多い](https://theleanstartup.com/principles)とされています。検討すべきは開発できるかでなく、[開発すべきか、事業として持続するか](https://theleanstartup.com/principles)だとされています。

![全機能を開発してから公開する場合と、小さな版から公開する場合を時間軸で比較した図。前者は開発期間が長く、公開の後に利用されないと分かる。後者は短期間で開発して公開した後に反応が分かり、その時点が強調されている。](https://media.marketing.kdotdev-tunnel.org/glossary-mvp-250d5e836223f0c22f7ef89848d5d56b4d071c38418a1069b44b730deeca4550.png)

組織内の仕組みでも事情は同じです。スウェーデン警察が開始した車載端末の開発では、以前の試みが[最初のリリースまで7年かかり、状況が変化して失敗した](https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp)と報告されています。この取り組みは対象を地域と犯罪の種類で分割し、[1地域の数名の警官が利用する小さな版から開始](https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp)しました。その反応を反映しながら対象を拡大し、[全国の1万2千人に展開](https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp)しています。

## 効果

- 利用されない製品への大きな投資を、小さな版の結果で中止できる
- [事前の分析を徹底しても、最初の実利用で想定外の事実が判明する](https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp)ため、実態に反する想定に基づく機能の作り込みを避けられる
- 優先順位の議論に、検証したい仮説に必要かという基準ができる

## コストとリスク

- 検証には利用者との対話と計測に[相当な労力が必要になる](https://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html)。対象者の募集、説明、利用の支援にも時間がかかる
- 問合せ対応、障害対応、データの保全は、利用者がいる場合に必要になりやすく、少人数でも運用担当者の配置が必要になる。裏側を手作業で運営する場合は、利用者が増加するほど処理の負担が増加する
- 暫定的な作りのまま機能を追加すると、後から改修する手間が積み上がる。継続する場合の改修と拡張の費用を想定する
- 中止する場合も利用者への通知、データの返却や削除、必要な代替手段の費用がかかる
- 継続、方向転換、中止を決定する責任者が必要になる。決定する人がいないとMVPは作りっぱなしになりやすい
- [初版の後に担当が次の案件へ移行し、不具合の多い未完成品が残存する例が指摘されている](https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp)

![MVPで発生する費用を時期別に示した模式図。検証の対話と計測、運用の問合せ・障害の対応が結果の時点まで継続する。結果の後は継続する場合の運用と改修、中止する場合の通知・返却・代替手段に分岐する。結果の時点で決定する責任者が必要だと示している。](https://media.marketing.kdotdev-tunnel.org/glossary-mvp-67668702a9d9bc4a855cc514f9907701797934946913ea9597647b7430a761f0.png)

## 初版の機能はどこまで削減すればよいか

検証したい仮説に必要なものだけを初版に含め、利用者が価値を認める中心の体験は削減しません。

![初版の範囲と後回しにするものを区分した図。破線の枠の中の初版の範囲は中心の体験、安全面、検証に必要な機能で、中心の体験は削減しないと強調している。枠の外の仮説に関係しない機能、管理画面、ログインは、検証に必須でなければ後回しか代替にする。](https://media.marketing.kdotdev-tunnel.org/glossary-mvp-d902a4eb0a0c7b7be6f3d428762b8e09682b1eeb6d28c1dc30109abdb7e2ab78.png)

- 誰のどんな困りごとについて、何を検証するのかを簡潔に説明できるようにする
- 仮説に関係しない機能は後回しにする。ログインや管理画面は検証に必須でなければ表計算ソフトや手作業で代替できる。支払いに値するかを検証したい場合は、決済画面を省略しても、実際の支払いの機会は確保する
- 安全面は省略の対象にしない。個人情報取扱事業者には個人情報保護法が個人データの漏えいなどを防止する[必要かつ適切な措置](https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/)を求めている。手作業で代替する場合も担当者、閲覧できる範囲、保存と削除の方法を決定する
- 対象を限定する。警察の例のように、地域や業務の種類で区分して一部の人から開始する。最初の利用者には[機能が不足していても許容して利用してくれる早期の採用者](https://www.startuplessonslearned.com/2009/03/minimum-viable-product.html)を選定する。その反応が一般の顧客にそのまま適用できるとは限らない
- 反応の観測に長期間かかる場合は、製品全体を開発せずに検証できないかを検討する。[2週間かけて開発した機能が誰にも求められなかった例](https://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html)では、検索連動広告による簡単な試験で十分だったと説明されている

[最小限と実用の意味は人によって異なる](https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp)ため、開始前に、初版で利用者が完了できる行動と、提供しない機能を関係者で共有しておきます。

## 継続と中止の基準は何か

開発の前に、どの結果なら拡張し、方向転換し、中止するかを決定しておきます。結果を確認してから決定すると、どの結果も成功と解釈してしまうおそれがあります。

予約システムの例で、店舗の電話受付の負担を軽減する仮説を検証するとします。仮説の成否を測定する指標をKPI（Key Performance Indicator）として設定し、予約件数だけでなく電話の予約が減少したかも確認します。新規の受付による効果かを判定するには、[原因と結果を明示できる指標](https://theleanstartup.com/principles)が必要です。

- 指標は言葉でなく行動で測定する。予約が完了したか、再び予約したか、電話が減少したか。有料サービスなら支払いがあったか、支払いを継続しているか
- 基準は対象者、検証人数、通常の利用頻度、測定する行動とセットで決定する。客が月に1回来店する店舗なら、翌週の再利用は測定できず、翌月の再予約を確認する。人数や利用機会が不足する間は判断を保留する
- 結果が悪いときは中止の前に原因を分類する。予約画面に到達した人が少ないなら告知や導線、到達しても完了しない利用者が多いなら操作や入力項目、新規の受付でなく電話を選択するなら新規の受付への需要不足が原因の候補になる。利用行動の記録と利用者へのヒアリングで確認する
- 方向転換するときは対象者、提供価値、価格、提供方法のどれに関する仮説を変更するかを特定する。[方向転換の時期と継続の時期の判断](https://theleanstartup.com/principles)が、リーン・スタートアップの中心である

![予約システムの例で、結果の現れ方ごとに原因の候補を示した図。画面への到達が少ないなら告知・導線、到達しても完了しないなら操作・入力項目、新規の受付でなく電話を選択する場合は新規の受付への需要不足が原因の候補になる。](https://media.marketing.kdotdev-tunnel.org/glossary-mvp-858ad682a30c2f16f48138758c03439aede98e0fcf829d3aff4c8bf46990fef7.png)

## MVPで検証しない方がよいのはどんな場合か

需要と使い方が確認済みで大きな不確実性がない場合は、MVPによる検証は不要です。要件が確定しているだけでは、利用価値が確認済みとは限りません。

- 開発対象の複雑さとリスクが軽微で、同種の開発を何度も経験している場合は、[全体を開発してから公開する進め方で十分である](https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp)。操作性、安全性、移行の検証は別に必要
- 既存の基幹業務の刷新のように、現行の機能がすべて必要な場合は、機能を限定した初版では業務が停止する。必要なのは価値の検証でなく安全な移行のため、MVPで検証せず、限定するのは移行する拠点や業務の範囲になる。他システムとの依存で分割できない業務もある
- 目の前の困りごとを解消するだけの場合は、[MVPは不要](https://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html)とされているため、MVPで検証せずそのまま解消する
- 反応を観測する担当者や手段を用意できない場合は、小規模に公開しても学びが得られないため、MVPは実施しない

![MVPで検証するかを決定する二段階の分岐図。需要と使い方が確認済みで、検証すべき大きな不確実性がないならMVP不要。そうでなく、反応を測定する人と手段があればMVPで検証する。なければMVPは実施しない。](https://media.marketing.kdotdev-tunnel.org/glossary-mvp-2ec78b686a7ddd12437e13d3b40953a803a7016c64e3a54cb22b547b8cd43fc4.png)

## よくある誤解

### 品質を低下させてよい版である

削減するのは機能の範囲で、検証が成立する中心の体験の品質は削減しません。品質が不足すると[利用者が使用するかを正確に評価できません](https://agilealliance.org/glossary/mvp/)。Spotifyの初期の試作は、固定の数曲を検索して再生する以外の機能がない一方で、[再生ボタンの操作から再生開始までの応答速度に注力していました](https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp)。

### MVPを開発したら完了である

[利用者の反応に応じて、製品を継続する、方向転換する、中止する](https://agilealliance.org/glossary/mvp/)のが想定された使い方です。

### 最初に決定した最終形へ機能を追加していく工程である

検証によって最終形が当初の想定から変化することがあります。自動車を求める利用者に小さな乗り物を提供して反応を確認すると、[自転車のほうがよい製品だと分かる](https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp)という比喩があります。

![誤解と実際の進め方を比較した図。誤解では初版に機能を追加して最初に決定した最終形へ進行する。実際は初版への利用者の反応を確認し、製品を継続する、仮説を変更する、製品を中止するのいずれかを決定する。](https://media.marketing.kdotdev-tunnel.org/glossary-mvp-d803c56912e5ec157db5ba296c6c3814363a5c1005cc09c34a434e62fd8db803.png)

### 新規事業や新興企業だけの考え方である

警察の車載端末のように、組織内の仕組みにも適用できます。適用の条件は利用者の反応を観測でき、その結果に応じて判断を変更できることです。