問いを立てる ── 分析が始まる前の分析

2026/04/26

問いを立てる ── 分析が始まる前の分析

Ch.2 章の全体像

分析で最も難しいのは、分析そのものではない。何を分析するかを決めることだ。

現場で頻繁に起きるのは、次のパターンである。

よくある依頼：
  PM: 「先週のユーザー数、出してもらえる？」
  アナリスト: 「DAU？ MAU？ 新規？ 復帰？ どのセグメント？」
  PM: 「全部で」
  （1 時間後）
  PM: 「うーん、これで何が言えるんだっけ？」

この場面の根本問題：
  → 「何の判断に使う数字か」が決まっていない
  → 数字を見てから考えようとしている
  → 結果、見た瞬間に意味を失う

本章では、分析が始まる前の分析 ── 問いの立て方を掘る。ここで勝負の 8 割がつく。

Decision-first thinking

本書が何度も戻ってくる原則を最初に置く。

Decision-first thinking の公式：

  ① どんな判断を下す必要があるか？
     ↓
  ② その判断を変える可能性のある情報は何か？
     ↓
  ③ その情報はどうやって得られるか？

この順番を逆にしない。
「まずデータを見る」ではなく「まず判断を特定する」

最初の問いに答えられないなら、分析する前にやるべきなのは判断の棚卸しである。判断が具体的に描けない状態で数字を集めても、数字は「眺める対象」にしかならない。

判断を具体化する三つの問い

① その判断の結果、何が起きるか？
   （例：機能 X を続けるか撤退するか）

② どんな数字が出たら A にするか？
   （例：「継続利用率が 30% 下回ったら撤退」）

③ どんな数字が出たら B にするか？
   （例：「40% 以上で勝ち、40〜30% はグレー」）

数字を見る前に、閾値を宣言する。この一点が、Decision-first の実装である。閾値を事前に宣言できないなら、その分析は判断に繋がらない可能性が高い。

「問い」の三層構造

プロダクトの現場で扱う問いは、実は三つの層に分かれる。層を混同すると分析が迷走する。

graph TD
    A[戦略的な問い<br/>Strategic] --> B[戦術的な問い<br/>Tactical]
    B --> C[運用的な問い<br/>Operational]

    A1[「この市場に賭けるべきか」<br/>「この事業は続けるべきか」] -.- A
    B1[「この機能は効いたか」<br/>「この施策は進めるべきか」] -.- B
    C1[「昨日の DAU は？」<br/>「エラー率は？」] -.- C

戦略的な問い（Strategic）

範囲：四半期〜年単位
例：「この事業ラインは残すべきか」「この顧客層にピボットすべきか」
データの役割：一つの材料にすぎない。市場、競合、組織、ビジョンが重みを持つ

戦術的な問い（Tactical）

範囲：週〜月単位
例：「機能 X は効いたか」「オンボーディングのステップは減らすべきか」
データの役割：中心的な判断材料。A/B テストや施策後分析の主戦場

運用的な問い（Operational）

範囲：日〜週単位
例：「昨日 DAU が落ちてないか」「エラー率は閾値を超えてないか」
データの役割：監視。ダッシュボード・アラートで自動化すべき領域

層を間違えると何が起きるか

層の混同は、現場で見かける二つの失敗の原因になる。

失敗①：戦略判断を戦術データで決めようとする
  例：「5年後の事業を続けるか」を先月の KPI で決める
  → データは短期しか映さない
  → 戦略判断にはビジョンが必要

失敗②：戦術判断を運用ダッシュボードで済ませる
  例：「施策の効果」をダッシュボードの数字の上下で評価する
  → 季節性・トレンド・他施策との重なりを無視
  → 「動いたように見えるが何が効いたのか分からない」に陥る

問いを立てるときは、それが三層のどれかを明確にする。層が違えばアプローチが違う。

良い問いの 5 条件

問いが良いかどうかを判別する実用的なチェックリスト。

条件 ①：判断に紐付いている

❌ 「ユーザーの行動を知りたい」
   → 知って何をする？

✅ 「オンボーディング完了率が 50% を下回ったらリデザインを決めたい」
   → 閾値・判断・アクションがセット

条件 ②：反証可能である

❌ 「この機能は価値がある」
   → 何が見えたら価値がないと判断するか不明

✅ 「この機能は、利用者の継続率を非利用者より 5pt 以上引き上げる」
   → 5pt 未満なら仮説は棄却される

条件 ③：時間軸が具体的

❌ 「ユーザー満足度は上がっているか」
   → いつからいつまで？

✅ 「リリース前 4 週と、リリース後 4 週で NPS が 3pt 以上上がっているか」
   → 観察期間が明確

条件 ④：比較対象が明示されている

❌ 「機能 X の利用者は 1 万人」
   → 多いの？少ないの？

✅ 「機能 X の利用者は、同等機能を持つ競合比で 1.2 倍、社内目標比で 80%」
   → 何と比べて評価するかが明確

条件 ⑤：行動が結びついている

❌ 「Cohort A のほうが B より数字が良い」
   → で、何をする？

✅ 「A が勝ったら、B のユーザーにも同じ体験を段階ロールアウト」
   → 結論が行動にマップされる

これら 5 つを満たさない問いは、分析する価値はあっても判断には繋がらないと考えてよい。分析を始める前にこのチェックを挟むだけで、ムダが激減する。

問いを立てるときの「二つの対話」

現場で問いを立てるとき、二種類の対話を意識的に分ける。

対話 ①：依頼者との対話（Why Down）

