一人目データアナリストとしてやったこと

初回の記事ということで自己紹介も兼ねたエントリーです。

僕は今、Web系の企業でデータアナリストとして働いています。
中規模サービスで、割と利用している技術も新しめの会社ではありますが、データ分析人材が今までいない状態できました。

分析人材がいなくてもここまで事業を伸ばしてきて、経験値の多い方が揃っているんだなあと感じたのを覚えています。

僕自身は前職でもデータアナリスト（やってることは同じでもデータサイエンティスト）と呼ばれる職種で働いてきており、今の会社には分析人材一人目という形で転職しました。

一人目のデータアナリストとして入社後やったこと

まずジョインして気づいたのは、今いる会社は分析人材がいなかったとしても、分析自体は行なっていました。例えばサーバーをRedashに繋げてPMがクエリを実行したり、CSチームがユーザーの行動状況を分析して問い合わせ対応をするなどです。
そのため簡単な集計は常日頃から行っており、一人目のアナリストとして入ったもののその基盤はできている状態でした。

経験上、データアナリスト（面倒なので今後DAとします）やデータサイエンティスト（DS）は、こいつ面倒だなと思われるか、こいつ使えるなと思われるかでその後扱える仕事の範囲が大きく変わってきます。
世の中データドリブンと言いつつ、現状まだまだアシスト部門であることが多く、ましてや自分たちで簡単な集計ができてしまうと、特に業務上困ることは無かったりするのです。

そのため、一人目のDAとして組織に価値を与えられるか、分析者を入れるとより成果が出る、というのを伝えたいと思っていました。

まずは手の内を言語化して伝える

DAがいなかった組織からすると、DAって何をする人なのか、何が出来る人なのかあまりよく分かってはいません。

実際DAの人材にもスキルがバラバラのことも多く、得意分野も違うケース多いです。

また単なるデータ出し屋、クエリやダッシュボードを作る部隊になっているチームも多いのではないでしょうか。（過去自分は、データ組織と言いつつ集計屋になっているケースを何度も見てきました）
もちろん、実際こういった業務は必要なので自分もやりますが、少なくともこれを主務にしたくは無く、仮にそうであったら最もAIに取って変わられる部署のため焦りを感じるかなと思います。

話を戻すと、他チーム目線でDAって結局何をするの？という期待と、DA目線で何がして欲しいの？という部分をマッチしないといけません。今回、自分は入社タイミングで、PMのマネージャーに以下のように自分ができること、やってきたことを伝えました。

• KPIの設計、マネジメント
• Webサービスの課題発見・改善アイディアの提案
• BIツールを活用したデータの可視化・ワークフロー構築
• 因果推論手法を使った効果検証
• 機械学習を用いた予測モデルの構築

上記の内容を、実際のサービスの例と照らし合わせながら具体的に説明をさせていただく機会をもらいました。

その際PM視点で、ここはやって欲しい、逆にここはあんまり話に出ない、みたいな感想をもらうことができ、自分ができることの説明を事業の課題や温度感を知ることができました。このコミュニケーションが非常に大事で、具体化したタスクは実はやらないことも多かったのですが、この後いろいろと仕事を貰うきっかけになったと思います。

とにかく実務で信頼を勝ち取る

具体的な要望を元に、実際にタスクを行なっていきました。タスクに取り組む際は、よくある話ですが依頼者の期待値を上回るように、自分なりの考察やスピード感を持って打ち返しました。

最初なのでサービス理解が浅く、頓珍漢なことを言ってしまうケースも多いのですが、とにかく変なことを言えるのも最初のうちだという思いで、とにかくフィードバックを貰うために分析結果を共有がてらディスカッションをさせていただきました。

僕が今いる会社はまだ一人目なので部署ではないのですが、通常分析部署は横断組織として機能することが多いです。
様々な部署からデータを用いて解決して欲しいという要望が来ることが、分析部署としての理想の一つだと思っています。

ただ、当然ですが誰かも分からぬ人にいきなり時間を割いて相談しようとは思いません。
そのため、自分から各部署の方に困りごとはないか聞いて回ったり、何かあったら連絡して欲しいということをSlackや別の会議のついでに言って回りました。

1、2ヶ月ほど経った頃、幸運にもどうやら分析が得意な人間がいるらしいということがまわり、いくつかの分析結果を共有する機会をもらいました。上記で書いたように分析結果を通してディスカッションすることで、だんだんと相談をいただく機会も増えてくるようになりました。

アナリストとしての提案を増やし始める

実はここまで、分析依頼をいただいたらそれを打ち返すことに集中していました。

しかしDAをやっている方なら分かると思いますが、この課題設定が適切かだったり、もっと問題は深いところにあるのではないか？と思うケースは良く出てきます。

そういった、調査をしてみないと何が出てくるか分からない系のタスクは、お互いの信頼関係がある程度無いと難しいと思っています。
そのため、この段階までは特に強く勧めたりはしていませんでした。

ただ、一度分析を通して雰囲気を掴んだらこの辺りもやりやすくなります。この辺りからは会議でも、以下のような問いを増やす機会が増えてきました。

実績をドキュメントに残していく

分析結果は意思決定を伴うことが多く、分析と共有を何度も往復するケースが多いです。
グラフや表も出し直したり編集することが多く、結局使われたのはごちゃついたコードのJupyter Notebookや、pivotとsumifが大量に使われたスプレッドシートだったりします。

また結果自体もSlack上で共有されるケースが多かったりしますが、自分は面倒でもドキュメント形式にまとめ直すようにしています。
ドキュメントに直すことは面倒なのですが、結局は自分を守るために必要だと思っていて、その理由として

1. 分析者の実績になりづらいこと
2. 知見がたまらないこと（同じような分析を繰り返ししないこと）

があります。
1つ目の内容は、Qや半期の評価で自分が適切な評価を受ける上で必須で、正直これが無いと評価する側も定性的にしか見れなくなります。

2つ目の理由では、あるあるなのが似たような分析を繰り返しすること。
きちんとまとめていないと、絶対同じ分析を後々やることになります。これは断見できます。
ただ一度目の分析時にしっかりとまとめておくと、あらビックリ、そのドキュメント共有で（なぜか）納得してくれます。不思議。

おわりに

以上が、僕がDA一人目として入社して、だいたい半年ぐらいに行なってきたことでした。

元々分析自体を行っていたメンバーも多く、すんなりと分析結果を施策に活かすのはさすがだなと思いつつ、何とかベンチャーのスピード感についていけるようにアウトプットを出し続けてきました。

今回のエントリーが、どこかのDA一人目になった人のお役に立てれば幸いです。