MVPとは｜ビジネスサイドのための IT 用語集

 MVPとはMVPは新規の製品やサービスを顧客が必要とし、利用し、購入するかを最小の労力で検証する最初の版です。顧客についての検証された学びを最小の労力で最大限に収集できる版が、リーン・スタートアップでの定義です。検証された学びとは利用者が使用し購入するかなどを実験で仮説を検証して得られる知見です。形は稼働する製品に限らず、紹介ページだけの公開や、裏側を手作業で運営するサービスも含みます。紹介ページなら申込みのクリック数で需要を、予約システムなら受付だけを一部の店舗で提供し、予約の継続で検証します。新メニューを全店で提供する前に、1店舗で限定販売する進め方に近いです。
PoC（Proof of Concept）は技術的な実現性、MVPは利用者が価値を認めるかを検証します。一方、プロトタイプは画面や操作などの設計案を試験する試作で、本番提供は前提にしません。
 なぜ必要か全機能を開発してから公開すると、利用されないと分かるのは完成した後になります。製品を数か月から数年かけて作り込み、見込み客に一度も提示しないまま失敗する例が多いとされています。検討すべきは開発できるかでなく、開発すべきか、事業として持続するかだとされています。
組織内の仕組みでも事情は同じです。スウェーデン警察が開始した車載端末の開発では、以前の試みが最初のリリースまで7年かかり、状況が変化して失敗したと報告されています。この取り組みは対象を地域と犯罪の種類で分割し、1地域の数名の警官が利用する小さな版から開始しました。その反応を反映しながら対象を拡大し、全国の1万2千人に展開しています。
 効果利用されない製品への大きな投資を、小さな版の結果で中止できる
事前の分析を徹底しても、最初の実利用で想定外の事実が判明するため、実態に反する想定に基づく機能の作り込みを避けられる
優先順位の議論に、検証したい仮説に必要かという基準ができる
 コストとリスク検証には利用者との対話と計測に相当な労力が必要になる。対象者の募集、説明、利用の支援にも時間がかかる
問合せ対応、障害対応、データの保全は、利用者がいる場合に必要になりやすく、少人数でも運用担当者の配置が必要になる。裏側を手作業で運営する場合は、利用者が増加するほど処理の負担が増加する
暫定的な作りのまま機能を追加すると、後から改修する手間が積み上がる。継続する場合の改修と拡張の費用を想定する
中止する場合も利用者への通知、データの返却や削除、必要な代替手段の費用がかかる
継続、方向転換、中止を決定する責任者が必要になる。決定する人がいないとMVPは作りっぱなしになりやすい
初版の後に担当が次の案件へ移行し、不具合の多い未完成品が残存する例が指摘されている
 初版の機能はどこまで削減すればよいか検証したい仮説に必要なものだけを初版に含め、利用者が価値を認める中心の体験は削減しません。
誰のどんな困りごとについて、何を検証するのかを簡潔に説明できるようにする
仮説に関係しない機能は後回しにする。ログインや管理画面は検証に必須でなければ表計算ソフトや手作業で代替できる。支払いに値するかを検証したい場合は、決済画面を省略しても、実際の支払いの機会は確保する
安全面は省略の対象にしない。個人情報取扱事業者には個人情報保護法が個人データの漏えいなどを防止する必要かつ適切な措置を求めている。手作業で代替する場合も担当者、閲覧できる範囲、保存と削除の方法を決定する
対象を限定する。警察の例のように、地域や業務の種類で区分して一部の人から開始する。最初の利用者には機能が不足していても許容して利用してくれる早期の採用者を選定する。その反応が一般の顧客にそのまま適用できるとは限らない
反応の観測に長期間かかる場合は、製品全体を開発せずに検証できないかを検討する。2週間かけて開発した機能が誰にも求められなかった例では、検索連動広告による簡単な試験で十分だったと説明されている
最小限と実用の意味は人によって異なるため、開始前に、初版で利用者が完了できる行動と、提供しない機能を関係者で共有しておきます。
 継続と中止の基準は何か開発の前に、どの結果なら拡張し、方向転換し、中止するかを決定しておきます。結果を確認してから決定すると、どの結果も成功と解釈してしまうおそれがあります。
予約システムの例で、店舗の電話受付の負担を軽減する仮説を検証するとします。仮説の成否を測定する指標をKPI（Key Performance Indicator）として設定し、予約件数だけでなく電話の予約が減少したかも確認します。新規の受付による効果かを判定するには、原因と結果を明示できる指標が必要です。
指標は言葉でなく行動で測定する。予約が完了したか、再び予約したか、電話が減少したか。有料サービスなら支払いがあったか、支払いを継続しているか
基準は対象者、検証人数、通常の利用頻度、測定する行動とセットで決定する。客が月に1回来店する店舗なら、翌週の再利用は測定できず、翌月の再予約を確認する。人数や利用機会が不足する間は判断を保留する
結果が悪いときは中止の前に原因を分類する。予約画面に到達した人が少ないなら告知や導線、到達しても完了しない利用者が多いなら操作や入力項目、新規の受付でなく電話を選択するなら新規の受付への需要不足が原因の候補になる。利用行動の記録と利用者へのヒアリングで確認する
方向転換するときは対象者、提供価値、価格、提供方法のどれに関する仮説を変更するかを特定する。方向転換の時期と継続の時期の判断が、リーン・スタートアップの中心である
 MVPで検証しない方がよいのはどんな場合か需要と使い方が確認済みで大きな不確実性がない場合は、MVPによる検証は不要です。要件が確定しているだけでは、利用価値が確認済みとは限りません。
開発対象の複雑さとリスクが軽微で、同種の開発を何度も経験している場合は、全体を開発してから公開する進め方で十分である。操作性、安全性、移行の検証は別に必要
既存の基幹業務の刷新のように、現行の機能がすべて必要な場合は、機能を限定した初版では業務が停止する。必要なのは価値の検証でなく安全な移行のため、MVPで検証せず、限定するのは移行する拠点や業務の範囲になる。他システムとの依存で分割できない業務もある
目の前の困りごとを解消するだけの場合は、MVPは不要とされているため、MVPで検証せずそのまま解消する
反応を観測する担当者や手段を用意できない場合は、小規模に公開しても学びが得られないため、MVPは実施しない
 よくある誤解 品質を低下させてよい版である削減するのは機能の範囲で、検証が成立する中心の体験の品質は削減しません。品質が不足すると利用者が使用するかを正確に評価できません。Spotifyの初期の試作は、固定の数曲を検索して再生する以外の機能がない一方で、再生ボタンの操作から再生開始までの応答速度に注力していました。
 MVPを開発したら完了である利用者の反応に応じて、製品を継続する、方向転換する、中止するのが想定された使い方です。
 最初に決定した最終形へ機能を追加していく工程である検証によって最終形が当初の想定から変化することがあります。自動車を求める利用者に小さな乗り物を提供して反応を確認すると、自転車のほうがよい製品だと分かるという比喩があります。
 新規事業や新興企業だけの考え方である警察の車載端末のように、組織内の仕組みにも適用できます。適用の条件は利用者の反応を観測でき、その結果に応じて判断を変更できることです。