営業からデータアナリスト？に転身した人の話〜学び編〜
今年の3月で営業からデータを触ってどうにかするという職種に変わってちょうど2年になりました。
ちょうどいいタイミング（営業やってた期間とデータ触り始めた期間が同じ長さになって感慨深かっただけw）なので、ちょっと長めの怪文書を残しておこうと思います。
今回は今までの職種と会社で学んできたことを雑にまとめた「学び編」になります。
1社目：営業
キャリアのスタートは営業だったのですが、実は最初の会社でもアナリスト的な職種を希望していました（本当は営業は一番やりたくなかったw）
が、営業経験で得られた学びが後のデータをどうにかするキャリアにおいても非常に役に立っています。
営業で学んだことは以下のポイントでした。
ポイント
①要件定義に必要な要素
②KGI（売上）の要因分解
③社内での調整業務
①要件定義に必要な要素
当時の具体的な業務内容はプロダクトの戦略資料や振り返りのためのパーツ（データ）を提供する提案営業でした。
そこで必要だったのが、以下の要素のヒアリングです。
・どのようなストーリーラインに乗せたいのか（背景・戦略）
・どのポイントで詰まっているのか（課題）
・どのような情報が欲しいのか（目的）
・どのようなアクションを取りたいのか（施策・戦術）
・いつまでに欲しいのか（期限・スケジュール）
・いくらまでなら出せるのか（費用）
上記の項目は一つでも欠けていたら提案ができない、あるいはできても質の低い提案になってしまうため、非常に重要な質問項目でした。
（本当は5W2Hに沿って要素を整理すべきですが、今回は割愛します）
これらの要素を聞くためには仮説設計（どういうデータがどのタイミングでなぜ必要なのか）が重要で、仮説の精度が高ければ高いほど、質の高いヒアリングが可能になり、結果受注の確度も上がるわけです。
そのためには丁寧な事前準備（IR読み込み、市場状況の理解、クライアントの業務領域の把握...etc）が必要だったのですが、自分はここの情報の取得と整理が非常に苦手で大変苦労しました（今でも苦手なので、各所に迷惑をかけている真っ只中です。。）
②KGI（売上）の要因分解
例えば売上が減ったときに減った要因として考えられる要素は大きく2つあり、大きな要素の中でまたいくつかの要因に分解できます。
■間口（購入者）
・新規顧客の減少
・リピーターの減少
■奥行（購入金額）
・顧客の一人あたりの単価の減少
要因によっては打ち手も変わってくるので、売上が減ったからといって慌てて施策を決めてやっても正しい状況を理解できていなければ、何をしても空振りする可能性があります。
要因を分解することで、解決しなければならない課題が明らかになり、提案する内容やアプローチの方法が変わってくるので、正しい状況を理解することと理解するための情報（データ）を準備することは非常に重要です。
③社内での調整業務
自分でできないこと（データの集計や値引きの判断...etc）を誰にいつまでに何をしてもらうのかを判断して、報告をするというものになります。ここに関しては営業に限らず、どんな場面でも必要になるスキルになると考えているので、こちらも非常に重要なスキルになると考えています。
2社目：データアナリスト（受託・常駐）
ここではデータ分析はほぼ未経験（学生時代に少しRは触っていたが、ビジネスで使ったことは全くなかった。。）状態で拾ってもらいました。
ちょうどデータ分析バブルということもあり、会社も人をどんどん採用していたフェーズだったので、たまたま乗っかれてラッキーだったと思います。
ここでは以下のポイントを学ばせていただきました。
ポイント
①google力
②要件定義のファシリテーション能力
①google力
これはどちらかというとエンジニア界隈の話？に近いものになると思いますが、自分が「何のために」「何を」「どうやって」動かしたいのかを正しく調べるための情報を取得するスキルになります。
プログラミングに限らず、初心者はわからないことをどうやって調べたらいいのか以前にわからない箇所がわからないというケースが往々にしてありますが、ことプログラミングに関しては解決方法は簡単で、まずは「エラーコードをそのままコピペしてググる」これに限ります。
エラーは自分がわからなかったことは他の人もだいたいわからないことなので、誰かがどこかで質問してそれに対する回答がどこかに落ちています。自分しか理解できていないエラーがあるなんてことはないと思った方がいいです。
あとは冒頭にも書いた、自分が「何のために」「何を」「どうやって」動かしたいのかさえ意識すれば、迷子になる回数はだんだん減っていくようになると思います。
余談になりますが、そもそもどうやって動いているのかがわかれば、どういう書き方をすればエラーになるのかがわかるという逆説的な考えもあります。
（ちなみにどこかの研究室では全てのエラーコードを発生させるという合宿が行なわれているらしい。。すごい。。）
②要件定義のファシリテーション能力
これは受託・常駐を請け負っている会社あるあるなのですが、納品物や常駐時の終了までの条件をクライアントが納得する形でこちらが有利な条件に導くためのストーリーをいかにして作るのかという話になります。
基本的にZのつくアニメでサングラスをかけた人が言っていた「出資者は無理難題をおっしゃる」を地で行く世界（変な案件取ってきて雑に投げて放置するのもどうかと思うが。。）なので、どうやってだいぼうぎょを敷くか、だいぼうぎょを敷く前に座組みをどうにかこちらに有利になるようなストーリーを用意して、着地をコントロールをするかという話になります。
案件が始まってしまったら、どうしようもないので案件が始まる前のスコープの擦り合わせと握り、つまり要件定義が一番パワーを使うポイントになると思います。
（たまに握った条件を平気でひっくり返してくる人もいますが、その時は何も言わずに違約金を払ってでも契約を切って逃げることをオススメします）
3社目：データアナリスト（事業会社）
ここで初めて事業会社に就職をします。事業会社に就職するに至った経緯についてはまた別で投稿をしたいと思っているので、ここでは割愛します。
今まではtoBのデータによる意思決定やビジネスモデルの支援を中心に行なっていたので、toCに向けたデータ分析をしようとするのは初めてなので、まだまだ色々手探りですが、現時点まででの学びは以下のポイントになります。
ポイント
①データマートの設計
②KPIツリーの作成
③サブスクリプションモデル
④ROAS
①データマートの設計
これも分析あるあるなんですが、データを分析しようと思ったら分析するデータがない、あるいはデータはあるが分析できる状態になっていないというパターンだったので、まずはマートの設計から始めました。
↑リンクの記事はマート設計をする上で参考になると思うので、データがあるけど分析できない系の悩みを持っている方は是非ご覧になっていただければと。
↑リンクの記事は分析するためのデータを獲得するためのオペレーションから引き直し、データを溜めるところから始めないといけない方は是非ご覧になっていただければと。
自分は両記事が該当していたのですが、オペレーションを改善した方がいいと気づいたのがある程度マートが設計できてからだったので、急いでマニュアルを作成しました。
データを使わない（厳密にいうとSQLなどを使って集計を自らしない）人には、出したい指標を取るためにどういう設計が必要なのかまではわからないので、データを使い始めたタイミングで分析者が入ると、設計のタスクから始めなければ何もできないというのは大きな学びでした。
②KPIツリーの作成
先述のKGIの分解をもう少し正確に実施したもののイメージになります。
全ての要素を四則演算すると最終的にKGI（売上）になるという構造になっています。以下のようなツリーがあるとします。
これは式で表すと以下のような形になります。
計測指標がもう少し細かくなってくると少し式は複雑になります。
外部から提案をしていた頃は要因を分解して、自分たちが情報提供できる範囲の要因を中心に考えていましたが、事業会社側の人間になると要因分解をして、どこをコントロールすれば売上が上がるのか、あるいは売上の減少を食い止めることができるのかを考える必要があります。
事業会社の人間は中で考えられるあらゆる要因を考えるために、計測可能な指標をできる限り細かくして、小さな改善を積み重ねる施策を検討できることが醍醐味であると思います。
③サブスクリプションモデル
④ROAS
上記に関しては事業会社に入ってから知ったビジネスモデルとマーケティングの投資対効果の話になります。
こちらに関しては書籍やweb上での記事がすでにたくさんあるので、具体的な内容は割愛させていただきます。
サブスクリプションの参考
ROASの参考
今回は学び編ということでここまでになります。
（偉そうに学びという割には当たり前のことしか書いていないですが。。）
あとは文字文字してて気持ち悪いので、いつか各項目を図解して書き直すようにします。見直すと後半疲れて露骨に失速気味になっているのが笑えるのでw
次は思考編ということで、どういう経緯で今のキャリアに至ったのかをまとめようと思います。
思考編は抽象的な話になってしまって、まとめるのに時間がかかっているため、先にこちらを投稿した次第です。
長文に最後までお付き合いいただきありがとうございました！
この記事が気に入ったらサポートをしてみませんか？