エンジニアと採用担当の目線を合わせる方法｜要件ヒアリングの設計

エンジニア採用の要件を固めようと現場のエンジニアにヒアリングしたのに、終わってみると「結局どんな人を採ればいいのか」が固まらない。エンジニア採用を任されたばかりの採用担当者から、この相談をよく受けます。

理由は能力の差ではありません。準備なしでヒアリングに行き、現場に丸投げしてしまうと、要件は固まらないまま目線だけがずれていきます。

ヒアリング前の準備、質問票による論点の整理、必須要件の工程別の切り分け、そして実在の人を使った基準合わせ。この4つを設計できれば、非エンジニアの採用担当でも要件は固めきれます。すれ違う背景そのものから整理したい場合は、エンジニアと採用担当がすれ違う3つの原因と打ち手もあわせてどうぞ。

なぜエンジニアと採用担当の目線は合わないのか

バックグラウンドとミッションの違いから、すれ違いが起きます。違いを前提に置いて話す場をつくれば、目線は揃えられます。

エンジニアと採用担当は、同じ採用を見ていても立っている場所が違います。エンジニアはコードや技術的な文脈から候補者を見て、採用担当は市場や母集団の状況から見ます。手元にある情報が別なので、すり合わせなしでは要件が噛み合いません。

背負っているミッションも同じではありません。目指す方向は同じでも、質と数、採用にかけるリソースと開発業務のバランスのところで対立が生まれやすくなります。そしてこの対立は、現場では「人事とエンジニアの連携が組めていない」という形で表に出てきます。

質を優先、数を満たす

開発責任者や現場のエンジニアは、事業計画に沿ったプロダクト開発を成功させ、事業成果を上げるために、本当に優秀で自社に合う方に入ってもらいたいと考えています。

これまでエンジニアとしてコードを書き、設計を積み上げてきた文脈があり、そこから来る暗黙のこだわりもあります。この文脈は、採用担当からは見えにくいまま現場側に溜まっていきます。

採用担当も「事業成長のための仲間集め」という大目的は同じです。ただし採用のKPIが人数で置かれていると、目標人数の達成に重心が寄りがちになります。

• エンジニア側: 妥協のない「質の充足」を求める

• 採用担当側: 計画達成のための「数の充足」を求める

どちらも正しいので、順序だけ決めておきます。まず必須要件で質の下限を固定し、そこから必要な母集団の量を逆算します。

母集団を広げる、開発時間を守る

最初から候補者を絞り込むより、まずアプローチする人数を確保したほうが結果は出やすくなります。これは支援に入ってきた現場で共通していました。そのため採用担当は「できるだけ多くの候補者と会ってほしい」と考えます。

一方で、現場のエンジニアがカジュアル面談や面接に時間を取られすぎると、本来の開発業務に割く時間が失われます。人を採用するために肝心の開発が進まなくなる、という逆の結果になりかねません。

• エンジニア側: 面談・面接の件数を、開発業務とのバランスで調整したい

• 採用担当側: 母集団を広げて、会える確率を上げたい

前提として、エンジニアが非協力的なわけではありません。採用への協力は本来の開発業務の合間に差し込まれるので、優先度が構造的に上がりにくいだけです。

広げるのは母集団で、絞るのは面談に乗せる基準です。要件をゆるめて面談の件数だけ増やすと、通過率が落ちて現場の時間が空回りします。

人事とエンジニアの連携しきれていない

エンジニア採用には、総合格闘技のような側面があります。エンジニアリング技術への理解と、採用活動の知見、採用マーケットの観点が同時に必要になるので、人事とエンジニアリング組織が協力しないと成り立ちません。

ただ、両者で取り組めている企業は、自分たちが見てきた範囲ではまだ少ないのが現状です。人事だけが責務を負ってしまう、逆にエンジニア側だけで進めてしまう、あるいはエンジニア側が採用に参加しない。どちらか片方に採用の責務が寄らないよう、役割分担を最初に決めておく必要があります。

また、双方の関与が浅いままだと、採用活動にも影響が出ます。

たとえばFDE（Forward Deployed Engineer、顧客先に入り込み、プロダクト改善まで一貫するエンジニア）の募集です。現場が「コンサルティングの経験とシニアエンジニアの技術力、その両方が必須です」と言い、採用担当がそのまま必須要件に書き写す。当然ながら両方を高い水準で持つ方は市場にほとんどいないので、何ヶ月経っても母集団が溜まりません。

ところが「その両方が入社後にどう必要になるのか」を一段掘ると、別の話が出てきます。お客様に深く踏み込みながら提案や折衝している既存メンバーがいて、そのメンバーと連携しながら柔らかい要件に基づいてプロダクト目線の提案や機能開発を推進することの重要度が高い、といったエピソードがでてきます。求めていたのはエンジニア寄りの方で、コンサルタントとしてのスキルではなく、顧客の業務を理解して何を作るかを判断できる、ビジネス視点を持った開発経験だったわけです。

要件を鵜呑みにせず、なぜその要件を求めているかを自分の言葉で説明できるようになるまでヒアリングできれば、早期に目線は合ってきます。

