読み込み中...
投稿日
仮説検証とMVPへの向き合い方
もくじ
はじめに
本ページでは、仮説検証にMVPが必要と判断した場合にどのように進めていけばよいのか、その考え方をまとめています。
仮説を検証するために、MVP開発が必須というわけではありません。またMVPを開発するとしても、仮説検証ができるだけの最低限のものをスピーディに構築する必要があります。
以降では、この考え方を基本にMVPを開発する目的、要件整理などの方針をまとめています。
ぜひ本ページを読み、仮説検証およびMVP開発に役立ててください。
MVPとは
概念実証ステージでは、事業が顧客課題を解決できるかという視点で立てた仮説を検証します。
この目的を達成するため、仮説の検証に必要と判断された場合はMVPを開発します。
MVPとはMinimum Viable Productの略で、「仮説を検証可能な最小限の製品」を意味します。
MVPを開発する場合、プロダクトオーナーのロールを担う人がMVP開発の主軸を務めるようにしてください。
基本的な考え方
検証内容と開発方針の策定
MVPを開発するにあたり、検証したい仮説の内容を明確化する必要があります。
この整理にはMVPキャンパスが適しており、各項目を埋めていくことで検証する仮説の優先度や抜けていた観点などを確認できるでしょう。
MVPキャンバス
必要最小限の機能を決める
MVPでは、本当に検証すべきことは何か、必要な機能はなにかを整理して必要最小限の機能を開発対象とします。
この「必要最小限の機能」の絞り込みには、ユーザーストーリーマップを作成するのがよいでしょう。
ユーザーストーリーマップは、ユーザーの一連の行動を表した図です。商品・サービスを使いはじめてから使い終えるまでのユーザーストーリーについて、横軸は時系列、縦軸は優先度順で整理し、MVPで開発すべき機能を決定します。
ユーザーストーリーマップ
ユーザーストーリーマッピングでは利用者に価値をもたらす大まかな行為(例:「製品を購入する」; エピックと呼びます)を考えた上で、以下のように進めます。
- エピックを達成するために必要な手順・一般的なワークフローを考え、時間軸に沿ってテーマを並べる
- それぞれのテーマをユーザーストーリーに分解し、優先順位に基づいて縦に並べる
このようにして全体を俯瞰し、必要な機能の確認と優先順位を決定しましょう。
使い捨てを前提に機能要件・非機能要件を整理する
MVPの目的は仮説の検証です。立てた仮説は誤っていることもあり、トライ＆エラーを繰り返すことがつきものです。
そして多くのMVPは仮説検証に特化しているため使い捨てになります。
このため、MVP開発は多くの機能を作り込むのではなく、仮説を検証可能な最低限の機能に絞って作成する必要があります。
MVP開発を始める前に、ユーザーストーリーマップで絞り込んだ機能を実現するために開発が必要な機能要件はなにかを整理しましょう。
また、検証方法についても「人力で代用できる部分とそうでない部分」を切り分け、検証方法を決定しましょう。
検証したい仮説の内容と以下に紹介するMVP型を参考に、極力開発をせずに素早く仮説検証ができる方法を検討してください。
| MVPの型 | 概要 | 検証できること | 事例 |
|---|---|---|---|
| ランディングページMVP | Webページ（ランディングページ）だけを作り公開するMVP。ユーザーに登録してもらうといった機能のみを持つ | ニーズの多さ、顧客のプロフィール | ・その業界を知らなくてもBtoB事業は立ち上げられる−やり方とコツ− ・Idea to Paying Customers in 7 Weeks: How We Did It |
| 動画MVP | 動画を活用してユーザーがプロダクトに興味を示すかを検証するMVP 1 | ニーズの多さ | ・How DropBox Started As A Minimal Viable Product |
| プロトタイプ型MVP | 実際に動くものを作り公開するMVP | 機能性、デザイン性、体験など | ・$12.000, 3 weeks and a business angel: make app like Reddit |
| オーディエンス開発型MVP | 製品を開発する前に顧客基盤を開発するMVPのこと。まず見込み客のセグメントを明確にし、これら顧客と意見交換するための場を構築し、オーディエンスを観察する2 | 開発する製品の機能、ニーズの多さ3 | How Pinterest Grew From 3,000 to 73 Million Users |
| コンシェルジュ型MVP | プロダクトと同じ効果を、自分たちの手で提供する MVP | ニーズの多さ、サービスの成果に価値を感じてもらえるか、顧客がお金を払ってくれるか | ・フードデリバリーのユニコーンの「DoorDash」が仮説検証に行った人力MVP ・Manuel Rosso, Food on the Table |
| オズの魔法使い型MVP | 顧客は製品が手作業によって動作していることを認識していない上で、完全に機能が実装されているように見せかけ、提供するMVP4 | ニーズの多さ、サービスの成果に価値を感じてもらえるか、顧客がお金を払ってくれるか | ・「デザイン思考」のプロトタイプ（試作品）とは？ ・1年間開発したプロダクトを捨てて、5日でダイニーをリリースした話 |
また、MVPは使い捨てとなるため、非機能要求グレードがスコープとするような非機能要件への対応を最低限にできます。
ただし、非機能要求のグレードを最低限とすることにより、バックアップからの復旧ができない等、MVPのユーザーになんらかの不都合が生じ得ます。この点については、必要であればMVPの利用規約で明記しておくべきでしょう。
セキュリティについては、注意が必要です。
大前提としては、個人情報等、守るべき情報資産をできるだけ持たないように検証計画を作成するのがよいでしょう。
一方で、仮説によっては情報資産を持たないと検証できない場合もあります。このようなケースでは、当該の情報資産の漏洩を防ぐ等、最低限のセキュリティは具備しておく必要があります。
このような考えに沿って、非機能要件を整理します。
数値目標を設定する
開発したMVPは、ユーザーに使ってもらい、仮説の検証結果を判断することになります。
この時、どのような値を元にして判断するのか、その仮説が正しかったと判断するための目標値を決めておく必要があります。
目標データはできるだけインタビューなどの認知データではなく、ユーザーの行動データで検証する方が蓋然性も高く、望ましいでしょう。
開発するMVPにそのデータを収集する機能が必要であれば、それは開発時に盛り込んでおく必要があります。
開発計画
開発プロセス(MVP)・開発体制
MVPでは仮説の検証ができればよく、動作するものを素早く開発する必要があります。
またこのステージでは予算も限られるため、エンジニア1〜2名の体制となることがほとんどです。
このような状況では、あえて重厚な開発プロセスを構えることはありません。
事業オーナーとエンジニアの間で密なコミュニケーションを行い、動くインクリメントを前提にしたフィードバックを繰り返すことで、MVPの解像度を上げてください。
もしエンジニア3名以上といった規模で開発することになった場合は、アジャイル形式で進めてください。
アジャイルの実践手法として、我々はスクラムを使っています。詳細はスクラム概論 | アジャイル・スクラム | Fintanを参照ください。
いずれにおいても、できる限り少人数かつアプリからインフラまでカバーできるスキルセットを持つようにしましょう。
人数が多すぎる場合、コミュニケーションコストが高くなるからです。
全体計画の策定
MVP開発では詳細な計画は必要ありませんが、全体計画は必要です。
機能実装がいつ頃完了し、どのようなテストをいつから実施するか、いつリリースするかを事業オーナー・プロダクトオーナーと相談して決定します。
この全体計画の作り方はスプリント運営ガイド – スプリント全体計画が参考になるでしょう。
MVPのテストをどこまで実施するかは悩ましい問題ですが、MVPの目的は仮説の検証であり、その目的を達成できる品質を担保できれば十分です。
検証したい仮説に対して、どこまで・何をテストしなければならないのかを、事業オーナー・プロダクトオーナーで決めましょう。
実施するテストは、テスト種別＆テスト観点カタログのテスト種別カタログをベースに定めます。
最低限、MVPで検証したい機能や業務シナリオが成立すること、 実際の環境で動作することを確認する構成テストは必要でしょう。
また、セキュリティについては事故とならないように担保する必要があります。
各種準備
MVP開発において、アプリケーションを動作させるためのインフラ環境が必要になる場合、その準備も忘れないようにしてください。
AWSを使用する場合、環境準備時間を短縮可能なEponaの利用を検討するとよいでしょう。
その他、以下のような準備や手続きも必要に応じて実施してください。
- VCSリポジトリの準備
- 必要に応じて、MVPで利用するSaaSに関するサインアップ、開発ツール・ライブラリを利用する場合のライセンスの準備
- 会議体の設定
- ビジネスパートナー様を含む利用PC等の準備
MVP開発の進め方
ドメインの理解
新規事業の目的はそのユーザーが抱える特定領域(ドメイン)の課題の解決であり、MVPではその課題を解決できるかどうかの仮説を検証します。
課題に対して適切な解を打ち出すには、開発者が当該ドメインとユーザーの抱える課題を理解することが必要です。
開発者・プロダクトオーナーは、当該ドメインに詳しい事業オーナーと会話し、得られた知識をMVPで開発するアプリケーションに反映しましょう。
設計
MVP開発の目的は「仮説の検証」であるため、開発対象の機能は少ないはずです。
設計などをドキュメント化する範囲も最小限に抑え、スピーディにプロダクトを開発しましょう。
ドキュメントを作成する場合、以下のようなチーム内で共通認識を揃える必要があるものに絞るとよいでしょう。
| 設計 | 内容 |
|---|---|
| ER設計 | MVPでデータストアを利用する場合、テーブルおよびテーブル間の関連の設計(ER設計)が必要でしょう。ERモデルに変更が入ると、プロダクト全体に大きな影響が発生します。 |
| 方式設計 | HTTPメソッドの使い分けやエラー処理、キャッシュの利用方法等、システム全体として整合性を取らなければならない箇所の設計を行います。 |
| システム利用シーケンス設計 | ユーザーがシステムを使い始め、課題を解決するまでのシーケンスを設計します。このような全体像を示す図がないと、全体最適なUXを提供できるMVPには至れません。 |
丁寧なドキュメントを書くことに拘る必要はありません。設計の深さについても、MVPで検証したい内容が担保できれば十分です。
テスト
テストもMVPでの仮説検証に必要な最低限のものを実施します。
通常の開発、特に大規模ないし長期間メンテナンスをする必要があるプロダクトの場合はテストコードの作成が求められます。
しかし、MVPはできるだけ早期のリリースが必要であり、使い捨てを前提としています。
テストコードの作成で重要なのは費用対効果に見合うかであり、MVP開発においては作成しなくても構わないくらいです。
インフラ
インフラについても頑強なものは不要で、非機能要件に沿って最低限のリソースを利用した設計・構築をします。
ただし、個人情報のような守るべき情報資産を保持する場合、その部分については一般的なインフラと同等のセキュリティを担保すべきです。特に以下のような点に注意します。
| 注意点 | 対応 |
|---|---|
| インターネットを通過するデータが盗聴されないか | 通信経路の暗号化 |
| 関係外の人間(等)がオブジェクトストレージやデータベースにアクセスできないか | アクセスコントロールの適切な設計 |
| 個人情報などの機密情報が含まれるデータが盗まれた際、機密情報が漏洩しないか | データの暗号化 |
おわりに
本ページでは、仮説検証にMVP開発が必要となった場合に、どのように進めていけばいいのかをまとめました。
MVP開発では、以下の点がポイントになると考えています。
- MVPは仮説を検証することが目的であり、その目的達成ための必要最低限なものに絞って開発すること
- 立てた仮説は誤っていることも多いため、MVPは使い捨てとなるため割り切って作り込む範囲を判断すること
- 仮説の検証結果を判断するための数値目標を設定すること
優先度判断に迷った時などは、MVPで本来達成したい目的を今一度思い出し、必要な仮説検証が行える最短距離を進めるようにしましょう。
