ATSとCRMを連携するときは、最初に「どの業務の、どの情報を、誰へ渡すか」を決めます。APIで接続できても、更新元やIDが曖昧なら、候補者の重複登録、案件日程の上書き、不要な個人情報の共有が起きます。
案件、求人、候補者、応募、配置を分け、情報ごとに正しい記録の置き場所と同期方向を定義します。通常の更新に加え、延期、辞退、削除、同期失敗を扱えることが、運用を止めない連携の条件です。
連携が必要になる条件
自社採用で、応募受付から内定までをATSだけで完結できるなら、営業用CRMとの接続を急ぐ必要はありません。連携が役立つのは、部門間の受け渡しで転記や伝達漏れが起きている場合です。まず繰り返している転記を一つ選びます。
- 営業の案件から、開始日と必要な技能を採用担当へ渡す
- 案件の延期を受け、候補者への条件確認と配置を見直す
- 採用決定後に、人材管理へ入社日と担当可能な役割を引き継ぐ
- 候補者CRMで面談を希望した人について、ATSに応募を作る
顧客CRMと候補者CRMでは接続する情報が違います。両者の役割はATS・CRM・SFAの違いで整理できます。「データを一つにしたい」より、「開始日の変更を関係者が同じ日に把握できる」など、確認できる完了条件を置いてください。
案件・人材・配置を分けて持つ
一人の候補者が複数の求人へ応募し、一つの案件に複数人が参加することがあります。人材の行へ案件名を直接上書きするだけでは、過去の配置や並行案件を残せません。対象ごとにIDを持たせ、関連を記録します。
| データ | 識別する単位 | 正本を置く場所の例 |
|---|---|---|
| 案件 | 顧客と合意する仕事 | CRM・SFA |
| 求人・必要枠 | 募集する役割と条件 | ATSまたは要員依頼の台帳 |
| 候補者 | 一人の人物 | ATS・候補者CRM |
| 応募 | 人物と求人の組み合わせ | ATS |
| 配置 | 人物・案件・期間・工数の組み合わせ | 配置管理 |
連携用の対応表には、送り元ID、送り先ID、データ種別を記録します。氏名だけで照合すると同姓同名を、メールアドレスだけでは変更や共用アドレスを扱えません。重複候補が見つかったら自動で統合せず、人が根拠を確認できるようにします。
同じ人への新たな応募を同期するときも、人の情報を毎回新規登録するのか、既存候補者に応募だけ追加するのかを区別します。選考を終えた履歴は、別の求人への応募で書き換えません。
同期する項目と正本を決める
項目ごとに、意味、更新元、利用先、空欄の扱い、変更条件を定義します。正本とは、その項目について最終的に正しい値を持つシステムです。画面が複数あっても、同じ項目を自由に両側から更新しない運用にします。
| 項目 | 更新元の例 | 送り先 | 送る条件 |
|---|---|---|---|
| 案件開始予定日 | CRM | 要員計画・配置管理 | 承認された日付が変わったとき |
| 役割と必要工数 | 要員依頼 | 採用・配置担当 | 依頼の受付が完了したとき |
| 選考段階 | ATS | 権限を持つ調整担当 | 応募の段階が変わったとき |
| 入社予定日 | ATS | 受け入れ管理 | 本人と会社の確認後 |
| 配置の状態 | 配置管理 | 案件担当 | 配置承認または変更時 |
例えばCRMの「開始予定日」とATSの「入社予定日」は、同じ日付とは限りません。項目名が似ていることを理由にコピーすると、案件の延期で本人と合意した入社日まで変わるおそれがあります。値ではなく意味を対応させます。
未入力と削除指示も分けます。送り元が空欄だった場合、送り先の値を消すのか、変更しないのかを定めます。日付の形式、時刻のタイムゾーン、状態名、必須項目の不足は、取り込み前に確認します。
選考状態を案件担当へ渡す範囲を絞る
案件担当が知りたいのは、候補となる人材をいつ確保できそうかであり、面接官の所感の全文とは限りません。「調整中」「条件確認中」「配置未確定」など、その担当が判断に使う状態へ変換して渡す方法があります。
ただし、選考段階から配置の確約へ自動変換しないようにします。最終面接へ進んだことと、本人が入社・参画を承諾したことは別です。連携先の表示にも、本人との合意が未確認なのかを残し、営業上の約束へ誤って使われないようにします。
CSV・API・手動の連携方法を選ぶ
件数が少なく更新頻度も低いなら、担当者が確認してCSVを取り込む運用から始められます。CSVでは列の対応、文字コード、重複の判断、取り込み結果の確認を手順にします。ファイルの保管場所と削除方法も決めてください。
APIによる定期連携は転記を減らせますが、利用制限、変更通知の方法、障害時の確認が必要です。Webhookを使う場合も、通知が遅れたり同じ変更が複数回来たりする前提で扱います。製品ごとに提供条件が違うため、導入時の公式仕様と契約を確認します。
選ぶ基準は「すぐ同期できるか」だけではありません。許容できる遅れ、1日に変わる件数、失敗した場合の業務影響、保守できる担当者を並べます。毎朝の更新で足りる情報と、候補者連絡前に即時確認が必要な情報を分けると、連携範囲を絞れます。
延期・失注・削除・同期失敗を設計する
案件が延期されたら、開始日を変えるだけでなく、仮押さえの期限と本人への確認要否を配置側へ返します。失注した場合は、必要枠の募集を止めるか、他案件でも必要な役割として継続するかを判断します。失注を理由に候補者情報を一律削除する設計にはしません。
候補者が辞退したら、その応募の状態を更新します。他の選考や将来の連絡まで止める希望なのかは別に確認します。削除の請求などがあった場合は、連携先のコピー、書き出したファイル、検索用の記録も含め、社内の管理手順に沿って処理します。
再送しても同じ記録が増えないようにする
同期が途中で止まり再実行したときに、同じ応募を二重登録しない仕組みが必要です。送り元のIDと変更を識別する値を記録し、反映済みか確認してから更新します。古い変更が後から届いた場合も、新しい値を戻さないようにします。
エラー一覧には、対象ID、発生日時、処理内容、失敗の分類、再確認の担当を残します。履歴書や秘密情報をそのままエラーログへ写さないようにします。再送前に原因を直し、反映結果と未処理件数を確かめます。
障害時の手動対応も重複を防ぐ
同期が止まっていても、候補者への連絡や案件の開始調整は待てないことがあります。手動で更新した場合は、対象ID、変更内容、時刻、担当を記録し、同期再開時にどの値を優先するかを確認します。再開後に古い値が上書きされないことまで点検してください。
復旧したら、処理の成功件数だけでなく、対象期間の変更件数と送り先の反映を照合します。案件10件を送って10件成功しても、そもそも送信対象から1件抜けていた可能性はあります。未送信、送信失敗、反映後の不一致を別に探せる形にします。
権限と運用を決めてから実装する
営業担当に必要なのが開始可能日と役割なら、面接評価の全文や住所までコピーする必要はありません。個人データの共有範囲は、個人情報保護委員会の通則編ガイドラインと自社の利用目的を確認し、閲覧者を限定します。
連携に使うアカウントは担当者個人の共有IDにせず、必要な権限だけを付けます。秘密情報をCSVや引き継ぎ資料へ記載しないこと、担当交代や契約終了時に接続を管理できることも要件に含めます。
試行では架空データを用い、新規登録、更新、重複、延期、辞退、削除、再送を順に確認します。業務への受け渡し自体が曖昧な場合は、業務プロセス設計の進め方へ戻り、誰が受け取り、何を確認したら完了かを定めてから接続します。
本格運用の前には、システムごとの管理者、業務の判断者、障害時の連絡先を決めます。APIの仕様変更や契約プランの変更を誰が確認するかも含めてください。担当者が変わっても、同期項目と停止方法を読めば状況を把握できる資料を残します。
まとめ
ATSとCRMの連携は、データの種類、ID、正本、同期条件を決めるところから始めます。必要な情報だけを渡し、延期・辞退・削除と再送を試してください。接続できたことに加え、担当者が反映と未処理を確認できる状態まで整えることで、連携後の伝達漏れを減らせます。
コメント