MVPに最低限入れる計測は、「検証の判定に使う行動のイベント」「流入元の記録」「問い合わせの記録」「利用者単位の利用ログ」の4つです。アクセス解析ツールを入れてページビューを見るだけでは、MVPの検証にはほとんど役立ちません。何を確かめたいかを先に決め、その判定に必要な行動だけを、公開前に確実に記録できる状態にしておくことが大切です。項目を増やしすぎるより、少数の項目を正しく取るほうが、検証の判断は速く確かになります。
この記事は、MVPの公開を控えた新規事業の担当者、プロダクトマネージャー、計測の設定を開発会社と相談しながら進めたい発注者に向けたものです。分析の専門家でなくても、何を、どこで、どう記録すればよいかを判断できるように説明します。
読み終えると、MVPの計測で決めるべきこと、最低限のイベントの選び方、ツールの組み合わせ方、公開前の確認手順、計測でよくある失敗と避け方が分かります。
MVPの計測は「判定に使う数字」から逆算する
MVPの計測を考えるとき、多くの人は「どのツールを入れるか」から考え始めます。しかし、先に決めるべきは、MVPで何を確かめ、その判定にどの数字を使うかです。
たとえば、架空の例として「中小企業の経理担当者は、毎月の請求書の作成をこのサービスで行い、3か月続けて使う」という仮説を検証するなら、判定に必要な数字は次のようになります。
- 登録した企業の数
- 登録した企業のうち、請求書を一枚以上作成した企業の数
- 請求書を作成した企業のうち、翌月・翌々月にも作成した企業の数
この三つが分かれば、仮説の判定はおおむねできます。逆に言えば、この三つが取れていなければ、どれだけ多くのデータを集めても判定はできません。
計測の設計は、次の順番で考えます。
- MVPで確かめたい仮説を一文で書く
- 仮説の判定に使う数字（判定指標）を決める
- 判定指標を計算するために、どの行動を記録する必要があるかを洗い出す
- 判定指標の変化の理由を探るために、補助的に記録する行動を少数加える
- それぞれをどのツールで、どの形式で記録するかを決める
この順番で考えると、記録すべき項目は意外と少ないことに気づきます。
最低限入れる計測1：検証の判定に使う行動のイベント
最も重要なのは、判定指標の計算に使う行動を、イベントとして記録することです。イベントとは、「登録した」「請求書を作成した」「招待を送った」のような、利用者の行動の記録です。
MVPで記録すべきイベントは、おおむね次の三種類に分けられます。
| 種類 | 内容 | 例 |
|---|---|---|
| 入口のイベント | 利用を始めたことを示す行動 | 登録完了、初回ログイン、初期設定の完了 |
| 価値のイベント | サービスの中核の価値を得たことを示す行動 | 請求書の作成、予約の確定、マッチングの成立 |
| 継続・拡大のイベント | 繰り返し使っている、利用を広げていることを示す行動 | 2回目の作成、メンバーの招待、有料プランへの切り替え |
特に「価値のイベント」が何かを明確にすることが大切です。登録やログインは利用の入口にすぎず、それだけでは価値を感じたかどうかは分かりません。利用者がサービスから価値を得た瞬間を一つか二つ選び、それを確実に記録します。この瞬間はアハモーメントと呼ばれることもあります。
イベントの名前と属性を決める
イベントには、後で集計しやすいように、一貫した名前を付けます。たとえば「invoice_created」「member_invited」のように、対象と動作を組み合わせた形にそろえます。名前のルールを決めずに追加していくと、似たようなイベントが複数でき、集計のたびに混乱します。
また、イベントには必要な属性（どの利用者が、どの企業で、どのプランで、など）を付けて記録します。属性があると、後から「業種別の継続」「招待した企業と招待しなかった企業の違い」などを比べられます。命名の考え方はGA4のイベント設計で詳しく説明しています。
補助的に記録するイベントの選び方
判定指標に必要なイベントのほかに、数字が動いたときに理由を探るための補助的なイベントを少しだけ加えます。選ぶ基準は「判定指標が想定より低かったとき、どこで止まったかを知るために必要か」です。たとえば、請求書の作成が少なかった場合に備えて、「作成画面を開いた」「取引先を登録した」「プレビューを表示した」を記録しておけば、作成に至らなかった利用者がどの段階で止まったかが分かります。
補助的なイベントは、主要な流れの各段階に一つずつ程度で十分です。画面上のすべての操作を記録しようとせず、流れの節目だけを押さえます。
最低限入れる計測2：流入元の記録
二つ目は、利用者がどこから来たかの記録です。MVPでは、知り合いへの個別の案内、SNS、広告、イベントでの紹介など、複数の経路で利用者を集めることがよくあります。経路によって利用者の質や継続の度合いが違うことが多いため、流入元を区別して記録しておくと、次の集客の判断に役立ちます。
流入元の記録には、案内に使うURLにUTMパラメータを付ける方法が一般的です。案内の経路ごとにパラメータを決め、一覧にしておきます。付け方のルールを決めずに案内を送ると、同じ経路が別の名前で記録され、集計が難しくなります。
さらに、登録時に流入元の情報を利用者のデータとして保存しておくと、アクセス解析ツールの外でも、登録した利用者がどの経路から来たかを追えます。MVPの段階では利用者数が少ないため、この情報は登録時の簡単な質問（「どこでこのサービスを知りましたか」）で補ってもかまいません。
最低限入れる計測3：問い合わせの記録
三つ目は、問い合わせの記録です。問い合わせは数字ではありませんが、利用者がどこでつまずいているかを知るための重要なデータです。
記録する項目は、日時、利用者（分かれば）、問い合わせの経路、内容、分類（不具合・操作の質問・要望・契約や料金・その他）、対応結果です。スプレッドシートやチケット管理ツールで構いません。大切なのは、どの経路から来た問い合わせも同じ場所に記録することです。
問い合わせの数や分類を週ごとに見ると、「設定画面についての質問が続いている」「同じ不具合の報告が複数ある」といった傾向が分かります。これを利用ログと組み合わせると、どこを改善すべきかがはっきりします。
最低限入れる計測4：利用者単位の利用ログ
四つ目は、利用者単位で行動を追えるログです。アクセス解析ツールは、多くの場合、訪問者全体の傾向を見るのに向いていますが、MVPでは「この企業は、いつ、何をしたか」を個別に追えることが大きな意味を持ちます。利用者が少ないため、一社一社の行動から学べることが多いからです。
利用者単位のログを残す方法には、次のようなものがあります。
- 自社のデータベースに行動を記録する：主要な操作のたびに、誰が・いつ・何をしたかを保存する。集計の自由度が高く、ツールに依存しない。
- プロダクト分析ツールを使う：利用者の識別子を付けてイベントを送信し、ツール上で個別の行動や継続を分析する。
- アクセス解析ツールにユーザーIDを送る：ログインした利用者の識別子を送ることで、ある程度は利用者単位の分析ができる。
MVPでは、少なくとも主要なイベントは自社のデータベースにも記録しておくことをおすすめします。ツールの設定ミスや乗り換えがあっても、データが失われないためです。後から分析しやすいログの残し方はプロダクトのイベントログ設計で詳しく扱っています。
計測ツールの組み合わせ方
MVPで使う計測ツールの組み合わせは、事業の内容と体制によって変わります。代表的な組み合わせを示します。
| 構成 | 内容 | 向いている場面 |
|---|---|---|
| 最小構成 | アクセス解析ツール＋自社データベースへの行動記録＋問い合わせの記録表 | 利用者が少なく、個別に追えば十分な段階 |
| 標準構成 | 最小構成＋プロダクト分析ツール | 利用者が増え、継続や行動の分析を手早く行いたい段階 |
| 拡張構成 | 標準構成＋データを集約して集計する仕組み | 複数のデータを組み合わせて定期的に指標を見たい段階 |
最初から多くのツールを入れる必要はありません。ツールが増えるほど、設定と確認の手間が増え、数字の食い違いも起きやすくなります。MVPでは最小構成から始め、必要になったら足していくのが現実的です。
アクセス解析にはGA4がよく使われます。プロダクト分析ツールにはいくつかの選択肢があり、それぞれ得意なことが異なります。比較の観点はプロダクト分析ツールの選び方を参考にしてください。
MVPの計測を設定する手順
ここまでの内容を、実際の設定の手順にまとめます。
- 計測設計書を作る：仮説、判定指標、記録するイベントの一覧（名前、記録する場面、属性）、流入元のパラメータの一覧を、一つの文書にまとめる。簡単な表で構わない。
- 開発チームと記録の場所を決める：どのイベントを自社のデータベースに、どれをツールに送るかを決める。
- 実装する：開発チームがイベントの記録を組み込む。ツールの設定（タグの設置など）もあわせて行う。
- テスト環境で確認する：一通りの操作を行い、イベントが正しい名前と属性で記録されているかを確認する。
- 社内アクセスの除外を設定する：社内の利用やテストの操作が、集計に混ざらないようにする。
- 本番環境で確認する：公開直前または公開直後に、本番環境で同じ操作を行い、記録されていることを確認する。
- 数字を見る場所を用意する：判定指標を毎週確認できる表やダッシュボードを用意し、誰がいつ見るかを決める。
計測設計書の書き方は計測設計書（トラッキングプラン）の作り方で詳しく説明しています。MVPの段階では、完璧な文書を目指すより、関係者が同じ定義で数字を見られることを優先してください。
公開後に数字を見る運用を決めておく
計測の設定は、数字を見る運用とセットで初めて意味を持ちます。公開後は、週に一度、決まった曜日に判定指標と補助的な数字を確認し、前週からの変化と気づいたことを短く書き残します。数字に大きな変化があった週は、その理由を推測で終わらせず、利用者単位のログや問い合わせを確認し、必要なら利用者に話を聞きます。
確認の場には、事業責任者と開発担当者の両方が参加するのが理想です。数字の背景にある画面や処理を開発担当者が説明できると、改善の打ち手をその場で話し合えます。毎週の記録は、検証の判定日に振り返る際の重要な材料になります。
計測でよくある失敗と避け方
失敗1：ページビューだけを見て判断する
アクセス解析ツールを入れただけで、ページビューや訪問者数を見て「反応がよい」と判断してしまう失敗です。訪問しても使っていなければ、検証にはなりません。避け方は、判定指標を利用者の行動（価値のイベント）で定義することです。
失敗2：イベントを記録しすぎる
すべてのボタンのクリックを記録しようとすると、設定の手間が増え、どの数字を見ればよいか分からなくなります。避け方は、判定指標に必要なイベントと、その変化の理由を探るための少数のイベントに絞ることです。
失敗3：本番環境で計測が動いていない
テスト環境では動いていたのに、本番環境では設定が漏れていて、公開直後のデータが取れなかったという失敗です。避け方は、公開直後に本番環境で自ら操作し、記録を確認する手順をリリースの作業に含めることです。
失敗4：イベントの定義が人によって違う
「アクティブな利用者」の定義が担当者によって違い、会議のたびに数字が合わない失敗です。避け方は、計測設計書に指標の定義（何を数えるか、期間はいつか）を書き、関係者が同じ定義で見ることです。
失敗5：社内の利用が数字に混ざる
MVPは利用者が少ないため、社内のテストや確認の操作が混ざると、数字が大きく歪みます。避け方は、社内のアカウントや社内からのアクセスを識別し、集計から除外する設定を公開前に行うことです。
失敗6：個人情報の扱いを考えずに記録する
利用者の氏名やメールアドレスなどを、そのままツールに送ってしまう失敗です。避け方は、ツールには利用者の識別子だけを送り、個人を特定できる情報は自社のデータベースで管理することです。取得する情報と利用目的は、プライバシーポリシーで説明しておきます。
失敗7：数字を見る人が決まっていない
計測の設定は済んでいるのに、誰も定期的に数字を見ておらず、判定日に初めて集計して想定外の結果に驚く失敗です。途中で気づいていれば打てた手が、打てないまま期間が過ぎてしまいます。避け方は、判定指標ごとに確認する担当者と頻度を決め、週次の確認を予定表に入れておくことです。
MVPの計測チェックリスト
公開前に、次の項目を確認します。
- 仮説と判定指標が一文で書かれている
- 入口・価値・継続のイベントが決まり、名前のルールがそろっている
- イベントに必要な属性（利用者、企業、プランなど）が付いている
- 案内の経路ごとに流入元のパラメータを決め、一覧にしている
- 問い合わせを一か所に記録する場所と分類が決まっている
- 主要なイベントが、利用者単位で自社のデータベースにも記録される
- 社内アクセスを集計から除外できる
- テスト環境と本番環境の両方で記録を確認した
- 判定指標を毎週見る場所と担当者が決まっている
- ツールに個人を特定できる情報を送っていない
具体的な場面で考える：架空の飲食店向け発注サービスの例
架空の例として、飲食店が食材を複数の仕入れ先にまとめて発注できるサービスのMVPを公開する場面を考えます。当初、開発チームはアクセス解析ツールを入れ、ページビューと訪問者数を見る予定でした。
計測を見直すため、まず仮説を「個人経営の飲食店の店主は、電話やFAXでの発注の手間を減らすために、このサービスで週に複数回発注し、2か月続けて使う」と書きました。判定指標は、発注を一度以上行った店舗の数と、その店舗の2か月目の週あたり発注回数です。
そこで、入口のイベントとして「店舗登録完了」「仕入れ先の登録」、価値のイベントとして「発注の送信」、継続のイベントとして「2週目以降の発注」「仕入れ先の追加」を定めました。いずれも店舗の識別子を付け、自社のデータベースにも記録しました。案内の経路は、商店街の組合経由、知人の紹介、SNSの三つに分け、それぞれパラメータを付けたURLを用意しました。
公開後、組合経由で登録した店舗は発注まで進む割合が高く、SNS経由の店舗は仕入れ先の登録で止まりがちなことが分かりました。仕入れ先の登録を運営が代行する案内を追加したところ、止まっていた店舗の一部が発注まで進むようになりました。計測を判定指標から逆算して設計したことで、どこを改善すべきかが具体的に見えた例です。
よくある質問
Q. MVPでもアクセス解析ツールは必要ですか？
流入元やページごとの訪問を把握するために、入れておくと便利です。ただし、検証の判定は利用者の行動で行うため、アクセス解析ツールだけでは不十分です。自社のデータベースへの行動記録と組み合わせて使ってください。
Q. 計測の設定は、開発会社に任せてよいですか？
設定作業は開発会社に任せられますが、何を記録するか（仮説と判定指標、イベントの一覧）は事業側が決める必要があります。開発会社には、決めた内容を計測設計書として渡し、実装後の確認にも事業側が立ち会うことをおすすめします。
Q. 公開後に計測の項目を追加しても問題ありませんか？
追加はできますが、追加する前のデータは取れません。判定に必要な項目は必ず公開前に設定し、補助的な項目は必要に応じて追加するのが現実的です。追加した場合は、いつから記録しているかを計測設計書に書いておきます。
Q. 利用者が少ないうちは、数字よりインタビューのほうが大切ではないですか？
どちらも必要です。数字だけでは理由が分からず、インタビューだけでは全体の傾向が分かりません。数字で気になる動きを見つけ、インタビューで理由を確かめる組み合わせが有効です。進め方はMVP公開後のフィードバックの集め方で詳しく説明しています。
Otsumuに相談できること
検証したい仮説が明確で、開発チームがイベントの記録を組み込める体制があるなら、この記事の手順で自社でもMVPの計測を設定できます。まずは判定指標を一つか二つに絞り、それに必要なイベントを公開前に確実に記録できる状態にするところから始めてください。
一方で、仮説と判定指標の決め方に迷っている、開発会社にどう依頼すればよいか分からない、ツールの選定や設定に時間をかけられない、といった場合は、外部の力を借りるのも一つの方法です。計測は事業と開発の境目にある作業のため、両方を理解している相手と進めると、抜け漏れが減ります。
Otsumuの新規事業の爆速MVPシステム開発では、仮説の整理から計測の設計、開発、公開後の数字の見方まで一気通貫で支援しています。公開後の指標の設計や改善に重点を置く場合は、KPI改善コンサルティングもご相談いただけます。
「何を計測すればよいか分からない」という段階でも構いません。30分の無料相談で、検証したいことをお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01