分析の仕方シリーズ3本目の記事です。
さて、以下のような分析の悩みに心当たりはないでしょうか？
「いざ分析をしようという時にどこから手をつけたらいいか分からない」「いきなり手が止まる」「いきあたりばったりで作業時間が読めない」「分析したけど良い結果が出なくて途方に暮れる」「個々の集計アウトプットはできたけど何が言えるか分からない」
今回もデータ分析経験の浅い方、これからデータサイエンスを使って仕事をはじめようという方向けに、「分析設計の重要性」と「具体的にどのように設計をしていくのか」をまとめていこうと思います。
分析設計前に留意しておきたい「顧客の課題を明確化する」については前回の記事
「データ分析の仕方②課題を分析に落とし込むコンサルティングスキル」をどうぞ。
目次
分析設計の重要性について
分析レポーティング全体の工程のうち、この「分析設計」は非常に重要なポイントで、私自身も実際にデータ分析案件にデータアナリスト・データサイエンティストをアサインする際にはこの部分のスキルを判断基準のベースにしています。
分析設計ができるということは、「ビジネス課題に対して分析を使って解決の筋道を立てられる」ということに他なりません。
・解決すべき課題に対して改善につながる仮説を立てられる
・仮説を検証するための分析フローを整理できる
・分析フローから具体的に集計条件まで落とし込める
これらのスキルがないと分析を計画的に進めることは難しく、その結果アウトプット品質の低下やスケジュール遅延を招きかねません。
ではどうやって分析設計を進めていけば良いでしょうか？手順をまとめてみます。
分析設計の手順について
背景・課題を明示する
改善したい課題だけでなく、課題となっている背景についてもできる限り明確にしておきます。後々分析を進めていく中でも、解くべき問題の軸をブラさないために重要です。
分析テーマを言語化する
分析の概要を簡潔に言語化します。「課題」と同様、分析の軸を1本通しておくイメージです。
目的を明示する
何のための分析かを明確にしておきます。知ることが目的ではなく、アクションにつなげられる分析かどうか、「何が分かるとうれしい？」を意識し「アナリストの目的ではなく顧客の目的となっているか」に要注意です。
そこを無視して「自分の分析結果」をまとめてしまうのがよくある残念な例。顧客が既に把握している情報だったり、過去分析とほぼ同じ結果を平気で「示唆出ました！」とまとめてしまうのは避けたいところです。
仮説を立てる
仮説を立てるにはビジネス理解が必要不可欠です。あるサービスの分析をするのであれば、1ユーザーとしての感じてる気持ちや違和感から着想して、解決したい課題に対する仮説を立てることもあります。
経験上そういった自分発の仮説を検証すると仮説通りであっても棄却されてもビジネス価値の高い知見となることが多いように思います。
また利用者の声から仮説を立てて検証していくこともあります。いずれにしてもやはりビジネス理解・サービス理解なしには仮説は立てられません。
仮説はただ立てればいいわけではなく、「立証できればビジネスインパクトが大きいもの」「施策の実行が可能なもの」に着目することが重要です。
分析ストーリーを組み立てる
仮説の検証も含め、「どんな分析をすることでどのような結果を導き出すか」「それぞれの分析結果をどう論理的につなぎ合わせてレポートのストーリーを構成するか」を考えます。
仮説がどっちに転んでもストーリーになるように前後のつなぎ込みが重要です。例えば、「仮説通りじゃなかった場合はこっちの軸で分析しよう」といった想定もストーリーとして組み込んでおくことです。
集計条件を決める
次に具体的にどんな集計や分析をしていくか、分析項目と集計定義を書き出します。ここを曖昧にしたまま集計着手すると無駄に時間がかかったり目的がぶれてしまうので、「手を動かす前に詳細集計レベルで設計をする」ことが重要です。
仮想のテーマで分析設計をしてみる
ここでごくシンプルな仮想のシチュエーションを設定し、分析設計への落とし込みをどんな考え方で進めていくのか、一例として考えてみます。
想定事業
EC通販サービスの分析を想定してみます。
背景・課題
「コロナ禍の巣篭もり需要でEC事業部の売上は堅調に伸びているが、初回購入者のリピートが伸びていない。これまでの社内分析知見からF2転換すれば顧客の定着、LTVの増加が加速することがわかっている。新規購入者のリピートを増やしたい。」
分析テーマ
「新規購入者のリピート購入（F2転換）につながる要因分析」
目的
新規購入者のリピート率を上げるにはどんなサービス改善や施策をしたらよいか？次の打ち手を意思決定できるインサイトを得る。
仮説
仮説を考えるためにまず、「リピート購入をしたくなる気持ち」を考えていくつか書き出してみます。
(1)安く買えた
(2)商品のクオリティが良かった
(3)早く届いた
(4)対応が丁寧だった
(5)好みの商品のお知らせが届いた（セールや在庫少ない等）
(6)初回購入時点で値引きポイントが残っている状態だった
ここで「改善施策の工数」と「改善インパクト」から優先順位を考えます。
要するに、「より簡単にアクションができて効果が高そうなものはどれか？」を考えます。
今回は例えば、(5)から「DMがリピートに効果的である」（仮説Aとする）について分析を優先するとしましょう。
どの仮説を検証するかは当然根拠を持って決めるべきです。この例では「ユーザーへの様々なアプローチのバリエーションが考えられるため、分析結果からアクションに起こしやすい」「アクション結果が直接的に何かしらの影響を生みやすい」という点で優先度が高いと考えてみます。
次にこの着眼点でさらに具体的な仮説を考えてみましょう。
(A-1)DMの内容で効果が異なるのではないか？
→より効果の高いカテゴリや文章表現に傾向がある？
(A-2)DMが届くタイミングにより効果が異なるのではないか？
→初回購入をした直後のDM？N時間後がベストといったしきい値がある？
(A-3)DMを送った回数で効果が異なるのではないか？
→送り過ぎるとマイナス効果など、最適な回数が存在する？
※どれもインサイトを得られれば、具体的な施策に活かしやすい（POINT)
分析ストーリー
これらの仮説を元に分析ストーリーを組み立てていきます。
①リピート（F2転換）と相関の強い変数を俯瞰的に調査
まずは仮説で着目している以外の変数も含めて、目的変数であるリピートに影響のある変数を俯瞰的に探っていきます。
その中で、「DMの受信や開封などの変数とリピートに相関がある」という最初の仮説Aの検証も行いますが、この結果によって分析方針は分岐します。
「DMの受信や開封などの変数とリピートに相関がある？」に対し「NO」だった場合、別軸で検証する必要があります。
最初の仮説(A)「DMがリピートに効果的である」を棄却して、例えば(6)「初回購入時点で値引きポイントが残っている状態だった」というリピートしたい気持ち（想像）から、「次回購入に有効な値引き条件の発生がリピートに効果的である」（仮説Bとする）を検証していく。など。
このように検証する仮説の軌道修正が発生する可能性を考えておき、当初仮説Aが見当外れだった場合の仮説B、Cを集計着手前の分析設計時に考慮しておけると、分析の品質としてもタスクスケジュールの点でも、より理想的な仕事の進め方ができます。
一方、「DMの受信や開封などの変数とリピートに相関がある？」に対し「YES」であれば、以下②に続きます。
②想定した仮説の深堀り調査（さらなる仮説の検証）
(A-1)DMの内容で効果が異なるのではないか？
(A-2)DMが届くタイミングにより効果が異なるのではないか？
(A-3)DMを送った回数で効果が異なるのではないか？
仮説(A)が正しい前提なので、上記の分析結果何かしらの示唆が得られる可能性は高いと思いますが、仮に何も取れ高がなかったとします。そんな場合でも分析の軸を再検討することになります。
例えば、仮説(A)「DMがリピートに効果的である」が正しいと言っても、人によって「効果的である人」と、「効果的でない人」に分かれるのではないか？（仮説Cとする）
これを元に「ユーザー属性や初回購入前後の行動の違いからユーザーをセグメンテーションしてDMとリピート（F2転換）との相関を改めて確認してみるなど。
この仮説(C)も分析設計時に想定しておければベターですが、現実的には事前に想定できないことも多いです。「集計や分析をしてみて示唆が出ない」ということは誰もが経験するアナリスト泣かせな状況ですね。
ただ、今回お話している分析設計をしっかり考え込んでおくことで、そんな状況に陥る可能性を減らせるし、いざそうなった時に（上記の仮説(C)のように）臨機応変に新たな軸を考えつく訓練にもなるので、この分析設計をしっかり考え込んでおく経験自体が分析力を養っていく大きな要素と言えます。
さて、上記のような分析ストーリー（分析進行の概要のつなぎ合わせ）を作ったらある程度完成しているようにも思えますが、「分析設計」としてはもう１歩ディテールに踏み込んでおきましょう。
集計条件
上記(A-1)～(A-3)が具体的な検証内容となってきますが、「どのような集計や統計解析をしたらその検証ができるのか？」実際に着手できるレベルの粒度で集計条件などを設定します。
例えば、以下を検証する場合。
(A-1)DMの内容で効果が異なるのではないか？
「集計条件としてはどの期間？」「対象とするユーザー層は？」「各種DMのタイプの効果を正しく比較するために必要な条件設定は？」など、SQLクエリを書くために必要な条件を記しておきましょう。
（これら比較検証には基本的にセレクションバイアスを含まないような集計条件設定のテクニックや統計処理が超重要ですがそれはまた別の機会に）
このように「集計条件のディテールを記載」する目的としては、「分析方針をぶれさせない」「分析の質を高める」「集計速度上昇」があげられます。
手を動かす前に細かな集計を考えていくことで、実現可能な集計が見極められたり、より良い比較条件が整うことが多いです。何より、細部を設計せずにSQLを書き始めると、手戻りが発生してSQLを書くスピードが格段に遅くなります。
そしてコーディングであれでもないこれでもないと修正作業をしていると「当初の分析設計からぶれはじめる…」というのが最悪のケースです。
わざわざ集計条件を言語化するのは面倒な作業に思えるかもしれませんがトータルで時間短縮につながります。
また、レポーティングの際に詳細集計条件を明記しておく際や、同条件で分析結果を再現したい場合にも必要な情報となるので、そういった後工程にとっても必須な作業工程と言えます。
まとめ
長くなりましたが、「分析設計の考え方」についていかがでしたでしょうか？経験の浅いアナリストはここで手が止まってしまうことが本当に多く、私自身もどうこの部分のスキルアップをフォローしていけるか日々検討しているところです。
「ビジネス課題に対して分析を使って解決の筋道を立てられる」
文字にすると簡単に書けちゃいますが、かなり幅広いスキル、特に情報整理能力を要求されます。
分析手法の各論やコーディングスキルと違って、このようなソフトスキル（ビジネススキル）は簡単には伸ばすのが難しい部分なのですが、その重要性と考え方のとっかかりとして参考になれば幸いです。
本記事は「データ分析の仕方」シリーズの第3回目となります。
シリーズの全体感、概要は「データ分析の仕方①分析レポートの書き方までの実務上のポイント」もご覧ください。
