TL;DR（この記事で得られること）
- 「この機能の利用率を調べて」と言われたときに、なぜとりあえず分析を始めてはいけないのかが分かる
- 分析を始める前に「解くべきイシュー」を定義し、「仮説（スタンス）」を立てる具体的な手順が分かる
- 分析結果をステークホルダーに納得してもらうための「空・雨・傘」フレームワークの使い方が分かる
- 未経験からPdM/PMMとして実務に入った人が、実際につまずいたポイントと回避策が分かる
はじめに
プロダクトマネージャー（PdM）やプロダクトマーケティングマネージャー（PMM）として実務を始めたばかりの頃、先輩やステークホルダーから「この機能がどれくらい使われているか調べておいて」と依頼されて、すぐにSQLを叩き始めたり、既存のダッシュボードを見たり、新しく作り始めたりしていませんか？
先日の私がまさにそうでした。「とりあえずデータを集めて可視化すれば、何か見えるだろう」と考えて動き出し、結果として「で、結局何が分かって、次どうするの？」と突っ込まれるであろうと進めていく中で追加の観点が出てきて、プロジェクトが進まない、かつ何のために・何を調査したらいいんだっけ？という点が盲目的になっていました
この記事では、未経験からPdM/PMMとして現場に飛び込んだ私が、「目的不明な分析沼」から抜け出し、「何が本質的なイシューなのか？」という問いとゴールを定義する重要性を実体験ベースでお伝えします。
この記事で伝えたい核心
データ分析の価値は、分析作業そのものではなく「解くべきイシューの定義」と「分析前に立てたスタンス（仮説）」が欲しい結果を最短距離で手に入れるために重要である。
なぜこの問題が起きるのか（背景と課題）
現場でよく陥りがちなのが「手段先行」と「ゴール不在の分析」です。
| 陥りがちなアンチパターン | 本来あるべき姿 |
|---|---|
| 手段の目的化：「とりあえずデータを集めてグラフを作る」 | 目的からの逆算：「何のために、どんな判断を下したいから分析するのか」を決める |
| スタンスなしの調査：「結果を見てから何を言えるか考える」 | 仮説駆動の検証：「現状はこうなのではないか？」という仮説を持って検証する |
| 問いの粒度が粗い：「利用率を調べる」という抽象的な問いのまま着手 | サブイシューへの分解：「解が出せる」レベルまで問いを細分化する |
目的やゴールが見えないまま「一旦分析する」を始めると、以下のような悪循環に陥ります。
- 時間と労力の浪費：時間をかけて集計したデータが、意思決定に役立たない「ただの事実」で終わる
- ステークホルダーとのコミュニケーション不全：「なぜそれを調べているのか？」「何が分かったからどうするのか？」を自分の言葉で説得力をもって説明できない
この根本原因は、名著『イシューからはじめよ』でも言及されている「解くべき課題（イシュー）を見極めずに解き始めてしまうこと」にあります。
（私はこの本をずっと読んでいますが、常に携帯するレベルで合計数10回は見直しています、、）
【実例】現場で遭遇した課題と試行錯誤
私が実際に遭遇したケースをご紹介します。PdMから「最近リリースした〇〇機能が、現場でどう活用されているか調査してほしい」とリクエストを受けました。
失敗しかけた初期の思考
最初は素直に「利用率＝管理画面のとある機能の活用に関連するイベント計測数・イベントが計測されているユーザー数（例えば、該当機能への導線クリック数など）」を出そうとしました。しかし、途中で「利用率が高ければ成功なのか？低ければ失敗なのか？」「そもそも何をもって『活用された』と言えるのか？」が自身の思考として抜けていることに気づきました。
思考の転換：大目的から問いを再定義する
一旦手を止め、そもそも何のためにこの調査をするのかという「大目的」まで遡って考えることにしました。
1. 何をしたいのか？なぜしたいのか？
単に数値を把握したいのではなく、「機能が狙い通り使われていないとしたら、どこにボトルネックがあるのか」を特定し、改善策を打ちたい。
2. 「利用率」を解くべきレベルまで分解する
- 導線の評価：機能が存在する画面やボタンがクリックされた回数（認知・興味）
- ジョブの完遂評価：その機能を使い切って価値が得られたイベント発生回数（弊社プロダクトの場合は「施策配信」の設定完了など）
単純な「利用率」という粗い問いから、「ユーザーは途中で離脱しているのか？そもそも導線に気づいていないのか？」という、答えが出せる（かつアクションに直結する）サブイシューへ分解していく必要があると感じました。
思考の整理と技術的アプローチ
イシューを定義し、価値のある分析にするために実践している本を読んで実際に実践した2つのアプローチを紹介します。
学び① 分析の本質は「比較」である
分析（Analyze）とは、本質的に「分けて、比べること」です。意味のある洞察を得るためには、「どのような軸で」「何と何を比べるか」という設計が不可欠です。
- 比較（同一軸での対比）：ヘビーユーザーとライトユーザーの行動差分はどこにあるか？
- 構成（全体と部分）：利用率の全体値のうち、どの業界・セグメントが割合を占めているか？
- 変化（時系列）：機能改修の前後で、ジョブの完遂率はどう推移したか？
「とりあえず集計する」のではなく、「この軸で比較すれば、こういう差が出るはずだ」という仮説（スタンス）を事前に持っておくことがポイントです。
学び②「空・雨・傘」フレームワークで最終アウトプットを構造化する
分析結果をチームやステークホルダーに届ける際は、「空・雨・傘」のフレームワークで思考を整理します。
【空】事実（データ）
└─ 「機能の導線クリック率は30%だが、設定完了率は5%にとどまっている」
↓
【雨】解釈（分析・気づき）
└─ 「機能への関心はあるが、設定フローが複雑で途中で挫折している」
↓
【傘】判断・アクション（次の一手）
└─ 「設定ステップのUIを簡略化する改善イシューを優先度高で立てる」
受け手に価値を感じてもらうゴールは「納得して次の行動に移ってもらうこと」です。事実（空）だけを報告しても意思決定はできません。
実戦で分かった個人的な注意点・落とし穴
実際に現場で試行錯誤する中で見えてきた、個人的なハマりどころと注意点です。
「自分はどう思うのか？どんな結果が出ると予想しているか？それはなぜか？（＝仮説）」というスタンスが問いを解く前になければ、それは分析ができない（なぜなら、比較対象を定義できないため）ので、仮説を立てることが重要である感じました。
1. 仮説（スタンス）を恐れずに1つに絞る
分析前に「自分はこうなのではないか？」という仮説（スタンス）を明確に立てる癖をつける。スタンスを取ることで、検証すべき条件が絞られ、無駄なデータ抽出を減らせます。仮説が間違っていたら、その時に修正すれば良い。
2. むやみに考慮点を増やして問いをぶらさない
分析を進めていると「あ、このセグメントも気になる」「時間帯別も見たい」と考慮点を追加したくなるが、これをやり過ぎると初期の「解くべき問い」がブレる。まずはメインのイシューに対する答えを出し切ることを最優先にする。一つずつ問いを解くこと。
3. 「答えが出ない」時は、問いの分解が粗いサイン
もしデータを見ても結論が出ないなら、自分の分析スキルではなく「問いの分解度」を疑う。問いが大きすぎる（例：「なぜ売上が上がらないのか？」）と、具体的な答えは出ない。「新規獲得の転換率に問題があるのか？チャーン率なのか？」とサブイシューに刻むことで、初めて答えを導き出せる。
まとめ
未経験からPdM/PMMを経験して学んだ最大の教訓は、「作業を始める前のイシューの定義・ゴール解像度」こそが最短ルートであるということです。
本記事の要点
- 「一旦分析する」は悪手。まず「何がイシューか」を明確にする
- 分析とは仮説を持った「比較」である
- 何がゴールなのか？ゴール状態はどのような状態か？を定義して言語化する
- 粗い問いは「答えが出せるレベル」までサブイシューに分解する
- 空（事実）・雨（解釈）・傘（アクション）を揃えて意思決定を促す
明日から使えるアクション
- 分析依頼を受けたら、いきなりデータを集めず「何のための調査か（大目的）」を依頼者に確認する
- データを調べる前に、メモ帳に「たぶん〇〇が原因ではないか？」という仮説を1文で書く
- 提示する分析結果には、必ず「だから次どうするのか（傘）」の提案を入れる
- 何がわかればゴールか？というゴールの状態を言語化して定義する
イシューから始める思考を身につけて、価値ある仕事を見極め、最大限バリューが出せるように実践していきましょう！