Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

$shibayu36->blog;

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

データ分析設計を知るために「本物のデータ分析力が身につく本」を読んだ

最近仕事では機能開発ではなくデータ分析の仕事をしばらくやっているのだが、同僚から「本物のデータ分析力が身に付く本」というムックが良かったと聞いたので読んでみた。

この本は「データを集計し計算する」といった、いわゆる一般的にはデータ分析のメインと考えられていていろんな書籍で語られているような部分には焦点を当てず、その前後で何をすべきかを語ってくれている。たとえば

  • データ分析実行の前には、開発設計で書くようなdesign docのようなものをデータ分析設計としてまとめる。さらに生データを見てデータの信頼性や傾向を事前チェックし、設計と事前チェック結果を見て分析方法を選択する
  • データ分析実行の後には、結果の確からしさの検証をしつつ、バイアスを避けた結果の解釈を行う。その後、データを他の人に使ってもらえるように、数字の実質的な意味合いを相手の判断に刺さる視点で伝える必要がある

自分もいきなりデータを見るのではなくてちゃんと仮説を立ててから調査すべきという心構え自体は持っていたが、この本を読んでデータ分析実行の前にここまで時間をかけて事前に設計と事前チェックをするのかと勉強になった。

ちなみにこの本を参考にして仕事中に調査したいことのデータ分析設計書を作っていたが、確かに設計書は良い。何が良いかというと

  • 調査していると、さらにどんどん深掘りしたいという気持ちになる。その時に設計書に立ち返って、その深掘りを本当にすべきかを再確認できる
  • その調査がPMの悩み事にマッチしているかを先にすり合わせることができる
  • 調査自体の方向性が合っているか、他のデータ分析エンジニアにレビューしてもらえる

まさにdesign docと同じようなメリットが得られている。この調子で分析をやっていきたい。

こんな感じでデータ分析をするエンジニアはぜひ読んでおきたい一冊だと思った。演習もついていて知識も深めやすいので是非。

読書ノート

## プロローグ
- どんな計算をしたかの技術論を聞かされても意思決定者は苦痛。本当に共有すべきはデータ分析の一連のストーリー 7
    - 1. 何のために、何を知ろうとしたか
    - 2. そのためにどんな仮定を置き、どの範囲を考えに入れたか
    - 3. どんなデータを使って、どんな意味合いの数字を出したか
- データ分析の心構え 9
- 必ず課題アプローチをする 10
    - 「課題」を決める
    - 課題を解決するための「問い」を決める
    - 問いに答えるための「データと分析方法」を決める
- データ分析の正しさは「プロセス」で評価 11
    - ![[Pasted image 20240328115652.png]]
    - すぐに平均値を出す、集計表を作るといった「計算」を始めてはならない
    - 計算の前にやること 11
        - 1つ目: 前述の一連のストーリーを設計する
            - 1. 何のために、何を知ろうとしたか
            - 2. そのためにどんな仮定を置き、どの範囲を考えに入れたか
            - 3. どんなデータを使って、どんな意味合いの数字を出したか
        - 2つ目: データの信頼性と傾向をチェック
        - 3つ目: すでに明らかにした「知りたいこと」と「データの傾向」とを照らし合わせて適切な分析方法を選ぶ
    - 計算の後にやること 12
        - 分析の結果を正しく評価し解釈する
            - 計算結果誤差、AとBは本当に差があるのか、認知バイアスの思い込みに囚われていないか
        - 分析の結果を正しく使ってもらえるように表現する
            - 要するに何が言えるのか、だから何をすべきなのかを、ビジネスの文脈に落とし込んで端的に語れなければならない

## データ分析を設計する
- 分析の概念図 20
    - ![[Pasted image 20240328144334.png]]
    - 問題領域 = 課題解決のための問い
    - 評価軸 = 何を良い施策とするかの判断軸
    - 要因 = それぞれの評価軸に左右するもの 
    - ![[Pasted image 20240328144522.png]]
    - 利点:重大な見落としを防ぐ、無駄なデータ収集を防ぐ、作業の途中で迷子になるのを防ぐ、結果を相手に納得してもらい使ってもらえる、データアプローチになるのを防ぐ
- 概念図を書くステップ 23
    - ![[Pasted image 20240328144752.png]]
- 問題領域の決定では、 26
    - 1. 問題領域を出す。もっと広い可能性ともっと狭い可能性を書き出し、その中でどの問いが最適か見比べる 26
    - 2. 問題領域を選ぶ。この問題領域を選んだ理由を説明できるようにし、関係者と合意をとる
- 評価軸決定のプロセス 30
    - 1. 評価軸を挙げる
        - コツは
        - ボトムアップ式:問題領域に関わりそうな言葉をたくさん出してグルーピングしてみる
        - 芋蔓式:1つの評価軸から、その評価軸が良ければどんなものでもいいか?と問う。「安くて機能が足りていれば、どんな機種でもいいのか?」
    - 2. 評価軸を選ぶ
        - 一般には2~4個程度の方が良い
        - 選んだ時に関係者と議論して合意すべき
