この記事のポイント
- プロダクト指標を読めるエンジニアは技術判断と事業判断を接続できる
- 非PMが押さえるべきはMAU・LTV・CAC・Retentionの4指標
- LTV/CAC比率が3を切るプロダクトは技術投資の優先順位を見直す合図
- Retention曲線の形状で「機能追加」と「品質改善」の判断が変わる
- データドリブンな技術判断ができるエンジニアは昇進速度が1.5倍速い
なぜエンジニアにプロダクト指標が必要なのか
ある SaaS企業のシニアエンジニアが、検索機能のリファクタリングを提案した。技術的には正しい判断だった。レスポンスタイムが3秒から0.5秒に短縮される。
だが、プロダクトマネージャーはこう聞いた。「それで、チャーンレートはどのくらい改善するの？」
エンジニアは答えられなかった。結果、そのリファクタリングの優先度は下げられた。
技術的な改善を事業の言葉に翻訳できない。これが、多くのエンジニアが「技術はあるのに影響力がない」と感じる根本原因だ。
プロダクト指標の全体マップ
プロダクト指標は、大きく4つのカテゴリに分類できる。
| カテゴリ | 問い | 代表的な指標 |
|---|---|---|
| 獲得（Acquisition） | ユーザーはどこから来るか | CAC, オーガニック流入数, サインアップ率 |
| 活性化（Activation） | ユーザーは価値を体験したか | Aha Moment到達率, オンボーディング完了率 |
| 継続（Retention） | ユーザーは使い続けているか | DAU/MAU, リテンション率, チャーンレート |
| 収益化（Revenue） | ビジネスとして成立しているか | MRR, ARPU, LTV, LTV/CAC比率 |
この4カテゴリを意識するだけで、プロダクトのどこにボトルネックがあるかが見えるようになる。
エンジニアが押さえるべき必須10指標
| # | 指標名 | 定義 | エンジニアへの関連性 |
|---|---|---|---|
| 1 | DAU / MAU | 日次/月次アクティブユーザー数 | デプロイ後の利用状況モニタリング |
| 2 | リテンション率 | N日後に戻ってくるユーザーの割合 | 機能追加の効果測定に直結 |
| 3 | チャーンレート | 一定期間内に離脱するユーザー/顧客の割合 | パフォーマンス改善の説得材料になる |
| 4 | MRR | 月次経常収益 | 新機能リリースとの相関を見る |
| 5 | ARPU | ユーザーあたり平均収益 | プラン別の機能設計に影響 |
| 6 | LTV | 顧客生涯価値 | インフラコストとの対比で投資判断 |
| 7 | コンバージョン率 | 特定のアクションを完了するユーザーの割合 | UI改善・API最適化のROI算出 |
| 8 | NPS | 顧客推奨度スコア | プロダクト品質の包括的な指標 |
| 9 | P95レイテンシ | 95パーセンタイルのレスポンス時間 | SLO設計・アラート設定の基準値 |
| 10 | エラーレート | 全リクエストに対するエラーの割合 | デプロイ後の品質ゲートとして機能 |
指標9と10はエンジニアにとって馴染み深い。問題は1〜8だ。これらを「PMの仕事」として無視していると、技術的な意思決定の説得力が弱くなる。
DORA Metricsを知っているか
Googleが提唱するDORA（DevOps Research and Assessment）Metricsは、エンジニアリング組織の生産性を測る4つの指標だ。
| 指標 | 定義 | エリート水準 |
|---|---|---|
| デプロイ頻度 | 本番環境へのデプロイ回数 | 1日に複数回 |
| リードタイム | コミットから本番リリースまでの時間 | 1時間未満 |
| 変更失敗率 | デプロイ後に障害が発生する割合 | 5%未満 |
| 復旧時間 | 障害発生から復旧までの時間 | 1時間未満 |
DORA Metricsが面白いのは、「速度」と「安定性」がトレードオフではないことを証明している点だ。エリートチームは、速くデプロイしながら、障害も少ない。
この指標を自チームで計測し、改善を主導できるエンジニアは、組織から高く評価される。
指標を武器にする3つの実践
実践1: 週次でプロダクト指標を確認する
Mixpanel、Amplitude、Google Analyticsなど、自社が使っている分析ツールのダッシュボードを週1回見る。最初は数字の意味がわからなくても、3ヶ月続ければトレンドが読めるようになる。
実践2: PRの説明に指標を入れる
「検索のレスポンスタイムを3秒→0.5秒に改善」ではなく、「検索のP95レイテンシを3秒→0.5秒に改善。過去のデータから、検索速度が1秒短縮されるとコンバージョン率が0.3%向上すると推定」と書く。
たったこれだけで、PRレビューでの評価が変わる。事業インパクトを語れるエンジニアは希少だ。
実践3: SQLで指標を自分で引く
分析チームに依頼するのを待たず、自分でSQLを書いてデータを取得する。これができるだけで、仮説の検証速度が劇的に上がる。
多くのSaaS企業ではRedshift、BigQuery、Snowflakeなどのデータウェアハウスが整備されている。基本的なSELECT文とWINDOW関数を覚えれば、ほとんどの分析は自力でできる。
指標リテラシーがキャリアを分ける理由
テック企業のシニア以上のグレードでは、「技術的な意思決定を事業成果と接続できること」が昇格の条件になっていることが多い。
Googleの「Staff Engineer」の定義にも、Meta の「E6」の期待値にも、「ビジネスインパクトの理解」が含まれている。純粋に技術だけで昇格できるのは、ごく一部の例外的な天才だけだ。
プロダクト指標は、技術とビジネスをつなぐ共通言語だ。この言語を習得することが、エンジニアとしてのキャリアを次のステージに進める最も確実な方法ではないだろうか。
指標が読めるエンジニアの具体例
実際に指標リテラシーがキャリアを変えた事例を紹介する。
事例1: リテンション改善で昇格
あるSaaS企業のバックエンドエンジニアが、自社のリテンション率が業界平均を下回っていることに気づいた。分析すると、サインアップ後7日以内に特定の機能を使ったユーザーのリテンション率が、使わなかったユーザーの3倍だった。
彼はオンボーディングフローを改修し、その機能への導線を強化する提案をPRに書いた。技術的には小さな変更だったが、リテンション率が8%改善。この成果が評価され、シニアエンジニアに昇格した。
事例2: コスト削減の可視化
インフラチームのエンジニアが、特定のAPIエンドポイントのレスポンスが遅いことに気づいた。P95で5秒かかっていた。技術的にはキャッシュの追加で簡単に改善できる問題だったが、優先度が低いまま放置されていた。
彼はGoogle Analyticsのデータと突き合わせ、「このエンドポイントの遅さが原因で、月間約200人のユーザーが離脱している」と推定した。LTVから計算すると、年間約2,400万円の機会損失。キャッシュ追加の工数は2日。ROIは圧倒的だった。この分析がきっかけで、チーム全体が「指標ドリブンなタスク優先順位付け」を採用するようになった。
PMとの協業——指標を共通言語にする
エンジニアがプロダクト指標を理解すると、PMとの会話の質が根本的に変わる。
指標を知らないエンジニアとPMの会話は「作ってほしいもの」と「作れるもの」の交渉になりがちだ。だが指標を共有すると、会話の軸が「ユーザーにとって何が最も重要か」にシフトする。
具体的には、週次の1on1でPMと一緒にダッシュボードを見る時間を15分つくるだけでいい。数字を眺めながら「この数値が下がっているのはなぜだろう」と議論する。この習慣が、エンジニアの視野を技術の外側に広げてくれる。
まず今週、自社のダッシュボードを1つ開いてみてほしい。
導入5ステップ
ステップ1: Acquisition・Activation・Retention・Revenueの4カテゴリを把握する
プロダクト指標を獲得・活性化・継続・収益化の4軸に分類する。CAC・Aha Moment到達率・DAU/MAU・MRRを自社のどこで計測しているかを特定する。
ステップ2: 必須10指標とDORA Metricsを週次で確認する
Mixpanel・Amplitude・Google Analyticsのダッシュボードを週1回開く。DAU/MAU・リテンション・チャーン・P95レイテンシに加え、DORAのデプロイ頻度・リードタイム・変更失敗率・復旧時間を自チームで計測する。
ステップ3: SQLで自分で指標を引く
Redshift・BigQuery・SnowflakeなどのDWHにアクセスする。SELECT文とWINDOW関数を使い、分析チームに依頼せず自分で仮説検証クエリを実行する。
ステップ4: PR説明に事業インパクトを数値で記載する
「P95レイテンシを3秒→0.5秒に改善」に加え、「過去データから検索速度1秒短縮でコンバージョン率0.3%向上と推定」のように事業影響を定量化してPRに書く。
ステップ5: PMとの週次1on1で15分ダッシュボードを見る
PMと週1回15分、分析ダッシュボードを一緒に眺める時間を設定する。「この数値が下がっているのはなぜだろう」と議論し、技術的意思決定を事業成果と接続する習慣を作る。
よくある質問
Q. エンジニアがKPIを学ぶ意義は
A. 技術判断を事業インパクトに翻訳できるようになる。「この機能を作るとRetentionが何%改善するか」を語れるエンジニアは、CTO・VPoEへの昇進候補として認識されやすい。
Q. まず押さえるべき指標は何か
A. MAU・LTV・CAC・Retentionの4つだ。それぞれ「規模」「収益性」「獲得コスト」「定着」を表し、組み合わせで事業の健全性が判断できる。ARPUとChurn Rateも追加で押さえたい。
Q. データ分析ツールは何を使えばいいか
A. プロダクト分析はAmplitudeかMixpanel、SQL直接分析ならBigQueryかRedshiftが定番。まずは自社で使われているツールでクエリを書ける状態を目指すのが近道。
関連記事
- [FDE（フォワードデプロイドエンジニア）とは？AI時代に年収2倍を実現する最強キャリアの全貌](/articles/10000028) - [【2026年版】ITエンジニアにおすすめの資格ロードマップ｜レベル別・目的別に解説](/articles/10000182) - [GTMエンジニアとは？ セールスエンジニアとの違い・年収・スキルを徹底解説【2026年最新】](/articles/10000282)
