人材紹介業の案件・候補者管理システムの作り方｜候補者×求人企業を一元化する営業DX設計

候補者の情報は紹介媒体の管理画面と表計算ソフト、求人企業とのやり取りは各担当者のメール、面談で聞いた本音は個人のメモ帳——人材紹介業の現場では、こうした情報の分散が半ば当たり前になっています。原因は担当者の管理能力ではありません。求職者（候補者）と求人企業という2種類の顧客を同時に抱えるという、業態そのものの構造にあります。この記事では、両面の情報を1つのデータベースに集約し、マッチング・進捗管理・掘り起こしを個人の記憶に頼らず回すためのデータ設計と運用を、人材紹介会社の支援実例を交えて解説します。近年相談が増えているAIマッチングの考え方も、1セクションで扱います。

なぜ人材紹介業では、候補者と求人企業の管理がバラバラになりやすいのですか？

一般的な顧客管理の考え方が「顧客は1種類」を前提にしているのに対し、人材紹介業は候補者（個人）と求人企業（法人）という性質の異なる2つの顧客を持つからです。しかも入口が違います。候補者は紹介媒体・スカウト・自社サイトなど複数の経路から入り、求人企業は営業活動や紹介から入ります。担当も両面型・分業型（キャリア担当と企業担当）で分かれることがあり、それぞれが自分の持ち場のリストを別々に育てていく結果、候補者リスト・企業リスト・求人票が自然と別のファイルに割れていきます。

さらに深刻なのは、この2つをつなぐ「マッチングの検討履歴」がどこにも残らないことです。「この求人にあの候補者を当てられないか検討したが、勤務地希望が合わず見送った」という判断は、多くの会社で担当者の頭の中にしかありません。その帰結が、過去に接点のあった候補者を掘り起こせない、同じ企業への二重推薦が起きかける、担当者の退職とともにマッチングの知見が消える、という人材紹介業に典型的な悩みです。これは営業管理全般に共通する属人化の問題の、業態特有のあらわれ方です（全体像は営業DXの全体像で解説しています）。

候補者・求人・企業の情報は、どんな構造で一元化すればいいですか？

一元化とは「1つのファイルにまとめること」ではなく、データを業態に合った構造に分けた上で相互につなぐことです。人材紹介業なら、次の5種類に分けます。

データ	中身	管理上の役割
候補者	経歴・スキル・希望条件・転職意欲	マッチングの片翼
求人企業	会社情報・契約条件・採用背景	マッチングのもう片翼
求人票	必須条件・歓迎条件・年収・勤務地	検索と照合の単位
推薦履歴	推薦日・選考状況・結果・辞退/見送り理由	候補者と求人をつなぐ記録
活動履歴	面談・電話・メールなどの接触記録	温度感と経緯の根拠

設計の要は2つです。第一に、求人企業と求人票を分けること。1社が複数の求人を出すため、企業に求人情報を直接書き込む構造ではすぐ破綻します。第二に、推薦履歴を独立したレコードにすること。1人の候補者は複数の求人に推薦され、1つの求人には複数の候補者が推薦されます。この多対多の関係を独立した記録として持つことで、初めて「いまどの組み合わせがどの選考段階にあるか」という進捗管理と、「なぜ見送った・辞退されたか」という理由の蓄積が両立します。

進捗管理は両面のパイプラインになります。候補者側は登録→面談→推薦→選考→内定→入社、企業側は接点→契約→求人受託→推薦→成約。この2本を推薦履歴が接続する、と捉えると全体像が整理できます。

面談や連絡の履歴入力が負担です。入力を増やさずに記録を残せますか？

残せます。原則は、人が手で入力するのは「選考の状況」と「面談・会話のメモ」だけに絞り、それ以外は自動で入る設計にすることです。メールのやり取りを候補者・企業のレコードに自動でひも付ける、Webフォームからのエントリーを自動で候補者として登録する、メッセージアプリでの連絡やオンライン面談の記録を接触履歴として自動蓄積する——こうした構成は、汎用的なCRMの標準機能や連携で組み立てられます。

