$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

データ分析の基本の因果推論を学ぶため、「原因と結果の経済学」を読んだ

データ分析をやっていると、ある施策の効果検証をすることが多い。効果検証では、ある施策Aが仮説通りにある指標Bを変化させられたのかを検証したい。これはつまり「ある施策Aの実施」と「ある指標B」が因果関係にあるかを推論したいと言い換えられる。

このことからデータ分析をするには、因果推論の技術の習得が基本であると考え、「原因と結果」の経済学という本を読んだ。

この本は評価が非常に高かったのだけれど、その評価に違わず因果推論の技術の入門に最適だった。明示的にデータ分析担当にならなくてもエンジニアはデータを見る機会が多いので、その解釈を間違えないように読んでおくと良いと感じた。

たとえば印象に残った部分だと以下の話があった。

  • 因果関係の存在を証明するためには、原因が起こったという「事実」における結果と、原因が起こらなかったという「反事実」における結果の二つの結果を比較する必要がある
    • しかし反事実の確認はタイムマシンがなければできないため、もっともらしい値で穴埋めする方法を考えなければならない
    • もっともらしい値を出すためには、因果推論したい「原因」以外の条件が揃ったもう一つの比較可能なグループを作る必要がある
    • すべての因果推論の技術は、この比較可能なグループを作ることを目的としている
  • 因果関係を確認するためには、3つのチェックポイントを確認する必要がある
    • 全くの偶然ではないか、交絡因子が存在しないか、逆の因果関係ではないか
  • ある実験をした前後での比較は因果関係を明らかにすることはできない
    • 時間とともに起こる自然な変化 = トレンドの影響を考慮できない
    • 平均への回帰(= 極端な値をとったあとは徐々にいつもの水準に近づいていく)に対処できない

このあたりの話をベースとして、比較可能なグループを作りだす因果推論の手法について1つずつ解説してくれる構成になっているため理解しやすかった。たとえば手法としてランダム化比較試験、差の差分析、マッチング法などを教えてくれる。

このように非常に短いページ数で、因果推論の基本を教えてくれるのでおすすめだ。データ分析担当になった人はもちろん、エンジニアやPMなどもさっと目を通すと参考になりそうだ。

読書ノート

- 因果関係を確認する3つのチェックポイント 29
    - まったくの偶然ではないか
        - 例: 地球の温暖化が進むと海賊の数が減る
    - 第3の変数(=交絡因子)は存在していないか
    - 逆の因果関係は存在していないか
- 因果関係の存在を証明するためには、以下二つの結果を比較する必要がある 41
    - 原因が起こったという「事実」における結果
    - 原因が起こらなかったという「反事実」における結果
        - 反事実 = 仮に〜しなかったらどうなっていたか
    - 反事実はタイムマシンがないと確認できないため、もっともらしい値で穴埋めする方法を考えなければならない
- 穴埋めをするには、比較可能なグループを見つける必要がある 50
    - 例: 売り上げに影響しそうなすべての特徴が似通っていて、2つのグループの唯一の違いは「広告を出したかどうか」だけなら、比較可能
- 因果関係を明らかにするための方法は、全て「比較可能なグループを作り出し、反事実をもっともらしい値で置き換える」ことをしている 53 ⭐️
- 因果関係を証明する方法: ランダム化比較試験 80
    - 対象となる人々を、乱数表などで介入群(事実)と対照群(反事実)にランダムに割り付ける
- 因果関係を証明する方法: 自然実験 96
    - 対象となる人々が、制度の変更、自然災害などの「外生的なショック」によって、介入群と対照群に自然に分かれてしまったという状況を利用する
    - 観察データから「あたかも人為的な実験が行われたかのような」状況を見出す
- ある実験をした前後での比較は因果関係を明らかにすることはできない 106
    - 時間とともに起こる自然な変化 = トレンドの影響を考慮できない
    - 平均への回帰(= 極端な値をとったあとは徐々にいつもの水準に近づいていく)に対処できない
- 因果関係を証明する方法: 差の差分析 102
    - 介入群と対照群において、介入前後の結果の差の、さらに差を見て因果効果を判定する方法。ただし元々のトレンドが同じ、介入のタイミングで別の変化が起きていないという2つの前提条件あり
    - 使える前提条件
        - イベントの前のトレンドが平行である 114
        - 指標に影響を与える「別の変化」が起きていない 117
            - 例: Aにだけ指標に影響を与えるドラマが放映されていた
