エンジニアの採用活動の負荷軽減に配慮しながらアジャイル採用(Agile Recruiting)を進行するための工夫
エンジニア採用 Advent Calendar 2022 25日目です。(クリスマス…明けたけど…！)
manateeです。スタートアップでエンジニア採用に関わりはじめて5年になります。2022年は、保険基盤SaaSのjustInCaseTechnologiesおよび未来査定型資金調達プラットフォームのYoiiで主にエンジニア採用に関わりました。
最近Twitterで英語アカウントも開設しましたので、ご興味ある方はフォローお待ちしています。(まだ犬の写真しかあげていません…)
この記事では、採用担当者などの非エンジニアが開発チームを巻き込んでアジャイルな採用活動(Agile Recruiting)を行う場合に、いかに開発チームの負担を軽減しながら行うことができるか、私が実践したことを紹介します。
アジャイル採用の背景と定義
ここ数年のエンジニア採用の傾向は、大きく変わってきているように見えます。
私がエンジニア採用に関わりはじめたのは、2017年ですが、2010年代後半は、まず「Webエンジニアを見つける」こと自体が至難の業でした。
しかし、2020年前後からは、Webエンジニアリング従事者の総数は増えたものの、各社の技術スタックや事業ドメインの多様化が進み、「自社に合うエ人材を見つける」ことが難化してきています。
例えば、2010年代は、多くのベンチャー企業ではRuby on RailsかPHPがメジャーでした。現在は、バックエンドだけでもPHP・Golang・Kotlin・Rustなど様々な言語を使っています。
そんな中、引き手あまたのエンジニアに、タイムリーに自社のことを見つけてもらい、面談に参加し、選考を受け、内定を承諾してもらうためには、エンジニアが必要としている情報をできるだけ豊富に、正しく、早く提供することが重要です。
そこで、昨今はHERPさんが提唱しているスクラム採用や、開発チーム・エンジニア組織内でHRBPやEMが主導での採用活動を実践する企業が増えています。
私は、justInCaseで導入していたスクラム採用の考え方をもとに、現在まさにYoiiで自分なりに編み出したアジャイル開発を実践中です。
アジャイル開発は、欧米で呼称されるAgile Recruitingをそのまま日本語訳したものなので、あまり馴染みがないかもしれません。いわゆるスクラム採用を深掘りしていくと、スクラム採用のフレームワークに則ったプロセスの採用ではなくあくまで概念的なものなので、私はアジャイル採用のほうが本来の意味に合致していると思い、この呼び方を使っています。
アジャイル採用を推奨するケース
私が今年エンジニア採用に主に関わった justInCase および Yoii の両社は広義的にfintechスタートアップで、どちらもアジャイル開発の手法を取っていました。
アジャイル採用は、どのような状況でも最適とは限らず、私は以下のような状況で適用するのが良いと考えています。
CTO・VPoE・EM・テックリードなどにエンジニア採用経験が豊富なメンバーがいない場合
上記のメンバーが開発管理・開発実務などの逼迫により、エンジニア採用に十分なリソースを割けない場合
エンジニア採用専任がおらず、採用担当者が他の職種の採用も兼任している場合
エンジニア採用専任をエンジニア組織に配置した場合に、適切に人事評価ができる人がいない場合
上記のような場合には、開発チーム内で採用活動を運用することが難しく、開発チーム外の採用担当者(多くのケースでは人事)が開発チームと連携して採用をすることになります。
アジャイル採用で想定される問題
アジャイル採用を実践することでメリットは確かにあると信じていますが、その一方でよく発生しやすい問題もあると感じています。
開発チームが採用担当者に期待する採用活動のアウトプットと実際のアウトプットに齟齬が起きてしまう
技術的なアセスメントを開発チームに投げることで、開発自体に割ける工数がどんどん削られてしまう
それぞれの背景と解決方法
開発チームが採用担当者に期待する採用活動のアウトプットと実際のアウトプットに齟齬が起きてしまう
特にシリーズBに到達していないスタートアップでは、全社で1〜2名の採用担当がいることが多いと思います。その場合には、採用担当は複数の部署の採用を兼任するでしょう。
すると、各部署からすれば、採用担当がどの程度自分の部署に工数を割いて採用活動を行なっているか分からず、いっこうに採用が進まない状況に「採用担当はちゃんと仕事をしているんだろうか？いつになったら開発メンバーが増えるのだろうか？」という不信感を抱いてしまうことがあります。
そこで私は、少なくても週に1度、採用に関する情報共有の場を設けました。私は、これを Agile Recruit Meeting と呼んでいます。
justInCaseでは毎週金曜日に30分〜1時間、採用担当・CTO・テックリードが集まる「エンジニア採用定例」を行いました。
Yoiiではまだ開発チームが小規模なので、採用のみの定例ミーティングは設けず、毎週月曜日のスクラムミーティングの冒頭10-15分をもらっています。
この Agile Recruit Meeting で意識することは3つです。
同期的なミーティングにすること
データを事前に用意すること
透明性の高い情報共有をすること
同期的なミーティングを推奨する理由は、部署横断のコミュニケーションでは、具体的なコンテキストの理解度が人によって異なりやすいためです。きれいに言語化しにくい内容や補足説明まで口頭でカバーすることができます。また、関係性が密でない場合には質問や不安がテキストベースで提起されづらいことがあるため、そのようなことを共有してもらいたいと考えています。
また、具体的な数値やデータを事前に用意して話を進めるようにしています。例えば、
「xxさんのテックブログ記事のおかげで応募量が増えました」よりも、「xxさんのテックブログ記事のおかげで、○月よりも□倍くらい応募量が増えました」
「○月は転職活動の停滞時期なので、応募数が落ち込むと思います」よりも、「○月は転職活動の停滞時期なので、通常□□くらいの応募数が△△くらいに落ち込むと思います」
これによって、より明確な理解のもとで、具体的なアクションについて議論することができます。
透明性の高い情報共有は、アジャイル方法論における重要な価値観のひとつでもあります。
候補者の個人情報や年収情報を除いて、なるべく誰でもアクセスできる情報と説明を心がけています。特に人事情報はブラックボックス化しやすいので、積極的に情報開示をしていくことで、各人が採用や組織作りに積極的に関心や当事者意識を持ってほしいと思っています。
例えば、Yoiiでは採用に関する情報をNotionで一元的に管理し、社内の誰でもアクセスできるようにしています。各ポジションの採用判断基準・週次の採用担当者の工数・直近の採用優先度が高いポジションまで明記しています。
技術的なアセスメントを開発チームに投げることで、開発自体に割ける工数がどんどん削られてしまう
防ぎたい例を挙げると、日程調整以外は全てエンジニアに投げてしまうようなケースです。個人差があると思いますが、だいたい1名の応募書類確認に最低でも3~10分、技術テストの結果確認に15~30分、面接準備に15~30分、面接には30~90分、面接後の引き継ぎメモ作成に5~15分程度はかかるでしょう。
そのため、採用担当の役割はエンジニアにしか確認できない部分を定義し、エンジニアになるべく有意義な採用活動の時間を使ってもらうことでもあると思っています。
そこで私が行なっていることを紹介します。
技術面接の面接ログは学びの宝庫！！！命！！！
書類選考の判断基準を言語化してドキュメントにする
カルチャーフィットや条件面での懸念材料がある場合には、事前に確認して目線合わせをする
まず、技術面接(=エンジニアが面接担当者として参加し、ライブコーディングや口頭質問で候補者の技術力を確認する面接)の面接ログは聖書のように読み込むべきです。
技術面接で何を質問しているか、不通過の理由は何だったのかを必ず確認しましょう。できれば、それらを箇条書きのように書き留めて残しておき、情報が溜まってきたら書類選考の判断要素としてドキュメントに残しておくのが良いです。
そして、その内容に分からない用語があったら、自分で調べて次回の書類選考のスクリーニングに役立てます。
しかし、採用基準が明確化していない未成熟な組織では、この採用基準が高すぎるか低すぎるケースがあり、既存メンバーのスキルに依存しやすいので注意しながら採用基準をすり合わせていくことが必要です。
また、技術力以外の点でよく不通過になりやすい理由があれば、面接調整前に確認するのが良いでしょう。例えば、
「これまで面接してきた中で、自社開発経験がない若手メンバーは設計力不足のために不通過になりやすい傾向ですが、それでもこの方と面接しますか？そうしたい理由はなんですか？」
といった具合です。積極的にこのあたりは臆せずに議論しながら、自社なりの採用哲学を形成していきましょう。
現在改良中のこと
さて、上記で主要なアジャイル採用での頻発問題を述べましたが、まだまだ改良の余地はたくさんあります。実現したいことの一例をあげると、
面接の日程調整機能で、開発メンバーの忙しい時間帯や曜日は自動でブロックされてほしい
候補者の方のプロフィールを自動で読み込んで、適切な面談担当メンバーをレコメンドしてほしい
技術面接不通過の理由をATSから自動でスプシに流れ込むようにしたい
などなど…。「こうやったら実現できるよ！」というアイデアをお持ちの方(または実装したい方)からのDMをお待ちしています(笑)。
それでは、メリークリスマス & 良いお年を！