本記事ではデータ分析の基本として分析の目的の設定におけるステップや注意点を概観します。
ただデータの形式や分野・データの利用目的によって手順や判断基準は異なります。
今回は筆者が扱うことの多いアンケートデータを前提にして記載していきます。
データ分析は最初の目的設定が大事
分析が迷走するのは、データが足りないからではありません。手法が古いからでもありません。最初の問いが曖昧だからです。
実際の現場を見ていると、分析が失敗またはうまくいかない場合のパターンはかなり決まっています。
「とりあえずデータを見てみよう」「使えそうな手法で一回試してみよう」「何か示唆が出たら施策を考えよう」
一見もっともらしいこの進め方なのですが、実務ではかなり危ういです。なぜなら分析のゴールが最初から決まっていないからです。（目的が決まったうえでシミュレーション的に、探索的に分析することはあると思います。）
私が関わってきた失敗ケースもほぼ同じでした。集計はきれい。グラフも多い。モデルの精度も悪くない。なのに、会議で最後に残る一言がこれです。
「で、結局どうするの？」
「結局CLにお見せできる結果・示唆は出ませんでした。」
痛いのは、そこまで数週間、ひどい時は数か月かかっていることです。つまり分析が外れるのは、終盤で起きるように見えて、実は最初の設計段階で既に決着しているのです。
CRISP-DMという分析の進め方の枠組みでも、Microsoft のデータサイエンスライフサイクルでも、一番最初に「ビジネス理解」を置いています。それは偶然ではなくて、分析は本質的に意思決定を支える仕事だからです。
前置き：「知りたいこと」と「変えたい意思決定」は別物
「売上を上げたい」という相談はよくあります。ただ、これはまだ分析目的ではありません。これは事業上の願望です。強い言い方をすれば、まだ問いになっていません。
分析で扱える形にするには、最低限ここまで落とし込む必要があります。
1. どの事業課題を扱うのか
売上なのか、利益なのか、数量なのか、継続期間なのか。同じ「業績改善」でも、打つべき施策はまるで違います。
2. 誰の意思決定を支えるのか
経営層なのか、営業の現場責任者なのか、マーケティング担当なのか。見るべき粒度も、必要なアウトプットも大きく変わります。実務で何度も見かけるのが「誰にも刺さらない資料」です。つまり上層部の意思決定にも寄与しなければ、現場が動けるほど細かい粒度にもなっていない。きれいだけど誰が何に使うのか分からない状態です。
3. どの指標をどう動かしたいのか
指標が曖昧な分析は、最後に都合のいい解釈に流れやすいため、必ず先に決めておきます。
特に定量的な分析の場合はマストです。「
4. 分析結果を受けて何を実行するのか
予算配分を変えるのか。ターゲティングを変えるのか。UIを変えるのか。ここがない分析は、だいたい「報告」で終わります。
要するに分析の目的とは、知識を増やすことではなく、判断を変えることです。
なぜこんなに外れやすいのか
理由は意外とシンプルです。事業課題と分析課題と評価指標と実行アクションが混同されるからです。
実例を挙げると、こんなズレが起きます。
事業課題は「売上を伸ばしたい」なのに、分析課題は「離脱率の要因を知りたい」。評価指標は「離脱率の予測モデル精度」を見ている。実行アクションはまだ未定。（ぼかしているので変な例ですが、上記の歪さは深いドメイン知識がないとずれを認識できないため、実務上は特に気を付ける必要があります。）
この状態で分析を進めると、途中で必ずブレます。なぜなら「何をもって成功とするか」が、関係者ごとに違ってしまうからです。売上を伸ばしたい人は問題点が知りたい。分析担当は説明力の高い結果を出したい。現場責任者は、すぐ打てる粒度の施策の具体的な提案が欲しい。この3つが揃っていないと、結果はアウトプットとしては立派でも現場で使われません。
分析で最も怖いのは「間違った答え」ではなく「使えない正解」です。
分析は実は暗黙の仮定を多く、置いていることが多いため、本当の意味では全て間違っていると言ってよいと思います。ただ正解の範囲を如何に狭めるか、その範囲においてどのように意思決定するのかを規定することを念頭に置かないといけません。
実務で失敗するパターン
ここから、現場でよく見かける失敗を六つ挙げます。
1. 目的が抽象的すぎる
「売上を上げたい」で止まってしまう。その結果、分析テーマに落ちないまま進む。
2. 意思決定者がいない
誰が何に使うのか、そもそも決まっていない。つまり誰にも刺さらない。
3. 指標が後付けされる
分析後に評価軸を決めてしまう。解釈がブレます。
4. データで取れないことを目的にする
現場で測れないものを追ってしまう。設計段階のミスです。
5. 手法から入ってしまう
「機械学習を使いたい」とか「回帰分析がしたい」という思いから始まる。それは目的ではなく、ただの手段です。
6. 実行アクションがない
分析して終わる。これが一番多い失敗パターンです。
分析の目的と手法選択のステップ
目的設定は、次の流れで定義するのがおすすめです。
STEP 1 ： 事業目的を明文化する
まず最上位の目的を定めます。売上成長なのか、顧客満足の向上なのか。
ここでは「組織として何を良くしたいのか」を一文で言えることが重要です。ふわっとした理想論ではなく、事業として改善したい対象を明確にします。分析の段階というよりはプロジェクトのキックオフのタイミングで握っておきます。
STEP 2 ： 誰の意思決定を支援するのか決める
マーケ責任者が予算配分を決めるのか。営業責任者が重点顧客を決めるのか。プロダクト責任者が改善優先順位を決めるのか。この一文があるだけで、必要な粒度がかなり変わります。同じ分析でも経営層向けなら要点は粗くていい。現場責任者向けなら、すぐ打てる施策の粒度まで必要です。
こちらもSTEP1同様最初に目線合わせしておきます。
STEP 3 ： 分析目的に翻訳する
ここで初めて分析の問いを立てます。解約を減らしたいなら、解約者の共通特徴を特定するのか、解約前兆行動を検出するのか、解約確率を予測するのか。新商品の勝ち筋を知りたいなら、類似商品の購買層を分類するのか、高LTV層の特徴を抽出するのか。営業効率を上げたいなら、受注率の高い商談条件を特定するのか、優先訪問先をスコアリングするのか。事業目的を分解してどこに問題があるのか、目的に対してどの程度乖離があるのか、何が変数（変えようがあるポイント）なのかを考えます。
この翻訳が上手い人ほど、分析の無駄が少ないです。
逆にここが曖昧だと、途中で「あれも見よう」「これも見よう」と枝葉が増えていきます。
まずは重要度が高く、事業目的に直結する分析から対応するのが定石です。
あれもこれもはその後にしましょう。
STEP 4 ： 成功条件を二層で決める
ここはしばしば見落とされますが、かなり重要です。成功条件は「分析」と「事業」に分けて置くべきです。
分析における成功とは、主要因が説明できた、セグメント分類が再現可能になった、モデル精度が必要水準を満たした、継続監視できる形で可視化できた、という類のことです。
事業における成功とは、解約率が3か月で2ポイント改善した、CPAが15％改善した、商談化率が10％改善した、在庫廃棄率が20％下がった、という結果です。
この二段構えにしないと「精度は高いのに現場で使われない」という悲しい事故が起きます。実務で本当に評価されるのは、分析の美しさではなく、事業への接続です。
リサーチでは必ずしも事業成功を何％向上など詳細に定義することは多くありませんが、STEP1で記載したように事業成功に対して現状、何が問題となっていて、どのくらい乖離があるのかが分からないと提案が出来ないため、調査の目的を踏まえて必要な範囲でなるべく具体化するべきです。
STEP 5 ： データ要件を逆算する
目的が決まると、必要データはかなり明確になります。目的変数は何を説明・予測したいか。説明変数候補は何が要因として効きそうか。粒度は顧客単位、店舗単位、それとも日次、週次か。どれだけ遡るか。チャネル、地域、商品、担当者など、どれで比較したいか。欠損はあるか、取得できるのか、バイアスや法規制の制約はないか。
ここで初めて「どのデータが必要か」を考えるのが自然です。先にデータがあるから分析する、ではなく、目的から逆算して必要データを定義する。順番は地味ですが、この差が大きい。
STEP 6 ： アウトプットを先に設計する
これも実務ではかなり効きます。分析前に「どの図表が出れば判断できるか」を決めておくのです。要因分解図が出れば判断できるのか。セグメント比較表か。ファネル分析か。コホート分析か。回帰係数表か。特徴量重要度か。施策優先度マトリクスか。KPIダッシュボードか。
先に出口を決めておくと、分析が散らかりません。逆に出口なしで始めると、途中で図表ばかり増えていきます。
「売上を上げたい」をそのまま分析できない理由
ここで一つ、ありがちなテーマを分解してみましょう。
「売上を上げたい」このままでは、正直ほとんど何もできません。
売上を分解すると、例えば客数 × 購買頻度 × 客単価になります。さらに言えば、客数は新規獲得数から離脱数を差し引いたもの。客単価は購入点数 × 平均単価です。
ここまで分けると、問いは急に鋭くなります。新規獲得が落ちているのか。それとも離脱が増えているのか。特定カテゴリの単価が下がっているのか。特定チャネルで頻度が落ちているのか。
この状態になって初めて、分析は意味を持ちます。つまり大事なのは、最初に高度な手法を選ぶことではなくて、問いを分解することです。アルゴリズムは後。まず構造。ここを取り違えると、分析はすぐ方法論に流れてしまいます。
コンサル視点とデータサイエンス視点とリサーチ視点の役割の違い
実務では、この二つの視点がしばしばズレています。ただどちらかが正しいというより、役割が違うだけです。
コンサル寄りの視点は、どの事業課題に効くのか、どんな意思決定を支えるのか、論点分解は妥当か、施策に落とせるか、関係者が納得できるかを重視します。つまり「何を決めるべきか」を詰める役割です。
データサイエンス寄りの視点は、その問いは観測可能か、ラベルは定義できるか、データで測定可能か、評価指標は適切か、運用・実装できるかを重視します。つまり「それをデータでどう解くか」を詰める役割です。
リサーチよりの視点はコンサルとデータサイエンスのどちらの視点も重要となります。
何故ならデータの生成過程の設計から意思決定に繋げる役割の双方を担うためです。
（視点としてはコンサル＋データベーススペシャリスト＋データサイエンスのイメージ、あくまでイメージですが）
そのため実務では、どちらか片方だけでは足りません。前者だけなら施策なき分析になるし、後者だけなら実装不能な理想論になる。両方揃わないと、価値のある分析にはならないのです。
実務における分析をする前に整理しておくべきポイント
ここまで読んで「結局どのように目的を定義すればよいのか」と感じた方のために、実務でそのまま使える型を整理しました。
1. 背景
いま何が起きているか。どの指標に、どんな異常や課題があるのか。
2. 事業目的
何を改善したいのか。売上、利益、継続率、満足度、生産性など。
3. 意思決定者
誰がこの結果を使い、何を決めるのか。
4. 意思決定論点
どの選択肢を比較したいのか。例えば、A施策を継続するか、B施策へ寄せるか。
5. 分析目的
意思決定に必要な情報差分は何か。例えば、高解約群の特徴、チャネル別効率差、受注率に効く条件。
6. 成功指標
分析成功指標と事業成功指標を分けて書く。
7. データ要件
必要テーブル、粒度、期間、比較軸、欠損有無。
8. 制約条件
納期、予算、データの取得可否（代理変数・共変量・媒介変数は考えられるか）、法規制、運用負荷。
9. 想定アウトプット
どんな図表や一覧が出れば判断できるか。
10. 想定アクション
結果Aなら何をするか。結果Bなら何をするか。
このテンプレートの良いところは、分析を「知的作業」で終わらせず、実行可能な業務設計までつなげられることです。
理想はプロジェクトが始まるまでの段階で上記を詰めて置くことです。
それがプロジェクト全体の精緻化、調査の目的を達成するためのCLへの提案、プロジェクトの目的と実際に進めていく中での乖離を最小限に繋がります。
分析の成否は、データを見る前に決まっている
分析というと、ダッシュボードや統計手法、機械学習モデルを思い浮かべる人が多いです。でも現場で本当に差が出るのは、もっと手前です。
何を変えるために、何を明らかにするのか。
ここが曖昧なまま始めた分析は、途中で必ず迷います。
逆に目的が明確な分析は、使う手法が比較的シンプルでも目的に直結するからです。
派手な分析ほど評価されるわけではありません。むしろ現場で価値が高いのは、必要十分な問いを立て、必要十分なデータで、必要十分な判断を支える分析であり、説得力がある分析です。
最後に
①分析の目的とは、知りたいことではなく、変えたい意思決定を定義すること。
②そして事業課題→意思決定→分析課題→指標→実行アクションの順で設計するとブレにくい。
③分析の成否は手法選定より前、最初の目的設定でほぼ決まる。
この三点が、分析を成果につなげるために本当に大事なことだと考えております。。
出典
- CRISP-DM Guide — SPSS Modeler CRISP-DM Guide
- McKinsey：七段階問題解決プロセスをマスターする方法 — How to master the seven-step problem-solving process
- AWS ML Lens：ML問題フレーミング — ML problem framing
- Microsoft Learn：データサイエンスプロセスへの導入 — Introduction to the Data Science Process
- Microsoft Learn：データサイエンスライフサイクルとは？ — What is the Data Science Lifecycle?
- McKinsey：なぜピープルアナリティクスを活用すべきか — Why you should apply analytics to your people strategy
- NIST SP 800-55：情報セキュリティ測定ガイド — Measurement Guide for Information Security
- IBM：データの理解と準備 — Understanding and preparing data