「経験のあるエンジニアを募集しても、そもそも応募が集まらない」「採れたとしても採用単価が跳ね上がったり、内定を出しても他社に流れたりしてしまう」。エンジニア採用に関わる現場では、このような壁にぶつかったことがあるのではないでしょうか。
その解決策として注目を集めているのが、「ポテンシャル採用」です。即戦力人材ではなく、入社後の育成を前提に選考する採用方法です。しかし、ただ採用対象を広げればよい、という話ではありません。やり方を間違えると、かえって選考にあたって現場の負担を増やしたり、入社後のミスマッチを引き起こしたりするリスクもあります。
この記事では、エンジニア人材のポテンシャル採用を検討している企業へ向けて、次の3点を解説していきます。
- エンジニアではどのような人材が「ポテンシャル採用」の対象になるのか
- 採用を始める前に、現場と何を・どのようにすり合わせておくべきか
- 求人票・面接・受け入れ後の段階で、それぞれどんな点につまずきやすいのか
1.経験者採用が難しい企業が、ポテンシャル人材に注目する理由
そもそも、なぜ今多くの企業がポテンシャル採用に関心を寄せているのでしょうか。経験者採用が行き詰まる理由をたどると、人材市場そのものの事情が見えてきます。
1-1. なぜ経験者エンジニアの採用は難しいのか
即戦力となるエンジニア人材の不足は、人材市場で長く指摘されているテーマです。
一般的に「IT人材不足」と認識されている状況には、実際の人材数の不足という側面と、企業側の「不足感」の両方の側面があります。こうした構造を示す調査結果は、別の記事で説明したとおりです。いずれにせよ「同じ層の人材を複数社が同時に必死で探している」状況が続いているのは、弊社へ寄せられる多くの相談からも明らかです。
ただし、企業側の「人が足りない」という認識が、経験年数やスキル要件を限定しすぎた結果として生じているケースもあります。ここを考え直す余地があれば、3章以降で紹介する方法を検討してみてください。
1-2. 求人を出しても候補者に届きにくい
経験者は転職市場に出ても短期間で決まることが多く、そもそも求人媒体をじっくり見ていない可能性があります。
「スカウトを送っても開封されない、返信が来ない」というのも珍しくありません。露出を増やしても、それだけで流入や応募につながるとは限りません。媒体だけ増やしても、空振りに終わりやすいのが実情です。
1-3. 採用対象を広げるだけではミスマッチを招く
こうした傾向を背景に、多くの企業が採用対象をポテンシャル層へ広げています。
ただし、要件を緩めただけだと、現場が求める水準とのズレが大きくなり、入社後のミスマッチのリスクは大きくなります。
エンジニアの中途採用でミスマッチが起きやすい構造については、「エンジニア採用でミスマッチが続く理由は「要件・評価の4つのズレ」──半年で立て直す設計図」の記事でも詳しく説明しています。あわせて参照ください。
2.ポテンシャル採用の対象となるエンジニア人材の種類
ポテンシャル採用の成否は、対象範囲の決め方で大きく変わります。 まずは、対象になり得る代表的な5つの層を、開発実務に近い順に確認していきましょう。
2-1. 第二新卒エンジニア
第二新卒エンジニアは、新卒入社から3年以内に転職を検討している層です。
基本的なビジネスマナーや開発現場の進め方を一度経験している分、完全未経験者に比べれば、戦力化が早い傾向があります。一方で、前職での経験が浅いため、採用では技術力そのものよりも「なぜ転職するのか」「何を学び直したいのか」を確認しておきたいところです。
2-2. 実務1〜2年程度の若手エンジニア
次は、すでに1〜2年間は開発実務に就いている層です。特定の言語や領域で初歩的な経験を積んでおり、多くの場合「即戦力の一歩手前」と位置づけられます。ポテンシャル採用の中では実力を見極めやすい中核層といえるでしょう。
ただし本人が「経験者」として転職市場に出ているケースもあり、ポテンシャル枠の想定で提示すると、条件面で折り合わないことがあります。
2-3. プログラミングスクール卒・独学で開発を学んだ人材
次は、プログラミングスクールや、独学でプログラムを習得した人材です。ここは評価が最も分かれる層です。
学習意欲やキャッチアップ力が高い人がいる一方で、実際に所属したスクール等の課題制作と実際の開発業務のギャップに苦労する例も少なくありません。
修了した学校やコースの名前で判断せず、「何を、どの深さまで理解しているか」を丁寧に確認する必要があります。
2-4. IT周辺職種からエンジニアを目指す人材
続いて、IT周辺業務から、エンジニアへの転身を目指す層です。例えば前職として、インフラ運用、社内ヘルプデスク、あるいは営業・カスタマーサポートといった職種が挙げられます。実務経験を土台に個人でリスキリングを進めている点が、スクールなどで学んだ人材との違いです。
業務やシステムへの理解が強みになるケースもありますが、理解の対象や程度はまちまちです（インフラ寄りなら構成、営業・CS寄りなら製品や顧客理解など）。こちらも個別によく確認しなければなりません。
2-5. 完全未経験者を含める場合の注意点
未経験者まで対象を広げるかどうかは、慎重に決めるべき事項です。受け入れる以上、「育成にかかる工数と期間」を現場とともにしっかり見積もり、合意する必要があるためです。
「採用してから考える」という考えはおすすめしません。結果として現場の疲弊につながるだけでなく、その後の採用計画にも悪影響を及ぼします。
3.ポテンシャル採用で失敗しないために、現場とすり合わせておくべきこと
構造的な背景が見えたら、いよいよポテンシャル採用の準備を始めましょう。まず決めるべき条件を3つに分けます。次に条件を現場から引き出すヒアリング方法と、企業のミッションや職種別に見ておきたいポイントまで説明します。
3-1. 入社時点で必要なこと（must/want）
入社初日に求める最低限の要件（must）と、あれば望ましい要件（want）を分けます。
ここで精査が不足すると、「wantの項目がいつのまにか増え、実質的にmustと変わらなくなる」状況に陥りがちです。wantが多いほど対象が狭まり、ポテンシャル採用の意味が薄れます。「mustはできるだけ絞り込む」ことを心がけましょう。
3-2. 入社後3カ月～半年で伸ばせること
次に「今はできないが、入社後に習得を見込める範囲」を決めます。ここの認識がきちんと現場と一致していれば、面接での評価軸が「今できるか」から「伸びそうか」に切り替えられます。
同時に、教える現場側のリース（人・時間）がどれぐらいあるか、という条件をできるだけ正しく見積もっておく必要があります。
3-3. 採用対象外にすべき条件
「この条件は今回は見送る」という線引きを先に決めておくと、判断がぶれにくくなります。
例えば特定領域の経験が必須となる場合、ポテンシャル採用ではなく経験者採用として別に設計するほうが、面接で評価するときの負荷が減る可能性が高いです。
3-4 人事が現場から要件を引き出すためのヒアリングフォーマット例
中途採用は、まずは「抜けた人の穴を埋める」発想で進むことが多いです。その結果、要件が前任者のスキルをなぞる形で限定的になりすぎるケースがあります。
また一方で、現場のチーム内でも「やるべき業務」と「必要なスキル」の整理が不十分で、必要な技術の名前だけが一人歩きしてしまうことも少なくありません。
そこで人事側から、業務とスキルを分けて引き出す問いを用意しておくと、要件が現場感に近づきます。 例えば以下のような質問です。
| ①現状把握：現在、チーム内でいちばん負荷が高い／滞っている業務は何ですか？ ②スキル要件の確認：そのスキルは、具体的にどの業務を遂行するために必要ですか？ ③採用目的の明確化：今回の採用で、チームのどの不足・負荷・リスクを解消したいですか？ ④立ち上がり期待値：入社1カ月目／3カ月目／6カ月目に、それぞれ任せたい業務は何ですか？ ⑤成功の定義：入社6カ月後、チームがどのような状態になっていれば「採用成功」と言えますか？その状態につなげるために、中途入社社員に何を担ってもらう必要がありますか？ |
3-5.ミッションと職種ごとに見るべきポイント
企業にとって、「どのような職種で、どのようなミッションを達成してほしいか」によって、候補者を見るべきポイントは変わります。
ここでは4つのミッションにもとづいて、重視したい点をそれぞれ紹介します。
| ミッション | 主な職種 | ポテンシャル採用で見るべきポイント |
| DX推進・組織変革 | Web系エンジニア／DXコンサル／PM／UI・UXデザイナー | 業務フロー改善やユーザーの課題解決を技術に落とし込めるか 部署を横断して関係者を巻き込んで進められるか 非エンジニアにも伝わる言葉で説明できるか |
| 製品価値の最大化 | 機電エンジニア／プロダクトマネージャー（PdM） | 「なぜこの仕様か」をを掘り下げて考えられるか 品質と納期の折り合いをつけられるか 作って終わりにせず、使われ方までこだわりを持てるか |
| データ・AI活用 | AIエンジニア／データサイエンティスト／データエンジニア | 数字を扱う基礎が身についているか 都合のよい数字だけでなく、反証となるデータも確かめられるか 課題から逆算してデータの意味を解釈できるか |
| 事業基盤の安定稼働と堅牢化 | SRE／セキュリティエンジニア／インフラエンジニア | トラブルを個人のミスでなく、仕組みの弱さとして捉え直せるか 動いているものを安定して支え続けることにやりがいを感じられるか 監視や地道な改善など、表に出にくい作業を続けられるか |
いずれも、保有スキルそのものではなく、面接でのやり取りや過去の業務への取り組み方から読み取る観点です。
4.ポテンシャル採用を導入する際の求人票の作り方・注意点
では、決まった条件を求人票に落とし込むには、どのような点に注意しておけばよいのでしょうか。ここでは「ありがちな失敗例」を交えて説明します。
4-1. 必須条件と歓迎条件を分け、応募ハードルを明確にする
まずはmustとwantの条件を、そのまま「必須／歓迎」に反映します。
必須条件に願望まで書き込むと、見る人の心理的ハードルが高くなります。「この欄を見て応募をためらう人がいないか」を基準に、削れる項目は歓迎条件へ移すとよいでしょう。
| 失敗例： Must 基礎的なDB設計の知識 Gitでのチーム開発経験 AWSの基礎知見 |
この事例は、実際に筆者の前職の職場で起こりました。詳しく紹介します。
Case Study：必須要件を増やしすぎて失敗した事例
エンジニア採用が進まない中、人事と開発現場で「今回は育成前提のポテンシャル採用で進めよう」と合意しました。
しかし現場側が「少しでも教える手間を減らしたい」と、「基礎的なDB設計の知識」「Gitでのチーム開発経験」「AWSの基礎知見」を、すべて必須要件（Must）に追加。人事側も技術的な妥当性を判断できず、現場の意向を尊重してそのまま公開しました。
すると、数カ月間応募がゼロという結果に。つまり、これは立派な「経験者採用の募集要件」でした。しかし、提示年収はポテンシャル採用の基準のままだったため、スキルと給与のバランスが完全に崩壊していたのです。この条件で応募する人は、市場には存在しません。貴重な採用活動の時間を大きく無駄にしてしまいました。
もし「DB設計の基礎知識」や「AWSの基礎知見」を歓迎条件、「Gitでのチーム開発経験」のみを必須条件として絞っていれば、応募のハードルは大きく下がっていたはずです。
この事例のように、たとえ前任者がすべて満たしていたとしても、そのまま必須にすると、ごく限られた経験者しか応募できません。ポテンシャル採用なら必須は1〜2項目に絞り、残りは歓迎条件へ移動するのがおすすめです。
また、人事担当者自身も現場任せにするのではなく、技術要素や市場におけるエンジニアのレベル感について、継続的に解像度を高めていく姿勢が大事です。
4-2. 求める基礎スキルや学習経験を具体化する
どの言語で、どの程度のものを作った経験を想定しているのかを、一段具体化すると伝わりやすくなります。
| 失敗例： 基礎的なプログラミング知識をお持ちの方 何らかの開発経験 |
「基礎」「何らか」の水準が読み手任せで、判断できません。「いずれかの言語で、Webアプリを一つ作り切った経験（個人開発・スクール課題可）」のように、範囲と到達点を示します。
4-3. 入社後に担当する初期業務を明記する
入社後しばらく何をするのかが見えると、候補者は自分が活躍できそうかを判断しやすくなります。
「開発業務全般」のように抽象的な表現より、最初の数カ月に任せたい具体的業務を記載したほうが、ミスマッチの予防につながります。
| 失敗例： 〇〇チームでの開発業務全般をお任せします スキルや要望に応じて、幅広い業務を担当していただきます |
何をするか見えず、候補者は「自分に務まるか」を判断できません。「配属直後は既存コードの構造理解を優先して影響範囲の小さい改修から着手。その後チーム内の基準に照らし、次のステップへの移行を判断する」のように、「入社直後は何を任されるか」が分かるように具体化します。
4-4. 即戦力採用に見える表現を避ける
「個人の裁量が大きい環境」「自走できる方」といった表現は、ポテンシャル層を遠ざけがちです。
経験者向けの言葉が混じっていないか、現場と人事の双方で読み合わせておくと安心です。
| 失敗例： 自走できる方歓迎 キャッチアップの早い方 即戦力として活躍いただけます |
いずれも経験者を想起させ、意欲ある未経験層が「自分には早い」と離脱します。「わからないことを調べ、周囲に相談しながら進められる方」のように、伸びしろを前提にした言葉に置き換えます。
5.ポテンシャル人材の採用面接で必ず確認したい5つの力
続いては面接です。「これから伸びるかどうか」を見るポテンシャル採用において、必ず確認しておきたい5つの力と、面接での尋ね方の例を紹介します。
5-1. 技術の基礎理解
まずは技術の基礎理解力です。暗記した知識やペーパーテスト的な設問への正しい回答ではなく、「仕組みを自分の言葉で説明できるか」をチェックします。説明の筋道が通っているかどうかにも注目したいところです。
質問例：
「直近で学んだ技術を、専門外の人に説明するとしたら、どのように話しますか」
「その技術をあえて選ばないほうがよい場面があるとしたら、どんなときですか 」
（メリットだけでなくデメリットまで説明できる）
5-2. 学習継続力
独学やスクールで学んだ人なら、入社後も学びつづけられそうかを確認します。新たな知識や領域について学習を続けられる人ほど、業務でわからないことにぶつかった時にも、その状況を早く克服できる可能性が高いからです。
質問例：
「学習が思うように進まなかった時期に、どう対処しましたか」
「最近、自分からすすんで学んだことは何ですか。きっかけも教えてください 」
5-3. 問題解決力
問題が起こったときを想定し、解決策そのものより、組織の中で「わからない時にどう動くか」を見ます。「すぐ人に聞く」と「まず自分で調べる」を状況に応じて使い分けられるかどうかが鍵になります。
質問例：
「解決法が見つからない課題に直面したとき、最初に何をしましたか」
「自分で調べても解決せず、人に頼ったときのことを教えてください。どの段階で切り替えましたか 」
5-4. フィードバックを改善につなげる力
ポテンシャル採用では、入社後にレビューや指摘を受ける機会が多くなります。他者からの指摘を素直に受け止め、次に活かせるかは、本人の伸びしろと直結する部分です。
質問例：
「レビューや指摘を受けて、自分のやり方を変えた経験はありますか」
「最初は抵抗を感じたものの、あとから『指摘してもらって良かった』と感じたことはありますか 」
5-5. チームと連携する力
組織の中で働く以上、一人で完結する開発業務はほぼありません。わからないことを抱え込まず、上司や先輩・同僚などに相談・共有できるかを確認します。
質問例：
「チームで開発していて、他の人と認識がずれていると気づいたとき、それをどう解消しましたか」
「チームの中で、自分の働きかけを誰かに感謝された経験はありますか。何をしたか教えてください」
5-6. 人事と現場の「面接での役割分担」
面接官が複数いる場合は、「誰が何を見るか」を事前に決めておかないと、評価が重複したり、逆に誰もが見落としてしまう観点が生まれたりします。一般には、人事がカルチャーフィットや学習姿勢を、現場が技術の基礎や業務適性を担当すると進めやすいです。
また、評価のばらつきを抑えるために質問を定型化しすぎるのも問題です。台本どおりの面接になり、候補者の素の反応が引き出せなければ意味がありません。例えば「評価基準はそろえつつ、最後に一つだけ自由に質問する時間を確保する」といった工夫が有効です。
6.ポテンシャル採用の成否を分ける面接の仕組み
ポテンシャル採用は見極めが難しい分、面接官による評価のばらつきが出やすいです。評価の属人化はいったいどのようにすれば抑えられるのでしょうか。
6-1. 評価のばらつきは、採用の質と候補者体験の両方を損なう
面接官ごとの評価のばらつきは、二重の損失を生みます。一つは「企業の採用の質そのものが安定しない」こと。そしてもう一つは、「候補者側へ悪影響を与える」ことです。
面接官によって聞かれることや反応が違うと、候補者の目には「組織として何を求めているのかいまいち見えない会社」に映ります。これが辞退や早期退職につながるのです。
6-2. 人事と現場で「誰が何を見るか」を事前に決める
面接官が複数いる場合は、「誰が何を見るか」を事前に決めておかないと、評価が重複したり、逆に誰もが見落としてしまう観点が生まれたりします。
一般的には、人事がカルチャーフィットや学習姿勢を、現場が技術の基礎や業務適性を担当すると進めやすいです。現場側は技術力を判断できても組織への適応能力までは見極めにくく、人事側ではその逆になりやすいためです。
6-3. 質問は標準化しても、候補者の”素”が見える時間を残す
評価のばらつきを抑えるためとはいえ、質問を定型化しすぎるのも問題です。台本どおりの面接になり、候補者の素の反応が引き出せなければ意味がありません。
そろえるべきなのは、質問内容ではなく評価基準です。「評価基準はそろえつつ、最後に一つだけ自由に質問する時間を確保する」といった工夫が有効です。
6-4. 質問項目だけでなく、評価基準までそろえておく
5章で挙げたような質問例に対しては、尋ね方だけでなく「答えをどう評価するか」までそろえておきましょう。
学習継続力についての質問であれば、「主体的に、半年以上学習を続けた実績が読み取れること」「つまずいたとき実践した対処法に、再現性が期待できること」といった基準まで決めておくと、面接官が変わっても解釈がぶれません。
評価基準を統一すると同時に、候補者視点から見た「面接の質」を高めたい場合は、 LeINが提供している面接官トレーニングをチェックしてみてください。面接官の評価力そのものを底上げしておくと、候補者の見極め精度も上がります。
7.ポテンシャル採用で入社後のミスマッチを防ぐための4つのポイント
採用はゴールではありません。ポテンシャル採用はとりわけ、入社から数カ月後に成否が分かれます。 この章では、採った人を現場に定着させるために、入社前後で本人と握っておきたい4つのポイントを説明します。
7-1. 入社後に任せる業務範囲を具体化する
入社後に任せる業務範囲は、本人に具体的に伝えておきます。「慣れてきたら任せる」では、本人は何を目指せばいいか分かりません。最初に担当する範囲を、入社時点で明示します。
一例として、「入社直後は既存コードの修正とレビュー参加、入社3カ月時点は役割達成度によって新機能の一部を担当 」という具体像まで示せると、本人は迷わず動き出せます。
ここが曖昧なままだと、現場で雑務だけを振りつづけてしまい、双方が手応えを失う…といった事態も起こりえます。
7-2. 育成担当者や質問・レビュー体制を整えておく
育成担当者と連携し、質問・レビュー体制も決めておきましょう。ポテンシャル採用で最も避けたいのが、現場の善意ベースの教育に期待して「採ったはいいが、教える人がいない」という放置状態を作ってしまうことです。
Case Study：「善意頼み」のOJTが早期離職を招いた事例
筆者が採用をサポートした企業でも、過去、次のようなケースが実際にありました。
ポテンシャル層の若手を受け入れた際、「現場の優秀なシニアエンジニアがOJTで教えてくれるだろう」という期待だけで、教育体制づくりを現場の善意に委ねていました。ところが入社時期が開発の繁忙期と重なり、現場は常にピリピリした空気に。本人から質問したくても上司や先輩に声をかけづらく、「放置されている」と孤独感を募らせ、3カ月で辞めていきました。
この一件をきっかけに、この企業では、育成担当者がサポートに割く時間も「開発工数」に含めることにしました。後輩を育てることそのものを、その人の評価に組み込むよう変えたのです。教えることが業務であると同時に本人にとってもメリットになる、という形にしてからは、ポテンシャル採用の社員の早期離職はなくなり、戦力化も早まっています。
7-3. 入社後3カ月・半年で期待する役割を共有する
採用者に「いつまでに、何ができていれば 順調か」を共有しておきましょう。3カ月・半年の区切りで、期待する役割を示します。
「活躍」「戦力化」といった抽象的な言葉でぼかさず、対応可能な範囲で表現するのがポイントです。 例えば「入社3カ月で『レビューを受けながら既存機能の改修を一人で進められる』、半年で『小さな新機能なら設計から任せられ、自分で判断できないときだけ相談する』」といったものです。
自走できる範囲と、相談しながら対応可能なレベルを区切っておくと、誤解が生まれにくいです。
7-4. 入社後の評価基準と評価タイミングを内定承諾前に伝えておく
人事評価の基準とタイミングは、候補者が内定を承諾する前に伝えておきます。ここが抜けていると、最初の評価面談で食い違いが表面化しがちです。
- 本人は業務はアウトプットの正確さが大事だと思っていたが、上司は完成度よりもチーム連携を前提にしたスピード感を重視していた
- 半年で評価が上がると思っていたが、現場は基礎固めの期間と捉えていた
- 評価面談の結果によっては1回目から昇給できると考えていたが、一年目は据え置きが前提だった
業務の中で何を見て、いつ・どう処遇に反映するかを先に伝えておけば、こうした食い違いは防げます。オファー面談の段階で資料として渡しておくと確実です。
まとめ
エンジニア人材のポテンシャル採用は、経験者を採りにくい昨今、成功率を高めるのに有力な選択肢です。ただし本記事で解説してきた通り、対象を広げるにあたっては「現場と人材要件や評価基準を、どこまで丁寧にすり合わせられるか」が問われます。
たった1つのポイントは、「要件の定義から求人票、面接、入社後の受け入れまでを、人によってぶれない仕組みにしておくこと」です。とりわけ面接では、基準をそろえておかないと判断が属人化しやすいです。
まずは一歩を踏み出し、走りながらPDCAを回していくのが最もベーシックな解決方法とはいえ、要件設計から運用までを一から自社だけで組むのは、負荷が大きい企業課題です。ポテンシャル採用で失敗しないために、エンジニア採用に強い外部の支援サービスの活用をぜひご検討ください。