特に、FDEのように役割の定義がまだ固まっていない職種は、要件が高くなりやすい傾向があります。だからこそ、採用担当が短い時間で要点を引き出せる場を用意することが、すれ違いを減らす現実的な打ち手になります。

ヒアリング前に何を準備すればよいか

他社の求人、候補者リスト、自社データを先に集めます。叩き台があれば、ヒアリングは丸投げでなくレビューに変わります。

要点を引き出せる場は、事前の準備で決まります。手ぶらで現場ヒアリングに行き、「どんな人が欲しいですか」と聞くと、現場はゼロから考えることになり、結局「いい人がいたら」に戻ってしまいます。

支援の現場で繰り返し見てきたのは、叩き台を一枚持って臨むだけで会話の質が変わることです。用意した素材に対して現場が「ここは合っている」「ここは違う」と反応すればよくなるので、目線が揃うまでが早くなります。準備は次の3点です。

求人のリサーチ

なぜ他社の求人を見るかというと、自社だけを見ていても「その職種で市場が当たり前に求める水準」が分からないからです。複数社を並べて共通している項目は、その水準だと考えてよいでしょう。逆に、どの社にもない要件を自社だけが必須にしているなら、それは母集団を狭めている可能性が高い項目です。

あわせて、媒体の担当者に「いま実際に反応が出ている求人」を聞きます。これは特別なルートではなく、媒体を利用していれば誰でも投げられる質問です。

• この職種・このフェーズで、いま返信や応募の反応が良い求人はどれか

• どんな訴求や条件が効いているか

• 自社の求人と比べて、見せ方で差が出ているところはどこか

媒体担当者が精度高く答えられるのは「反応が出ている求人の型・見せ方」です。最終的に決まりやすい要件までは見えていないことも多いので、聞く相手と質問はこの範囲に寄せると、期待と回答がずれません。

候補者のピックアップリスト

求人を見るだけでは、現場が候補者のどこを見ているかまでは分かりません。リストの目的は、要件の文面には出てこない判断軸を引き出すことです。

検索条件は、現行の求人票か、①で見た他社の求人から仮に組み立てれば十分です。この時点で要件が固まっていないのは当然なので、精度は気にしなくて構いません。

媒体を契約していない場合は、取引のあるエージェントに要件に近い匿名の職務経歴を数件出してもらう形でも代用できます。

「この人はどうですか」と一人ずつ聞いていくと、その判断軸が言葉になります。設計まで踏み込んでいるか、事業の規模感が近いか、直近で何に取り組んでいるか。この段階では合否を決める必要はなく、現場がどこに反応するかを掴むのが目的です。年齢や性別など、本人の能力に関係のない属性で切る発言が出たら、そこは判断基準にしません。

抜き出す人選は、要件にぴったりの方だけにしません。少し外れた方を混ぜておくと、どこまでなら許容できるのかが見えます。

素材にするのは、まだ接触していない方です。媒体の規約で候補者情報の持ち出しが制限されていることが多いので、資料に写さず画面のまま扱います。

自社側の事前収集

外を見るのと並行して、自社の情報も集めておきましょう。過去に活躍・定着した人の傾向が分かれば、「理想の人物像」を印象ではなく実績から語れます。自社のこの一次データは、外部のどの求人よりも精度の高い手がかりになります。現場の期待値とメンバー構成も押さえておくと、ヒアリングの場で「自社ならではの条件」を具体的に確認できます。

すり合わせの場と質問票はどう用意すればよいか

短い個別ヒアリングと非同期レビューの組み合わせが基本です。質問票で論点を構造化してから臨みます。

長い対面ミーティングで要件をすべて決めようとすると、議論が発散して結論が出にくくなります。短い個別ヒアリング（30〜60分）で要点を引き出し、そこで作った叩き台を非同期（ドキュメントやSlack）でレビューして固める。この形にすると現場の負担も軽く、進みやすくなります。

時間配分には注意が必要です。スカウト要件や候補者ペルソナまで一度に聞こうとすると60分を超えやすくなります。その場合は回を分けるか、最初から時間を多めに確保しておくのがよいでしょう。

ヒアリングの場では、聞く論点をあらかじめ構造化しておくと取りこぼしが減ります。要件ヒアリング質問票の骨子は次の通りです。これは誰でも使える汎用の型として整理しています。

カテゴリごとに「なぜ聞くか」を意識しておくと、返ってきた答えをそのまま必須・歓迎の線引きに使えます。たとえば「このポジションの存在理由」を聞くのは、そこがあいまいなまま進むと、入社後に何をしてほしいのかが候補者にも現場にも伝わらないからです。

聞き漏らしやすいのがNG要件です。求める条件は語られても、「これに当てはまったら見送る」は言語化されないまま現場の頭の中にあることが多く、スカウトを送ってから初めて発覚してしまうこともあります。そのため、事前に必ず確認することが大切です。

NG要件は現場の思い込みが混じりやすい項目でもあります。例えば「転職3回以上はNG」の理由を聞くと、過去に一度早期離職があっただけ、というケースもあります。理由まで聞いて、根拠が薄いものは外す判断も提案し、機会損失の最小化します。

