エンジニア採用人数が年間0名→13名になった、「採用できない」を解決する方法
これはエンジニア採用 Advent Calendar 2021 20日目の記事です。
こんにちは！justInCase HRチームのまなてぃです。
私は、今年の3月からjustInCaseのエンジニア採用に関わり始めました。
ちょうど1年前ころに入社を決めた時の、「この会社はエンジニア採用に強くなれる」という確信は、いま振り返っても正しかったと思いますし、まだまだ成長の可能性があります。
この記事では、justInCaseで実際に取り組んできたエンジニア採用の実績と、達成要因となった各施策を例に、エンジニア採用における「採用できない」を解決するにはどうしたらいいかを考えていきましょう。
2021年のエンジニア採用実績
実はjustInCaseは、2020年度はエンジニアの入社が0名でした。しかし、2021年度は、今日時点で正社員13名の採用を達成しました。(内定者を含む)
その内訳はこちらです。
(職種、技術スタック、人数の順に記載)
webフロントエンド(TypeScript, React) 5名
バックエンド(Kotlin, Spring) 6名
ソリューションアーキテクト 1名
QA 1名
また、優秀な業務委託の方々の参画も決まりました。
webフロントエンド(TypeScript, React) 2名
SRE 2名
その他 2名
正社員と業務委託を合計した採用経路の内訳はこちらです。
当初はエンジニアリング組織の技術的発信はまだまだ少なかったので、スカウト媒体を利用しつつも、年度後半にかけては事業の動きと技術的発信が徐々に大きくなり、社員紹介・イベント・自己応募などの直接採用が増えてきました。
採用のために実行したこと
それでは次に、この採用実績を達成できた要因について、触れていきます。
まず初めに行ったことは、組織の現状を知り、それに合った適切な情報発信と採用手法を考えることです。
各職種ごとに見ていきましょう。
(なお、以下の図はエンジニア採用担当として客観的に見た採用難易度についての強み・弱みであり、異なった意見もありうることはご承知おきください)
バックエンド
入社当初、流入自体が最も多かったのはバックエンドエンジニアでした。
Java経験者は他のサーバーサイド言語に比べて多いほうなので、母集団形成自体は割と容易だと思います。
しかしそこから採用したい方に絞ると1割になるかどうか程度だったので、採用基準の言語化をCTOとリードエンジニアと共に行いました。
「う〜ん、微妙...」と感じる理由をとにかくwhy?で深堀りし、採用したい人物像と経験値を明確にすることで、紹介会社からの紹介とスカウトメールの打率がぐんと良くなりました。
また、社内にサーバーサイドKotlin経験者が少なく、転職市場にもKtor経験者はかなり希少であることから、Java(もしくはKotlin以外のJVM言語)+Spring経験者にスコープを広げたところ、経験言語に囚われない大規模システム開発に精通したメンバー複数名を採用することができました。
webフロントエンド
webフロントエンドは、流入獲得にも採用にも、かなり苦戦していました。
導入している技術自体が新しいものなので、実務経験に加えて、自分なりのこだわりを言語化してチームと共有できる程の豊富な経験のある方となかなか出会えずにいました。
webフロントエンドは、主にTypeScript, Reactという、最近はかなりメジャーになってきた技術スタックを使っているため、エンジニアにとっては、初めの接点(=カジュアル面談)を持つかどうか、判断する情報が揃っていることが欠かせません。
元々社内のwebフロントエンドエンジニアが少なかったので、開発業務とのバランスの調整が難しかったものの、徐々にイベント登壇やテックブログへの記事投稿を行っていくことで、採用面談・面接での話がより活性化し、選考に進んでもらえる割合も高くなり、シニアエンジニア(と私たちが定義している)経験値を持つ方々からの応募も増えてきました。
他にも、SREをはじめ他の職種についてもご紹介したいところですが、長くなるのでこの記事では割愛します♡
エンジニアを採用に巻き込んで起きたこと
最後に、上記で挙げたそれぞれの施策は、私の功労ではなく、ほとんどがエンジニアが主体的に取り組んできたものです。
justInCaseでは、今年の夏頃にスクラム採用という採用手法を取り入れました。
これによって、以前からのエンジニアの採用への関わりが、より質が高くなりました。
(スクラム採用の導入をリードしてくれた同じくHRチームの麻賀さんに改めて感謝！)
いくつか、エンジニアを採用にどんどん巻き込んでいった結果起こったことを紹介します。
自社の組織作りに主体的になっていく
面談で自社の良いところ（と課題）を話す日々を送っていると、自社の良いところ（と課題）に敏感になってくるし、面談する前より良いところに思えてきた
— kondei エンジニアアカ (@kondei_dev) November 16, 2021
（実際単調増加で改善しているので良いところになり続けてはいる）
以前から、『コーディングテストを行なう』『面接に参加する』といった採用の一部の関わりはあったものの、スクラム採用を始めて、採用の入り口から出口まで一緒に行うようになりました。
すると、最初はHRチームから依頼したことに対応してくれていたのが、エンジニア自ら、社外に公開している情報の修正や面談のやり方の改善について提案したり、行動してくれるようになりました。
一緒に働くメンバーの採用に能動的に関わっていくことで、『組織で働く』という意識が、『組織を作っていく』という意識に変わっていっているように感じます。
採用のマッチ具合を早めに見極め、ミスマッチを予防できる
アーリーフェーズの小規模なスタートアップ・ベンチャー企業では、良くも悪くもメンバー1人の影響が大きいです。
そのため、できるだけ入社したら関わりが多いメンバー順に会ってもらうことを意識しています。
もちろん、それによって技術力が高い方が選考辞退になってしまうこともありますが、チーム開発でのコミュニケーションの取り方・コーディングのこだわりなどをすり合わせ、おたがいのマッチングを早期から精度高く見極めることができます。
「採用できない」に魔法の技はありません
難易度が高いと言われるエンジニア採用を筆頭に、全ての採用において、魔法のようにすぐ効くやり方は、ありません。
頭を使い、考える！そして、やる！
それしか、答えはありません。
まずは、組織の現状を知り、それに合った適切な情報発信と採用手法を考えることから始まります。
それを抜きに、いわゆる『採用できるtips』だけを行なってみても、採用は失敗します。採用できたとしても、その後にリテンションができません。おそらく早い段階で、辞めていきます。
エンジニア採用がますます激化していく中で、自社に適切な採用の仕方を考え、実行していくことが益々求められていきます。
一体何がその適切な採用の仕方なのか。それを常に探し続け、エンジニアを巻き込んでいくのが、今後エンジニア採用をリードする者に必要だと思います。
以下、FYI
この記事が気に入ったらサポートをしてみませんか？