- 因果関係を証明する方法: 操作変数法 138
    - 「原因に影響を与えることを通じてしか結果に影響を与えない」という操作変数を用いて、介入群と対照群を比較可能にする。前提条件は2つで、操作変数が原因には影響を与えるが結果には直接影響しない、操作変数と結果の両方に影響する第4の変数が存在しないこと
- 因果関係を証明する方法: 回帰不連続デザイン 155
    - 恣意的に決定されたカットオフ値の両サイドで、介入群と対照群が分かれる状況を利用する。前提条件は、カットオフ値の周辺で結果に影響を与える他のイベントが起きていないこと
    - 例: 従業員が50人を超えた店舗でだけ広告を出せるケース
- 因果関係を証明する方法: マッチング法 175
    - 結果に影響を与えるような共変量を用いて、対照群の中から、介入群によく似たサンプルをマッチさせて比較する。複数の共変量があるなら、それらをまとめたスコア(=プロペンシティ・スコア・マッチング)を使うこともある。マッチングが成り立つ条件は、結果に影響を与えるような共変量が全て観察可能であること
- 因果関係を証明する方法: 回帰分析 182
    - 原因と結果に最適な線を引くことで、因果効果を推定する。ただし交絡因子が存在していないことが条件
    - 交絡因子が似ている人の中で、回帰分析を行うと影響を取り除ける = 重回帰分析
        - 飲酒と肺がんの因果関係を見つけたい -> 喫煙量が同じ人の中で飲酒量が多い人と少ない人を比較し、肺がんのリスクが異なるかどうかを調べる
        - ただし中間変数を取り除くと本来の影響を過小評価してしまうので注意 191
- 因果推論のステップ 196 ⭐️
    - 1. 原因と結果を明確に定義する
        - 原因として広告をとっても、広告料なのか、掲載面積なのか、もしくは単に出したかどうかなのか
        - 結果として売上でも、売上高なのか営業利益なのか
    - 2. 3つのチェックポイントの確認
        - 全くの偶然ではないか、交絡因子が存在しないか、逆の因果関係ではないか
    - 3. もっともらしい値を使い、反事実を作り出す
        - 広告を出した時と比較するため、広告を出さなかった時という反事実を、もっともらしい値を使って作りだす
        - 手法は書籍で紹介されたもの

「DMM.comを支えるデータ駆動戦略」読んだ

データ分析を学びたいシリーズとして読んだ。

この本はプロダクト作りにおけるKPI分解から施策決定、施策振り返りから次の施策へ活かすなどのリーンおよびアジャイルな開発の一連の流れをデータ中心に教えてくれる。ちょうど正しいものを正しくつくるをもうちょっとデータ寄りにした本のイメージ。

個人的にはKPI分解をどのようにやっていくかの流れや、仮説検証の流れが具体的に示されていたことが非常に参考になった。

データ分析学びたいシリーズ

読書ノート

- 「データ駆動」な戦略を立案して実現するのに、一番大事なのは強固な組織体制 7
- データ駆動戦略を用いたプロダクト開発の進め方の全体像 17 ⭐️
    - 1. 事業を数値モデルとして理解する
    - 2. 事業構造をKPIで表現し、予測可能性を作る
    - 3. KPIから見えた課題に対して施策を当てていく
    - 4. 仮説検証サイクルによって学習が生まれる
    - 5. 仮説検証サイクルを高速に合理的に回す
    - 大きく、事業をどうつくるかを捉える部分と、何をどのように作るかの部分 33
- KGI/CSF/KPIによって事業構造を数値モデル化する 23
- 施策を実施するときは、その施策が直接的にターゲットとするKPIだけではなくて、他のKPIをみるべきである。そのために事業構造を数値モデルとして表しておくと良い 31 ⭐️
    - 流入を増やす施策をしたら、思った以上に継続率が下がってた的な
- 操作可能変数 68
- ユーザー単位のユニットエコノミクスによって事業の健全さを把握する 70
    - LTV > CAC(顧客獲得コスト)なら黒字
    - ユニットエコノミクス = LTV / CAC > 3 && コストに対する利益が出るまでの「回収期間が6~12ヶ月」であれば健全な事業であるという指標
    - LTV = ARPA / Churn Rate
        - ARPA = 売上 / アカウント数
        - Churn Rate = 退会数 / アカウント数
    - CAC = 新規獲得コスト / 新規獲得数
    - 改修期間=Playback Period = CAC / ARPA
