Recruiting Opsをやっていく 2

# はじめに
前回の「Recruiting Opsをやっていく(無印)」は[こちら](https://qiita.com/Changkengo/items/4b35e0526c01f9c7a785)です

## 自己紹介
- 株式会社エクサウィザーズで採用部を担当しています
- マーケティング/PRがバックグラウンドで、現在は採用人事をメインにしています
- 技術者だったことはありません (予防線)

# 課題(再掲)
前述の記事を見て頂いていたら読み飛ばしても大丈夫です。
また、後述の内容は↑の記事を見ていなくてもわかるように書いています。

##### 1.採用は自動化されていないオペレーションだらけ
オペレーションの重要性が高い一方で、よりよい活動のためには個別化(パーソナライズ)が必須という状況。モチベーションとしては適切なオペレーションの自動化を通して、個別化を限界までしたいわけです。

##### 2.エクサウィザーズは採用目標人数に対して採用チームが小さく、効率化 or Die
※数字の更新がめんどくさかったので前回記事の内容をそのまま引用してますが、今も大体同じ感じです。

年間100人以上の採用目標があって、2020年4月〜2021年3月の1年間で5,948件の応募がありました。2020年度の営業日は246日だそうなので、24.2件/日の応募があったことになります。この応募数に対して、約4名のリクルーターと、2名弱のバックオフィスで対応しています。

しかしチームは肥大化させたくないのです。これは経営のわがままとかではなく、チームが大きく組織に対して金銭的コスト・コミュニケーションコストが高い状態は普通に考えてネガティブという話です。

##### 3.適切なビジネスインサイトを取り出せる分析の基盤/ツールが無い
以上を考えるとコックピット的な、複数のレーダーが一覧できるダッシュボードのような存在が必要になるわけです。が、そんなものはない。

##### 4.ゆえに属人化を生み、スケーラブルではない構造に陥りかけている
当たり前ですね。我々はもっと採用活動を可視化し、センシングし、改善し、標準化していくという当たり前のことを、当たり前にする必要があります。主語が大きくなったので今回は「可視化とセンシング」にフォーカスを絞ります。

# 「やっていく 2」になった
今回は下記の話をします。
![採用モニタリングの設計.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/242023/84ccbfef-68cd-8bf0-7612-a962c1d78ef7.jpeg)

ざっくり言うと**Talentioにデータを蓄積→日次でGAS経由でAPI呼び出し→BIツールに接続→モニタリング・インサイトの抽出**を行っています。
BIは採用部が管理する応募者情報全体にアクセスできるものと、Hiring Manager・面接官が担当求人の応募状況を確認できるものがそれぞれ用意されています。(データソースは同一)
手作業が避けられない領域もあるので、それはそれでシートを切り分けて使用してます。

「やっていく」→「やっていく2」になった背景は下記のためです。レベルアップしました。
1. 処理がシステムで完結して、モニタリングの仕組み自体が安定した
1. BIツールへの接続ができるようになってインサイトの抽出が習慣化した
1. 生成AIで採用担当もプログラミングが一部できるようになった 

# 何をモニタリングしてるのか
### 採用目標全体のスケジュールと予実
人員計画、採用目標、入社決定数、採用ヨミの４つを主に月次でトラックし、乖離を算出しています。
採用ヨミは求人ごとの選考通過率から逆算されて定量化されている指標です。
例えば内定承諾が50%、最終面接通過が50%、1次面接通過が50%だとしたら、1次以降の通過率は12.5% = 1次面接の応募者が一人いた場合、ヨミを0.125と捉えます。これは1次面接に8名の応募者がいれば0.125 x 8 =1名は決まる計算になると言う意味です。実績がない場合は平均値を用います。
また、求人ごと応募〜内定までの日数も計測されており、得られた採用ヨミ数値を何月に置くか、を決定しています。
これらを統合して、その月ごとの乖離を「採用目標 - (入社決定数 + 採用ヨミ)」で算出します。
このようにいわゆる予実を求人ごとに管理することにより、どのポジションの採用が順調で、どこが不調なのかが定量的に判断できるため、早い段階でデジタルに介入が可能になります。

※いろんなバックグラウンドの方が読んでいる記事だと思いますので補足します。 **これはあくまで採用担当が組織経営の観点で採用活動を定量的に把握するための擬似的な指標であり、応募頂いた方を数字や確率で捉えている訳ではありません。** みなさんにそれぞれの人生があり、大きな意思決定の最中にいることを理解しています。

### 求人(職種)×チャネルごとの応募数、通過率
(チャネルは例えば求人媒体、エージェント企業さん経由の紹介、当社によるスカウトなどなど応募者の方の流入経路を指します)

![採用部ヨミ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/242023/e699652f-7a26-b221-0d23-0583c315d754.png)

求人単位、職種単位、組織単位で確認ができるようにしています。(職種と組織は求人と紐づいています)
通過率に問題がある場合は課題が明らかなので読者の方にとって補足はいらないかもしれませんが、
不合格が多いのか辞退が多いのかによっても問題の性質が異なったり、面接の準備をしてもらわないといけない面接になっているのか、その場合、面接の準備してもらえるフェーズにあるのか(1次面接から重たい宿題をお願いするかどうかなど)、などなど課題は複数考えられるので注意しないといけません。

応募数に問題がある方がより急務で解決すべき問題です。そもそも応募がなければ採用できないので...。

##### 応募数
これはここから課題を発見すると言うより、施策の効果測定に用います。
想定していたチャネルから応募があったかどうか、仮説通り増えているかを注意深く確認します。
また、応募があったときも思惑通りのチャネル以外から増えているのは、単なる幸運であって再現性がないので、それはそれで確認をします。

##### 通過率
これは応募が得られた場合に、ボトルネックは発生していないかを確認するために用います。
通常どの経由で応募頂いたのかによって通過率が異なります。
正確に言うと直接応募、エージェントさん経由、の粒度では荒く、通常は、どこの媒体経由なのか、どこの会社のどの担当のエージェントさんなのかで傾向が違います。
具体的なシチュエーションを考えます。エージェントさんの紹介で応募してくれている場合は面接の通過率が高いが、自主応募の場合は通過率が相対的に低い、と言ったことが起きた場合、例えば必要なレベルを超えて面接のために準備が必要になってしまっていて、サポートしてくれるコミットメントの高いエージェントさんがいるなら大丈夫だが、そうでないと不合格になりやすいとか、数値から十分に仮説が立ってきます。

### 応募数のトレンドライン
![採用部ヨミ-›-Agt応募-内定状況.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/242023/e4273aea-ff88-75ac-34d4-55ce727d8301.png)
単純な応募数だけでなく、これまでと比較してどうかも確認します。恒常的に応募が得られる状態にある時の方が少ないですよね。
応募数のトレンドが変化していないか週次でトラッキングしていきます。いつの間にか増えている、減っているという状況を、せめて解釈ができていると言う状態でもいいので、とにかく減らします。
**応募数のダウントレンドは意外にも気付きづらいものです。** 経験則ですがモニタリングしてないと、応募がゼロでない限り、目の前の応募者の方の面接やコミュニケーションに気が向いて、気付いた時にはダウントレンドになってから3-4週目と言うのはよくあります。

### 上記を統合して週次で議論、先週以前のアクションの追跡
マジ当たり前すぎる話なのですが、数字を眺めて終わってはならないので、アクションに落とします。
月曜にリクルーターのミーティングを設定して、金曜に集計データをもとに確認事項を洗い出し、月曜に不調のポジションを中心にボトルネックの解消に向けて議論をします。

### これATSのモニタリングツールでよくない？
まあ...ダメじゃないんですが、特に採用ヨミの管理、「何月に何人入りそうか？」と言うシンプルな問いに回答しづらいと思ってます。
この管理の肝心なところは、採用ヨミ以外にも、意外と求人ごとの対応表が用意されていて、それに合わせて(ATSのデータ構造や規定に影響されず)柔軟に観測ができるところにあると言えるかもしれません。タグ管理に近いです。

日常的には求人ごとの区分管理にやや足を取られますが、この辺りはSlackの通知を併用して抜け漏れを回避するようにしています。
一度整理してしまえば「ここのポジション/ポジション群は応募は順調か？」「エージェントさんから紹介はもらえてるか？」の確認は発生せず、自分でBIを開いたら通過率含めて実数で確認できる...と言う点が強力なのです。

# 細かい話

上記の実現にあたり、やっていく(無印)からの大きな変更点がいくつかあります。
1. 採用管理システム(ATS)を変更しました。
1. 採用チームにエンジニアが参画しました。
1. ChatGPTが登場し、プログラムを代筆してもらうことができようになりました。

### 採用管理システム(ATS)を変更しました。
前回の記事でも触れていますが、元々はHRMOSを利用していました。
3年ほど利用してきて、もちろんATSとしては大きな不便がなかったのですが、APIが存在しないためにOpsを行う上で、Seleniumを挟まなければならないためHTML構造の変更に弱かった背景があります。
そのため、2022年10月当時、APIの提供が恐らく唯一されていたTalentioへ移管しました。

### 採用チームにエンジニアが参画しました。
時系列で言うとATSの変更より先に参画してくれていて、この出来事により主に下記が可能になりました。
##### エンジニアリングリソースの確保
(当たり前すぎますが一応...)
やっていく(無印)では採用担当であった自分がなんとかやっていくという体制で、対応できない範囲も多々あったのですが、微修正から新規の開発まで、早く、広く対応できる体制が整いました。
##### 運用を意識したクラウド化、ドキュメンテーション、管理
それまでは自分のローカル環境で計算→計算結果をチャットにプッシュする、と言う範囲に留まっており、イベント対応などで処理を走らせる時間にPCを閉じてると処理が自動でできないと言う課題を抱えていました。
エンジニアの方が参画してくれたことにより、前述の通り処理は全てGASに移管し、処理がスケジュールされるようになり、システムのドキュメントが用意され、管理状況が明らかにレベルアップしました。

上記の2点はエンジニアの方からすると当たり前だろうと思われるかもしれませんが、ソフトウェア開発のチームでない採用部にとっては手が及んでいない点であったのです。

### ChatGPTが登場し、プログラムを代筆してもらうことができようになりました。
GPTのパワーで日本語(自然言語)による指示で、GASのプログラムが書けるようになりました。
特にかっこいいプロンプトエンジニアリングはしていません...。

無骨に、列名を与えて[^1]、列Aに対して列Bのデータを参照して、こういう条件だったらデータを返して欲しいとか、JSON形式のデータ構造がこうなってて、ここのデータが取得したいんだけどどうすればいいかとか、なんとなく入力すれば足がかりになるものは得られるので、そこからちょっと修正して実用に持っていってます。主にGPT-4を利用しています。[^2]
これにより、採用チームのエンジニアの方が開発→リクルーターで修正・保守が可能になりました。
既にいろんなところで語り尽くされていると思いますが、非エンジニアの自分にとっては自然言語からプログラムが得られる変換器として生成AIのパワーをとんでもなく感じています！
もちろん複雑化、高度化していく/いこうとするとGPTだけでは足りなくなりそうですので、その辺りは採用チームのエンジニアの方と連携していくつもりです。

# 何ができたらやっていく3になるのか
これだ！というものはまだイメージしきれていないですが、
##### 生成AIでなんかできそう
雰囲気ですみませんがなんとなくありそうと思ってます。
##### インサイト・アラートの定式化
現状は数値を読んでインサイトを取り出すということをしているのですが、前回も触れた通り数値を読む能力に依存もしているので、特定のシチュエーションにおける仮説リストのようなものが得られる仕組みにできるとより安定しそうです。
##### タレントプールの高度化
過去に応募いただいたり、イベントに参加いただくなど接点があった方とのコミュニケーションはまだまだやりようがあると考えています。基本的には1-to-1でコミュニケーションしたいのですが、真正面からやると採用担当が何人いても足りません。特にゆるい繋がり、情報提供のような関わりは未開だと思っています。

### お知らせ
面白そうと思ったら連絡ください。[採用担当を募集しています](https://open.talentio.com/r/1/c/exwzd/pages/70301)。
※求人は新卒採用担当なのですが中途採用担当もまもなく募集します

[^1]: インプットすべきでないものは***とか適当な文字列に変換します
[^2]: ExaWizardsでは自社で生成AIのサービスを提供しており、そのおかげで社内メンバーは全員利用できる環境があります。ありがたい