エンジニアの採用プロセスについて考える

この記事は個人の意見であり現在から過去の如何なる所属企業を代表するものではありません。またどの企業の採用プロセスでもありません。対象としているのはIT業界のエンジニア採用であり、それ以外の領域の方にとっては参考にならない記事です。この記事は文献と経験から得られた内容をまとめた個人の意見であることを理解した上でご拝読いただければと思います。

Glossary

• JD - Job Description

• HR - Human Resource (人事)

• EM - Engineering Manager

• IC - Individual Contributor

• TC - The Candidate (候補者)

• HC - Head Count (採用目標人数)

はじめに

GREAT BOSS(グレートボス): シリコンバレー式ずけずけ言う力

フェイスブック流 最強の上司

Cracking the Coding Interview, 6th Edition: 189 Programming Questions and Solutions (Cracking the Interview & Career)

最近マネジメントについて考えています。上記のような本をいくつか読み、私なりに採用プロセスがどうあるべきか考えてみました。

そもそもなぜ採用するか？

チームには解決したい問題があり、その問題を解くことができる人材を採用します。優秀な人を採用したいという気持ちはありますが、採用の目的は優秀な人を採用することではなく、チームの問題を解決できる人を採用することにあります。例えば、フロントエンドのスペシャリストをマネージャーとして採用しても（本人がやりたいかどうかはさておき、機能として）機能はしないでしょう。チームの問題を解決する人を雇うためには、適切なJDを書くことが大前提で、そのJDに対応した適切なインタビュー項目を設計する必要があります。

私の場合、JDを書く前にまず2年後の組織図を書きます。チームはミッションによって定義され、それぞれのチームがどんな役割で相互にどのように関係するのかを書きます。もちろん社会はナマモノなので、社会の状態によって会社は変わります。ここでの組織図は完璧になることはあり得ません。あくまで現時点からの理想を反映したものでよく、また状況や組織に対する理解度が深まったときに都度組織図も更新します。そして、半年後、1年後、1年半後の組織図を書きます。こうすることで、いつまでにどのような人材を雇わなければならないか大枠でイメージすることができます。そして作ったペルソナを元に JD を詳細化し、インタビューの設問を設計します。四半期あたりどれくらい採用できるかは会社の規模やブランドによりますが、私は「EM 1人あたり四半期でIC 2名の採用をコミットする」という目安を置いています。
（ちなみに、私は計画通りに採用できたことは今まで一度もないので、私の見積り精度は低いと認識しています。振り返りつつ、見積り精度を高めていく必要があると感じています）

とても良い候補者がいるとJDに記載したレベルに満たなくても採用したくなることがありますが、いくつかの文献で指摘されているとおりこれは間違った考え方です。なぜならJDには必要なレベルを記載しているので、そのレベルの人が雇えないとチームの問題が解決しないからです。レベルを妥協すると他のメンバーがフォローに回ることになり、結果的に優秀なメンバーが離職することになります。一方で、不必要に高いレベルの人材を求めると採用で苦戦するので、JDは慎重に作成する必要があります。

採用フロー

オープンしているポジションの詳細はJDに書かれており、そのポジションは特定のチームに紐づいていることが多いです。一般的な採用フローは以下のようになります。

1. 履歴書スクリーニング

2. コーディング試験

3. ソフトスキル面接 (1~2回)

4. ハードスキル面接 (1~2回)

5. リファレンスチェック

6. オファーレター

もちろん、一括採用の会社もありますし、面接の回数は会社によります。リファレンスチェックを行なっていない会社も多くあります。私は何回か転職していますが、日本企業では面接は3回のところが多い印象です。一方で欧米の企業では4回から7回くらいある印象です。

採用の各ステップは以下の役割を持っていると私は考えています。

足切り