MVPとは？小さく作って何を確かめる？
目次
MVPはMinimum Viable Productの略です。顧客のニーズや事業として成り立つ可能性を、必要最小限の取り組みで学ぶための製品やサービスを指します。大切なのは、機能数の少なさよりも、顧客の実際の行動から何を判断できるかです。
「まず必要そうな機能だけ作って、反応を見る」と考えることもあるでしょう。ただ、何を知りたいかが曖昧だと、使われたあとにも次の判断ができません。この記事では、確かめたい問いを決め、提供する範囲を絞るところから考えます。
- 機能一覧より先に、顧客について確かめたいことを書く
- 対象と提供範囲を絞り、実際の行動を見られる形にする
- 反応をもとに、続ける・変える・やめるを判断する
MVPは小さな完成品を作るだけではない
機能を少なくした初版が、いつでもMVPになるわけではありません。たとえば登録画面だけを作っても、「このサービスで顧客の仕事が楽になるか」を確かめるには足りないかもしれません。どこまで提供すれば問いに答えられるかを考える必要があります。
The Lean Startupの原典は、解くべき問題を捉え、MVPで学習を始め、反応を測って次の方向を考える流れを説明しています。MVPは「小さいものを完成させたら終わり」という考え方ではありません。
プロトタイプがアイデアや使い方を試すための試作品であるのに対し、MVPでは、顧客に提供したものへの反応から、事業や製品についての仮説を確かめる点に目を向けます。ただし呼び方や実物は重なることもあり、プロトタイプ、MVP、β版を必ず順番に通る工程だと考える必要はありません。
作る前に確かめたいことを決める
誰のどんな困りごとか
「予定を調整するサービス」だけでは、誰の何を助けるのかが広すぎます。「社外との打ち合わせ日時が変わった際、候補日を集め直している担当者」のように、困る場面を具体的にします。
以下では、予約変更の調整を手伝う架空のサービスを考えます。実在するサービスの実績や、アーコレ！の開発事例ではありません。
この例で確かめたいのは、「変更が起きたとき、担当者は今の手作業の代わりに、候補日の整理を任せたいか」です。まずは何が負担なのかを聞き、必要なら顧客ニーズ調査で背景を確認します。「任せたいはず」と決めつけて始めないことが大切です。
どの行動を見て判断するか
「便利そう」という感想と、実際に依頼することは分けて見ます。依頼されたあとでも、必要な情報が集まらず調整できなければ、提供方法を見直す材料になります。
| 見たいこと | 確認する材料の例 | それだけでは分からないこと |
|---|---|---|
| 本当に任せたい場面があるか | 変更時の依頼と、その背景 | 将来も使い続けるか |
| 必要な情報を渡せるか | 依頼時の記入、追加確認の記録 | 自動入力なら使いやすいか |
| 整理した候補日が役立ったか | その後の調整の進み方と本人の説明 | すべての業種でも役立つか |
この表は試し方を考えるための例で、合格基準ではありません。今回は何を判断したいのかに応じて、見る行動と確認時期を先に決め、対象や提供条件と一緒に記録します。「依頼はあるが追加確認で止まるなら入力方法を見直す」のように、結果ごとの対応も仮に書いておくと、振り返りで使えます。
機能ではなく確認範囲を絞る
最初から、あらゆる種類の予約、複数のカレンダー、自動通知までそろえる必要があるかを考えます。架空例なら、社外打ち合わせの日時変更に対象を絞り、候補日を整理して返すところまでを提供範囲にできます。
手作業で提供する部分を残す例
利用者は依頼フォームに条件を入力し、担当者が手作業で候補日を整理して返す。このような形でも、「その作業を任せる価値があるか」という問いを考えられます。Agile AllianceのMVP解説にも、手動で動くサービスを含め、実際の利用行動から学ぶ考え方が示されています。
ただし、手作業で対応した結果から、自動処理の精度や多人数への提供能力まで確認できたとはいえません。また、利用者に対して全自動だと偽ったり、返答できない時間を約束したりしないようにします。誰がどの情報を扱うか、いつ返すか、何を引き受けないかを説明します。
小さくするのは、確認する対象や作業の範囲です。安全性や個人情報の扱いを後回しにする理由にはしません。実データを扱う前に、提供条件と必要な管理方法を確認してください。
次のシートは、編集部による計画用の記入例です。
| 記入欄 | 架空例 | 自分の案 |
|---|---|---|
| 対象 | 社外打ち合わせの日時変更を調整する担当者 | ［記入］ |
| 困りごとの仮説 | 候補日の集め直しに負担がある | ［記入］ |
| 提供範囲と条件 | 一種類の予約変更。担当者が候補日を整理して返す | ［記入］ |
| 確かめる行動 | 実際の依頼、情報の受け渡し、その後の調整 | ［記入］ |
| 判断する時期 | 対象の調整が一区切りした時点 | ［記入］ |
| 次の対応 | 続ける／条件を変える／提供をやめる | ［記入］ |
反応を見て続ける・変える・やめる
実際に提供したら、期待した反応だけでなく、依頼されなかった場面や途中で止まった理由も振り返ります。「依頼がなかった」場合も、困りごとがなかったのか、頼めることを知らなかったのか、条件が合わなかったのかで次の対応は変わります。
続けるなら何をもう一度確かめるか、変えるなら対象と提供方法のどちらを変えるか、やめるなら利用中の人にどう案内するかまで整理します。結果に合わせて目的を後付けせず、最初の問いと確認した材料を並べると、判断の根拠を共有できます。
申し込みがあったことだけで、料金を払ってもらえることや継続利用まで証明した扱いにはしません。無料で試した場合は、その条件での反応です。製品が市場に合っているかをさらに考えるときは、PMFを確かめる方法で、継続利用と得られる価値を見ていきます。
最初の一歩：機能一覧の前に、問いを一文にする
まず「どの人が、どんな場面で、何を任せたいかを確かめる」と書いてみましょう。その問いに答えるために必要な提供だけを選び、確認する行動と次の判断を添えます。
機能を増やすことより、次に進むための材料が得られるかを考える。それが、MVPを単なる小規模開発で終わらせない出発点です。学んだことを開発計画へつなぐ際は、プロダクトロードマップの作り方も参考にしてください。
参考資料
- The Lean Startup：Methodology — 問題の把握、MVPによる学習、作る・測る・学ぶ流れを参照。
- Agile Alliance：Minimum Viable Product — 実際の行動から学ぶこと、最小機能との混同に関する説明を参照。本文の予約変更サービスと記入シートは編集部による架空例です。
