人材獲得競争が激化し続けている、エンジニア採用市場。パーソルキャリア社が発表した2023年1月度の最新職種別有効求人倍率（※）において、 エンジニア（IT・通信）の有効求人倍率は11.17倍 と、全職種の2.34倍に比べて非常に高い倍率となっています。
（※引用：https://doda.jp/guide/kyujin_bairitsu/ ）

難易度の高いエンジニア採用市場において、苦戦を強いられている企業様も多いのではないでしょうか？
特にスタートアップ・ベンチャー企業は、知名度・リソースなど難しい状況の中で、優秀なエンジニアを獲得するための様々な工夫が求められます。

そのような厳しい状況下でも、エンジニアと人事でスクラム採用を行い、優秀なエンジニアの獲得に成功しているのが、現在創業6期目の株式会社ispecさんです。

今回のセミナーでは、CTO山田氏とVPoE石川氏にご登壇いただき、採用オペレーション設計の話やダイレクト・リクルーティング運用時にぶつかった壁、フルリモートワークで面接～入社まで一度も会わずに採用を推進していく上での具体的なアトラクトの工夫などについてお話しいただきました。

登壇者紹介

株式会社ispec / 取締役・CTO / 山田 佑亮
ソフトウェアエンジニア。慶應義塾大学政策・メディア研究科にて機械学習の研究を行い、ACM Multimediaや情報処理学会論文誌で研究が採択される。複数のスタートアップでプロダクトの立ち上げを行った後、ispecにCTOとしてジョイン。複数の開発チームを支える技術基盤の設計・開発や、アジャイルな組織づくりに携わる。

株式会社ispec / 執行役員・VPoE / 石川湧馬
慶應義塾大学在学中にプログラミングと運命的な出会いを果たし、ルールをハックして効率化することが生き甲斐となる。ispecでは、バックエンドの開発やインフラ構築、開発生産性の向上にコミットするプラットフォームエンジニアとして従事。併せて開発実務や組織設計に貢献しながら、「エンジニア採用戦略の航海士」ロールも担当。技術者と人事の苦手と得意を補完しあった体制づくりを推進し、全社を巻き込むスクラム採用をリード中。

株式会社YOUTRUST / HR / 渋谷 篤史
株式会社インテリジェンス（現：パーソルキャリア）にてキャリアカウンセラーを中心とした人材紹介事業の勤務を経て、リブセンスに転職。人材紹介事業の立ち上げや人事としての業務に関わった後に2019年合同会社DMM.comに入社。 DMM.comでは開発組織担当HRBPとして、エンジニア採用を中心として採用・育成・広報業務に携わった後、2022年9月に株式会社YOUTRUSTにHRとして入社し、現職。

LAPRAS 株式会社 / カスタマーサクセスマネージャー / 浦山 也実
専修大学卒。2017年新卒で株式会社ネオキャリアに入社。2年間保育向けの求人サイトの営業やCAを行った後、新卒採用向けのLINEを活用した採用管理ツールのCSMとして従事、その他新卒採用に関わる課題解決を提案。2021年5月にLAPRASに入社。夢は、お客さんと盃を交わすこと。趣味はサッカー観戦とカラオケ。

激化するエンジニア採用市場。全社採用のメリットとは？

渋谷さん：みなさんご存知とは思いますが、現在のエンジニア採用市場は超売り手市場です。エンジニアに限らず、採用全体としても、有効求人倍率が1倍を超える状況が、10年以上は続いています。

出典：厚生労働省

こちらはdodaの「転職求人倍率レポート」から引用した画像です。技術系（IT・通信）職種に至っては、12.09倍にもなっています。
毎年1倍ずつ上がっているんじゃないかというペースで、グングン上がってきている形です。

出典：doda

特定の言語に関しての有効求人倍率では、20倍を超えるものも出てきています。そんな厳しい採用市場で注目されているのが、「全社採用」という取り組みです。

優秀なエンジニアを採用するには、人事やHRといった一部のメンバーだけで採用活動を完結するのではなく、全社員が一丸となって取り組んでいくことが非常に重要になってきています。

エンジニアなど、実際に開発に参加する社員も採用活動に参加することで自社にマッチする人材が採用でき、リーチできる層も増え、社員のエンゲージメントが高まります。