履歴入力の負担が大きい会社ほど、「せっかくシステムを入れるなら」と入力項目を増やして自滅しがちです。必須項目の絞り込み方と「勝手にデータが入る」仕組みの作り方は、入力最小主義のCRM項目設計で実例つきで解説しています。人材紹介業では特に、候補者との接触頻度が高いぶん、履歴の自動化が効く度合いも大きくなります。

そして履歴が自動で残ると、掘り起こしが仕組みに変わります。最終接触日と選考状況を条件に「半年以上連絡していない、一次面接まで進んだ経験のある候補者」のようなリストを自動抽出し、フォロー連絡につなげる。これは記録が残っていて初めて成立する業務です。

マッチングを個人の勘から仕組みに変えるには？

一元化の実利が最も分かりやすく出るのがここです。同じデータベースに両面の情報が載っていれば、求人を起点に条件へ合う候補者を絞り込む・候補者を起点に合いそうな求人を絞り込む、という双方向の検索が同じ画面でできるようになります。条件項目（勤務地・年収・経験・資格など）が構造化されていれば、担当者が変わっても同じ精度で候補を洗い出せます。

もう一つ重要なのが、検討した組み合わせの結果を推薦履歴に残すことです。推薦に至らなかった理由、選考で落ちた理由、候補者が辞退した理由——これらは記録されないと単なる徒労ですが、記録されれば「この企業はこういう候補者を通しやすい」「この条件のズレは後で辞退につながりやすい」という、自社にしかないマッチングの資産になります。

AIマッチングはどう考えればいいですか？

AIマッチングとは、候補者と求人を複数の観点で照合し、候補の一覧・合致度・その理由・確認すべき不足情報を返す仕組みのことです。条件の完全一致だけでなく、職務経歴や面談メモのような文章情報も含めて「なぜ候補になり得るか」を説明つきで出せる点が、単純な条件検索との違いです。

ただし、効果を期待する前に押さえるべき設計原則が3つあります。

第一に、AIの役割は判断ではなく作業の肩代わりに置くこと。候補者本人の意思確認や推薦可否の最終判断はAIには任せられません。AIが省けるのは、候補の初期絞り込みのリストアップ、推薦理由文の下書き、確認すべき不足情報の洗い出しといった、判断の前段にある作業です。第二に、スコアを1つの数字にまとめすぎないこと。必須条件（足切り）・希望条件・経験の近さ・活動状況（重複推薦や過剰接触の防止）を分けて見せなければ、担当者は結果を検証も説明もできません。第三に、順番はデータ設計が先ということです。希望条件が自由記述のメモにしかない、求人票の書き方が人によって違う、推薦履歴が残っていない状態では、どんなAIを載せても出力の精度は安定しません。前セクションまでの一元化は、それ自体が業務改善であると同時に、AI活用の前提整備でもあります。

宮村の見解: 「人材紹介の会社からAIマッチングのご相談を受けたとき、私たちが最初に見るのはAIではなくデータの持ち方です。候補者の希望条件と推薦履歴が構造化されていない状態でAIを足しても、出てきた候補を担当者が検証できず、結局使われなくなります。一元化が先、AIは後——この順番を崩さないことが、遠回りに見えて最短です」（宮村佳祐・株式会社etika代表取締役）

実際の人材紹介会社は、どんな理由でこの仕組みを選んでいますか？

私たちが支援した人材紹介会社の実例を2つ紹介します（いずれも社名は非公開）。

特定領域に特化した人材紹介会社では、導入の目的は2つでした。1つは、事業拡大に伴う個人情報管理のガバナンス強化。もう1つは、複数の媒体から入ってくる候補者データを統合し、将来のマーケティング施策（配信の自動化など）につなげる基盤づくりです。業界専用パッケージや大手SFAも比較した上で、決め手になったのは「自社独自のオペレーションと計数管理を作り込めるカスタマイズ性」と、機能あたりのコストでした。導入後は追客メールの自動化や一覧画面での直接編集が日々の効率化に効いているとのことです。

東京都の人材紹介会社では、候補者と求人企業について「入口の獲得から紹介後の関係管理まで」を1つの仕組みで、かつ安価に自社向けに構成できる点が選定理由でした。