依頼： 「先週のユーザー数を出して」
  ↓ なぜ？
  → 「機能 X が効いているか知りたい」
  ↓ なぜ？
  → 「続けるか撤退するかを決めたい」
  ↓ どんな数字なら続ける？
  → 「継続率 30% 以上なら継続」
  ↓ ようやく「問い」が確定
  → 「機能 X 利用者の 28 日継続率を、非利用者と比較して出す」

「ユーザー数を出す」が「継続率の比較」に変わった。依頼そのものを鵜呑みにせず、Why を三回くらい掘ると、ほぼ確実に別の問いが出てくる。これは Toyota の「5 Whys」のアナリティクス版と言ってよい。

対話 ②：自分との対話（What If）

問い：「機能 X 利用者の 28 日継続率を出す」

  What if 数字が高かったら？
    → 続ける。じゃあ「高い」って具体的に何%？

  What if 数字が低かったら？
    → 撤退する。じゃあ「低い」って具体的に何%？

  What if グレーゾーンなら？
    → どうする？もう 4 週様子を見る？セグメント深掘り？

  What if 数字は良いが、代替機能のカニバリだったら？
    → その可能性は今回の分析で分かる？分からないなら別途設計必要

結果の分岐で自分の行動が変わらない分析は、やる価値が薄い。「数字を見るまでは行動を決めない」は一見慎重に見えるが、実際は「事前に選択肢を考えていない」サインであることが多い。

「分析しない」という選択肢

最も強力な問いの捌き方は、実は分析しないことである。

分析しない方が良いケース：

① 判断が既に決まっている
   → 「一応データで確認したい」は時間の無駄
   → 決断のための儀式としての分析

② 判断のコストが極端に低い
   → 「UI 文言を直す」くらいなら直してしまえ
   → 分析の工数のほうが施策より重い

③ データが示唆を与えられない構造
   → 前例がない、十分なサンプルがない、計測できない
   → 「エイヤ」で決めて後で計測を仕込む方が早い

④ 判断のタイミングが今しかない
   → 完璧な分析を待つとチャンスを逃す
   → 「今の情報で決め、後で検証」の方が価値が高い

「データ駆動」と「データでしか決めない」は違う。どの判断がデータで決めるに値するかを選ぶのも、Decision-first thinking の一部である。

「分析すべきか」の判断フロー

graph TD
    A[判断が発生] --> B{判断は<br/>可逆的？}
    B -->|Yes| C{実行コストは<br/>低い？}
    B -->|No| D[分析必須]
    C -->|Yes| E[やってから<br/>測る]
    C -->|No| F{データで<br/>差がつく？}
    F -->|Yes| D
    F -->|No| G[経験と<br/>ビジョンで決める]

    style E fill:#cfc,stroke:#333
    style G fill:#cfc,stroke:#333
    style D fill:#ffc,stroke:#333

AWS の Jeff Bezos が言った「Type 1 / Type 2 Decisions（不可逆 / 可逆）」は、ここで役立つ。可逆な判断は分析より実行を優先、不可逆な判断は分析を厚くする。

「問い」の立て方の悪い例・良い例

最後に、現場でありがちな悪い問いと、それをどう書き直すかを例示する。

例 1

❌ 悪い問い：「ユーザーエンゲージメントを分析したい」

  問題点：
    - 何をもってエンゲージメントとするか未定義
    - 分析して何を判断するか不明
    - 結果の評価軸が存在しない

✅ 書き直し：
  「新機能 X のリリース後、利用者の週次訪問回数が
   リリース前同セグメントより 20% 以上増えているかを検証する。
   増えていれば全ユーザーに展開、そうでなければ撤退。」

例 2

❌ 悪い問い：「離脱率が高い理由を知りたい」

  問題点：
    - 「高い」の比較対象が不明
    - 理由を知って何をするか未定
    - 仮説が列挙されていない

✅ 書き直し：
  「新規ユーザーのオンボーディング 3 日以内離脱率が、
   過去 3 ヶ月の同時期より 5pt 以上高い。
   原因を a)UI 変更、b)集客チャネル変化、c)季節性 の
   3 仮説で切り分け、最も寄与の大きいものに対して施策を打つ。」

例 3

❌ 悪い問い：「機能 Y の使われ方を知りたい」

  問題点：
    - どのユーザーセグメントに興味があるか不明
    - 「使われ方」の粒度が曖昧
    - 結論が行動に繋がらない

✅ 書き直し：
  「機能 Y の主要ユースケースを発見する。
   上位 10% ヘビーユーザーの操作ログから、
   頻出する 3 〜 5 のシークエンスを抽出。
   それを元に、裾野ユーザー向けのチュートリアルを作る。」

書き直し前後で、同じデータを見ても結論と行動が変わる。問いの立て方ひとつで、分析の価値が決まる。

本章のまとめ

✅ 分析の 80% は問いを立てる段階で勝負がつく
   「まずデータを見る」ではなく「まず判断を特定する」

✅ Decision-first thinking の公式：
   ① どんな判断を下す必要があるか
   ② 判断を変える情報は何か
   ③ どうすれば得られるか

✅ 問いは三層（戦略・戦術・運用）に分ける
   層が違えばアプローチが違う

✅ 良い問いの 5 条件：
   ① 判断に紐付く
   ② 反証可能
   ③ 時間軸が具体的
   ④ 比較対象が明示されている
   ⑤ 行動が結びついている

✅ 「Why Down」「What If」の二つの対話で問いを磨く

✅ 分析しない選択肢も常に検討する
   可逆 × 実行コスト低 → やってから測る

問いが立ったら、次は何を測るか ── メトリクス設計に進む。良いメトリクスは「問いを翻訳する」行為であり、翻訳の仕方でデータから見える風景がまるで変わる。