エンジニアのリファレンスチェック対策は「推薦者の調達」で決まる SES・フルリモートで推薦者が枯れる構造と、職務経歴書が崩れる3つの論点【2026年8月版】

リファレンスチェック対策の記事はどれも「質問内容」と「落ちる原因」から書き始める。だがエンジニアが実際につまずくのは、質問の中身ではない。「この人に頼めば成立する」という推薦者が、自分の職歴の構造上そもそも見つからないという一点だ。客先常駐で自社の上司が現場を見ていない、フルリモートで上司が2回変わった、直属のマネージャーが非エンジニアで技術的な判断を説明できない——この状態で最終面接後に依頼が来ると、その場で詰む。

この記事では、実施率のデータで「そもそも自分に降ってくるのか」を見積もったうえで、推薦者の調達 → 職務経歴書の整合 → 依頼文面 → 法的な拒否ライン、の順で逆算する。質問の一覧暗記は最後に置く。優先順位が逆だと、準備しても間に合わない。

01そもそも実施されるかを、応募前に見積もる

全社が実施するわけではない。エンワールド・ジャパンが2021年1月に303社（外資系52%・日系48%）へ実施した調査では、中途採用でリファレンスチェックを「実施している」と答えたのは全体で41%だった。内訳の差が大きい。

同じ調査で、実施タイミングは最終面接後が62%（外資系65%／日系55%）。ただし日系企業では「最終面接より前」が45%と、外資系の23%を大きく上回る。日系を受けるときは「最終面接まで進んだら準備する」では遅れる可能性がある、ということだ。

結果の重みも小さくない。同調査では68%が「採用判断に影響する」と回答しており、しかもその割合は日系81%・外資系62%と、日系のほうが高い。実施率は低いが、実施した場合の影響度は日系のほうが大きい。推薦者の人数は2人が58%で最多だった。

実務の運用は「オンライン型」が主流になっている

かつての電話ヒアリングに代わり、候補者が推薦者を登録し、推薦者がフォームに回答する SaaS 型が広がっている。国内実施数の多い back check の公表値では、職種やポジションに合わせて設問は10問前後、依頼からレポート回収までは平均4.6日、レポート取得率は82%とされる。推薦者側の回答所要時間は30分程度を見込むのが一般的だ。

ここから逆算すると、依頼が来てから推薦者を探し始めると、探索に数日＋回答に数日で、オファー期限に間に合わない。とくに内定承諾の期限交渉を並行している場合、リファレンスの遅延がそのまま他社との比較検討の時間を削る。

02エンジニアのボトルネックは「推薦者の調達」

一般的な対策記事は「上司に頼みましょう」で終わる。エンジニアの職歴では、その前提が成立しないケースが多い。典型は次の4つだ。

ケース1: SES・客先常駐で、自社の上司が現場を見ていない

自社の営業やマネージャーは稼働と請求は把握しているが、設計判断やコードレビューでの振る舞いは見ていない。一方で実際に働きぶりを見ていたのは常駐先の顧客側リーダーで、この人は別会社の人間だ。推薦者としては最も解像度が高いが、依頼には注意点がある。

ケース2: フルリモート・業務委託で、上司が短期間に変わった

在籍1年半で上司が3人変わった、という状況では「6ヶ月しか一緒に働いていない上司」しか残らない。この場合は上司より、通しで並走したテックリード・同僚エンジニア・PdMのほうが証言の中身が濃くなる。企業側も「直属上司であること」より「一定期間、業務上の接点があったこと」を求めているケースが多い。

ケース3: プロジェクト単位で人間関係が離散している

受託開発では、プロジェクトが終わるとチームが解散する。SNSで繋がっていない相手には数年後に連絡が取れない。これは事後には解決できないので、在籍中に手を打つしかない。退職時にプロジェクトの主要メンバーとは私用の連絡先を交換しておく。退職交渉の進め方を設計する段階で、この「連絡先の持ち出し」まで含めて考えておくと後が楽になる。

ケース4: 直属のマネージャーが非エンジニア

マネージャーが技術的な貢献を説明できないと、回答が「真面目でした」「勤怠に問題はありません」で終わる。これはネガティブではないが、無価値だ。企業側は技術的な裏取りができず、面接で語った内容の確認になっていない。この場合は、非エンジニアのマネージャー1名＋技術を見ていたシニアエンジニア1名の組み合わせで出す。

