MVP検証のKPIとは、「何が観測されたら継続・変更・撤退するか」をあらかじめ数字で決めたものです。リリース後に集まった数字を眺めて解釈するものではなく、リリース前に判断基準として固定しておくものです。
この順番を逆にすると、どんな結果が出ても「もう少し様子を見よう」と言えてしまい、MVPが意思決定につながりません。MVP開発全体の流れはMVP開発とはで、KPIを含む要件定義の書き方はMVPの要件定義で解説しています。
この記事のポイント
- KPIは「検証仮説の成否を判定する基準」。仮説から逆算して設計する
- 価値と事業性の中心指標は「続くか・払うか・広がるか」の3つに絞る
- 発言(満足度・意向)ではなく、行動(反復利用・購入行動・拡大)を測る
- 安全性・技術品質はKPIではなく「前提ゲート」として別管理する
- 指標×結果の組み合わせで次の行動を決める判定テーブルを事前に作る
KPIの役割 — 観測ではなく判定
MVPのKPIには二つの役割があります。
- 判定 — 成功・保留・撤退の条件として、判定日に意思決定へ使う
- 診断 — どこでユーザーが止まっているかを見つけ、改善につなげる
設計で失敗しやすいのは、この二つの混同です。診断用の指標(画面ごとの離脱率、機能ごとの利用率など)は多くてかまいませんが、判定に使うKPIは仮説ごとに1つ、全体で3つ程度に絞ります。判定指標が10個あると、一部が良く一部が悪い結果になったとき、解釈が恣意的になります。
設計手順 — 仮説から逆算する
KPIは指標一覧から選ぶのではなく、検証仮説から逆算します。
| 手順 | すること | 例(問い合わせ分類サービス) |
|---|---|---|
| 1. 仮説を文にする | 誰が・どの場面で・何をするか | 担当者が毎日の振り分けをMVPで置き換え、継続する |
| 2. 行動に分解する | 仮説が正しければ観測されるはずの行動を列挙する | 業務日にMVPを開く、分類結果を確定する、手作業に戻らない |
| 3. 指標に変換する | 行動を数えられる形にする | 業務日利用率、確定まで進んだ割合 |
| 4. 閾値と期間を決める | どの水準を、いつまでに、何件観測したら判定するか | 4週間で業務日の8割以上の利用 |
| 5. 計測方法を決める | どのイベントを、どう記録するか | 日次利用ログ、修正発生箇所、離脱理由のヒアリング |
重要なのは手順4をリリース前に固定することです。結果を見てから閾値を動かすと、検証ではなく後付けの正当化になります。
中心指標は3つのR — 続くか・払うか・広がるか
価値と事業性の判定指標は、次の3つに集約できます。
| 指標 | 見るもの | 証拠になる行動の例 |
|---|---|---|
| 続くか(Retention) | 業務・生活の周期に沿った反復利用 | 業務日ごとの利用、対象業務の処理割合 |
| 払うか(Revenue) | 支払いに向けた具体的な前進 | 見積もり依頼、有償トライアルの相談、決裁者との面談 |
| 広がるか(Referral) | ユーザー側から利用範囲が広がる動き | 別業務への適用相談、同僚への紹介、利用者の追加 |
満足度アンケートの点数や「便利そう」という感想は、参考情報にはなりますが判定には使いません。発言は安く、行動は高いからです。3つのRの詳しい測り方、BtoBで顧客数が少ない場合の見方はMVPで検証すべき3つのRで解説しています。
安全性・品質は「前提ゲート」として分ける
エラー率、応答速度、AIの出力品質、データ保護などは、KPIと同じ表に並べません。これらは満たしていなければ3つのRを測る資格がない前提条件であり、達成しても事業性の証拠にはならないからです。
- ゲートの例 — 重大な誤出力ゼロ、対象業務での応答時間、権限逸脱ゼロ
- 扱い — ゲート未達なら検証を一時停止して修正する。ゲート達成は「検証を続けてよい」の意味しか持たない
AIプロダクトの場合、出力品質の継続監視(評価基盤)をゲートに組み込みます。実例はMVP開発の事例で紹介しています。
判定テーブルを事前に作る
指標が出そろった後に議論を始めないよう、結果の組み合わせごとに次の行動を決めておきます。
| 続くか | 払うか | 広がるか | 解釈 | 次の行動 |
|---|---|---|---|---|
| ○ | ○ | ○ | 中心価値が成立 | 対象拡大への投資を検討 |
| ○ | × | ○ | 価値はあるが対価が壁 | 買い手・価格・ROIを再検証 |
| × | ○ | △ | 期待先行で定着しない | 利用フローと障壁を修正 |
| × | × | × | 仮説不一致の可能性 | 対象変更または撤退 |
○×の境界(閾値)と観測期間、判定の責任者を要件定義書に書いておきます。
定量だけで判断しない — 理由は定性で取る
KPIは「何が起きたか」を教えてくれますが、「なぜか」は教えてくれません。数字とセットで、必ず理由を取りに行きます。
- 使い続けている人に: 何の代わりに使っているか、なくなったら困るか
- 離脱した人に: どの時点で、何が障害だったか
- 手作業へ戻った日に: その日に何があったか
少人数のクローズドβでも、インタビューを重ねれば判断材料は集まります。実際のMVP検証では、テストユーザー10人・インタビュー3回といった規模でも、次の事業判断に必要な一次情報を得られています(事例参照)。
よくある失敗
完成品と同じKPIを置く
DAU、コンバージョン率、NPSなど、スケール後のプロダクト向け指標をMVPに適用すると、母数が小さすぎて何も判定できません。MVPでは絶対数の大小ではなく、「対象ユーザーの中で仮説どおりの行動が起きたか」を見ます。
指標を増やしすぎる
計測できるものをすべてKPIにすると、判定日にどの数字を信じるかの議論が始まります。判定用は3つ程度に絞り、残りは診断用として分けます。機能を絞る判断と同じで、足すほど検証はぼやけます。
結果を見てから閾値を決める
「利用率6割なら成功と言えるか」をデータが出た後に議論すると、必ず甘い方に倒れます。閾値・期間・責任者はリリース前に固定します。
よくある質問
MVPのKPIはいくつ設定すべきですか
判定用は仮説ごとに1つ、全体で3つ程度(続くか・払うか・広がるか)に絞ります。診断用の指標は別枠でいくつ持ってもかまいませんが、判定には使わないと決めておきます。
ユーザーが10人しかいなくてもKPIは機能しますか
機能します。割合ではなく一人ひとりの行動(毎日使ったか、どこで止まったか、なぜ戻ったか)を追い、定量と定性を組み合わせます。少人数の場合はむしろ全員にインタビューできることが強みになります。
検証期間はどれくらい必要ですか
対象業務が一巡する期間が最低ラインです。日次業務なら数週間、月次業務なら1〜2ヶ月。業務の周期より短い期間で「使われなかった」と結論づけることはできません。
