プロローグ ── データ駆動の「嘘」と本当

2026/04/26

プロローグ ── データ駆動の「嘘」と本当

Ch.1 章の全体像

シリーズ構成（全10章）

Part 1 — 分析の前段 Ch.1 プロローグ（本章） / Ch.2 問いを立てる / Ch.3 メトリクスを設計する / Ch.4 計測を仕込む

Part 2 — 数字と向き合う Ch.5 数字を読む（統計的な目） / Ch.6 実験を設計する / Ch.7 因果を推定する

Part 3 — 判断する Ch.8 判断を下す / Ch.9 アンチパターン

Ch.10 エピローグ — データと判断の文化

この記事で扱う違和感

「データ駆動」という言葉は、2020 年代に入ってから完全に市民権を得た。プロダクトミーティングで「データはどう？」と誰かが聞き、Amplitude や Looker のダッシュボードが開かれ、誰かがクエリを書く ── この風景は、もはや大企業だけのものではない。

それでも、こういう場面に心当たりはないだろうか。

あるある場面：

場面1: ダッシュボードを 20 枚作ったが、誰も見ていない
  → 「作っただけで満足した感」

場面2: A/B テストで有意差が出たのに、ローンチ後の指標が動かない
  → 「テストでは勝ったはずなのに何故？」

場面3: KPI が 8% 改善した。だが事業責任者は喜ばない
  → 「その数字、何の意味？と聞かれて答えられない」

場面4: 「データがないから判断できない」と決定を先送り
  → 半年経ってもデータは溜まっていない

場面5: 平均値だけ見て意思決定。実態とズレてる
  → 上位 1% のヘビーユーザーに引っ張られた数字だった

これらは全て、「データ駆動」の旗の下で起きる典型的な失敗である。

面白いのは、データがないから起きるのではなく、データがあるから起きることだ。データを集めたのに判断が歪む。ダッシュボードを作ったのに行動が変わらない。数字が動いたのに事業が動かない。

この記事は、こうした「データ駆動の失敗」を直視しつつ、どう考えればプロダクト開発プロセスの中でデータが本当に効くのかを体系化する試みである。

この記事のスタンス

重要なので先に宣言しておく。

❌ この記事が扱わないこと：
   - SQL / Python / dbt の書き方
   - Amplitude / Mixpanel / Heap のツール比較
   - データサイエンスの数式導出
   - 機械学習モデルの構築

✅ この記事が扱うこと：
   - 「どう考えるか」の思考フレーム
   - 「なぜそう見るか」の論理
   - 現場で繰り返される失敗の構造
   - ツールが変わっても残る判断の原則

ツールは 3 年で入れ替わる。2020 年に Amplitude 前提で書かれた記事は、2026 年には一部が古い。しかし「なぜ中央値を見るべきか」「なぜ実験と観察は違うのか」「なぜ sunk cost で判断すると壊れるか」という論理は、20 年前も今も変わらない。

本書はその変わらない部分に徹する。

「データ駆動」の二つの誤解

本題に入る前に、広く信じられている二つの誤解を解いておきたい。

誤解 ①：「データがあれば正しく判断できる」

これが一番根深い。

「データが意思決定の質を上げる」という期待

  期待：  データ → 正しい判断
  現実：  データ + 問いの立て方 + 解釈力 + 判断の勇気 → 判断

  → データは材料にすぎない
  → 材料を集めるだけでは料理にならない

2010 年代の「データ民主化」の掛け声は、データへのアクセスの問題を解いた。誰でも SQL を書ける、誰でもダッシュボードを作れる環境は整った。しかしアクセスが解けても判断は解けない。むしろ、大量のデータに囲まれて動けなくなる組織の方が増えている。

「データがあれば正しく判断できる」という期待は、判断の困難をデータのせいにする心理を生む。「データがないから決められない」と言い続ける組織は、データが揃っても決められない。

誤解 ②：「HiPPO（偉い人の意見）を倒すためにデータが必要」

データ駆動の文脈でよく出る「HiPPO（Highest Paid Person’s Opinion）」という言葉。偉い人の主観で決まる組織を揶揄する言葉として広まったが、実はこの言葉の使い方自体がデータ駆動の誤解を含んでいる。

HiPPO を「データで殴る」文化の危険：

  ❌ データ = 議論を終わらせる武器
  ❌ 数字を出した方が勝ち
  ❌ 「エビデンスがないから却下」

  → この文化は別種の HiPPO を生む
  → 「データを持っている人」の HiPPO 化
  → 「データが出せないアイデア」の自動却下

