メトリクスを設計する ── 何を測れば仮説を検証できるか
問いが立ったら、次は翻訳である。「この機能は効いたか」という問いを、「何の数字がどう動けば効いたと判断するか」に翻訳する ── これがメトリクス設計の本質だ。
翻訳は単純に見えて危険が多い。良いメトリクスは判断を鋭くし、悪いメトリクスは組織を誤った方向に走らせる。本章ではその設計の考え方を掘る。
メトリクス設計の公理
まず、本章を貫く三つの公理を置く。
公理 ①：メトリクスは問いの「代理」にすぎない
→ どんなに完璧なメトリクスも、問いそのものではない
→ 代理が本物からどう離れるか、を常に意識する
公理 ②：測ったメトリクスは、その通りに最適化される
→ Goodhart の法則：「測ったものは目標になる、
目標になったものは指標としての意味を失う」
→ 何を測るかは、組織が何を追うかを決める
公理 ③：メトリクスは単独では動かない
→ 一つの数字を追うと、隠れた指標が悪化する
→ 常にカウンターメトリクスとセットで設計するこの三つを頭に入れた上で、具体的な設計論に入る。
リーディング指標とラギング指標
最重要の区別から始める。
リーディング指標（先行指標 / Leading）
未来を予測する指標。行動可能。
例：週次訪問回数、機能 X の利用率、オンボーディング完了率
ラギング指標（遅行指標 / Lagging）
結果を測る指標。行動しにくい。
例：月次売上、解約率、LTV、NPSなぜこの区別が重要か
ラギング指標だけを見ていると、既に手遅れである。
graph LR
A[行動の変化] -->|数週間〜数ヶ月| B[リーディング指標<br/>動く]
B -->|数ヶ月〜数四半期| C[ラギング指標<br/>動く]
style B fill:#9f9,stroke:#333
style C fill:#f99,stroke:#333「先月の解約率が悪化した」と気付いてから打てる手は限られる。解約が起きた顧客は既に去っている。一方で、「解約前にユーザーが取る行動」をリーディング指標で捉えていれば、顧客がまだ残っているうちに介入できる。
具体例：SaaS プロダクト
ラギング指標（結果）：
ラギング：月次解約率 5%（先月判明）
↓ これを動かすには 1〜2 四半期前に手を打つ必要がある
リーディング指標候補：
① 週次アクティブ率の下落
② 機能 X の利用回数の減少
③ カスタマーサポートへの問い合わせ増加
④ チームメンバーの招待数の減少
⑤ 支払情報の更新が遅延している比率
設計の要諦：
ラギング指標が動く「何週間前」に
リーディング指標が動くかを実測して確かめる良いリーディング指標の条件は、以下の二つを両方満たすことである。
✅ ラギング指標と相関している（予測力がある）
✅ 自社の施策で動かせる（行動可能性がある）
どちらか片方だけでは不十分：
- 予測力だけ → 「株価」のような指標（動かせない）
- 行動可能性だけ → 「ログイン回数」（結果に繋がるか不明）North Star Metric（NSM）
「一つだけ追うならこれ」と組織で合意する指標。2010 年代後半から広まった概念で、使い方を誤ると害になるが、正しく使うと組織を揃える力がある。
NSM の三条件
① プロダクトが提供する価値を反映している
❌ 「売上」そのもの（価値の結果であって価値ではない）
✅ 「ユーザーが価値を得た回数」
② ユーザー行動の集約である
❌ 社内の運用 KPI
✅ ユーザー側に起きる出来事のカウント
③ 成長と収益の両方に結びつく
❌ 登録数（価値提供していなくても増える）
✅ アクティブ化した週の回数NSM の例（事例ベース、概念）
Airbnb：予約された宿泊夜数（nights booked）
→ ユーザー側の出来事、ホストも恩恵、売上に直結
Slack：アクティブに利用するチーム数（大規模送信メッセージ）
→ 「50 メッセージ送信」がアクティブ化の閾値と特定された
Spotify：月間聴取時間
→ コンテンツ消費 = ユーザーの価値享受NSM の注意点
⚠️ NSM を過信すると：
一つの数字を追うあまり、他が壊れる
例：「宿泊夜数」を追うと、キャンセル率やホスト満足度が見えない
対策：
NSM は単独では動かさない
NSM + カウンターメトリクス + ガードレール のセットで扱うKPI ツリー ── NSM を分解する
NSM は抽象度が高く、日々の施策に落ちにくい。そこで KPI ツリー で分解する。
graph TD
NSM[NSM: 月間価値提供回数] --> A[① ユーザー数]
NSM --> B[② ユーザーあたり<br/>価値提供回数]
A --> A1[新規獲得数]
A --> A2[継続率]
A --> A3[復帰率]
B --> B1[アクティブ率]
B --> B2[1 セッション<br/>あたり価値]
A1 --> A11[流入数 × CVR]
A2 --> A21[オンボーディング<br/>完了率]
A2 --> A22[習慣化率]
B1 --> B11[機能発見率]
B1 --> B12[機能定着率]
style NSM fill:#fcc,stroke:#333,stroke-width:3px分解の原則
① MECE を意識する（漏れなくダブりなく）
掛け算 / 足し算で NSM に戻せる関係を保つ
② 各ノードに担当を置ける粒度まで分解する
「このチームがこの数字を動かす」が明確に
③ 分解は 3〜4 階層で止める
深すぎると見失う、浅すぎると施策に落ちない掛け算分解と足し算分解
掛け算分解：
NSM = ユーザー数 × アクティブ率 × 1人あたり回数
足し算分解：
新規 NSM = 新規獲得ユーザーの NSM + 既存ユーザーの NSM掛け算分解はどこを伸ばすかの議論に、足し算分解はどの層から来ているかの議論に向く。組み合わせて使う。
カウンターメトリクス（対指標）
「この指標を上げる施策は、別の指標を下げていないか？」を監視する指標。Goodhart の法則への防衛線。
なぜ必要か
典型的な失敗例：
目標： 動画の視聴時間を増やす
施策： 自動再生、次の動画を強制表示、広告スキップ強制
結果： 視聴時間は増えた ✅
副作用：
- ユーザー満足度が下がる
- 翌週の復帰率が下がる
- ブランド毀損
→ カウンターメトリクスを置いていなかったので気付かないカウンターメトリクスの設計
主指標に対して「裏側」「副作用」「質」を置く
主指標： 視聴時間
カウンター：
✅ 視聴後の満足度（セッション終わりの CSAT）
✅ 翌週復帰率
✅ ブロック・解除率
主指標： コンバージョン率
カウンター：
✅ コンバージョン後のキャンセル率
✅ 課金後 30 日の利用継続率
✅ カスタマーサポート問い合わせ率
主指標： 開発リードタイム短縮
カウンター：
✅ 変更失敗率
✅ コードレビュー品質
✅ インシデント件数主指標を動かすたびに、必ずカウンターメトリクスも確認する文化を作る。これだけで暴走を防げる。
ガードレールメトリクス
カウンターメトリクスに近いが、少し役割が違う。「この値を割ったら施策を止める」という下限を定める指標。
例：ページ表示速度
ガードレール：p95 が 2 秒を超えたら新施策を止める
例：エラー率
ガードレール：5分間のエラー率が 1% を超えたら自動ロールバック
例：ユーザー満足度
ガードレール：NPS が 40 を下回ったら全施策を凍結A/B テストや段階ロールアウトでは、主指標・カウンターメトリクス・ガードレールの三点セットを必ず定義する。これが Ch.6 で詳しく触れる「勝ったのに止める判断」の基礎になる。
Goodhart の法則と「測ると壊れる」問題
ここで Ch.1 の公理 ② に戻ってくる。
Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure.” （指標が目標になると、それは良い指標ではなくなる）
これはデータ駆動組織の深刻な病である。
代表的な事例
事例 1：カスタマーサポートの解決時間
指標：平均応答時間を短くする
結果：適当な返信で早く閉じる、結局ユーザーは再問合せ
教訓：「早さ」を測ると「質」が壊れる
事例 2：コードコミット数
指標：エンジニアのコミット数を評価
結果：意味のない粒度で分けてコミット
教訓：「量」を測ると「粒度」が壊れる
事例 3：OKR の達成率
指標：OKR 達成率 100% を目指す
結果：簡単に達成できる OKR しか立てなくなる
教訓：「達成」を測ると「挑戦」が壊れる
事例 4：デプロイ頻度
指標：1日何回デプロイしたか
結果：意味のない変更を細分化してデプロイ
教訓：「頻度」を測ると「変更の質」が壊れる防衛策
✅ 主指標に対してカウンターメトリクスを置く
✅ 指標は「結果」を測り、「プロセス」は測らない
✅ 指標を定期的に見直す（3〜6 ヶ月）
✅ 「指標が操作されていないか」の健全性チェック
✅ 個人評価に直結させない（組織レベルで使う）特に最後が効く。個人の評価に直結した指標は必ず操作される。これは人間の合理性であって悪意ではない。だからこそ指標は組織・プロダクトレベルで使い、個人評価には別の軸（質的評価・ピアレビュー等）を混ぜる。
代理変数（Proxy）の罠
「本当に測りたいもの」が測れないので、近いものを代わりに測る ── これが代理変数である。
測りたいもの：ユーザーの「価値体験」
↓ 測れない（主観・文脈依存）
代理変数の候補：
- アクティブ時間
- 機能利用回数
- リテンション
ここで罠：
代理変数が本物とどれだけ離れているかを忘れる
→ 「アクティブ時間が伸びた = 価値が伸びた」と誤って等号を引く代理変数を使うときのチェック
① 本物とどの程度相関するかを一度は実測する
ユーザーインタビューや NPS と突き合わせる
② 代理変数と本物がズレる条件を列挙する
例：アクティブ時間は、UI が使いにくくても伸びる
③ 複数の代理変数を組み合わせる
単独の代理より、複数の代理が同時に動くほうが信頼できる
④ 定期的に「本物」を直接測る
四半期に一度は NPS、ユーザーインタビュー、定性調査代理変数を忘れずに「これは代理である」と書いておくことが地味に効く。ダッシュボードに「※ xxx の代理指標」と注記するだけで、数字の読み方が変わる。
Input / Output / Outcome の三層
最後に、メトリクスを時間軸で三層に分ける考え方を紹介する。
graph LR
A[Input<br/>投入] --> B[Output<br/>出力] --> C[Outcome<br/>成果]
A1["エンジニアの投入時間<br/>開発予算<br/>マーケ支出"] -.- A
B1["リリースした機能数<br/>配信したコンテンツ数<br/>送ったメール数"] -.- B
C1["ユーザー価値<br/>リテンション<br/>売上"] -.- C三層の関係
Input（投入）： 自分がコントロールできる
Output（出力）： Input の結果として生まれる
Outcome（成果）： Output がユーザーに起こす変化よくある失敗
❌ Output を Outcome と勘違いする
例：「今期は 10 機能リリースした」（Output）
→ これは成果ではない
→ リリースした 10 機能が、ユーザーの何をどう変えたか（Outcome）が成果
例：「広告キャンペーンで 100 万 imp 獲得」（Output）
→ これは配信量であって成果ではない
→ 配信後のユーザー行動変化（Outcome）が成果Output の達成を Outcome と誤認する組織は、忙しいのに事業が伸びない。三層のどこを追っているかを常に意識する。
メトリクス設計の実践手順
ここまでの概念を手順に落とす。
Step 1：問いを書き出す（Ch.2 の結論）
→ 「機能 X が効いたかを判断する」
Step 2：ラギング指標を特定する
→ 最終的に動かしたい数字
→ 例：継続率、LTV、NPS
Step 3：リーディング指標を候補出しする
→ 施策で動かせる、ラギングと相関する
→ 例：利用回数、機能発見率、週次訪問
Step 4：主指標を 1〜2 個に絞る
→ 追う指標を絞らないと組織が散る
Step 5：カウンターメトリクスを置く
→ 主指標の副作用を監視する
Step 6：ガードレールを定める
→ 「ここを割ったら止める」の下限
Step 7：Input / Output / Outcome を分けて記述
→ 自分が混同していないか最終チェック本章のまとめ
✅ メトリクスは問いの「翻訳」。翻訳の仕方で見える風景が変わる
✅ 三つの公理：
① メトリクスは代理にすぎない
② 測ったものはその通りに最適化される（Goodhart）
③ 単独では動かさない（セットで設計）
✅ リーディング vs ラギング：
ラギングだけでは手遅れ、リーディングで先回りする
✅ North Star Metric：一つだけ追う指標
価値 × ユーザー行動 × 成長・収益 に結びつく
✅ KPI ツリーで NSM を分解
掛け算分解 / 足し算分解を使い分ける
✅ カウンターメトリクス・ガードレールを必ずセットで
Goodhart への防衛線
✅ 代理変数は「代理である」と明記する
✅ Input / Output / Outcome を分けて考える
Output の達成を Outcome と勘違いしないメトリクスが決まったら、次は実際に測る準備に入る。Tracking Plan ── 計測の設計図を作る段階である。これがズレると、全てが手戻りになる。