必須要件はどう分解すればよいか

必須要件には、レジュメで分かるものと会わないと分からないものが混じっています。判断する工程で分けます。

「サーバーサイドの実務3年以上」はレジュメを見れば判断できます。一方「事業の状況を踏まえて技術選定ができる」は、会って話さないと分かりません。求人票やスカウト要件の「必須」欄には、この2つが同居しています。

同じ「必須」として並べておくと、レジュメでは判断できない項目まで書類選考の基準に持ち込むことになります。結果として、会えば通ったはずの方を書類で見送ってしまいます。逆に、レジュメで分かることを面接まで持ち越すと、貴重な面接の時間が確認作業で埋まります。

工程名は自社の選考フローに合わせて読み替えてください。プロフィールの情報量は媒体によって差があるので、スカウトと書類選考の線引きは、実際に使う媒体の項目を見て決めます。

カジュアル面談は、この表に入れません。相互理解の場として案内している以上、合否の判定工程として使うと、候補者への説明と実態が食い違います。

スカウトの段でカルチャーの相性を求めても材料がないので、そこは面接に回す。書類で分かることは書類で判断しきる。この整理だけで、取りこぼしと面接の空回りが両方減ります。

現場から出てきた必須要件を、この3つのどこで見るかに割り振ってみると、どの工程にも置けない項目が残ることがあります。多くは「あったら嬉しい」に近いもので、歓迎要件の候補です。選考では判定できず、入社後にしか分からない項目もここに含まれます。

求人票に書く要件と、選考の判断基準は分ける

ここでもう一段、見落としやすい区別があります。求人票に書く要件と、実際の選考の判断基準（書類選考・スカウト対象の判断）は別物だということです。

求人票は候補者に向けて「こういう人を求めています」と伝えるものです。一方、選考の判断基準は採用担当が「この候補者を次に進めるか」を判断する内部の物差しです。両者を混同すると、運用が噛み合わなくなります。

特に、採用担当が書類選考やスカウト対象を判断するオペレーションでは、本来通すべき候補者を誤って見送ってしまう取りこぼしが起きやすくなります。これを防ぐため、初期設計は次のようにしておくのがおすすめです。

• やや広めの判断基準にしておく（最初から絞りすぎない）

• YES/NOで明確に判断できる基準にする（人によってブレない、デジタルに判定できる形）

• 反応を見ながら徐々に絞り込む

最初から厳しく絞ると、要件設計の精度がまだ低い初期段階で、良い候補者を見送りやすくなります。広めに置いて、データを見ながら調整するほうが安全です。

合意した基準はどう運用・維持すればよいか

実在の人物をOK/NGで判定しながら、現場と採用担当の基準を揃えます。振り返りは定例やSlackで都度おこないます。

準備段階のピックアップリストが現場の判断軸を掴む作業だったのに対して、こちらは合意した基準がずれていないかを確かめる作業です。要件を言葉で合意しても、実際の判断では人によって解釈がずれます。定義をどれだけ詰めても、具体的な人物を前にするとOKラインの感覚は割れるからです。これを揃えるのが、実在の人物をもとに基準を確認する作業です。

やり方はシンプルです。候補者プロフィールや社内メンバーのプロフィールを見ながら、「この人はOK/NG、それはなぜか」を現場と採用担当で一緒に確認します。言葉だけの合意よりも、具体的なプロフィールで「ここがOKライン」と確認したほうが、その後の判断が安定します。

現場のエンジニアを長く拘束する必要はありません。過去に選考が決着した候補者や社内メンバーを数名、30分ほど一緒に見るだけでも、OKラインの感覚は揃っていきます。素材にするのは、すでに選考が終わった候補者か社内メンバーにしましょう。進行中の候補者をこの場でOK/NG判定すると、記録に残らないまま実質の選考判断になってしまうためです。

振り返りは重い場を設けず、流れの中でおこなう

基準の維持のために、独立した重い振り返りの場をわざわざ設ける必要はありません。定例ミーティングの一部として扱うか、Slackでの随時の質問で都度解消するのが現実的です。

運用の中では、基準がずれていることが行動に表れてきます。たとえば書類選考やスカウト返信者の評価が、現場と採用担当で割れたときです。こうした場面には、立て直しの行動を対で用意しておきます。

• 書類評価が現場と採用担当で割れたら、見送り理由をすり合わせ表（必須／歓迎／見送り）に追記し、次回の基準を更新します。

• スカウト返信者の評価がブレたら、判断基準をYES/NO形式で見直し、判断のばらつきを減らします。

評価が割れること自体は問題ではありません。割れたときに「なぜ割れたか」を言語化して基準に反映できれば、基準は使うほど精度が上がっていきます。この物差しが揃っているチームは、選考が進んでも判断がぶれません。自分たちが支援に入るときも、まずこの基準をすり合わせることから着手します。

要件が固まらず迷ったら、集めた情報から持ち帰れる要件の叩き台まで、HRdevが一緒に整理しますので、お気軽にお声がけ下さい。