生成AI時代のエンジニア採用|見直したい評価の観点と採用業務でのAIの使い方
生成AIの普及で、エンジニアに求める経験や選考で確かめる内容はどう変わるのか。採用担当者が要件と選考で見直したい観点と、候補者探しから内定後までの採用業務で生成AIをどう使うか、使うときの注意点を整理しました。
開発の現場で生成AIを使うチームが増え、エンジニアに何を求めるかを見直す企業も出てきています。エンジニアの採用で何を評価すればよいかが、以前より分かりにくくなっています。
採用担当者が採用要件と選考で見直したい観点と、候補者探しから内定後までの採用業務で生成AIを使うときの進め方と注意点を取り上げます。開発の進め方はチームによって大きく異なるため、自社の開発チームと話し合うときの材料として読んでいただければと思います。
生成AIの普及でエンジニアの採用要件はどう見直せばよいか
採用要件、スカウト要件・書類選考要件、面接で見極めることの3段に分けて見直します。採用要件には必要な経験を言葉で書き、スカウト要件・書類選考要件には、その経験をしていると読み取れる条件を置きます。プロフィールや職務経歴書から読み取れないことは、面接で見極めます。

生成AIの効果はチームによって異なります。実装にかかる時間が短くなったチームでは、何を作るべきかを決め、AIが書いたコードが正しいかを判断し、開発の進め方を整える仕事の比重が大きくなっていることがあります。この変化を要件に反映するときは、3段のうち採用要件から見直します。
採用要件には必要な経験を言葉で書く
採用要件を見直すときは、現場のエンジニアに「生成AIを使い始めてから、チームの中で時間の使い方がどう変わったか」を聞くところから始めます。
たとえば必須要件が「〇〇言語での実装経験3年以上」のままになっている場合、聞いてみると、実装の速さはAIの支援で差が縮み、チームに足りないのはレビューと設計の判断だと分かることがあります。「〇〇言語での実装経験3年以上」は、本来はスカウトや書類選考で使う条件です。採用要件には、「AIが書いたコードも含めて、設計の妥当性をレビューで判断し、チームに指摘してきた経験」のように、チームが必要としている経験そのものを書きます。
現場のエンジニアと話すときは、次の3つの観点を手がかりにします。
観点 | 採用要件の書き方の例 |
|---|---|
課題を設計する力 | 事業の課題を、開発で解決できる単位に分解し、仕様に落とし込んできた経験 |
AIの出力を検証する力 | AIが書いたコードや設計の案が、要件を満たしているか、安全か、保守しやすいかを判断してきた経験 |
開発の進め方を整える力 | AIを使った開発の手順や、チームでの使い方のルールを整えてきた経験 |
スカウト要件・書類選考要件には経歴から読み取れる条件を置く
採用要件に書いた経験は、プロフィールや職務経歴書にそのままの言葉で書かれているとは限りません。そこで、採用要件の経験を、年数や担当した範囲など経歴に書かれる事柄に置き換え、スカウトや書類選考の条件にします。スカウトでは媒体のプロフィールで分かる条件を、書類選考では職務経歴書で分かる条件を使います。
採用要件の観点 | スカウト要件・書類選考要件の例 |
|---|---|
課題を設計する力 | 機能の企画や仕様の策定から担当した記載がある、技術選定を担当した記載がある |
AIの出力を検証する力 | コードレビューを担当した期間が1年以上ある、テストや品質を担保する仕組みを整えた記載がある |
開発の進め方を整える力 | 生成AIの開発ツールをチームに導入した記載がある、3名以上のチームで開発の進め方を決める立場にいた |
年数や人数は一例です。どの水準なら採用要件の経験をしていると読み取れるかは、開発チームと相談して設定します。プロフィールで分かることと職務経歴書で分かることの分け方は「エンジニアと採用担当の目線を合わせる方法」で解説しています。
AIを前提にした新しい職種の採用については「AI時代のものづくりの新職種「AI Builder」とは」や「FDEとは|Forward Deployed Engineerの仕事内容と国内3社の求人」でも解説しています。
生成AIを使うエンジニアの面接では何を見極めればよいか
書類では読み取れない、設計の判断の過程と、AIの出力をどう確かめているかを見極めます。
スカウト要件・書類選考要件を満たしていても、その経験の中で本人がどう判断したかまでは分かりません。面接では、採用要件に書いた経験を本人がしてきたかを、過去のプロジェクトでの判断の過程から確認します。
選考の段階 | 確認する人 | 確認すること・聞く質問 |
|---|---|---|
書類 | 採用担当者 | スカウト要件・書類選考要件に置いた条件を満たしているか |
面談・面接 | 現場のエンジニア、エンジニアリングマネージャー | 「なぜその設計にしたのか」「他にどのような選択肢があったか」「業務で生成AIをどう使い、出力をどう確認しているか」 |
技術課題 | 現場のエンジニア | 課題の提出後に、実装の判断を説明してもらう |
コーディングの課題は、AIの支援を受ければ短い時間で完成させることができます。完成したものだけを評価すると、候補者の力を見分けにくくなります。生成AIについては、使ったうえで品質をどう担保しているかに注目します。
技術課題を出す場合は、次の点を候補者に事前に伝えます。
生成AIの利用を認めるかどうか。オンラインの技術面接の最中にAIを使ってよいかも、あわせて伝えます
課題にかかる時間の目安。AIの利用を認めると課題の範囲が大きくなりやすく、負担が大きいと辞退の理由になります
提出後に、実装の判断について説明してもらう時間を設けること
採用業務のどこで生成AIを使えるのか
候補者探し、文面の作成、選考の記録、内定後の連絡など、多くの工程の下書きと整理に使うことができます。
工程 | 生成AIに任せやすい作業 | 人が担う判断 |
|---|---|---|
候補者探し | 経歴と要件の照合、経歴の要約 | 誰に声をかけるか |
スカウト | 候補者ごとの文面の下書き | 送る内容と事実の確認 |
選考 | 面接の記録の要約、評価コメントの整理 | 合否 |
内定後 | 連絡文や案内の下書き | 条件と伝え方 |
表の右側の判断は、どれも採用の結果に直接つながります。まずは人が担う形で始め、AIに任せる範囲を広げるときは、起こりうる誤りを先に洗い出します。取り入れるときは、スカウト文の下書きや面接記録の要約のように、人が確認してから使える工程から始めると、効果と課題を把握しやすくなります。
AIでスカウト文を作るときの考え方は「AIで体験を損なわず、スカウト返信率高めるには」で解説しています。人とAIの役割分担は「これからのHRは、人とAIの配置を設計する」で整理しています。
採用業務でAIを使うときに注意することは何か
評価の偏りの点検、個人情報の取り扱い、AIの出力を結論として扱う範囲の3点を事前に定めます。
評価の偏りを点検する
AIが過去の採用データをもとに候補者を評価すると、過去の採用の偏りを引き継ぐことがあります。AIの評価結果を使う場合は、評価の根拠を確認し、要件と関係のない事柄で判断していないかを点検します。
候補者の情報をAIに入力してよいかを会社として決定する
候補者の経歴や連絡先を扱う業務にAIを使うかどうかは、採用担当者が一人で判断することではなく、会社としての判断です。情報システムや法務の担当者と相談し、業務で使ってよいAIのサービス、入力してよい情報と伏せる情報、候補者に案内しているプライバシーポリシーの範囲に収まるかを決定してから使い始めます。
AIの出力を結論として扱う範囲を決める
AIの出力をどこまで結論として扱うかは、工程ごとに定めておきます。合否や条件のように影響の大きい判断をAIに任せる範囲を広げる場合は、起こりうる誤りを先に洗い出します。そのうえで、少数の候補者で結果を検証してから範囲を広げ、誰がどの判断に責任を持つかも明確にしておきます。AIを業務に組み込むときの考え方は「「AIに任せられる」組織は、どう統治をつくっているか」でも整理しています。
参考になれば嬉しいです。開発チームと一緒に進める採用要件の見直しでお困りの方は、ぜひお問い合わせからお気軽にご連絡ください。
永井涼平
HRdev代表
レバレジーズ、クラウドワークス等を経て2021年にHRdev創業。18年以上エンジニア採用の最前線に立ち、ログラス・MFS・SALESCORE等の支援実績を持つ。
