InsurTechラボ 研究員のたなたかです。
この記事はInsurtechラボ３月アドベントカレンダー企画で「2022年度の学び」について書いています。(16日目)
MVP作成における気をつけたいポイントを解説します。
MVPとは？
MVPとは「Minimum Viable Product」の略で、直訳すると「実現最小限の製品」となります。顧客の課題の有無や、現在検討している解決策を必要としているのかを検証することを目的に、検証に必要最小限のプロダクトを作成する考え方になります。
顧客のニーズや課題に不明確な部分がある場合、作ろうとしているプロダクトは誤っている可能性が高いです。そのため、如何に早く仮説検証を行って不確実性を取り除いて行くかが重要になります。誤ったものを作り、貴重なリソースを失ってしまうことを避けるために、MVPの考え方は有用になると考えられます。
また、MVPは、リーンスタートアップから生まれています。リーンスタートアップの考え方についても、合わせて参考にしておくのがいいと思います。
MVPの種類
MVPは、書籍や記事などを見ると様々な種類が解説されていますが、目的に応じて準備する内容が変わります。種類を選択する条件は、「目的（検証して学びたい内容）を満たすことができること」と「最小限の労力で準備できること」です。
そのため、目的に沿ってMVPの種類を理解することが重要だと考えられます。この記事では、大まかに目的を２つに分類し、まとめてみたいと思います。
| 目的 | MVPの種類 | 実施内容 | 検証できること |
|---|---|---|---|
| ①マーケットニーズ検証型 | ランディングページ | ・プロダクトを作る前に、サービス利用者向けの初期ページを作成する ・顧客の課題や提案価値、プロダクトの特徴を記載するのが一般的 | ・ニーズの多さ |
| デモンストレーション動画 | ・プロダクトを作る前に、動画でユーザの課題や、解決後の状況、プロダクト（解決手段）を説明する | 同上 | |
| カスタマーリサーチ | ・プロダクトを作る前に、ペーパーに必要事項をまとめてユーザからフィードバックを得る ・ランディングページと同等または、顧客がプロダクトを使用した際のユーザーストーリーを記載するのが一般的 | ・ニーズの多さ ※ユーザーストーリーを準備する場合は、②の目的にも利用できると思料 | |
| ②価値検証型 | コンシェルジュ（人力） | ・プロダクトが担うべき役割を人力で代替し、顧客にプロダクト同等の価値をユーザに提供する | ・解決策の価値 |
| オズの魔法使い（人力＋プロトタイプ） | ・人力とプロダクトを組み合わせて価値を提供する ・ユーザが触れる部分を作成し、裏では人力で処理をするのが一般的 | ・解決策の価値 ・プロダクトの使い勝手（デザイン／機能／体験） | |
| 競合利用・組み合わせ | ・競合のプロダクトや、世の中のサービスを組み合わせて、ユーザに使用してもらいフィードバックを得る | ・解決策の価値 ・競合プロダクトの不満（または優位性） ・プロダクトの使い勝手（デザイン／機能／体験） | |
| モックアップ（ペーパプロトタイプ） ※動かないプロトタイプ | ・ユーザが触れる部分のみを作成し、動かない状態でユーザからフィードバックを得る ・Figmaなどのデザインツールで作成するのが一般的 | ・解決策の価値 ・プロダクトの使い勝手（デザイン／機能） | |
| プロトタイプ ※動くプロトタイプ | ・動くプロダクトを作成し、動かない状態でユーザからフィードバックを得る | ・解決策の価値 ・プロダクトの使い勝手（デザイン／機能／体験） |
プロダクト開発では、価値検証に最初に（CPFit〜PSFitまでの局面では）取り組むことになると思います。取り扱うテーマや参画するメンバーにもよりますが、検証できることを比較しながら準備するボリュームを想像すると、”オズの魔法使い”や”競合利用・組み合わせ”が、手早く学びを得られる手段のように考えられます。
私たちの失敗談と気をつけたいポイント
MVP選択において、私たちのチームの失敗談を共有します。
まだまだ実践の道半ばであり、改善策自体も本当に正解なのか分からない状態ではありますが、目的まで立ち戻って振り返り、改善を繰り返すことで、良い成果に辿り着けることを信じて頑張っています・・・。
- 実施したこと
特定の状況下で「ユーザの行動変容が起こせるか？」を検証目的に、モックアップを作成し、ユーザーインタビューを実施しました。しかし、作成したモックアップではユーザー体験をイメージしてもらえず、期待していた行動変容に関するフィードバックを得ることができませんでした。 - 何が原因だったか？
原因は２点あり、結果として目的を満たすMVPが準備できなかったのだと考えられます。- 検証する仮説が複雑すぎた
検証目的に設定した仮説は、連続性を伴う複数の行動変容が前提となっていました。
（例：商品の必要性を理解する→どこで買うのが良いか理解する→購入先とのタッチポイントを得る）
そのため、ユーザ体験を引き起こすための条件設定（プロトタイプの項目やその設定値、ユーザに合わせたシナリオの設計）が、とても複雑になりました。
結果として、フィードバックを得たいポイントに辿り着く前に、様々な疑問点が生まれてしまったと考えられます。 - 選択するMVPを誤った（MVPの特徴を理解していなかった）
私たちが確認したかったのは、「ユーザの行動変容が起こせるか？」でした。
行動変容を起こすためには、ユーザに体験を想起してもらう必要があると理解していたものの、採用したMVP（ペーパープロトタイプ）では、目的を満たすことが難しかったのです。
ユーザ体験のためのシナリオを準備するために、数多くの画面を作る労力が必要となり、注力すべきポイントが曖昧になったと考えられます。
- 検証する仮説が複雑すぎた
- どうすべきだったか？（私たちの持論・気をつけたいポイント）
- 検証する仮説を絞り込む
複雑さを如何に排除するかはとても重要なのではないかと考えています。
連続性を伴う仮説においても、いくつかの前提を置き検証範囲を部分的にすることで、検証作業をシンプルにすることが可能にならないか、試してみたいと思いました。 - ユーザに触れてもらうことに拘らない
作成しようとしているプロダクトが曖昧または、複雑（難易度が高い）場合、プロダクトを用いたユーザ体験はかなりの労力が必要であることが分かりました。
仮説検証の初期段階では、無理に作ることを優先せず、他の方法を用いて解決策に価値があるかを細かくフィードバックしてもらう方が良いのではないかと考えられます。
- 検証する仮説を絞り込む
- 再実施の結果・・・
検証目的を「商品の必要性を理解することができるか？」ということに絞り込み、MVPはカスタマーリサーチ（ユーザーストーリーを作成）を用いて、ユーザの過去の行動との違いに対してコメントを得るように方針転換をしました。その結果、前回と比較して、明確なフィードバックを得られました。それにより、次回に向けたアクションが明確になったと考えられます。
検証目的を絞ったことにより、全体から見るととても小さい範囲しか行えていないのですが、多くの学びを得て仮説自体を見直すことに繋がったことはとても有益な成果でした。
まとめ
MVPについて、解説と経験から得た気をつけたいポイントを共有しましたが、いかがでしたでしょうか。
MVPを作るにあたっては、以下の状態を維持する必要があるということを学びました。
- 仮説を検証し学びを得ることが目的になっている
- 検証するために最小限だが価値のある製品になっている
今後も新しい発見がありましたら、情報発信をしたいと思います。
最後まで読んでいただき、ありがとうございました。
市場の規模やユーザーの関心を測ることが目的になります。
プロダクトを作成せずに、ニーズを素早く測る必要がある場合に用いられることが多いようです。
顧客の課題を解決することができるかを測ることが目的となります。
プロダクト開発ではこの目的が主軸となり、解決方法として最適な手段になるように、見直しを繰り返すことになります。