このたび、LAPRAS SCOUTはワークフローの思想を取り入れた機能をリリースすることになりました。その背景を説明するとともに、人事とエンジニアがどのようにコラボレーションして採用活動に取り組むと良いのか、その考え方をご紹介します。
目次
なぜLAPRAS SCOUTではチーム採用を推奨しているのか
LAPRAS SCOUTはスカウトもチームで行うことを推奨しています。その背景としては以下のような状況があります。
- スカウトに必要なスキルを全て持っている人材が少ない
- 必要なスキルがトレーニングによってもすぐに身につかない
- 採用全体のプロセスが長くなり、候補者とのコミュニケーションの量が必要になっている
LAPRAS SCOUTはオープンデータから148万人以上の候補者データベースを構築しており、転職サイトへ登録しない層をはじめ、多種多様な人材にアプローチすることが可能です。また、実際のアウトプット（記事やリポジトリ）を元にアプローチできるので、アプローチ時点からミスマッチを減らすことができるのが大きなメリットです。
その反面、使いこなすために必要なスキルが幅広く、運用が難しいという声をいただくことがあります。エンジニアのアウトプットを理解するにはエンジニアリングの知識や経験が必要ですが、さらに採用に繋げるとなると以下のような人事・採用のスキルも必要です。
- 採用候補者に刺さる発信を行うマーケティング力
- 選考プロセスやCandidate Experienceを設計するプロセス構築力
- 社内外の関係者を調整する調整能力
LAPRAS SCOUTを利用してスキル、カルチャーがマッチした人材を探して適切に口説くためには、採用の専門家とエンジニア両方のスキルが必要になります。一人で使いこなそうとすると、「エンジニアの仕事やキャリアパスを知っており、採用担当としてのスキルがある」人物が必要ですが、現実的に両立できる人は珍しいと言えるでしょう。
米国などではエンジニア経験者をビジネスサイドに配属することもあるようですが、日本ではエンジニア人材は受託開発会社などに集中しており、ビジネスや管理部門の人材とエンジニアには距離があります。
そういった背景もあり、LAPRAS SCOUTではスカウト業務をチームで運用することを推奨しています。
エンジニア採用の難しさ
Webエンジニアを始め、ITエンジニアの求人倍率は10倍以上との調査結果も出ており、ニーズの多い職種や優秀な人材にとっては完全に売り手市場です。単に需給のバランスだけからでも、採用が難しくなっていることがわかります。
また、マッチしない人材を採用してしまった場合は、離職リスクが上がり、採用やオンボーディングに伴うコストを無駄にすることになります。さらに、WebサービスをはじめとしたIT産業では、不確実な状況下で少人数でスケールするものづくりを行なっていかなければならないことが多々あります。そのような中にパフォーマンスを発揮できないメンバーを抱えることがチーム全体の生産性を下げてしまうという側面もあるため、チームとカルチャーやスキルレベルにマッチした人材を獲得することが非常に重要です。こうした複雑な条件が、採用の難しさにさらに拍車をかけています。
スカウトを行うための2つのステップ
1.事前準備
探したいポジションの要件がある程度出揃ったら、スカウト作業に入る前の準備を行います。この段階で、候補者からのレスポンスに基づくフィードバックループを回すプロセスを構築することが重要です。
以前から存在する登録型の採用サービスを使う場合は、は以下のような手順になることが多いでしょう。
サービスに登録→（募集要項を作成）→メールテンプレートをセット→候補者をサーチ→スカウトを送信
募集要項は広めの条件・最低限の条件で作成されており、「Webサービスの開発経験」「年収400〜800万」などの記載をよく見かけます。応募の間口を広げるという意味では良いのですが、これをもとにスカウトしようとするとスカウトが一斉送信できるということも相まって「なんとなくいい人」にとりあえずスカウトを送信してしまう、といったことはないでしょうか？
それに対し、LAPRAS SCOUTの手順は以下のようになります。
サービスに登録→採用ストーリー作成→メールテンプレートをセット→候補者をサーチ→アプローチ判断→興味通知送信→スカウトメモ作成→スカウト送信
LAPRAS SCOUT ではマッチした候補者にピンポイントでアプローチするため、スカウトに入る前の下準備として、人物像を明瞭化し「採用ストーリー」を作成することを強く推奨しています。
採用ストーリーは、いわば「採用における仮説」で、採用チームの認識を合わせ、候補者へリアルなイメージが伝えられるようにするために作るものです。
企業は「自分たちの状況」や、その人が要件にマッチしている理由を並べがちですが、「なぜその人が貴社に入ろうと思うのか、なぜ活躍できるのか？」という部分まで含めてストーリーを作ることが必要です。これらがしっかり整理できていることで、スカウトにおいてもその後においても判断軸、候補者をアトラクトするために伝えることが明確になります。採用ストーリーをチームで共有すると「想定と何が違ったのか？」が明確になり、面談や選考といった後続のプロセスから、候補者のサーチやスカウトといった手前のプロセスへのフィードバックのループが動くようになります。「なんとなく経歴が綺麗ないい人が欲しい」という要望は、採用要件が不明瞭な上にストーリもないので、何も言っていないのと同じです。
採用ストーリーは以下のようなポイントで整理するのがよいでしょう。
- そのポジションの募集の背景
- ビジネス的な背景
- 採用によって解決したい、チームや技術上の課題
- 課題解決のために求める人物像
- 候補者が入社する動機（貴社のアピールポイント）
採用ストーリーが大まかに決まったら、ストーリーに基づいて候補者との接点を設計していきます。
- 詳細な採用要件を作成する
- 採用要件に基づき、募集要項や求人票などを作成する
- Candidate Experienceを意識しながら採用プロセス全体を設計する
ここまでを整理してから業務に入ります。
詰めきれない部分もあるかもしれませんが、なるべく具体化していきましょう。
ある程度まとまったら実際にこれらを使って採用活動を実施し、候補者からのレスポンスなどを見ながら修正をかけていくようにします。
2.スカウトのプロセス
採用ストーリーをある程度固めたら、候補者へのアプローチを始めましょう。
スカウト送信までのステップは以下の通りです。
- 候補者のリストアップ
- アプローチ判断
- 追加コメント作成
- ファーストアプローチ
■ 候補者のリストアップ（推奨する担当者：人事）
後続のアプローチ判断と一緒に「ソーシング」「サーチ」などと呼ばれることの多いステップです。
「採用したい人物像に合致しそうな人」を粗く絞り込み、タレントプールに追加していくステップです。このステップでは広めの条件でサーチした候補者の中から、以下の観点を確認してタレントプールに追加していきます。
- スキルの方向性が合致していそう
- スキルが求めているレベルに達していそう
- 明らかに対象外となりそうな要素がなさそう
どのようにアプローチするかなどは後のプロセスで考えるので、あまり悩まずに進めましょう。作成した採用ストーリーに当てはまる可能性のある候補者をできるだけ拾い上げることが重要です。
このステップでは、基本的なエンジニアリング知識と一定の基準を決めて素早く意思決定していくスキルが必要です。
■ アプローチ判断（推奨する担当者：エンジニア）
リストアップした候補者にアプローチするかどうかを決めるステップです。
実際にアプローチするかどうかは、以下の観点を考慮して決定します。
- 想定しているポジションにスキルマッチしている見込みがあるか
- 現在声を掛けない方が良さそうな理由がないか
- 採用ストーリーが描けるか（興味を持ってもらえる可能性が少しはありそうか）
このステップではある程度詳細に技術的なアウトプットを見て判断する必要があるため、担当者にはエンジニアリングの知識が要求されます。さらに、エンジニアリング知識に加えて、「採用ストーリーが描けるか」といったことを考慮するための人事的な視点も多少は必要になります。
求めるポジションに必要な資質によって、技術記事、スライド、コードなど、見るアウトプットの優先順位を変えましょう。
あくまでオープンになっているアウトプットが中心ですので、書類選考ほど厳密に考える必要はありません。想定しているポジションで的外れな人ではないことを確認するに留めましょう。
この段階で「今は声を掛けない」と決めた人は、「ストック」のステータスを付与してタレントプールに保管し、声かけに適したタイミングを待ちましょう。
■ 追加コメント作成（推奨する担当者：エンジニア）
その候補者にアプローチすることを決めたら、どのように口説いていくかの材料出しをします。興味通知を送信できる場合は、追加コメントの作成を待たずに興味通知を送信しておきましょう。
LAPRAS SCOUTは他の採用媒体と異なり、候補者によって入力されたプロフィールではなくその人の実際の活動を見ることができるため、個々人に合わせて企業との出会いのストーリーを作ることが可能です。
スカウトでは個々人に合わせて、以下の内容を盛り込みます。
- 興味を持ってもらうきっかけ（共通の話題）
- なぜあなたなのか（あなたにとってこの誘いはどうマッチしているのか、その根拠は何か）
- なぜあなたは話を聞くべきなのか
ストーリーの大枠が決まったら、上記を文章で伝えられるように、わかりやすくまとめましょう。盛り込む内容は必ずしも技術的な内容である必要はなく、事業領域への興味や経験であったり、カルチャー的な親和性でも良いでしょう。
以下はLAPRAS SCOUTで提供しているメモのフォーマットの例です。
———————————————————————————
■ 会いたい度
是非会って口説きたい/ 先方が興味あれば会いたい/ 時期が悪い・良い人だがポジションがない/ うちとは合わない
■ 一番良いと思ったアウトプットまたは目に留まったポイント(冒頭で触れる)
媒体: GitHub/ Qiita/ ブログ/ SpeakerDeck/ Twitter/ Wantedly/ イベント記事orリポジトリ名:
■ その人をスカウトする理由
// 課題型（あなたが我々の課題を解決してくれそうだから）
ex.)Qiitaの記事「●●」を見ると●●にとても詳しそう。●●の解決に向け、●●な役割で活躍してもらえそう。
// 親和型（あなたの興味と我々のやっていることが近そうだから/やりたいと言っていることができるから）
ex.)●●(LAPRASの「やりたいこと」)に、●●という記載。うちの●●に興味を持ってもらえそう。
■ その他コメント(過去に接点があるか、エンジニア目線で訴求すると響きそうなポイントなど)
———————————————————————————
■ ファーストアプローチ（推奨する担当者：人事）
スカウト、興味通等候補者に対する「最初のアプローチ」のことを指します。候補者と「初めまして」の接触になる可能性が高いため、第一印象をポジティブなものにできるよう工夫します。
LAPRAS SCOUTでの候補者へのアプローチのステップは2種類あります。
うまく使い分けることで、候補者にとって受け入れやすいタイミングで貴社のコンタクトを受けることができます。
①興味通知を送信→リアクションに応じてスカウトを送信
先に興味通知を送り、「興味あり」をもらった人に優先的に声をかけていく方法です。
BtoCサービスで知名度のある会社や、情報発信が多く採用ブランディングに力を入れている会社などは興味通知の運用で効果を出しやすい傾向にあります。
興味通知やスカウトに反応をもらいやすい分、ポジションや社風に合わない人が面談につながってしまうケースが多いので、面談や選考からのフィードバックを考慮してよりマッチした人に興味通知を送れるように改善を繰り返ししましょう。
②直接スカウトを送信
LAPRASのユーザーではない人や、興味通知にリアクションがない人には直接スカウトを送ります。BtoBやニッチな会社、情報発信がまだ多くない会社に関しては、スカウトで丁寧に貴社について伝えることで良い反応を得やすいです。
興味通知が送れる場合でも、特に転職活動中の人はすぐに転職先が決まってしまうケースが多いので、興味通知を併用しつつ、早めにスカウトを送ると良いでしょう。
最後にスカウト文面を仕上げます。
窺い知れる範囲で構わないので、個々人の状況や企業との距離感を考慮したコミュニケーションを心がけましょう。転職活動中の人、特に転職を考えていない人、貴社についてどれくらい知っていそうかなどを考慮して文面に盛り込む情報を選別していきましょう。
長すぎると読みづらくなるため注意が必要です。しかし、BtoBなどでニッチなビジネスを行っている場合は一言で説明されてもイメージが湧かないケースが多いので、資料などを使って十分な情報提供を行うことも必要です。文字数は多くなりすぎないように注意する必要がありますが、それ以上に文章の流れや構成を工夫して読みやすいメールを心がけましょう。
また、事業の説明に終始してしまうと、エンジニアにとっては、もしご縁があったらどのような仕事になるのか、エンジニアとして成長できる環境はあるのかなどのイメージが湧かず、返信に踏み切れないケースもあります。技術面の情報もある程度開示することをお勧めします。
以下の記事の情報などが参考になるでしょう。
LAPRAS CTOが目指しているエンジニア組織
LAPRASを支える約20個の技術
このステップでは、相手に合わせて要点を伝える文章力が必要になります。文章を書くことに抵抗がなく、対外コミュニケーションに慣れている人が適任です。スカウトを送付した後は、カジュアル面談につなげるための対応力や、カジュアル面談で候補者の意向を引き出し、貴社の魅力をうまく伝えるスキルが必要になります。
面談の進め方は以下の記事を参考にしてください。
「参加者の95％が転職意欲あり！？カジュアル面談に対する候補者のホントの気持ち【アンケート結果公開】」
「LAPRAS式カジュアル面談のやり方（前編）」
「LAPRAS式カジュアル面談のやり方（後編）」
おわりに
以上のように、
- 候補者のリストアップ（人事）
- アプローチ判断（エンジニア）
- 追加コメント作成（エンジニア）
- ファーストアプローチ（人事）
のステップで分業すると、エンジニアと人事の両方が得意な領域に集中できるようになります。
しかしどこかのステップで詰まってしまったり下準備が不十分だと、一気に効率が下がり、以下のようなことが起こり始めます。
- エンジニアが忙しくなってしまい、依頼したレビューがなかなか上がってこない
- 候補者から良いレスポンスをもらえたのに返信に時間がかかる
- スカウトに何を書くのか見当がつかず、メモの内容が薄い
- 候補者が選考を希望しているにも関わらず、要件になかったはずの理由で落とされる
- スカウトへの返信や面談からのフィードバックが前工程に反映されず、改善されない
- スカウト文面と実際の面談の体験が乖離して、候補者に不信感を与える
LAPRAS SCOUTの管理者は「採用プロジェクトマネージャー」として、定期的に全体の状況を見直して、詰まっているステップがないか確認したり、スムーズに進むように各担当者に改善を促しましょう。
ダイレクトリクルーティングのノウハウを網羅したebookを公開中
ダイレクトリクルーティングをこれから始める方向けに、ダイレクトリクルーティングのノウハウを詰め込んだebookを公開しています。
ITエンジニア採用に特化して、他施策と比べたメリット／デメリットや具体的なノウハウ、ダイレクトリクルーティングが注目される背景をデータを交えて解説しています。
＜コンテンツ一例＞
・ダイレクトリクルーティングが注目される社会的背景
・他の施策と比べた「ダイレクトリクルーティングを導入するべき理由」
・理想の運用体制とは
・具体的なノウハウを解説
・ダイレクトリクルーティングのアンチパターン
etc.