- 問題の具体的記述のプロセス 33
    - 主語、問題領域、評価軸をつなげて、1つの文で表す
    - 言語化することでブレない分析が可能
    - 分析の方向を修正するラストチャンス
- 要因の列挙のプロセス 34
    - 評価軸に対してブレストを行う
- 要因の選択プロセス 38
    - 1. 重要度で仕分けする
        - 重要度の3視点
            - 問題や評価軸を大きく左右する
            - その業界の常識として、考慮しないと説得力がなくなる
            - 上のいずれかの視点で、重要と判断した理由を関係者に説明できる
        - ![[Pasted image 20240328160848.png]]
        - 必要あれば判断理由の補足も書く
        - 注意点
            - 重要度と入手しやすさは別で考える
            - 重要度の仕分けは、すべての評価軸の全ての要因を同じ1枚の紙の上で行う
                - 判断基準のブレをなくす
            - 重要度中に集中したら、さらに仕分けする
    - 2. データの入手しやすさで仕分けする
        - 入手しやすさ判断の2視点
            - 入手方法が想像できる
            - 入手できなくても、類似のデータなどから推測できそうと考えられる
        - アンケートなどで自分で調査できると考えられるなら入手可能で良い
    - 3. 分析する要因を決定する
        - 右上を分析する
        - ![[Pasted image 20240328161813.png]]
        - 右下で不可欠な例:ウイルス耐性
- 部品の配置・連結プロセス
    - 1. 問題領域と評価軸を書く
    - 2. 評価軸に要因をつなげる
        - ![[Pasted image 20240328162109.png]]
    - 3. 要因をグルーピングする
        - ![[Pasted image 20240328162140.png]]
    - 4. 要因同士の関係を推測してつなげる
        - ![[Pasted image 20240328162205.png]]
    - 5. 分析の流れを説明できるか確認する
        - 一連のストーリー3ステップを、概念図も使いながら報告できるかを確認する
        - ![[Pasted image 20240328162716.png]]


## データを事前にチェックする
- ヒストグラムを書かずに集計すると、データに外れ値があることにすら気づけない 53
    - データを「可視化」した方が平均値などを「集計」するよりもデータの実態がよく分かる
- データの事前チェックの必要性 53
    - 怪しいデータを使って分析をしないように
    - データの傾向を知り、どの分析方法が適切かを決定する
- データを事前にチェックする4つのポイント 54
- データの出所チェック 55
    - 5W1Hチェック: 誰が、いつ、どこで、何を、なんのために、どのようにして作ったデータなのか?を確認することで、信頼度・偏りのなさ・正確性をチェックする
    - 一次情報を使う
- データ全体概要のチェック。データ全体を、馴染み深く感じるまで視る 57
    - 1. データのサイズ確認
    - 2. データがどのように並んでいるか
    - 3. それぞれのデータの意味合いを理解する
    - 4. 値の大体の規模(桁)と、単位を確認する
    - 5. 欠損値、外れ値の「有無・多少」を見る
    - 6. その他、目立つ特徴を頭に叩き込む
    - 注意: データのサイズ確認、データの並び、データの意味合いは、生データを自分で確認しながら調査する 57
        - 何列・何行か、どのようなデータの塊があるか、各列の見出しと意味を解釈、各列ごとの気づき、一見して欠損値や外れ値が目立つか
- 個別の値のチェックを行うときは、欠損値、外れ値、データの方向の3つをチェックする
- 欠損値の特定の便利手法 62
    - 欠損値の中身がNULLだけでない場合や、空白が入っている場合などにも対応できる
- 外れ値特定の3ステップ 65
    - 有無:ヒストグラムや散布図などでデータを可視化し、外れ値の有無を判断
        - ヒストグラム:1変数の分布の形がわかる。2変数以上には不便
        - 散布図:2変数の関係がわかる。分布の形はわかりにくい
    - 値:最大値・最小値を算出して、外れ値の値を知る
    - 場所:データが大きい場合、フィルタ機能を使って最大値や最小値に等しいデータが「どこにあるか」を特定する
        - 外れ値のサインをつけておくと、たとえ取り除かなかったとしても取り除かなかった理由が説明できる
- データの方向をチェックする 70
    - 実はサービス評価が1の方が「良い」だったみたいな
- クレンジングのステップ 71
    - 欠損値の除外
        - 他の値で埋める時は、なぜ埋めた、どのように埋めたのかのメモを残す。これがないとデータの恣意的な改竄を疑われる
    - 外れ値の除外
        - 外れ値自体には学びが多いと心構える
    - データの方向の逆転
        - 直感と数字の大小が異なる場合に、データ方向を逆転する
    - 注意
        - 欠損値や外れ値だからといって無条件に除いて良いとは限らない。新しい発見が潜んでいることもある
        - クレンジング後にも最初に戻れるように生データを必ず残す
- クレンジング後にデータの傾向をチェックする 76
    - 1. データを再び可視化
    - 2. 値がどの辺に分布しているかをチェック
    - 3. どんな形に分布しているかをチェック