今回は全社採用を実現し、優秀なエンジニアを獲得しているispecさんにお話を伺います。

ispec流「全社採用オペレーション」

山田さん：弊社はホラクラシー組織（役職による区分をなくした、フラットな組織体制）を目指して、サークル（チーム）とロール（役割）を定義しています。ホラクラシーでは、それぞれのロールがどういった役割を持つのかを細かく定義したうえで、ロールに人をアサインしていきます。

山田さん：初期の採用リード（チームリーダーのような役割）は、開発のチームのリードである私が兼務していましたが、開発チームのフルタイムメンバーが10名を超えた頃に「さすがにこのままの体制ではキャパオーバーになる」と判断しました。

そこで体制を見直すため、まず開発チームを複数に分割して各チームにリードを立て、チーム単位でプロダクト開発を完結させられるようにしました。さらに、「今、どんな人が必要か」というのは開発に携わるメンバーでないとわからないので、採用の意思決定権をロール（役割）として切り出し、各チームのリードが採用の意思決定権を持つ”採用オーナー”というロールを兼務する体制に変更しました。

山田さん：しかし、ここでまた別の問題が生じます。開発する案件によって必要なエンジニア像は違うため、「フルタイムの正社員エンジニアがほしい」「特殊要件を満たした副業の方がほしい」と各開発チームからバラバラの要件が上がってきて、採用サークルの運用負荷が大きくなってしまったのです。

そこで一貫性のある戦略を立て、それに沿って要件を決めるアラインメントが重要だと考え、採用リードの私が持っていたアラインメントに関する業務を採用戦略ロールとして新たに役割を切り出し、VPoEの石川に委譲しました。

山田さん：最終的には、ベースになる要件を定義し、ベースをもとに各チームの要件をプラスしていくスキームを石川が構築しました。そのため、現状は次のような権限配置になっています。

山田さん：採用戦略担当である石川が、採用に必要なアクションやスキルにおける指標となるエンジニアラダーを設定し、採用における共通用語となる要件を定義します。これにより採用オーナーは、希望するエンジニア像を提案しやすくなります。

採用オーナーは、採用の意思決定をおこなう権限を持ちます。選考はスコアベースでやっていますが「ここの点数は少し低くてもいいから、ここが飛び抜けて高い人がほしい」などチームによって採用基準は若干変わるため、採用オーナーがメンバーの意見や希望をまとめて細かい要件調整・定義をおこない、最終的な意思決定をします。チームで定義した要件をもとに、採用戦略担当と採用オーナーで相談して採用を進めていきます。

選考の考案者は、採用オーナーからのフィードバックを受けながら選考方法を考案し、改善する役割です。候補者管理と採用広報は、エンジニアのバックグラウンドを持たないメンバーが進める形にしています。

採用に関わる人間が増えれば知見の共有や運用体制の構築などに時間はかかりますが、時間をかける価値はあると考えています。

浦山：開発業務と採用業務のバランスをとるのは難しいと思うのですが、山田さんと石川さんが工夫していることはありますか？

山田さん：面談を特定の曜日だけに設定して開発に集中する日を作るといったタスク管理をおこなっています。あとは候補者管理や採用広報のロールに、適任者をアサインすることもかなり重要ですね。候補者へのホスピタリティが高く、役割に対して主体的に動ける方をアサインできると、採用オーナーのチェック項目が減らせます。
石川も、採用の負担を減らすための仕組みづくりをしてくれています。

石川さん：WantedlyにきたメールをSlackで通知できるようにして、みんなで見られる仕組みをつくってコミュニケーションコストをさげる工夫をしています。また、採用オーナーが開発で多忙なときには私が対応できるように、意思決定できるだけの材料を常に持ち、面談を巻き取るなどの環境づくりもしています。

優秀な人材を惹きつける方法

石川さん：スカウトのスキームはLAPRASさんのLAPRAS SCOUTのシステムをメインで使用しています。共通の要件を作り、各チームで要件を確定し、記事を作ってタレントプールに追加し、反応がきたらメールを送って日程調整していく流れです。各フェーズでエンジニアとHRが共同作業しながら進めていきます。