本書の立場は、データは議論を終わらせるものではなく、議論を始めるものである。数字は前提を共有させ、視点を揃え、次の問いを生む。結論を生むのは最後まで人間の判断である。

これは Ch.10 で戻ってくるテーマだが、最初に言っておく。データ駆動とは、人間の判断を放棄する思想ではない。

プロダクト開発プロセスの中で、データが登場する 6 つの場面

この記事が扱う「プロダクト開発プロセス」を具体的にしておく。

graph LR
    A[① 何を作るか<br/>の判断] --> B[② 作る前の<br/>仮説設計]
    B --> C[③ 計測の<br/>仕込み]
    C --> D[④ リリース時の<br/>実験]
    D --> E[⑤ 効いたかの<br/>事後判定]
    E --> F[⑥ 続けるか<br/>撤退するか]
    F --> A

    style A fill:#fcf,stroke:#333
    style F fill:#fcf,stroke:#333

① 何を作るか
   → ユーザー行動データ、セグメント分析、ジョブ理論

② 仮説設計
   → 「何が変わるはずか」を事前に宣言する

③ 計測の仕込み
   → イベント設計、Tracking Plan、指標定義

④ リリース時の実験
   → A/B テスト、段階ロールアウト

⑤ 効いたかの事後判定
   → ポストローンチ分析、コホート観察

⑥ 続けるか撤退するか
   → 判断の論理、sunk cost との向き合い方

本書はこの 6 場面を、ライフサイクルに沿って順番に扱う。Ch.2 が ①②、Ch.3〜5 が ③、Ch.6 が ④、Ch.7 が ⑤、Ch.8 が ⑥ である。

読み進める前の「心の準備」

本書を通して、読者には以下の三つのマインドセットを身につけてもらいたい。

① Decision-first（判断から逆算する）

❌ ダメな順序：
   データを集める → ダッシュボードを作る → 何か言えそうな分析を探す

✅ 良い順序：
   どんな判断が必要か → その判断に効くのは何か → それを測る

分析は判断の手段である。判断に紐付かない分析は、どれだけ精緻でも仕事として成立していない。これは Ch.2 の主題である。

② 懐疑的である

数字を見たときの最初の問い：
  - この数字は何を測っている？
  - どう計算された？
  - 何と比べている？
  - この数字が動いたら、本当に嬉しい？

数字は嘘をつかないが、数字は多くのことを語らない。平均は中央値を隠し、合計はばらつきを隠し、割合は母数を隠す。懐疑的であることが、最も地味で最も効くスキルである。

③ 不確実性と共存する

「データが十分揃うまで判断しない」は多くの場合、判断の放棄

現実：
  ✅ データは常に不完全
  ✅ 判断のタイミングは多くの場合、分析完了を待てない
  ✅ 「確からしい」と「確実」は違う

完全なデータで判断するのは科学者、不完全なデータで判断するのがプロダクト開発者である。ここに尽きる。Ch.8 で掘り下げる。

対象読者

対象：
  - プロダクトマネージャー / プロダクトエンジニア
  - テックリード・EM で意思決定に関わる方
  - データアナリストでプロダクト側と協働する方
  - スタートアップで「何でもやる」立場の方
  - 「ダッシュボード作ったのに誰も見ない」に心当たりがある方

難易度：★★★☆☆
読了時間：約3時間（全章通読時）
前提知識：
  - 基礎的な統計用語（平均・分散・標準偏差・相関）を聞いたことがある
  - 「A/Bテスト」という概念を知っている
  - プロダクト開発の現場経験がある（規模は問わない）

本書の読み方

通読を強く推奨する。各章が前章の論点を前提にして書かれている。ただし時間がないとき用の入り口も用意しておく。

「そもそも何を分析すべきか」を整理したい     → Ch.2 → Ch.3
「数字の見方を鍛えたい」                    → Ch.5 単独でも可
「A/B テストの論理を押さえたい」             → Ch.5 → Ch.6
「実験できないときに困っている」             → Ch.6 → Ch.7
「撤退判断ができない組織にいる」             → Ch.8 → Ch.9
「データ文化を変えたい」                    → Ch.1 → Ch.9 → Ch.10

次章では、「分析が始まる前の分析」── つまり問いの立て方から始める。良い分析の 80% は、この段階で勝負がついている。