- 施策実施時に、施策による定量的な効果の予測をしておくことで、リリース後の実測値との差分を測り、そこから学習をできる 74
- どこまで事前に計画すべきかをDMMでは以下にしている ⭐️
    - 問いたい仮説は何か
    - 改善したいKPIは何か
    - そこから何を学習したいか
    - 失敗がコントロールできているか(施策失敗の時の売上などの影響。A/Bテスト20%にしておくと失敗時のコントロールがしやすいなど)
- A/Bテストをする前に必ず行うべきことは既存2パターンを用意して正しいデータを取れていることを確認する、AAテスト 109
- MVPによる実験手法 111
    - 気づき: 基本は開発コストを最小化して必要なものを作る手段
    - カスタマーリサーチ型(顧客調査)
        - ワイヤーフレームやスケッチなどを用意してユーザーに見せニーズを探る
        - メリット: アイディアをすぐに試せる、目に見える形で共有理解が生まれる
        - デメリット: 情報の幅が限定的になるため複雑な仮説の検証は難しい
    - スモークテスト型(プレオーダー、サービス紹介ビデオ)
        - カスタマーリサーチより広く市場に問いかけられる、事前登録でリアルなユーザーのニーズが把握可能、収益の目処が立ちやすい
    - オズの魔法使い型(一部手作業)
        - ユーザーから見ると実際のプロダクトと変わりがなく、解像度が高い状態で仮説検証可能
        - このまま事業拡大は難しいので適用範囲は限定的
    - コンシェルジュ型(全手作業)
        - オズの魔法使い型のさらに手作業版
        - 作業の多さによってはサンプル数が不足する可能性がある
    - プロトタイプ型(動くソフトウェア)
- 仮説に必要な情報は、学習結果・仮説・施策・実施・計測の5ポイント 153
- 仮説検証のステップはBMLループの逆回しにする 154
    - 計画ループ
        - (1) 仮説を考える。どんな確証を得たいか、なぜ知りたいかをしっかり定める
        - (2) 必要なデータの形は何か、どう計測するかを考える
        - (3) どう作るか考える。仮説が検証できる機能をどう作るか、検証方法はどうするか
    - 実行ループ
        - (1) MVPを実装する
        - (2) 計測してデータを作る。検証結果がわかるデータを可視化する
        - (3) 結果から学習して次の仮説を考える
- バリューストリームマップは最初は一人で始める 185
    - 関係者を集めて作るのが一番良いが、全員を数時間拘束は大変なため
    - 可視化して伝えるだけでも効果的
- データアナリストと事業改善プロセス 334 ⭐️
    - データアナリストとして貢献できるポイント
        - 現状分析:事業モデルの定義。KPIモデルの分解および目標値の設定と現状の差分
        - 課題分析:その数値が上がらない課題の掘り下げ。ファネルの中のボトルネック分析など
        - 施策提案:データ分析から施策提案
            - エビデンス付きで施策の提案をする
        - 効果検証:施策の結果がどうなったか
            - 施策の結果の定量的な改善結果を示す。失敗した場合も改善の知見を得られるようにする
- サイロ化を防ぐレポートテンプレ 340
    - サマリ、重要KPI状況、トピック=施策の目的進捗結果、中長期のOKR、今後のマイルストーン、所感
- ダッシュボードを作る 358 ⭐️
    - KPIダッシュボード:KPIツリーをもとに作った、全施策のベースとなるダッシュボード
    - 施策ダッシュボードに記載したい
        - 仮説は何か
        - 改善指標は何か
            - 気づき:ベースとなるKPIのどこに注力していて、中間指標はどれで、どこに悪影響を与えうるかみたいなのを可視化すると良さそう
        - そこから学習したいことは何か

「達人に学ぶSQL徹底指南書」読んだ

最近データ分析をしていて複雑なSQLを書き始めた結果、SQLの概念が理解できてなくて上手くクエリを書けないことに気づいた。そこで概念を理解するために「達人に学ぶSQL徹底指南書」を読んだ。

今まさに欲しい情報が詰め込まれていて良かった。本を読む前はCASE式やウィンドウ関数の概念、SQLの前提となる集合論の考え方、NULLが条件に含まれた時にどのような動きをするかを理解できていなかった。しかしこの本にはその辺りが全て含まれていたため概念を理解でき、その結果SQLを書くスピードが上がった。 それ以外にもいろんな集計をする事例も書かれていたため、SQLのチートシートとしても使えそう。

特に10章までの情報は非常に参考になった。SQLをちゃんと理解したい人はそこまで読むと良さそう。