MVP検証の指標を先に決める方法｜判断基準の作り方
動くプロトタイプやMVP（最小限の機能で作る検証用の製品）で事業性を確かめるとき、何を見て「進む・直す・やめる」を決めるのか。この記事では、その見る指標を作る前に決めておく方法を整理します。仮説の立て方、指標の種類、合格ラインの置き方、決裁者との事前合意までを順に説明します。
なぜ指標は「作る前」に決めておくのか
動くものができあがると、見た人はそれぞれの立場で都合よく解釈しやすくなります。画面がきれいなら「手応えがある」と感じ、数字が伸びなければ「まだ期間が短い」と考える、といった具合です。結果を見てから基準を決めると、結論が先にあって、それに合う数字を選ぶ形になりかねません。
私たちは、指標を先に決めておく利点を次の3つだと考えています。
- 判断がぶれにくくなる：検証が終わったあとに、数字の読み方で議論が割れることを減らせます。
- 作るものが絞れる：確かめたいことが決まっていれば、そのために必要な機能だけを作れば足ります。機能の絞り方は、MVP開発の機能の絞り方｜最初に作るものと後回しの基準でも詳しく整理しています。
- 次の動きを先に合意できる：基準を超えたらどうするか、下回ったらどうするかを事前に決めておけます。
新規事業では、経営陣（決裁者）と現場（立案者）が同じ目的を見ていても、判断の材料と進める速度が違うために話が噛み合わないことがあります。ズレているのは目的ではなく進め方であることが多く、指標の事前合意はそのズレを埋める手段のひとつになります。背景は新規事業で経営陣と現場がすれ違う原因は進め方のズレで扱っています。
なお、プロトタイプ、MVP、モックの違いを整理したい場合は、プロトタイプとMVP・モックの違いを整理｜新規事業の使い分けが参考になります。この記事では、動く実物で事業性を確かめる場面を前提に進めます。
指標を決める前に、確かめたい仮説を言葉にする
指標は、仮説から逆算して決めます。先に「どんな数字を取れるか」から考えると、取りやすい数字ばかりが並びがちです。
事業の前提を分解する
新規事業は、いくつもの前提が重なって成り立っています。代表的なものは次のとおりです。
- 特定の人たちが、ある課題を実際に抱えている
- その課題は、今の手段では十分に解決されていない
- 提案するシステムなら、その課題を解決できる
- 解決の対価を払う価値があると感じてもらえる
- 自分たちの体制で、継続して運営できる
このうち、外れると事業が成り立たなくなるものから確かめます。たとえば課題そのものが弱いなら、機能をどれだけ磨いても意味がありません。
仮説は「誰が・何を・どうする」で書く
仮説は、あとで数字に落とせる形で書きます。型として、次の一文が使いやすいと考えています。
〈対象の人〉は、〈今の困りごと〉を抱えていて、〈このシステムの機能〉を使えば、〈観察できる行動〉をとるだろう。
たとえば、専門家と依頼者をつなぐマッチングの仕組みを考えている場合を想定します（ここでの数字や内容はあくまで説明用の例です）。
小規模事業の担当者は、外部の専門家探しに時間を取られている。依頼内容を入力すれば候補が出る機能を使えば、その場で専門家に相談を申し込むだろう。
末尾が「観察できる行動」になっている点が要です。「便利だと感じるだろう」では見えませんが、「相談を申し込む」なら数えられます。マッチングサービスで最初に決めることは、マッチングサービス開発の進め方｜最初に決める5つのことでも触れています。
MVP検証で使う指標の種類
指標は多ければよいわけではありません。仮説ごとに1〜2個ずつ選び、全体で3〜5個程度に絞ると、検証の最中にも見失わずに済みます。ここでは、新規事業の検証でよく使われる5つの観点を挙げます。
課題の強さ
そもそも、対象の人がその課題を強く感じているかを見る観点です。操作ログよりも、対話での発言が手がかりになります。
- 今はどんな手段で解決しているか（代替手段の有無）
- 最後に困ったのはいつか、そのときどうしたか
- 検証への参加や事前登録など、手間のかかる依頼に応じてくれたか
「便利そうですね」という感想は、行動を伴わないため、指標としては弱いと考えます。
利用のされ方
プロトタイプを渡したときに、狙った操作まで到達できるかを見る観点です。
- 主要な操作（申込み、投稿、依頼など）を完了した人の数
- 初回の利用から目的の操作までにかかった時間
- 途中で止まった画面や、戻った操作
ここで止まる原因は、画面の分かりにくさと課題の弱さの両方があり得ます。切り分けのために、利用中の発言も合わせて集めておきます。質問の作り方はプロトタイプのユーザーテスト｜新規事業での確かめ方と質問にまとめています。
継続して使われるか
1回の利用ではなく、2回目以降も使われるかを見る観点です。業務の中で繰り返し発生する課題を扱う事業ほど、この指標が重要になります。
- 一定期間内に再び利用した人の数
- 利用の間隔（毎日、毎週、必要なときだけ、など）
- 自分から使い始めたのか、こちらが声をかけたのか
声をかけた結果の利用と、自発的な利用は分けて記録しておくと、あとで読み違えにくくなります。
対価を払う意思
事業として成立するには、使ってもらうだけでなく、対価を払ってもよいと思われる必要があります。実際の支払いが難しい検証段階では、それに近い行動を見ます。
- 正式な導入に向けた見積依頼や社内確認を申し出たか
- 利用の対価について、具体的な条件を相手から尋ねてきたか
- 周囲の関係者に紹介してよいかを確認できたか
「いくらなら払いますか」と直接聞くだけでは、答えが実態と離れることがあります。具体的な行動にどこまで進んだかを指標にするほうが、判断材料として確かです。
運営できるか
見落とされやすいのが、提供する側の負担です。使われても、運営の手間が大きすぎれば事業としては続きません。
- 1件の処理にかかった運営側の作業時間
- 人の手で補った作業の割合や内容
- 集まったデータの質（入力の抜け、表記のばらつき）
人が裏側で手作業をしていても、検証としては問題ありません。ただし、どこに手作業が残っているかを記録しておくと、本開発で何を自動化するかの判断材料になります。
見た目は良くても判断に使えない数字に注意する
登録者数、閲覧数、ダウンロード数のような「数が積み上がる指標」は、伸びていても事業性の根拠になりにくいことがあります。行動の深さや、継続、対価につながる動きが伴っているかを、あわせて確かめることが大切です。
合格ラインの決め方と、数字の読み方
指標を選んだら、次に「どこまでを合格とするか」を決めます。これが基準線です。
基準線を置く3つの手がかり
- 事業の見通しから逆算する：事業として成り立つために必要な利用や継続の水準を考え、その途中経過として、検証期間に見たい水準を置きます。
- 代替手段と比べる：今の手段（人に頼む、表計算で管理する、など）より明らかに楽だと感じてもらえたかを基準にします。
- 幅を持たせる：1点の数字ではなく、「ここまでは進む」「ここからは見直す」の2本の線を引き、その間を「追加で確かめる」とします。
進む・直す・やめるの3段階にする
合否の2択にすると、中間の結果が出たときに判断が止まります。次のように3段階で決めておくと、結果の読み方が揃います。
| 結果 | 判断の例 |
|---|---|
| 上の線を超えた | 本開発や次の段階の検証に進む |
| 2本の線の間 | 原因を切り分け、対象や機能を変えて再検証する |
| 下の線を下回った | 仮説を見直す、または事業の方向を変える |
母数が少ないときの扱い
プロトタイプの検証は、数社から数十人程度の小さな母数で行うことが多くなります。この場合は、割合だけで語らず、「何人中何人」と件数も併記します。たとえば「10社のうち7社が、2週間のうちに2回以上利用した」という書き方です（これも説明用の例で、目安の数字ではありません。水準は事業ごとに決めます）。
小さな母数では統計的な精度は望めません。その代わり、数字と一緒に、利用者の発言や詰まった場面といった定性的な情報を並べて読むことで、判断の質を補います。
決めるタイミング
基準線は、プロトタイプの開発に着手する前、作るものを関係者で決める場面で一緒に決めるのが理想です。作る範囲の議論と、見る指標の議論は表裏一体だからです。範囲を決めてから指標を考えると、その範囲では確かめられない指標が出てくることがあります。
指標を決めるときの落とし穴
よくある失敗を、あらかじめ挙げておきます。
- 指標を欲張る：10個も20個も見ようとすると、結局どれも深く読めません。3〜5個に絞ります。
- 好意的な人だけで検証する：身内や関係の近い人は、否定的な意見を言いにくいものです。実際に課題を抱える対象に近い人を選びます。
- 基準線を後から動かす：数字が届かなかったときに基準を下げると、検証の意味がなくなります。見直すなら、理由を記録に残したうえで関係者の合意を取ります。
- プロトタイプの出来と事業性を混同する：使われなかった理由が、画面の分かりにくさなのか、課題の弱さなのかを切り分けます。切り分けができないままPoC（概念実証）が止まる例は、PoC失敗で終わる新規事業の共通点と本開発への進み方で取り上げています。
- 測る仕組みを入れ忘れる：指標を決めても、操作の記録やアンケートの導線がなければ、数字が取れません。プロトタイプの段階から、測る仕組みを一緒に作っておきます。
検証計画を1枚にまとめ、決裁者と合意する
指標と基準線が決まったら、1枚の検証計画にまとめます。長い資料にする必要はありません。次の項目が揃っていれば、関係者の間で認識を揃えるには十分です。
- 確かめたい仮説（優先順位つき）
- 対象の人と、検証に参加してもらう人数・期間
- 見る指標と、その取り方（操作の記録、聞き取り、アンケートなど）
- 基準線（進む・直す・やめるの各条件）
- 結果が出たあとに誰が、いつ、何を判断するか
決裁者との合意が、あとの判断を早くする
企画書だけで決裁を取る難しさは、新規事業の決裁を企画書だけで取るのが難しい理由で整理しました。動く実物があっても、「何を見て判断するか」が合意されていなければ、検証後に再び議論が始まります。計画の段階で決裁者に見てもらい、基準線に同意をもらっておくと、結果が出たときの判断が早くなります。稟議にプロトタイプを使う場面は、稟議を通すシステム開発｜プロトタイプの使い方でも扱っています。
検証中の進め方
検証の最中は、次の点を意識します。
- 指標は毎週など、決めた頻度で同じ形式の記録を残す
- 途中で気づいたことは、指標とは別のメモに残す
- 計画を変える場合は、変更の理由と日付を記録する
検証の窓口となる発注側の担当者の役割は、発注側のプロダクトオーナーとは｜役割と判断のしかたで詳しく説明しています。
結果が出たあと
基準線を超えた場合も、そこで終わりではありません。検証で確かめられたのはあくまで最初の仮説であり、事業が育つ過程では、納品後も改善を重ねる前提が必要です。考え方はシステムは納品後の改善で育てる｜新規事業の考え方に書いています。小さく作って確かめ、投資を段階的に判断する進め方は、新規事業の開発は小さく作って確かめる投資判断の進め方にまとめています。
全体の進め方を俯瞰したい場合は、MVP開発・プロトタイプ開発の進め方｜新規事業の判断法や新規事業のアイデア検証方法｜動くシステムで確かめる手順もあわせてご覧ください。
まとめ
動くプロトタイプで事業性を確かめるときは、作る前に見る指標と基準線を決めておくことが、判断を支えます。要点は次のとおりです。
- 指標は、確かめたい仮説から逆算して決める。仮説は「誰が・何を・どうする」と観察できる行動で書く
- 観点は、課題の強さ、利用のされ方、継続、対価を払う意思、運営できるかの5つ。全体で3〜5個に絞る
- 基準線は、進む・直す・やめるの3段階で置く。母数が小さいときは「何人中何人」と、発言などの定性情報を併せて読む
- 登録数や閲覧数のような積み上がる数字だけで判断しない
- 基準線は後から動かさない。変える場合は理由を記録して合意を取る
- 検証計画は1枚にまとめ、決裁者と事前に合意する
指標の議論は、「何を作るか」の議論そのものでもあります。確かめたいことが明確になると、プロトタイプの範囲も自然と絞られていきます。
JustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断していただける受託開発サービスです。仕様が固まっていない段階でも、作るものを一緒に決める認識合わせの場面で、確かめたい仮説や見る指標を整理することができます。サービスの考え方はJustFitのサービス紹介で紹介しています。