誰に頼めるか: 優先順位の判定表

組み合わせの基本は「上司レイヤ1名＋横のレイヤ1名」。同じレイヤで2人揃えると、聞ける角度が重複して情報量が増えない。エンジニアリングマネージャーの役割で応募している場合は、上司1名＋元部下1名の構成が最も評価軸に合う。

03職務経歴書が崩れる3つの論点

リファレンスチェックで見送りになるケースは全体としては少ない。だが発生するときのパターンははっきりしていて、①明らかな経歴・実績の詐称、②面接での自己評価と第三者評価の極端な乖離、③重大な勤怠・トラブルに集約される。エンジニアで最も起きるのは②で、しかも本人に嘘をついた自覚がないまま起きる。以下の3つが震源だ。

論点1: 役割レイヤ（設計したのか、実装したのか）

職務経歴書の「要件定義から設計・実装・運用まで一貫して担当」は、書いた本人の実感としては嘘ではない。だが推薦者に「この方の担当範囲を教えてください」と聞くと、「設計は別のリーダーが引いて、彼は実装とテストを担当していました」と返ってくることがある。これが乖離になる。

論点2: 技術選定の裁量（決めたのか、決まっていたのか）

「Go / gRPC を採用し、レイテンシを40%改善」と書いたとき、企業側が知りたいのは誰が意思決定したかだ。すでに全社標準として決まっていた技術スタックの上で成果を出したのなら、それはそう書くほうが強い。技術選定の主体を曖昧にしたまま書くと、推薦者の「あれは全社方針でした」の一言で、他の記述の信頼度まで一緒に落ちる。

論点3: 規模と期間（チーム人数、担当期間、影響範囲）

「10名規模のチームをリード」の10名が、常時10名なのかピーク時のみ10名なのか。ここは推薦者が最も正確に覚えている項目でもある。数字を書くなら「ピーク時◯名／定常◯名」のように条件を添える。数字を盛るより、条件を明示するほうが説得力が上がる。

この3点の翻訳は、そのまま書類選考の通過率にも効く。SIerからWeb系への転職のように商流をまたぐ場合はとくに、役割レイヤを正確に書き直す作業が本丸になる。

04依頼は「3点セット」で送る

推薦者への依頼で最初にやるのは、承諾を取ることだ。本人の同意なく連絡先を企業に渡すのは、個人情報の第三者提供として問題になる。承諾を取ったうえで、次の3点をセットで渡す。

• 負担の見積もり：オンラインフォームで10問前後、所要30分程度、期限は◯日まで。これを最初に書く。工数が読めない依頼は後回しにされる。
• 文脈の共有：応募先の業種とポジション、なぜそこを志望しているか、面接で何を強みとして話したか。
• 期間の特定：いつからいつまで、どのプロジェクトで一緒だったか。推薦者の記憶を該当期間に絞る。

最後の一文が重要だ。「事実と異なる部分があれば、遠慮なくそのままご回答ください」と明示することで、依頼が口裏合わせの要請ではなく、事実確認の協力依頼であることが伝わる。推薦者にとっても、回答の心理的な負担が下がる。

05聞かれる質問と、答えにくい質問の潰し方

設問は10問前後で、基本情報＋勤務態度＋人物面＋スキルの4ブロックに、職種別の設問が数問足される構成が一般的だ。定量部分は5段階評価や10点満点、または「同年次の中での相対評価」を求める形式が使われる。

「答えられない」を減らす

推薦者が「わかりません」を連発するレポートは、ネガティブ回答よりも印象が悪い。企業側から見ると「本当に一緒に働いていたのか」が疑わしくなるからだ。これを防ぐには、依頼時に期間とプロジェクトを特定して渡すこと、そして推薦者が答えられない領域の設問が来る組み合わせを避けること。営業やコーポレート部門の人だけを推薦者にすると、スキルブロックが丸ごと空白になる。

06拒否できるのか、聞かれてはいけないことは何か

まず前提として、リファレンスチェック自体は違法ではない。ただし本人の同意なしには実施できない。個人情報保護法上、候補者の個人データを推薦者に提供すること、推薦者から候補者の情報を取得することのいずれも、原則として本人の同意が必要になる。だから実務では必ず同意取得のステップが入る。裏返すと、同意しない自由は形式上ある。

