データ分析者のバリューの出し方を考える
本稿は、自身がデータ分析者だと思っている人に対して、こういうのが事業会社におけるデータ分析者に求められている価値の出し方なんじゃないだろうか、というのを提案してみるために書きます。
そのため、一切の自身の所属団体、所属していた団体とは関係なく、あくまで一個人のプライベートな意見であることを記しておきます。
私はビジネスマンとしてまだまだ経験が浅く、至らないところが多いため、以下の点で間違っていたり、至らないことが考えられます。
・そもそもプロセスの全体像を勘違いしている
・プロセス自体への理解が浅い
・そこでバリューは出ないだろうという点に重点を置いている
・webでの分析に寄りすぎている
最後の問題はできるだけ一般的に書こうとはしますが、それでもそれはwebの話じゃんというのがちょいちょい出てくる気がします。
上記の問題点はあるのですが、自身がどう思っているかを記しておくことは非常に有意義だし、自身での整理にも繋がるため、本稿を記していこうと思います。
また、かなり理想の自分を描いているので、いやお前ここまで出来てへんやろ、というのが結構あると思うのですが、そこもお目溢しください。
想定する一連の流れ（事業会社でのビジネスの流れ）
事業モデリング
まず期初に今年いくら売上立つんですか、いくらお金使うんですか、いくら利益出すんですかという事業計画を立てます。
いっぱんに事業計画の目標は天与の場合が多いです。
事業モデリングに基づいたシミュレーションはできれば分析機能として持ちたいという認識です。ただ、慣れた人がいないと重い仕事なので、持っている分析チームは希少かもしれません。
そのため、実際には前年成長率横引きや市場成長率から出した目標に対してひたすら現場がコミットすることもあると思われます。
私はこれを必ずしも否定するわけではなく、現場でよしなにKPIツリーを運用していくかあでもそんなに困らないなあ、という立場です。
KPIを各リーダーに配るのが好きな意思決定者は、KPI単位でのシミュレーションをすべきでしょうし、そうでなくてお前ら全員売上かコストカットにコミットしろ！という旗の振り方をするならば現場でよしなにKPI分解をすればいいかな、と思っています。
つまり、どのような事業モデリングに基づいて計画を立てるかがまだ定まっていない場合は、分析者自ら事業を構造分解してどのようなKPIに分割していくべきかを考える必要があるでしょう。
具体的な事業モデリングの作業としては、PL/BS/CFという財務三表を計算するエクセルシートを用意しておいて、実績や市況感からこれくらいになるでしょうという仮設を積んで未来予想をするというプロセスだと思っているのですが、自身の作ったPLシミュレーションが偉い人のところまで行って使われる経験はあんまりないので、少し自信が持てません。
また、企業参謀では、いったん今の改善プランを全部積んで、それでも埋まらない目標との差が戦略的ギャップだとも語られており、どこまでやりきるかはその時の関係者の望んでいるアウトプットに寄せる印象です。
論点設計
事業計画が立った場合、次はどのような問いを解くべきかを考える論点設計のフェーズです。
論点が誰かから降ってくる場合は、大小様々あると思います。webの分析者だと、下の仮説構築で取り扱う問いくらいの粒度が一番多いのではないでしょうか。逆に、戦略コンサルとかだともっと大きな論点を扱っている印象があります。このあたりは、意思決定者との距離の近さや抽象的な問題を取り扱う能力や職能で決まる認識です。
自分が分析者として何かを提案する際は、どのKPIに注力すべきか、ということを見定めるというフェーズだと考えています。
ここの見定めに関する自身の見解は、後に記します。
仮説構築
どのKPIに対してアプローチをかけるかが決まった後は、どのようにしてKPIを上げるか、という仮説構築のフェーズです。
例えば、
・どの機能にテコ入れすべきか
・どういうユーザが優良顧客でどうやって育成していくか
・新規獲得のためにどの層を新たにターゲットにして、その時どれくらいの事業効果が予想されるか
・リテンションを上げるためにポイント・クーポン系の施策をすべきか、それともマーケティング・チャネルを新たに開設すべきか
などの、KPIを伸長するための小さな論点を新たに立てていくイメージです。そのため、仮説構築と言っていますが、whatからhowに問いの粒度が変わっているイメージで仕事をしています。
分析設計
仮説構築が終わったら、次は上で出た仮説のうち、筋の良さそうなものに対して、どのように証明すべきかを考えるフェーズです。
また、効果測定方法も合わせて一緒にここで作っておくことが多いです。
分析実行
上で立てた分析計画をSQL,Excel,Pythonなどを用いて証明していくフェーズになります。
レポーティング
意思決定者や現場のリーダーに対して結論と分析内容をプレゼンするフェーズになります。
施策実行
現場のリーダーが施策実行のためのプロジェクトを立ち上げ、その施策の遂行をともに行うフェーズになります。
効果測定
分析設計のフェーズにおいて決めておいた効果測定方法に基づいて、どのような結果が得られたかを再度意思決定者と現場のリーダー・メンバーに対して報告し、議論します。
議論から得られた次の仮説に対して、再び分析設計を行います。
事業モデリングについて
BSやCFが重要なフェーズの事業に携わったことがないので、基本的には使いやすいKPIツリーと、それに基づいたPLシミュレーションを行うことが重要だと考えています。
使いやすいの定義とは、次の三点だと考えています。
・和差積商で利益、売上総利益、売上を再現する
・施策に落とし込みやすい
・粒度が人間が見て理解しやすい
・効果測定しやすい
・使い回しが効く
とくに、和差積商で利益、売上総利益、売上を再現する必要があることを理解していないKPIツリーを見ると……とても悲しくなります。エクセルなりでシミュレーション出来ないと使えないですからね。
また、KPIツリーは理想的には関係者全員が理解し、かつ納得しておくべきものになるので、初期は忍耐強いコミュニケーションが必要になることが多いです。
あとは、webだと基本的にスケールするものが多いのですが、業態が変わるとスケールするものが減っていくので、そのあたりの感覚は何らか勉強しないとつかめないですね。私はずっとwebなので、そのへんの勘があまりないです。業態の違いを正しく捉えて比較しないと、めっちゃ炎上するので気をつけたいです（時事ネタ）。
論点設計について
論点設計で最も重要なことは、意思決定者や現場のリーダーの考えていることと目線が合っている（重要視しているKPIが一致しているか）か、ということだと思っています。
理由としては、誰かが気にしていることに答えを出すから価値があると考えており、実感として、誰も気にしていない論点は基本的に無価値なことが多いです。
逆に、それはおかしいでしょとツッコミが来る論点のほうが微妙な論点より価値があることのほうが多い実感すらあります。説得さえできれば、むしろ攻めている施策に落とし込みやすいからです。
自分もまだそこまで大きい論点を持ったことはなく、前述のどのKPIに対してアプローチしていくべきか、という論点も振られるとちょっとつらいのが現状です。
本を読むと、注力KPIは競合他社のベンチマーク、市場感、ビジネスの利益構造から答えを出すべきパターンも多いため、すこし荷が重めだったり、視座やビジネス理解の問題でwebのデータ分析者だとそこまではっきりとした答えが言えない論点だと思っています。
一方で、lean analyticsなどの本においては、基本的にこのKPIに対してアプローチしていけ、というノウハウなども記載されており、このあたりはまだ自身でも経験が足りてない領域です。
そのため、自身ではアニマルスピリットとシミュレーション結果に則って決めています。
ちなみに、誰かからもらった論点を仮説や分析に落とし込むのは結構得意です。言い換えれば、誰かの言ってることを算数やwhat if A then we Bの形に書き換えるのが得意だと言えます。
仮説構築について
このフェーズはhowをより問われるので、発想力、ユーザへの理解、世の中の取り組みへの理解が最も重要だと考えています。
また、私のようなビジネス寄りのデータサイエンティストは機械学習やテック的な施策に関する点で強みを出すことが多い認識です。
詳しく書くと、
・（機械学習問わず）なにかの自動化のロジックのPoCが出来て、その運用パイプラインなどもエンジニアと相談が出来る
・企画段階で機能を持ってるチームがまたがりそうな際に、適切な連携方法を関係各位に相談できる
・こういう仕様のAPIだとこういう機能が達成できそうなんだけどみたいなところまでいったん落とせる（だいたいボコボコにされるけど。）
・世間の機械学習活用プロダクトの仕組みを理解しており、必要ならば論文が読める
のような点で施策案を出す際に強みがあると思っています。
ここでいい仮説が出てこないときの処方箋が最近流行りのUXRだという認識です。
ここはどんな施策仕込んでるかとかが漏れそうなので、ちょっと控えめに書きます。
分析設計について
このフェーズはどれくらい型を知っているかが最も重要だと思っています。
基本的に観察データからの分析になるので、100%の精度は出ません。そのうえで、現実的なシミュレーションを出すためにどれくらい頑張るべきか、どういう頑張りかたを選ぶべきか、というところに重点を置きます。
具体的には、試算を正確にするためにどういう変数で層別化すべきか、傾向スコアや線形モデルまで頑張るか。
効果測定まで見据えたKPI分解とその測定準備ができるか。
ここは現在はまだ、下の分析実行フェーズも合わせて、早い・安い・うまいで差別化出来る領域ですが、そのうちコモディティ化する方向でみんな読んでいるようです。自分の競合比較したときの一番の強みはここなのですが、ちょっと不安です。
分析実行について
おまたせしました。やっと分析実行のフェーズです。
ここで重要なのは、以下の三点です。
・データラングリング力
・SQL力
・pandas力/R力
・ちゃんと辻褄合ってるか自分でチェックできるか
・どこからどういうふうにデータが生まれるかの理解力
・初見のDBを見てなんとなく構造を察する力
（普通こう作るだろ……のようなカンが効く力）
・サーバログ/クライアントログの違い
・行動データに乗りうるバイアスの理解
・アンケートデータ特有のクリーニング
・センサデータに乗りうるバイアスの理解
・売上基準がどのタイミングかの理解
・足りないデータをお願いしてETLしてもらう力
・可視化力
・表現したい事実に対して適切なグラフを選択できるか
自分はここも結構自信があります。とくに、SQLを書くのは普通の分析者の3倍早いと思っています。
SQLが早いのは、事業的貢献には遠いような、でもオペレーションエクセレンスとしては超重要な点のような、不思議な気持ちです。自分でも答えが出ていません。
レポーティングについて
ここは理系の作文技術とビジネス文書作成術といわゆるプレゼン術のあいがけみたいな能力がもっとも重要だと考えています。なので、各自そのへんを読んで勉強して実践するしかないというのが結論です。ちなみに私は苦手意識があります。
施策実行について
ここでは、あまり力になれることはないですが。強いて言うなら、分析者の立場から拾えるボールをちゃんと拾って投げる、ということが重要だと考えています。
ここでも存在感を出したいので、可能なら自分で手を動かせるパートを持つようにしたり、企画の会議にできるだけ出るようにしています。
一緒にやった施策のほうが楽しいし気合が入るという気持ちの問題ですが。
このフェーズでもっとも価値を出せるのは、PO/PM/PdMだったり、各プレイヤーですね。とくに私はプロジェクトマネジメントが死ぬほど苦手なので、あんまり出しゃばらないようにしています。
効果測定について
ここで重要なのは、以下の二点です。
・速報値をすぐ出す
・結局いくら儲かったの？に答えられるようにする
ここでのレポーティングは最も気合を入れてやるべきですし、仮定を置いていたらちゃんと仮定も記して誤解を招かないようにする、というのを重視しています。
ここは基本的に分析や提案段階で決めておくべきことなので、ノウハウらしいノウハウはないのですが、強いて言うならKPI分解をきちんとやっておくこと。また、A/Bテストが唯一の黄金律で、それに近づけるためにはどういう妥協とどういうお願いをすべきか、というやり取りをきちんと行っておくと作業段階では何も考えなくていいことが多いです。
まとめ
だいぶ自分語りが増えてしまいましたが、自分が分析職として、こういうところで事業貢献していくべきなのではないかと考える観点が明瞭になったので書いてよかったなあと思いました。
また、こうして記してみると、まだ自分が苦手だったり、未経験の領域あるなあと思いました。
色々経験してみたいという気持ち・自分が本当にやりたいことは何なのかという気持ち・そもそも自分の認識している強みはずれてないかという気持ちが出てきたので良かったなあと。
ご感想・ご指摘をお待ちしております。
この文章の出来がもし良かったとしたら、それは今まで出会ったたくさんの師匠たちのおかげです。
この記事が気に入ったらサポートをしてみませんか？