## 分析方法を選ぶ
- 代表値 = 平均値、中央値、最頻値
    - 平均値が有効な4条件 83
    - 中央値が有効な条件 85
    - 最頻値が有効な条件  87
    - 3つの代表値のメリットデメリット 87
    - 万能な代表値はなく、どんなに適切な代表値を選んでも生データに比べれば多くの情報が失われることに注意 88
- クロス集計
    - 効果 91
    - 注意点 95
        - 先入観を捨てるため、あらかじめ想定した要因だけ分析して終わらず、多くの組み合わせを試す。色々な組み合わせでクロス集計表や散布図を作る
        - 密接に関連する項目は全て出す
            - 例) 正規雇用数と非正規率だけ出すのはだめ。同時に雇用合計数を出すと別の観点が見えてくる
        - データ数や構成比も一緒に出す
            - データ数や構成比のクロス集計表を用いないと、そのクロス集計が妥当かの判断ができない

## 標準偏差
- 標準偏差の使い道 120
    - 多様性や格差を定量化する、比較する
        - サービスレベルを均質化する施策の導入前後で、効果を比較可能になる
    - 不確実性を定量化する、比較する
        - 為替レートの変動の激しさを定量化し、今後も同じ変動幅と仮定したときの不確実性を算出可能
    - リスクを定量化する、比較する
        - 投資のリスクの可視化など
    - 平均値の信頼性の判断と比較
    - 品質を管理する
- +-3標準偏差の場合0.27%となるので、これを使うと外れ値認定できる 131

## グループ間の差の確からしさを検証する
- 平均値の代償関係の確からしさは、以下の三つで決まる 149
    - 平均値の差が大きいほど信頼できる
    - ばらつきが小さいほど信頼できる
    - データ数が多いほど信頼できる
    - 他人の分析結果を聞いた時は、この三つを必ず確認すること
- 検証ツールのp値=全体では差が無い確率(危険率)を何%まで許容するかは状況による 153
    - 店の陳列棚をちょっと変えるだけなら30%くらいの失敗は許容できるかもしれないが、人命がかかる話なら0.01%の失敗も許容できないかもしれない
- 差の検証を行うときは、比較集団が対応ありか対応なしかに注意すること 155

## 分析結果の受け止め方と伝え方
### 分析結果の解釈の思い込みを避ける
- 分析をするときは、認知バイアスや印象操作に注意して解釈の誤りを防ぐ必要がある 161
- データ分析中は、思いついた仮説にいつの間にか囚われて信じてしまう、仮説確証バイアスになりやすい。エラーを防ぐためには 164
    - 無意識にとらわれている仮説はないか、自省する
    - 考えたこともない(関係なさそうな)要因でも、もしかして関係していないか、あえて分析する
- 極端な数字によるエラーであるアンカリング:数字を提示されると、その数字に意味がなくても、判断がその数字に影響される 166
    - この誤りを起こさないように
        - 意図的に余分な情報が提示されていないか、チェックする習慣をつける
        - 値の大きさで、差がある・ないような印象が提示されていないか、いつも冷静に検証する習慣を付ける
- 言葉の表現によるエラーであるフレーミング:同じ意味でも表現で判断が変わってしまう 167
    - 防ぐために
        - ポジティブ(ネガティブ)な結論に誘導していないか、疑う習慣を付ける
        - 同じ事象を、ポジ<->ネガと逆の言い方に置き換えてみて、自分の判断が変わらないかを確認する習慣をつける
- 情報の順序によるエラーであるプライミング:先にポジティブな事象を提示することで、ネガティブな事象を目立たなくしている 169
    - 防ぐために情報の提示順序を逆にしてみて、自分の判断が変わらないかを確認する習慣を
- 偽の関係によるエラーである擬似相関:2つの現象が、共に観測されるだけで、一方が他方の原因だと思い込みやすい 172
    - 防ぐために、複数の因果モデルを比較し、どれが論理的にもっともらしいか、どれが常識的に理解しやすいか、考える習慣を
- 分析結果の解釈におけるバイアスのまとめ 173
    - 思い込み(仮説確証バイアス)
        - 無意識にとらわれている仮説はないか、他に仮説はないか?
    - 極端な数字(アンカリング)
        - 余分な情報や極端な数字が、意図的に提示されていないか?
    - 言葉の表現(フレーミング)
        - 逆の言い方をした時に判断が変わらないか?
    - 情報の順序(プライミング)
        - 情報の提示の順序に引きずられていないか?
    - 偽の関係(擬似相関)
        - 他の因果モデルを考えたか?単なる偶然ではないか?

### 分析結果の表現で誤解を招かない
- 数字自体を使ってもらうには、数字の実質的な意味合いを、相手の判断に刺さる視点で伝えることが大切 181
- 誤魔化されないためのチェックポイント 182
    - 報告者の立場・思想信条・利害などから、どのような結論に誘導したがっているかを読むことで、鵜呑みを防ぐ
    - 調査方法、集計方法、強引な解釈に注目する習慣を
        - サンプル数は十分?
        - 偏りなく公平にサンプリングされている?
        - どんな質問文、どんな選択肢で聞いたか?
        - グラフや言葉の表現が操作されていないか?
        - 不都合な数字が意図的に隠されていないか?
        - 集計方法が適切か?
        - 解釈が客観中立か?