スカウトメモとスカウト文の作成が分かれているのは、エンジニアの負担を軽減して的確なスカウトをおこなうためです。
候補者を選定するにはエンジニアである採用オーナーのレコメンドが重要ですが、文章作るのは苦手なケースが多いので、スカウト文のベースとなるメモ作成までを採用オーナーが担当し、スカウト文は文章が得意なHRチームが担当します。

選考スキームでは技術、カルチャー、チームと、3段階の選考を設けています。

エンジニアが技術選考をおこない、カルチャーフィット選考はHRが主体となって判断し、チーム選考ではジョインする予定のメンバーも参加してフィーリングや認識の齟齬がないか確認します。関わる人を増やすことで、入社後のミスマッチを防げると考えています。

エンジニアとHRの連携体制を整える

石川さん：以下は、弊社の採用活動において実際に使っている応募者管理のNotionページです。特定のサービスを使わずに自分たちで作成しているので、必要なプロパティやUIも調整でき、フィードバックをすぐ反映できる形になっています。

右側に定量的な技術やカルチャーのスコアを記載しています。一覧表示させることで、想定より技術スコアが低いと感じたら求人記事の内容を見直すなど、リーチしたい層に届けるためのブラッシュアップがしやすい仕組みになっており、採用に関わるメンバー全員が閲覧可能です。

以下の候補者のページには採用に必要な情報が列挙されていて、右側は面談後の所感をメモする仕様になっています。誰が見ても「どういう方で、どういうステータスで、どんな温度感で採用が進んでいるのか」が一目でわかります。

以下は、実際にWantedlyから送ったメッセージのスクリーンショットです。
メッセージ担当のHRが、送る相手の属性だったり、面談後の所感だったりを汲み取って、人柄や姿勢に関するフィードバックをメッセージに組み込んで送っています。候補者の気持ちに寄り添った文章を作成するための工夫です。

以下はスカウト文作成の様子で、エンジニアが書くテンプレート形式のスカウトメモが左です。それをもとに文章のベースをHRが作成し、言い回しや技術的な部分をエンジニアが修正して送信します。フィードバックのやり取りの様子が右側です。

石川さん：スカウトメモではispecにマッチした技術や、やってほしいことなどを明確に言語化する必要があります。スカウト文のベースという役割もありますが、「このテンプレートを埋められないエンジニアはスカウトに値しない」という判断指標にもなるためです。

フレームワークを使用した採用活動の振り返り

石川さん：以前はKPT（Keep・Problem・Try）というフレームワークを使って振り返りをおこなっていました。

石川さん：star fishでは減らしたいこと、やめたいこと、増やしたいことなどを定量的に、より具体的な課題を共有できるので、より良い振り返りができるようになったと感じています。

浦山：エンジニアによるスカウト文作成の言語化がうまくいかない課題に対して、HRが文章を書いてエンジニアがチェックするといった体制構築など、自社の中でPDCAを回せているのは課題をしっかり認知して改善するための振り返りができているからだと感じています。
課題解決を実現する「振り返りの振り返り」とは、具体的にどのような取り組みなのでしょうか？

山田さん：解像度が不足している課題や解決策を認知して、適切なフレームワークを組み合わせて議論を重ねています。フレームワークの特性を活かして、課題を深堀するときはKPT、課題が明確になっていて解決策を探る場合はstar fishを使用する形です。
全員が課題の目線合わせができているところまで持っていくために、毎回の振り返りの中で覚える違和感を解消しています。

全社採用におけるQ&A

Q.開発チームが10名を超えたあたりを目安に開発リードと採用リードを分割したほうが、事業拡大や採用活動においてのボトルネックになりにくいのでしょうか？

山田さん：弊社の場合は順番が逆で、はじめは事業拡大や採用活動を見据えて分割したのではなかったんです。開発リードひとりで10名を超えた開発チームを運用すること自体が難しくなったので、開発チームを案件ごとに分割し、それに伴って採用に関する部分も分けようと意思決定が分岐していきました。

結果として、事業展開や採用活動においても大きな成果に繋がったと感じています。

Q.振り返りには、採用オーナーとHR領域のメンバーだけが参加するのでしょうか？チーム選考に同席したエンジニアも参加しますか？

山田さん：採用オーナーとHR領域のメンバーだけです。同席したエンジニアは面談のフィードバックや選考基準の見直しがメインなので、負担を増やさない目的もあって参加しません。

