データ分析者のバリューの出し方を考える 2021年版
はじめに
本稿は、自身がデータ分析者だと思っている人に対して、以下のことを自分の経験・学習した範囲から提案するものです。
・こういうプロセスでデータ分析・データサイエンスを活用するのがいいよね
・このプロセスではこういうことに気をつけたり、こういうことができるといいよね
世の人が、これを以下のように役立ててくださり、世の中に資することを期待します。
・これのどこまでが君のスコープなんだい？ということを、この文章を元に期待値調整（私は期待値を文脈に合わせて二つの意味で使うタイプの人です）できるようになる
・なるほど今俺は、こういうところで困っているのか？ということに気づける
また、こちらで書いたことが共通認識になればなるほど、自分の得意な働き方が世の中のデフォルトになるので、自分にとっても得だなという側面があります。
なので別に世のため人のためだけではないです。（古典的ツンデレ）（俺こういう感じで働いてっけど、みんなはどう？という問いかけというのが、自分の中での位置づけです）
今思うと2020年版は多少なりともストーリー感が強かったので、今回はお役立ちチェックリスト風に書くことにします。
具体的には、プロセスの内容と、そのプロセスの中身に対して、ここが勘所だと思ってるぜ、というのを書いて、それが振り返りやすいように整理することにします。
予実計画（財務モデリング）
まずは、計画からはじめる。
計画のために、事業の今後を占う差分方程式を組むのが、財務モデリングという作業である。
もっとも、企業買収のときにやるような重たいものが必要なことは通常ないので、普通は現場レベルではP/Lを作る。
そして、P/Lを視覚的にわかりやすく表現したのが、いわゆるKPIツリーである。
卑近に説明すれば、ECなら(売上) = (客数) x (客単価)であるし、サブスクリプションなら(売上) = (登録人数) x (平均継続月数) x (プラン単価)であり、これを共通言語として認識を一致させる作業とも言えるだろう。
予実計画におけるチェックポイント
・事業モデルに基づいた予測と計画はあるか？なければ誰かと作れそうか？
たとえば、https://note.com/modeling/n/na1fc4567cfb9
を参考にしよう。こちらの予想損益計算書を作ることができる程度の能力・環境があれば、データ分析をする上で困ることはない。
原価計算や減価償却や売上計上基準などのロジックは、誰かにその会社・事業でのやり方を聞こう。
個人的意見としては、データサイエンスでどうにかできるのは粗利までなので、初手は粗利までわかれば十分である。
・KPIの分解は施策レベルでコントロール可能なものか？
大前提として、KPI分解にはセオリーがある。客数と客単価のように。
まずそのセオリーを抑えることができているだろうか。重厚長大な産業と、スモールビジネスのKPI分解は一致しないだろう。
その上で、品揃えをデータ分析者が初手でどうこうするのは厳しいだろう。
ここで問うべきは、データ分析で改善できるようなKPIに落とせているか？であり、言い換えれば、バリューが出せそうな領域を発見できているか？である。
論点設計
KPIツリーにうまく分解できたあとは、どのKPIに力を入れるかを選定する、論点設計に入る。
もっとも、ここでは便宜上、その作業を論点設計と呼んでいるが、本来もっと大きな論点が来ることもある。
ビジネスの根幹を変えるような論点は、データサイエンスで取り組むこととはまた別のスコープになるので、今回の文章では触れない。
論点設計におけるチェックポイント
・選んだKPIは介入が可能そうか？
極端な例を上げると、日本人は人生で一回しか高校に行けない。（はずである）
学費を稼ぐために、1人あたりの高校に入る回数を増やそうとしても、法律との戦いになる。
ここまでの極端な例に出会うことはそうそうないが、直観的になんとかなるストーリーが描けるKPIを選定しよう。
・選んだKPIは誰かが気にしているか？
論点というほどなのだから、そしてそれは仮説の上に来るのだから、誰かがすでにそのKPIに対して危機感や仮説を持っているはずである。
現場のリーダーと意思決定者の気にしているKPIを最低限確認しよう。
・誰かから論点をもらえるか？
他者に重要論点をもらったほうが成果が出ることも多い。
そのための良好な関係を築くことは、成果のためにもかなり強く推奨される。
仮説構築
無事KPIを選定（論点を設計）できた場合、次は仮説構築に入る。
このプロセスにおいては、KPIを向上させるための仮の答えを洗い出すことが目的となる。
例えば、客単価をKPIとして選定し、(客単価) = (来訪日数) x (購買確率) x (購買あたり単価)と分解した場合に、
○○のようなキャンペーンを行えば、来訪日数をもっと増やせるのではないか？という仮説を立てる、といった具合である。
仮説構築におけるチェックポイント
・もっとも典型的なケースを描けているか？
まずは、このプロダクトやサービスを使うユーザの、もっともよくあるようなユースケースというものを脳内に叩き込む。
それらのユーザだけ抽出した場合のKPI、売上やUUにしめる構成比などが頭に入っているとなおよい。
ARPUが頭に入っている場合、コンビニでの代金と比べられるかもしれないし、旅行費の精算をしていてふと思い出せるかもしれない。
UUが頭に入っている場合、散歩中にすれちがった人数と比べられるかもしれないし、友人に連れられてきたライブ会場の人数と比べられるかもしれない。
身近でかつ近しい何かと比較することによってよりリアリティが増す感覚は、俺はいまビジネスをやっているのだ！と感じる最も顕著な一つの例だろう。
・面白い行動をとるユーザ、あるいは熱狂的にコアなユーザを描けているか？
典型的な行動を抑えた次にやるべきは、我々がこうなってほしいユーザ、あるいは面白いと感じるユーザをいくつかリストアップすることである。
なぜ筆者が一時期ガールズバーに入り浸っていたのかについて、読者の99％の方は理解できないだろうが、ガールズバーからしたら上客である。
あなたがガールズバーを経営するならば、私のような上客の心理を共感せずとも理解しなければならないし、人はなぜ上客になるのかを理解しなければならない。
（ちなみに、今は筆者はもう行っていない）
分析設計
筋の良さそうな仮説が見つかった場合、その仮説を証明するための分析を設計する。
例えば、先程の例に従えば、
・キャンペーンが無くとも仮説のような行動を取っているユーザを発見する
・それらのユーザが平均的なユーザに比べて良い顧客であることを確認する
・行動を促進できた場合、どれくらいKPIに変動を起こせるか試算する
というふうに、作業レベルへの分解を行うことになる。言い換えれば、仮説の成否と、可能性の幅出しのために必要なデータと、その取得方法を洗い出すプロセスである。
分析設計におけるチェックポイント
・空、雨、傘で整理できるか？
この比喩は、空=データ、雨=データを見て自分が考えたこと、傘=考えたことが正しい場合のアクション、と対応している。
まずはこの形に落とし込むことを徹底的にやるべきで、これがデータを取る前に描けていない場合は、手戻りするリスクが常にあると思ったほうがよい。
現実の難しいところは、落とし込めていなくても前に進んだほうが期待値が良いときはあるので、そのときは素直に前に進むのがよい。
たまに、空を見ないとどうにも……となるときはある。どうしてもある。
こういうときは、空➝雨➝傘と、空➝晴➝酒などの複数パターンを考えてからデータを見るようにするとよい。仮説力が鍛えられる。
空➝晴➝酒は今思いついたが、なかなか気に入ったので今後も使おうと思う。
・バイアスを取り除けているか？
世の中には様々なバイアスがあるが、これは純粋に、Apple to Appleな比較になっているかという確認である。
筆者は165cmしかないが、180cmの人と体重を比較して180cmの人より痩せていると言えるだろうか。（筆者の体脂肪率は20％前後を行き来している。）
筆者はまあまあ本にお金を落とす方だが、入学したての大学生と同じくらい本にお金を使っていたとて、その時の本代だけでグルーピングできるだろうか。期初に教科書を買っただけではないか。
このように、生まれうるバイアスを想像力の限り考えてみよう。（といっても、体感的に15分くらいでよい）
その上で、無視可能そうなバイアスかどうかを考えよう。
中学生からタバコを吸っている人とそうでない人の健康状態を直接比べるのは無理かもしれないが、同一地域の同一職業で揃えれば直接比較するよりはバランスできそうである。
・どういうグラフを描くかイメージができているか？
いい分析とはすなわち、全関係者が納得し、何も言わずともアクションに移るようなたった一枚の図を描くことである。
そこまでの分析は自身も行ったことはないが、立てた仮説に対するシンプルな表現を考えるのは当たり前に重要である。
どれほど難しい論点が来ようと、どれほど入り組んだ経緯で来ようと、あなたの言うことはこういうことですか、ならこのデータ見ればこうですね、の精神を忘れてはならない。
また、この幅を広げるために、色んな可視化に触れるべきであるし、同時に作法にも触れるべきである。
世の人はこれのために、IRを見よと言っている。（というのは筆者の見解である）
分析実行
いよいよ、分析を実行する。
ここは、基本的にSQLをやpythonを書いて、先程設計した分析を実現するプロセスになる。
ここでのノウハウ・やり方はたくさんTipsとして転がっている。
大体の分析は、まあ、型にはめてエイヤくらいだと思っておけばよい。
できない場合は、型を知らないだけなのである。
分析実行におけるチェックポイント
・定跡と定跡外を分けられるか？定跡に従えた部分はどれくらい大きいか？
定跡を自分の中に構築しよう。
バイアスを取りたいなら初手は層別化だとか（初手で傾向スコアはやらないだろう……多分）、想定したユーザがどれくらい居るかならクラスタリングだとか、そういった話である。
その場で考えなければいけないことは、体感1割で、残りの9割は定跡がある。
また、先も述べたように、定跡が足りていないか、定跡外のことが起きたため、分析設計まで手戻ることはあるだろう、これは問題ではあるが、そこまで重く捉えるようなことではない。
先に設計を行っておくことのメリットは、自分の想定とズレたことを認識するためであり、ズレの原因を分析し、それをチューニングすることによって腕がよくなる効果がある。
また、言い換えれば、設計と実行を行き来できることも、データ分析者のメリットである。ここが分離してしまうと、リードタイムが大きくなり、思った速度で成果に結びつかない。
・検算をしたか？
分析が終わったら、検算をしよう。
アクティブユーザーあたり10000円の単価のサービスの単価を100円上げるのは、まあ頑張ればできることだろう。
アクティブユーザーあたり100円の単価のサービスの単価を100円上げるのは、よっぽどドラスティックなことをしていないと達成できないだろう。
数値に現場感はあるか？
レポーティング（提案）
さて、分析を行ったら、この一連の仕事の報告を行う。
そしてその場で話が通れば、仕事は企画段階から実行段階に移る。
自分の分析結果を踏まえて、誰に何をしてほしいのかを伝え、実際に走り出す承認を取るのがこの段階である。
レポーティングおよび提案におけるチェックポイント
・会議でのやり取りを想定できるか？
分析結果を発表する予定の会議において、誰に何を言ってもらったらクリアかを明確にしてまず臨む必要がある。
これを踏まえてレポーティングの型や、想定される質問を先回りしておく必要がある。
また、可能ならば、想定されるやり取りを論点形式にまとめておくのがよい。
論点形式でまとめておくことによって、どの粒度で自分がうまくやれなかったかが明確になる。
施策実行
先程のレポーティングで承認が取れた場合に、実行を行うフェーズである。
例えば、先の例を踏まえると、キャンペーンを行うとして、当日のオペレーションや告知などのタスクを5W1Hで整理し、それを遂行していくフェーズになる。
・PJ進行のためにできることを拾おうとしているか？
データ分析者は驚くほど実行・運用の際においては無力である。
形にしてくれる誰かへの敬意を失っては、とても仕事にならないし、成果も出ない。
順調なPJ進行のために、やれることはなんでもやる意識を持って臨むべきだ。
・PJの成否にコミットしているか？
あなたの仕事はデータを分析するだけではない、何かを提案することでもない、プロジェクトを完遂することでもない。
巻き込んだ人たちと一緒に成果を出すことだ。
成果を出すまで歯を食いしばって脳に汗をかくことだ。
成果が出るまで問題解決したとは言えない。
データ分析者は、問題解決のプロとしての矜持を持つべきである。
効果測定
無事施策をやり終えても、仕事は終わっていない。
その施策の効果をKPIツリーに基づいて分析し、良かったのか・悪かったのか、想定通りだったのか・想定とズレたのか、を洗い出すのが効果測定のプロセスである。
そこから得られた示唆をもとに、上で述べたどれかのプロセスに再び戻って、また新たなプロジェクトを進めていくことになる。
一般には、仮説構築や、分析設計に戻るパターンが多いのではないかと思われる。
・どれくらい分析設計した時の想定とズレたか？
そもそも、分析設計において、試算に使ったフレームワークが完璧ならば、効果測定のときやるべき作業は、ちょっと変えてSQLを流し直すだけで終わる。
想定通りの結果が出なかった場合の原因究明も含めて、どこまで想定どおりに行えたか、は、腕のいいデータサイエンティストの一つの基準としていいだろう。
・次のプラン・アクションに繋げられる示唆は出せたか？
単によかったです・悪かったですでは、学習ができていない。
仕事を通じて学習できたことがなければ、何も進歩していないわけで、危機感を抱いたほうがいいだろう。
またこれは個人的な話ではなく、チームや組織として学習ができていなければ、すなわち人的資本に資するところがなかったわけで、それは結局競争力を失うことに繋がるだろう。
おわりに
以上のプロセスによって、データ分析者はバリューを出していくのが、いいんじゃないかな、というのが筆者の考えです。
この一連のプロセスを回せるようになった時、人はシニアデータサイエンティストになるのではないかと思っています。
めっちゃ書くの疲れたので、たくさんいいねしといてください。