はじめに

こんにちは、データアナリストの高山です。今日はデータアナリストの業務について実体験をもとに書きたいと思います。 OpenWorkのデータアナリストがどんなことをしているのか、どんなチームなのか、少しでも興味をもっていただけると幸いです。

OpenWorkのアナリストチームでは日々集まるデータを使ってユーザーの利用状況分析を行い、よりよいサービスにつながる提案ができるよう業務に取り組んでいます。また、データ抽出専門(SQLを書くだけ）の担当者や分析専門の担当者というように分かれておらず、分析者自身でデータと向き合いSQLを書いて集計し、それを分析しています。

今回は最近取り組んだ分析について、分析の一歩手前の「データを集計する」ところに焦点を当てて書いていきたいと思います。

ユーザーによって異なるOpenWork利用の背景

転職活動以外でも使われている

OpenWorkといえば社員クチコミのイメージをお持ちの方が多いかと思います。社員クチコミを読み転職活動に利用することはもちろんですが、

既に内定が決まった人が内定先の実情をみるために社員クチコミを見たり
特に転職活動していないが自社の他の社員の意見を見たり
取引先や投資先の調査として利用したり

というようにユーザーによって転職活動以外で利用されることもあり、その背景は様々です。

採用企業と転職希望者の出会いの場として

OpenWorkは社員クチコミが読めるだけでなく、企業が求職者（OpenWorkでWeb履歴書を登録しているユーザー）に対してスカウトを送れるダイレクトソーシングサービスも提供しています。

おかげさまでスカウトする企業も受け取るユーザー数も着々と増えている状況ですが、OpenWorkに登録するユーザーの目的は求職だけでなく様々であることから、スカウトの送信状況や返信状況をウォッチしていくとスカウトを受け取った後すぐに応募しているユーザーや活発にOpenWorkのサイトを利用しているユーザーが存在する一方、複数スカウトを受け取っていても全然動きのないユーザーがいることもわかってきました。

何に着目するか

動きが全然ないユーザーに対してスカウトを送るより、積極的に転職活動しているユーザーに送る方が企業にとっても採用効率が高まります。さらに転職活動中のユーザーはより企業との出会いが増えることになり、企業とユーザーとのよりよいマッチングにつながると考えました。

そこでまずは、スカウト返信をしていないユーザーに着目して、

どれくらい存在するのか？
(返信するユーザーと比較して)行動に何かしらの兆候があるのか?

といった現状を把握できるようなデータを集めようと考えました。

着目するデータの集計方法を考える

スカウト受信者の反応をみてみる

まず着目したのが 「スカウトの未読状況」 です。届いたスカウトが既読になっていれば反応しており、返信が無くてもスカウト内容を確認し求職者の判断で返信していないとわかります。

気になるのは、未読がたまっている（スカウトを全然見てもらえていない）ケースです。そこで、まずは未読状況を把握する事となりました。

カウント方法のロジックを考える

単純に「現時点」の「未読になっているスカウト数」をカウントするだけであれば簡単です。しかし、何年も前に届いたスカウトも最近届いたスカウトも一律に未読数をカウントすべきでしょうか？

過去の「ある時点」の状況を再現したり、複数スカウトが届いている人でとびとびに閲覧している場合どう集計するべきか、という点も考慮すると集計が複雑になってきます。

例えば、Aさんに6通スカウトが届いていて、1通目と3通目のスカウトだけ閲覧されたとします。

　　1通目：既読

　　2通目：未読

　　3通目：既読

　　4通目：未読

　　5通目：未読

　　6通目：未読

今回の分析では「行動に何かしらの兆候があるのか?」という点もみていきたいと考えているので、「そのスカウトが届く前に未読数がどれくらい溜まっているか」を調べることとしました。

Aさんのケースだと2通目のスカウトを送ろうとする時、未読数は1通目が既読なので「0」となり、3通目を送ろうとする時は2通目が未読なので「1」になります。では4通目を送ろうとする時、Aさんの未読数はどうカウントするのがよいでしょうか？

今回の集計では「一度既読したらそれより前に届いたスカウトの未読数はカウントしない」こととしました。例えば数年前に届いたスカウトが複数未読になっていても今週届いたスカウトを閲覧していれば、そのユーザーは最近活発に動いていると判断すべきで、昔の未読数を数えても現状を表さないのではないかと考えたからです。

もちろん私一人で決めたのではなく、プロジェクトメンバーと「当時の状況を把握するのはどうするのがよいのか」議論しながら決めました。なので、

4通目を送ろうとする時は3通目が既読なので未読数「0」（2通目の未読はカウントしない）
5通目を送る時は4通目が未読なので未読数「1」
6通目の時は4通目と5通目が未読なので未読数「2」

とカウントします。

SQLでロジック通り集計するには

この法則で「〇通目を送ろうとする時、未読数は〇通であった」とSQLで集計しなくてはならないのですが、これが骨が折れました。単純に未読の累計数だけだったら、、、、と何度か心の中で思いましたが、いやいや、目的は当時の状況を把握する事だからと自分を励まし（言い聞かせ？）SQLと格闘しました。

といっても、一人で悩んでもただ時間だけかかってしまうので、そこはアナリストチームのメンバーに助けてもらいました。一人で長時間悩まず済んだのはチームメンバーのおかげです。。。

【集計の流れ】

①スカウトを送信された順に並べる

②それぞれのスカウトに累計受信数(＝送信順の受信番号）を付与

③閲覧されているスカウトだけに絞って、②の累計受信数を取得

　※閲覧されていないスカウトはNULLにしておく

④一つ前のスカウトの③の累計受信数を取得

　※ここでも閲覧されていないスカウトはNULLのまま

⑤未読の場合④の一つ前の(NULLを除いた値が入っている)累計受信数を入れる（＝未読の場合、数が増えないようにする）

　※ここで、閲覧されていないスカウトに一つ前の④の数値がはいる

⑥最後に、②の累計受信数から⑤の数値を引き さらに1引く

　※直前の未読数が知りたいので、さらに1引いている

　※この時1通目は1通目として扱う

【Aさんのケースに当てはめると】

後は、1通目は絶対未読数が0になるから1通目として扱ったり、そもそも1通も既読がないケースを考慮するなど、諸々修正を加えSQLを作成しました。作成後、1通もスカウト閲覧していないユーザーやとびとびに閲覧しているユーザーなど複数パターンをもとに、想定通りに集計できているか確認も行いました。

大切にしていること

このように、 「どのように集計すべきか考える事」 と 「正確にデータを集計する事」 が分析をする上でとても大切となっています。当たり前なのですが、誤った集計方法で集計したデータを分析しても意味がないですし、場合によっては誤った施策を採用してしまう可能性もあります。

しかしながら、SQLを実行して出力した結果が正しいか判断する事はとても難しいです。なので、アナリストチームではチーム内でSQLや実行結果をお互いにＷチェックするようにしています。レビューに至る前に悩んだときは「SQLでこういう事がしたいのですが、どうすれば実現できますか？」と気軽にメンバーに相談できる雰囲気もあります。

また、注意が必要なテーブルや集計に関するナレッジについてはWIKIを作成し集計時の注意点をまとめる事もしています。集計時につまずいたことや、調べて分かったことは積極的にWIKIに残しナレッジDBとして大切に蓄積していくよう、チームとして取り組んでいます。