Q.ispecさんはエンジニアとHRメンバーの相互理解がしっかりできていると感じました。弊社は職種が多いせいか、HRのエンジニア業務への理解が進まず連携がうまく取れていない状況です。HRをエンジニア側に巻き込むための工夫していることはありますか？

石川さん：採用のオーナーシップがエンジニアにあるので、エンジニア側からHRに対して、積極的にサポートをお願いしています。

エンジニアとHR間において、技術に関する知識や要件定義を共通言語として扱えるように勉強会的なものを開くなど、コミュニケーションコストを下げるための施策はいくつかおこなっています。

Q.全社採用で、どこまで巻き込んでいくかのイメージが難しいです。どういった考えで取り組まれていますか？

山田さん：明確に採用メンバーとしてアサインしなくても「自分たちが一緒に働く人は、自分たちで決めよう」という価値観は、ベースとして全社員に持ってもらえるように働きかけるべきだと考えています。

その前提があったうえで採用オーナーである開発リードはしっかり巻き込み、他の開発メンバーに関しては無理に巻き込みすぎないことも重要です。積極的に関わりたい方は歓迎しますが、全社員を同じ温度感で巻き込もうと注力するのはコスパが良くないと思います。

Q.エンジニア採用における、ペルソナの設計方法について教えてください。

山田さん：自分たちだけで考えると知識もあまりないですし、視野も狭くなってしまうので、LAPRASさんやYOUTRUSTさんをはじめとしたさまざまな媒体の方との壁打ちを何回もさせていただいて設定しました。

知識が豊富な方たちにいろいろとフィードバックをいただきながら、ペルソナの解像度をあげていった形です。

Q.フルリモートでまったく会わずに採用するのは、採用する側・候補者側としてもリスクがあるように感じます。双方において入社後のギャップが生じたことはありませんか？

石川さん：入社前も入社後もギャップがないようにスキーム設計しているので、会社側としてはもちろん、入社してもらった方にもイメージ通りと言っていただいています。

オフラインで会ったことがない方がほとんどですが、問題なく業務やコミュニケーションをおこなっています。

Q.採用に関わるメンバーが増えると、給与などの個人情報の扱いが難しくなってくると感じています。どのように気を配っていますか？

山田さん：基本的に情報はかなり制限していて、採用に関するNotionの閲覧制限や、限られたメンバーだけが参加しているSlackチャンネルを開設するなど、会話がオープンにならないように取り扱っています。

病気などの個人情報など、知っていたほうがフォローできる場合もあるため、どこまで共有していくかは絶賛協議中です。

Q.全社採用に通じる部分もあると思うのですが、リファアラル採用においてメンバーの協力を得るために工夫していることはありますか？

山田さん：紹介する際に誰に声をかけたらいいか、どんな行動が必要かなどの情報を整理してドキュメント化し、紹介のハードルを下げる工夫をしています。「いい人がいたら紹介してね」くらいの温度感なので、紹介料の設定などはしていませんが、紹介しやすい流れをつくるための運用フローを明確にすることは大切です。

ただ、それ以上に大切なのは、入ってくれた方に「他の方にも紹介したい」と思ってもらえるようなカルチャーづくりだと考えています。

Q.選考の考案、候補者管理、採用広報を、同じメンバーが兼務している理由は何かあるのでしょうか？

山田さん：候補者管理で「この人は、要件をちゃんと見てない」「この人はカルチャーを理解していないかも」といった情報を拾い、それを採用広報での募集記事の改善にダイレクトに活すなど、一貫して同じメンバーがおこなうメリットは大きいと考えています。

まとめ

役割ごとにやるべきことを明確にしながらも、役割の垣根を越えて連携するホラクラシー組織やスキームを構築し、全社採用を実現しているispecさんのお話を伺いました。

全社採用とは、「全社員を巻き込んで行動を起こさせる」ことではなく、「社員全員が採用を自分ごととして捉える意識を持つこと」だと考えると、取り組むハードルがグッと下がるのではないでしょうか。

当イベントで共有した情報を、貴社のエンジニア採用や採用組織づくりに役立てていただけますと幸いです。

また、今後の開催イベント等につきましては、公式SNSにて情報発信していきますので、よければフォローお願いします。

（ライター：成澤綾子）