HRTでチームを改善！エンジニアと採用担当がすれ違う3つの原因と打ち手

こんにちは、HRdevの永井です。

エンジニアと採用担当がすれ違う構造的な原因と、それを仕組みで解消する方法を整理します。HRdevがエンジニア採用を支援する中で、このすれ違いが採用チームを機能不全に追い込むパターンを何度も見てきました。

この記事の打ち手は3つ。すれ違いを「人の問題」ではなく「構造の問題」として捉え直すこと、技術と採用の翻訳者を配置すること、共通言語を設計して自走できるチームを育てること。順に書いていきます。

エンジニアと採用担当の間で何が起きている？

「技術がわからない人に評価されたくない」と「現場が協力してくれない」。双方が抱えるこの認知のズレが、対立の起点になっています。

どちらか一方が悪いわけではありません。それぞれに合理的な不満があり、見ている景色が違うだけです。

よくあるケースとして、面談は現場、母集団形成はHRというような分業をしていることがあります。チームとしての生産性は高まりますが、お互いの領域に適切に関与・共有する仕組みがないと、改善の打ち手が打てなくなることがあります。たとえば「エンジニアは返信率や返信の質に不満があるものの、スカウトは人事の仕事なので口出ししにくい」といった状態です。

これは双方に悪意があるわけではなく、お互いの領分に対してのリスペクトがあるがゆえに、仕組みとしての連携ができていないことに起因するものだと考えています。

すれ違いの根本原因は何か？謙虚・尊敬・信頼の3要素で読み解く

このすれ違いを診断するのに、HRTというフレームワークが役立ちます。

HRTはGoogleのエンジニアだったBrian W. FitzpatrickとBen Collins-Sussmanが著書『Team Geek』で提唱した概念で、チームで働く個人の行動原則としてHumility（謙虚）、Respect（尊敬）、Trust（信頼）の3つを挙げたものです。あらゆる対人問題はこの3つのいずれかが欠けたときに起きる、と整理しています。

エンジニアと採用担当のすれ違いも、この3要素で分解できます。

小さなすれ違いはなぜチームを機能不全にする？

最終的には採用チーム全体が歩みを止めてしまいます。

機能不全はある日突然起きません。段階を踏んで静かに進行していきます。

弱い立場がどちらになるかは状況によります。採用担当が潰れるケースもあれば、エンジニアが「採用には一切関わらない」「エンジニア採用はすべてエンジニアが行う」と極端な意思決定に至ってしまうケースもあります。どちらが先に折れても、採用チームとしての機能は失われます。

技術と採用の「翻訳者」を置くとなぜうまく回る？

精神論ではなく、技術理解と採用ノウハウの両方を持つ人を構造的に配置することが鍵です。

「リスペクトを持ちましょう」は正しいけれど、現場では機能しません。EMは開発に追われ、採用担当はオペレーションに追われている。互いの専門性を理解する時間も余裕もない。だからこそ、翻訳者を「構造として」置く。

翻訳者が担う機能は3つあります。

では、翻訳者を誰が担うと良いでしょうか。

翻訳者がいると、EMは「判断が必要な工程」だけに集中できます。要件定義のヒアリング、技術面接、クロージング。それ以外は翻訳者と採用担当が回す。結果として、EMが採用に使う時間を週数時間に抑えながら、採用の質は維持できます。

社内に翻訳者がいない場合、外部の業務委託・副業・RPOを活用する選択肢もあります。

まずは間に立つ「翻訳者」を立て、回るようになったら次のステップは自律的に機能するチームへ進化することです。

翻訳者がいなくても回るチームはどう作る？

共通言語と判断基準の型をチーム全員が持てば、翻訳者なしでも採用チームは回るようになります。

翻訳者の最終的な役割は、自分がいなくても回る状態を作ること。翻訳と補完を繰り返す中で、エンジニアには採用プロセスの視点が、採用担当には技術判断の土地勘が蓄積されていく。このプロセスは放っておいても起きません。意図的に設計する必要があります。

『Team Geek』にはHRTを仕組みに落とすための具体的なプラクティスが書かれています。コードレビューでは「人ではなくコードを批判する」、障害対応では個人を責めないポストモーテムで振り返る、完成前にドラフトを共有して早期にフィードバックを得る。いずれも「心がけ」ではなく「プロセスの設計」でHRTを担保する考え方です。これを採用チームに転用したのが、以下の3つの打ち手になります。

打ち手1: 週1回15分の「要件すり合わせ定例」を置く

議題は「直近の候補者で迷ったケース」1件だけで十分です。書類選考で判断が割れた候補者を1名ピックアップし、EMと採用担当が「なぜ通すのか/見送るのか」を言語化する。これを4〜5回繰り返すと、暗黙の判断基準が共有され、採用担当の選考精度が上がっていきます。ポイントは結論の一致ではなく、判断の根拠を言葉にすること。『Team Geek』が「早期共有」を推奨するのと同じで、完璧な要件を作ってから共有するのではなく、ドラフト段階で認識を合わせるほうがすれ違いは起きにくい。

打ち手2: 採用プロセスの振り返りを「ポストモーテム型」で仕組み化する

『Team Geek』のポストモーテムと同じで、人ではなくプロセスの精度にフォーカスする。「誰が悪かったか」ではなく「どの工程の判断基準がずれていたか」を議題にする。「この表現だと候補者に伝わらない」は改善提案であり、「なんでこんな判断をしたのか」は人格攻撃です。この区別を仕組みとして守るだけで、振り返りの心理的安全性はまったく変わります。

たとえばスカウト文面であれば、月1回EMが3通だけサンプルレビューし、技術的な表現のズレを指摘する。採用担当はその指摘をテンプレートに反映する。毎回全通チェックする必要はなく、サンプルで型を揃えていくイメージです。採用担当とEMの振り返りサイクルの支援は適切に実施できれば、経験の浅い採用担当でも早ければポジションあたり1ヶ月程度で7〜8割の精度でのキャッチアップが可能です。

打ち手3: 選考基準を「共通言語」として文書化する

「コミュニケーション能力が高い」「技術力がある」のような抽象的な基準ではなく、「設計レビューで代替案を2つ以上提示できる」「未経験の技術スタックでも1ヶ月でキャッチアップした実績がある」のように、行動レベルで定義する。この文書をエンジニアと採用担当が一緒に作ること自体が、互いの判断基準を理解するプロセスになります。共通言語ができると、選考の振り返りも「なんとなく合わなかった」ではなく「この基準を満たしていたか/いなかったか」で会話できるようになる。

3つの打ち手に共通しているのは、対話の回路を構造として作ること。すれ違いの原因が構造にあるなら、解消する手段も構造で設計する。属人的な頑張りや相性に頼らず、仕組みとして回る状態を目指す。

自分たちのチームが今どのステップにいるのかを確認するための問いも置いておきます。

すれ違いは構造の問題だからこそ、構造で直せます。小さな仕組みを1つ入れるだけで、エンジニアと採用担当の関係は変わり始めます。

---