2社に共通するのは、専用ツールの決まった型に業務を合わせるのではなく、自社のマッチング軸とオペレーションに仕組みの側を合わせるという選び方です。なお、当社ではCRMはZoho CRMを標準採用しています（他ツールのご相談も可能です）。ツール固有の設定・活用手順は、当社が運営に関わるCRMサポートセンターで扱っています。

まとめ

人材紹介業の情報管理が散らかるのは、候補者と求人企業という2種類の顧客を持つ業態構造が原因であり、担当者の努力不足ではありません。処方箋は、①候補者・求人企業・求人票・推薦履歴・活動履歴の5分割でデータを設計し直す、②履歴は自動で残る仕組みにして手入力を最小化する、③推薦の検討結果を記録してマッチングと掘り起こしを仕組み化する、の3点です。AIマッチングはその先にある選択肢であり、データ設計ができていない段階で導入しても機能しません。

この一元化を、データ設計から週次の運用定着まで伴走して支援しているのがプロセス管理支援です。まずは自社の管理の現在地を知りたい方は、見込み客から受注までのプロセス無料診断をご利用ください。候補者・求人・企業の情報がいまどこに散らばっているかを整理するだけでも、着手すべき順番が見えてきます。

よくある質問

人材紹介業で候補者と求人企業の管理がバラバラです。どう一元化すればいいですか？

候補者・求人企業・求人票・推薦履歴・活動履歴の5種類にデータを分け、相互にひも付く形で1つのデータベースに載せるのが基本です。ポイントは、企業と求人票を分けること（1社に複数求人があるため）と、推薦・マッチングの検討履歴を独立したレコードとして残すことです。ファイルを1つに統合するのではなく、データの構造を業態に合わせて設計し直すことが一元化の実体です。

人材紹介の業界専用システムと汎用CRM、どちらを選ぶべきですか？

自社のオペレーションをどこまで作り込みたいかで決まります。専用システムは業界の標準フローが最初から揃う反面、独自のマッチング軸や計数管理をフローに反映しにくいことがあります。私たちが支援した人材紹介会社では、専用パッケージも比較検討した上で、自社独自のオペレーションを反映できるカスタマイズ性を重視して汎用CRMを選定しました。自社集客や独自プロセスを強みにしたい会社ほど、汎用型の作り込みが向く傾向があります。

面談や電話・メッセージの履歴を手入力するのが面倒です。自動化できますか？

かなりの部分は自動化できます。メールのやり取り、Webフォームからのエントリー、メッセージアプリでの連絡、オンライン面談の記録などは、候補者や企業のレコードに自動でひも付ける構成が汎用CRMの標準機能や連携で組めます。手で入力するのは「選考がいまどういう状況か」と「面談で何が分かったか」だけに絞るのが原則です。入力項目の絞り込み方は入力最小主義の記事で詳しく解説しています。

AIマッチングを導入すれば、担当者の推薦業務は要らなくなりますか？

なりません。候補者本人の意思確認、企業への推薦可否の判断、個人情報への配慮は担当者にしかできない仕事です。AIマッチングが省けるのは、候補の初期絞り込み、推薦理由の下書き、確認すべき不足情報の洗い出しといった「判断の前段の作業」です。AIの出力を判断結果ではなく判断材料として扱い、最終確認を担当者に残す設計が現実的です。

AIマッチングを始める前に、まず何を整備すべきですか？

データ設計です。候補者の希望条件が自由記述のメモにしかない、求人票の必須条件の書き方が担当者ごとにバラバラ、推薦・辞退の履歴が残っていない——という状態では、AIを載せても出てきた候補を検証できません。候補者・求人・推薦履歴を項目として構造化し、履歴が自動で蓄積される状態を先に作ることが、結果的にAI活用への最短ルートになります。

登録から時間が経った候補者の掘り起こしはどう仕組み化すればいいですか？

最終接触日と選考状況を条件にリストを自動抽出し、フォローの連絡につなげる形が基本です。前提として、面談や連絡の履歴が候補者レコードに自動で残っていること、推薦・見送り・辞退の結果が記録されていることが必要です。履歴が残っていれば「半年前に一次面接まで進んで辞退した候補者」のような精度の高い抽出ができ、掘り起こしが個人の記憶に頼らない業務になります。