こんにちわ！kofaです。
の読書録の続きです。
前回は、内容の要約を書きました。良ければ読んでみてくださいね。
刺さったフレーズ
人間はなぜ、ニュースが伝える破滅や憂鬱さに影響されやすいのだろう。狩猟採取の時代に戻れば、クモや蛇を100回怖がった方が、一回しか怖がらないより身のためになった。人は、怖がりすぎても死なないが、恐れ知らずだと死ぬ可能性が高くなる。
Humankind 希望の歴史 (全2巻)
破滅的、憂鬱だなと思える事態は仕事の中でよく起こります。
でも、そういった経験を積んでいくことによって、良い意味で悲観的に先を見越せるようになり、それが慎重という態度になります。
仕事においては「守り」の観点だと思いますが、守りを固めるとアウトプットは安定し、その積み重ねが顧客や仲間との信頼関係につながっていきます。
では、データ分析においてはどうでしょうか？
データ分析においては、間違った意思決定にガイドしてしまうことが最大のミスです。
このミスの要因としては大きく二つあります。
- 分析に使うデータを間違える
- 分析結果の解釈を間違える
データを間違えるというのは、例えばコーディングをミスって、数字が間違っているというのが代表的です。
解釈を間違えるというのは、例えば当初の仮説に固執してファクトを捻じ曲げて解釈してしまうなどが代表的です。
逆に言えばこの二つを押さえておけば、一定の品質を担保したアウトプットを出し続けることがでます。
今回は、データ作成、結果解釈に着目し、どのようにしてミスを抑えていくかという点を考えていきたいと思います。
分析プロセス整理
まず、本論に入る前にそもそも分析プロセスについて整理して、データ作成と結果解釈に着目する理由について説明したいと思います。
分析プロセスは、ざっくりこんな感じです。
20220326_分析プロセス_ver0.3 by kofa on Scribd
前述したように、データ作成と解釈の工程はミスると、間違った意思決定にガイドしてしまうリスクが上がります。
もちろん、仮説構築と可視化は適当にやっていいというわけではないのですが、この工程は品質が低かったとしても、意思決定を間違うリスクへの影響は小さいです。
「仮説構築」については、合っているかどうかを検証するために仮説を建てるわけで、そもそも間違えという概念がありません。
なんなら、間違えることを恐れずに大胆な仮説を構築すべきという話なので、仮説構築の工程に間違った意思決定を導くリスクはありません。
※ただし、仮説がしょぼければ、しょぼいアウトプットしか出せないというリスクはあります。
「可視化」は、わかりやすく説明することが目的です。
わかりにくいグラフを作ってしまったとしても、その場合は理解されずに意思決定がされないだけです。
よって、可視化についても間違った意思決定を導くリスクはありません。
※ただし、間違った意思決定に恣意的にガイドする方法として可視化が悪用されるケースはあります。
ということで、前置き長くなりましたが、今回はデータ作成の工程と解釈の工程に絞って考えていきます。
データ作成でミスらないためのコツは？
データ作成の工程では前処理したり、マートを作ったりするために、データ調査、コーディングなどのタスクが走ります。
これらのタスクに対して、コスパ良く品質を上げるにはどうすれば良いか？を考えていきます。
そこで、取り上げたいのはコードレビューです。
レビューというのはデータ分析に限らず、品質を上げるためのコスパの良い手段です。
そんなの当たり前だろと思われるかもしれませんが、私の見てきた範囲では、コードレビューはおざなりにされる傾向があります。
要因については以下の3つが大きいかなと思います。
- コードレビューは普通の資料レビューに比べてレビューする側の負担が大きい
- 人が書いたコードを黙々と読むのはそんなに楽しくない
- その割にレビューするべきコードはたくさんある
私が従事したケースでは、定常的に膨大な量のアウトプットを求められており、レビューすべきコードの量も普通のプロジェクトと比較してかなり多かったです。
要するに、「ちゃんとやれ」の一言では現場が疲弊するか、やられないかの二つしか道はなかったのです。
とはいえ、綱渡りを続けるわけにもいかなかったので、レビューを通っていないデータは使わないという大原則を周知徹底しつつ、「ピアレビュー風の高度なセルフレビュー」のコンセプトの下、
- どういう処理をしているかを、コード作成者がレビュー者に説明すること
- レビュー者はその説明がわかったかどうかをコメントするだけで良い
を要件として、実施してもらいました。
ピアレビュー風の高度なセルフレビュー
これ、気づいている人もいるかもしれませんが本質的にはセルフレビューです。
間違えに気づける確率を向上させるために他人に「説明すること」をお願いしました。
説明のために別の話をしますが、私はそこそこ大事な報告をするときは一人でリハをします。
リハでは、自分で「このスライドでは～」、「この結果の前提は～」、「ここの数字が上がっているので～」のように、自分で作った資料を見ながら説明する練習をします。
その過程で、セルフチェックでは見落としていた資料の間違いや、改善点は結構見つかります。
これをコードレビューに持ち込んだ感じです。
ちなみにですが割とシニアなサイエンティストの方がはまったみたいで、凡ミスに気づけたり、読みやすいコードに改善されたりといった効果が出てました。
解釈でミスらないコツは？
正しく解釈できているってどういこと？
それは、「ファクトを忖度なしにそのままとらえて、誇張することなく解釈している」ということだと考えています。
なので、ミスしているのは、その逆です。つまり、
- 解釈に忖度がある
- 解釈に誇張がある
の二つになります。
解釈に忖度がある
忖度する相手は顧客か上司しかいないので、彼らの仮説を支持するような解釈をしようとしてしまうという意味です。
ちょっと極端ですが、仮説を否定するような分析結果になって困っているという相談を受けることもあります。
忖度という言葉が流行語になるくらいですから、人間の心理としては忖度しやすい傾向があるのだと思います。
例えばこんなケースはよくあります。
- あるクロス集計表があったときに、部分的には仮説を支持している。
（その逆も真。つまり、部分的には仮説を支持しない。） - 仮説を支持しているところだけ切り取って解釈して、仮説を支持したと結論付ける。
- 仮説を支持しない部分は今後深堀しますとか言って、解釈もしないし、最終的に深堀もしない。
みたいな感じです。
なんでそういう状況になっているんだ？ということを解釈して、仮説を出すことが本来やるべきことです。
そして、解釈をちゃんとすることによって、新たなメカニズムの仮説が見えてきて、現象に対しての理解が一層深まっていきます。
忖度というのは、この一連のプロセスを放棄して、言いたいことを言うためにいいように使われているということになります。
解釈に誇張がある
誇張とは何か？
一言でいえば、そこまでは言えないでしょ？というやつです。
明らかに言い過ぎという判断が下せる場合は別として、一見最もらしくても言いすぎてしまっている時もあります。
例えば、「Aというファクトに対してBという解釈ができた、もし、Bが真だとすればCというアクションが抽出できる。」
何が問題かというと「Bが真だとして」という仮定を勝手においてしまっている点です。
上記のような論理構造の時、「解釈を誇張している」と私は判定しています。
あえて誇張するときも・・・ある。
原則としてはあくまでファクトに対して、誇張なく言えることにとどめるのが正しいですし、そういうスタンスを身に着けるのが大事だとは思います。
一方、そのスタンスが自分の中に確立されているのであれば、戦略的にあえて誇張するというのも手段としてはとりえます。
先ほどと同様に「Aというファクトに対してBという解釈ができた、もし、Bが真だとすればCというアクションが抽出できる。」
を考えてみます。
仮にCというアクションが絶対に取れないのであれば、この分析をこれ以上進める意義が無い可能性があります。
このように、前提条件を確認したり、アクションの方針を討議するために、あえて誇張した解釈をすることはあります。
ちなみに、こういう時には「踏み込んだ解釈」とか、言ったりします。笑
解釈の正しさはwhy soで確かめる
私は解釈をするとき、まずは思いつく言葉をばーっと書き下します。
このときに、「忖度」とか「誇張」とか気にしません。
書き下した後に、忖度してないか、誇張してないかをチェックします。
どういう風にチェックするかがポイントで、「なぜ、そう言えるか？」と問います。
いわゆる「why so?」ってやつですね
「なぜ、そう言えるか？」に対して、「このファクト（集計表）があるから」とストレートに言えない時は解釈に忖度、誇張があります。
- why so?したときに、「ファクトの一部」のみ参照していれば、忖度してしまっている可能性があります。
- why so?したときに、「解釈（＝ファクトにないこと）」を参照していれば、誇張してしまっている可能性があります。
まとめ
間違った意思決定を導いてしまうことが、データ分析で一番やってはいけないこと。
それを防ぐためにデータ作成と解釈の工程が大事であることを述べました。
データ作成においては、レビューが実施されていないケースが実は多かったりするので、リーズナブルにレビューを実施する方法としてピアレビュー風のセルフレビューを紹介しました。
分析結果の解釈では、忖度、誇張をしないように注意すること、また、チェック方法として「なぜそう言えるか？(=why so?)」と問うことが大事という話をしました。
守りの話が中心でしたが、守りをしっかりしておくと、安定的に品質の高いアウトプットを継続することができますし、そういう積み重ねが信用を固めていきます。
読書でキャリアを切り開こう！
コメント