ただし現実には、同意を拒否すれば選考が止まる可能性が高い。合理的な理由（現職に一切知られたくない等）を説明したうえで、「前職の元上司であれば対応可能」と代替案を出すのが実務的な落としどころだ。企業側も、拒否に妥当性があれば他の選考手段に切り替えるという運用を取ることがある。

収集してはいけない情報は法令で定まっている

職業安定法第5条の5と、これに基づく指針（平成11年労働省告示第141号）は、業務の目的達成に必要な範囲を超えた個人情報の収集を禁じている。具体的に列挙されているのは次の3類型だ。

1. 人種、民族、社会的身分、門地、本籍、出生地その他社会的差別の原因となるおそれのある事項
2. 思想および信条
3. 労働組合への加入状況

健康状態や家族構成、既往歴なども、職務上の必要性が説明できない限り踏み込めない。リファレンスの設問にこれらが混じっていたら、推薦者は答える義務がないし、候補者側から企業に指摘してよい。設問の適法性を知っていること自体が、対策の一部だと考えたほうがいい。

07現職にバレないための設計

「現職の上司に依頼して転職活動が発覚する」は、リファレンスチェックのデメリットとして最も多く挙げられる懸念だ。設計で回避できる。

• 推薦者は退職済みの前職から2名そろえる。これが最も安全で、多くの企業もそれを許容する。「現職には知られたくない」は正当な理由として通る。
• 現職に頼まざるを得ないときは、退職の意思を伝えた後に回す。順序を逆にしない。内定が出る前に社内に伝わると、交渉のカードを全部失う。
• 実施タイミングを事前に確認する。日系企業では45%が最終面接より前に実施している。「最終面接後だろう」という思い込みで動かない。
• 推薦者に「現職には未申告である」と伝えておく。推薦者経由での漏洩を防ぐ。とくに前職の元同僚が現職の関係者と繋がっているケースは意外と多い。

内定が出たあとの動き方は内定辞退のマナーの設計とも連動する。辞退する可能性がある会社のためにも推薦者は動いてくれているので、結果は必ず本人に報告する。ここを飛ばすと、次の転職で同じ人には頼めなくなる。

08詐称が発覚したあとに実際に起きること

「盛った程度なら大丈夫」と考える前に、実際の裁判例で線がどこに引かれているかを見ておく価値がある。エンジニアが当事者になった判決が2件ある。

判例が用いる基準は「真実を告知していたら採用しなかったであろう重大な経歴か」だ。使用言語をひとつ多く書いた程度でここに乗ることは考えにくいが、担当していないプロジェクトの経験を書く、在籍期間を偽る、解雇された事実を隠すといった事実レベルの捏造は、発覚したときに内定取消・解雇・損害賠償まで届きうる。リファレンスチェックは、その事実レベルの捏造を検出する装置として運用されている。

09応募から内定までの逆算スケジュール

準備は「依頼が来てから」では遅い。オンライン型でも回収まで平均4〜5日かかり、推薦者の返信が滞ればさらに伸びる。応募の時点から逆算する。

• 応募前 / T-30d
  推薦者の棚卸し：連絡が取れる元上司・元同僚を書き出す。連絡先が切れている相手がいたら、この時点でSNS等で復旧させておく。ここが最も時間がかかる。
• 書類提出前 / T-25d
  職務経歴書の整合チェック：役割レイヤ・技術選定の裁量・規模の3点を、推薦者が同じ言葉で説明できる粒度に書き直す。
• 一次面接後 / T-14d
  実施有無の確認：エージェントまたは人事に、リファレンスチェックの有無・タイミング・推薦者の要件（現職か前職か、上司限定か）を聞く。日系なら最終前実施の可能性も見ておく。
• 最終面接前 / T-7d
  推薦者に内諾を取る：まだ確定していない段階でも「近く依頼するかもしれない」と一報を入れる。負担の目安（10問／30分）を最初に伝える。
• 依頼確定 / T-0
  3点セットを送る：負担の見積もり・応募先の文脈・対象期間。企業に推薦者情報を登録する。
• 依頼後 / T+5d
  回収状況の把握とお礼：4〜5日で回収されるのが標準。遅れているようならリマインドを1回だけ。完了後は結果にかかわらず必ずお礼を入れる。

よくある質問

福朗

フリーランスAIエンジニア。AIパイプライン開発と技術キャリアについて発信しています。

Zenn