この記事はGoodpatch Advent Calendar 2023の10日目の投稿になります。
こんにちは、Goodpatchで中途採用のリクルーターをしている 宍戸 です。
エンジニアのリクルーターや、採用の数字集計や可視化を担当しています。
今回は、採用管理システムの応募者データをLooker Studioでダッシュボード化したときに工夫してよかったことをまとめました。 ダッシュボードの作成は1年半前で、その後運用しながら都度アップデートしています。
誰の役に立ちそうな記事か
- 採用の数値をまとめようとしている人
- いつかの自分(備忘録的に)
ダッシュボードを作る際に、採用文脈のテクニックが見当たらなかったため、誰かの役に立てばと思いこの記事をまとめることにしました。
また、同じような事をしている人と繋がれたら嬉しいという気持ちもあります。
会社ごとに独自の事情が多いのでそのまま活用できないネタもあると思いますが、ヒントになれば幸いです。
※Looker Studioの操作方法や、スプシやエクセルの関数の組み方は他の記事に譲ります。
採用管理システムとは
採用活動の情報を管理するサービスで、主にこんな機能があります。
- 求人媒体からの応募者情報の取り込み
- 応募者のステータスや、履歴書情報などの一元管理
- システムからのメール送信
- 求人ごとの応募ページ作成
- 業務ツールとの連携(GoogleカレンダーやZoom,Slackなど)
- 分析機能 など
エクセルやスプレッドシート、Notionなどで応募者管理をすることもできますが、年間4桁の応募者を対応するような場合は採用管理システムを導入することで効率的に採用活動を行うことができます。
※ 分析機能はついてますが、どうしても個別事情が発生してしまうためダッシュボードを作りました
やってよかったこと
もっといいやり方はあると思うので、あくまでも1事例として捉えていただけると嬉しいです。
1.見たい指標の優先度・Whyをすり合わせる
作業に取り掛かる前にチームで
- データまわりで不満に感じていること
- 見たい指標とその理由
- 見たい指標の優先度
などをブレストしました。 調査をしてみて取れない数字があったり、運用回避をする場合の議論ができたので、あらかじめ優先度を決められたことは良かったです。
2.職種、応募経路、ステータスなどの定義テーブルを作る
以下のようなケースに柔軟に対応できるよう、変換用のテーブルを作りました。
- ターゲット別に出している複数の求人に応募した人を、1つの職種として集計したい
- 特定の応募経路をまとめて集計したい
- 特定の応募ステータスをまとめたい(3次選考以降はイレギュラーのため3次選考に統合したい場合など)
3の変換用の列で引用したり、4の他のシートの入力規則として利用しています。 利用する求人媒体や職種が増えたとき、ステータスの解釈が変わったときなどに、簡単に対応ができて便利でした。
3.応募者CSVの変換用シートを作る
応募者CSVをそのままLookerに連携するとほしい数字が取れないので、各項目を独自に変換する列を追加した変換用のシートを作り、そのシートをデータソースとしています。
変換用に作成した列を一部紹介します。
「有効」列
応募とみなしたくない行をカウントしないように(重複応募など)、有効とするかどうかを判定する列を作りました。
Lookerで表を作るときにはこのフラグをフィルタの条件にすれば、意図しない行がカウントされることが防げます。
選考のカウント列
「●次面接」を実施したことをカウントする列を作りました。
応募者CSVには各選考フェーズごとに「●次面接担当者」「●次面接実施日」のカラムがあるので、そこに値が入っているかをカウントすればほしい数字は取れるのですが、以下の理由から個別の列を作成しました。
- シンプルに解釈しやすい表記にする(選考ごと列を用意し0，1でフラグが立っていたほうがわかりやすい)
- 別システムに切り替えたりCSVのフォーマットが変わったときに、この列をメンテするだけでよいため(今のところシステム変更の議論はされていませんが....)
部署列・職種列・応募経路列
以下に対応するため、2のテーブルを使って列を作っています。
- 部署列：複数の職種をまとめて部署単位で集計する際に、Lookerで絞り込むため
- 職種列：ターゲット別や個別の事情があり複数に分けた求人に応募した人を、1つの職種として集計するため
- 応募経路別：特定の応募経路や、表記が揺れているものを統合して集計したいため
選考ステータス列
応募者CSVの選考ステータスと、自社の運用上のステータスにギャップがあったので変換用の列を作り、2のテーブルを使って再定義しました。 以下のようなケースに対応できます。
- CSV上では「未対応」のステータスだが「選考前面談」のステータスにしたい
- 2次選考以降の人は、まとめて「2次選考以降」というステータスにしたい
4.入力規則を統一する(複数シートで採用情報を管理し、それらをデータソースにしたい場合)
これは採用管理システムのデータとは直接関係ありませんが、スカウト活動の記録などの採用に関する情報を、応募データと統合してLookerで可視化したいこともあると思います。
それらの情報を別のスプシ・シートで管理することになると思いますが、そのシートでも2で定義したテーブルの情報(職種や応募経路など)を共通の入力規則にしておくことで、データソースの統合が簡単に行えるようになって便利です。
5.β版で早めに公開してフィードバックをもらう
採用チームに限定して、β版として公開をしてプレ運用をしました。 運用をしてみて初めて分かる「やっぱり違った」「ほしい数字が取れてない」「バグがある」などの問題に対応できたので、最初から全体公開せずに早めに小さく公開して改善ができたことが良かったです。
いっぱい迷惑もかけましたが、信頼してあたたかく見守ってくれた＆運用回避などにも快く対応してくれたチームの仲間に感謝です。
最後に
以上です。
まだまだ課題や改善できることもあるので、運用をしながらアップデートしていきたいと考えています。 以下は、個人的に検討したいなと思っていることです。
CSVの自動取得(手動でCSVをダウンロードしているので、Power Automateなどを使って自動化したい)
集計情報の自動通知(今はSlackで手動で報告しているので、自動で通知できるようにしたい)
BigQueryなどへの移管(行が多くなってきておりそろそろスプシ運用の限界を迎えているような気がする)
他のデータとあわせた分析や予測
この手のことを話すのは大好きなので、同じような人はぜひXのメッセージなどでお気軽にご連絡ください。情報交換したいです。
余談
個人的にデータ分析に興味があり年明けから少し勉強をしていた(スカウトを送信する人を判定するモデルをBERTで構築していました)＆昨今のAIトレンドに乗ってその件を書こうと思ったのですが、久々にコードを動かしたらエラー頻発で解消できず泣く泣く諦めました。
来年には成長して報告できるように頑張りたいと思います。
Goodpatchではデザイン好きなエンジニアの仲間を募集しています。 少しでもご興味を持たれた方は、ぜひ一度カジュアルにお話ししましょう！
