%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
「RAとCAで分業したら、候補者の温度感が企業側に伝わらなくなった」「企業の本当の採用要件が、面談している側に届いていない」——人材紹介で分業体制を採る会社から、よくうかがう話です。
「RAとCAで分業したら、候補者の温度感が企業側に伝わらなくなった」「企業の本当の採用要件が、面談している側に届いていない」——人材紹介で分業体制を採る会社から、よくうかがう話です。
分業そのものが悪いわけではありません。専門性が上がり、1人あたりの処理件数も増えます。問題は、分業した瞬間に情報の受け渡しが必要になるのに、その受け渡しを仕組みで持っていないことにあります。口頭とチャットで補っているうちは、担当者が忙しくなった瞬間に切れます。
RA/CA分業のCRM設計とは、求職者・求人企業・求人・選考という4種類のレコードについて、それぞれ誰を持ち主にし、誰がどこまで見られるようにするかを決める作業です。権限設定の話に見えますが、実際には組織の分業の形をデータ構造へ写す設計です。
この記事では、HubSpotを例に、RA/CA分業をCRM上でどう表現するかを整理します。分業体制を採っている、あるいはこれから移行する人材紹介会社の方に向けた内容です。次の4点がわかります。
- 3つの体制とCRM設計の関係 ── 両面型・分業型・ハイブリッドで、必要な設計がどう変わるかを示します
- 誰がどのレコードの担当者になるか ── 求職者・求人企業・求人・選考のそれぞれについて判断の基準を示します
- 選考の取引に2人の担当を持たせる方法 ── 標準の担当者は1レコードに1人しか持てない制約への対処です
- 見える範囲の設計 ── 絞りすぎると分業が回らなくなる、というトレードオフの扱い方を説明します
読み終える頃には、自社の体制に合わせたレコードの持ち主と権限の設計案が作れる状態になります。ぜひ最後までご確認ください。
分業で切れるのは「人」ではなく「レコードの担当者」
まず、分業したときにCRM上で何が起きるかを整理します。
これは特定の企業の組織図ではなく、人材紹介でよく採られる体制を一般化した整理です。
3つの体制の違い
| 体制 | 担当の持ち方 | CRM設計で重くなる点 |
|---|---|---|
| 両面型 | 1人が求職者と求人企業の両方を担当 | 情報は切れないが、個人に依存し引き継ぎが難しい |
| 分業型 | CAが求職者、RAが求人企業を担当 | 選考1件に2人が関わるため、担当の表現が要る |
| ハイブリッド | 新規開拓のみRA、既存はCAが両面 | 誰が担当かが案件ごとに変わり、ルール化が要る |
両面型はCRMの設計が軽く、分業型は重くなります。これは分業が悪いという意味ではなく、分業には設計コストが伴うという事実です。分業に移行するタイミングでCRMを見直すのは、順序として正しい判断です。
分業で起きる3つの断絶
分業型に移ると、次の3つが起きます。
- 候補者の温度感が企業側に伝わらない ── CAが面談で得た「実は他社の内定が出ている」といった情報が、RAの手元にない
- 企業の要件の背景がCAに届かない ── 求人票には書かれていない「この職種は前任者が半年で辞めた」といった文脈が共有されない
- 選考の進捗が二重管理になる ── CAとRAがそれぞれ自分の管理表を持ち、数字が合わなくなる
このうち3番目は、選考のレコードを1つに定めれば構造的に解決します。1と2は、情報を書く場所と読む場所を一致させる設計で解きます。
誰がどのレコードの担当者になるかを決める
分業設計の中心は、レコードごとに「持ち主」を決めることです。
求職者はCA、求人企業と求人はRA
出発点はシンプルです。
- 求職者（コンタクト）の担当者はCA ── 面談し、意向を把握し、意思決定に伴走する人
- 求人企業（会社）の担当者はRA ── 契約し、要件を握り、フィードバックを受ける人
- 求人（カスタムオブジェクト）の担当者もRA ── 求人は企業に紐づくため、企業と同じ持ち主が自然です
求人をカスタムオブジェクトで持つ設計はHubSpotで求人を管理する方法で、3層のデータ構造全体は人材紹介CRMのデータ設計で扱っています。業界全体の設計観点は人材紹介・人材派遣のHubSpot活用ガイドをご覧ください。
選考の取引は、担当者を1人しか持てません
問題は選考（求職者×求人の1件）です。この1件には、CAとRAの両方が関わります。しかし、HubSpotの標準の「担当者」プロパティーは1レコードに1人です。
ここでどちらか一方を担当者にして、もう一方を「なかったこと」にする設計にすると、必ず不満と抜け漏れが出ます。
追加のユーザー型プロパティーで両方を持つ
現実的な解は、標準の担当者にCAを置き、「RA担当」というユーザー型のプロパティーを追加してRAを持たせることです。HubSpotではプロパティーの型としてHubSpotユーザーを選べます（プロパティーを作成・編集する）。
この構成にすると、次のことができます。
- CA別・RA別の両方でレポートを切れる
- 「自分がRAとして関わっている選考」だけを見るビューが作れる
- ワークフローの通知先を、局面によってCAとRAで出し分けられる
どちらを標準の担当者にするかは、日々の運用でその取引を前に進める人で決めてください。多くの体制ではCAですが、企業側の意思決定が重い領域ではRAが標準側になることもあります。
担当は自動で埋める
RA担当を手入力にすると、必ず空欄が出ます。選考の取引が作られた時点で、紐づく求人（または企業）の担当者をコピーしてRA担当に入れる。この自動化をワークフローで組むのが確実です（ワークフローを作成する）。
見える範囲をどう設計するか
分業では「誰が何を見られるか」が運用の質を左右します。
レコードアクセス権の4つの単位
HubSpotでは、ユーザーごとにレコードの表示・編集・削除の範囲を設定できます。設定できる範囲は「全て」「チーム所有分」「自分の担当分のみ」「未割り当て分」です。チーム単位の権限を割り当てるには、Professional または Enterprise のサブスクリプションが必要です（レコードへのアクセス権を割り当てる）。
分業型では、次のような設計が起点になります。
| 対象 | CAの範囲 | RAの範囲 |
|---|---|---|
| 求職者（コンタクト） | 自分の担当分＋チーム所有分 | 参照のみ、または限定 |
| 求人企業（会社） | 参照可 | 自分の担当分＋チーム所有分 |
| 求人 | 参照可 | 自分の担当分 |
| 選考（取引） | 自分が関わるもの | 自分が関わるもの |
チームで括る
CAチーム、RAチームという単位を作っておくと、権限の設定とレポートの両方が楽になります。チームの作成はユーザー管理から行い、入れ子のチーム階層を作るには Enterprise が必要です。また、ユーザーを追加のチームに割り当てるには Marketing Hub・Sales Hub・Service Hub のいずれかの Professional または Enterprise が必要です（チームを作成・管理する）。
拠点や領域が複数ある場合は、「拠点 > 職能（CA/RA）」の順で階層を組むと、拠点長が自拠点の両職能を見られる形になり、実態に合いやすくなります。
絞りすぎると分業が回らなくなる
権限設計で最も多い失敗は、絞りすぎることです。CAが求人を検索できなければ、候補者に提案する求人を探せません。RAが候補者を見られなければ、企業に推薦する人を選べません。
分業は「担当は分ける、情報は共有する」が原則です。編集は担当者に限定し、閲覧は広く取る。この非対称な設計が、分業型では最も機能します。個人情報の観点で閲覧も絞る必要がある項目（連絡先など）は、プロパティー単位の閲覧制限で個別に対処するほうが、オブジェクト全体を絞るより副作用が小さくなります。
情報の受け渡しを仕組みで持つ
権限が整っても、情報が書かれていなければ意味がありません。
口頭とチャットに流れる情報を止める
分業で失われる情報の多くは、口頭かチャットで交わされています。これを止めるには、書く場所を1つに決めて、そこ以外では意思決定に関わる情報をやり取りしないルールを作るしかありません。
現実的な落としどころは、選考の取引レコードにメモとして残すことです。候補者の意向変化、企業からのフィードバック、選考日程の変更。これらを取引に書けば、CAとRAの両方が同じ場所を見ることになります。
引き継ぎの型を決める
「CAからRAへ、候補者を推薦するときに何を渡すか」を項目として固定してください。自由記述に任せると、忙しい人ほど省略します。
推薦時に必ず埋める項目の例を挙げます。
- 現職の状況（在職／離職、退職予定日）
- 選考を受けている他社の数と段階
- 譲れない条件と、譲れる条件
- 面談で確認済みの懸念点
これらを取引の必須プロパティーにしておくと、ステージを進めるときに埋めざるを得なくなります。ルールを人に守らせるのではなく、構造で守らせる設計です。
書く場所は「選考の取引」に寄せる
情報を書く場所として、求職者のコンタクト、企業の会社レコード、選考の取引の3つが候補になります。分業では、選考の取引に寄せるのが最も機能します。
理由は、CAとRAの両方がその1件に関わっているからです。コンタクトに書けばRAが見に行かなくなり、会社に書けばCAが見に行かなくなります。求職者そのものの属性（希望条件、経歴）はコンタクトに、企業そのものの属性（採用の傾向、決裁者）は会社に。そしてその1件の選考に関する動きは、すべて取引に。この切り分けが迷いを減らします。
面談メモは「事実」と「解釈」を分ける
候補者の情報は、事実（勤務先、年収、資格）と解釈（前向き、迷っている）が混ざりがちです。解釈だけが残っていると、担当が変わったときに判断の根拠が失われます。事実を選択肢やテキストで持ち、解釈はメモに書く。この分離を最初に決めておくと、後から集計もできます。
分業の成果をどう測るか
RAとCAでは、見るべき数字が違います。
| 職能 | 主な指標 |
|---|---|
| CA | 面談数、推薦数、推薦通過率、決定数、決定単価 |
| RA | 求人取得数、有効求人数（動いている求人の数）、企業あたり決定数、取引継続率 |
| 共通 | 推薦から決定までのリードタイム、選考辞退率 |
厚生労働省の集計によれば、有料職業紹介事業の常用就職件数は令和5年度に843,950件（前年度比9.0%増）、手数料収入は約8,362億円で、常用就職1件あたりの手数料は約93万円でした（令和5年度職業紹介事業報告書の集計結果（速報）、2025年3月31日発表）。1件あたりの単価がこの水準である以上、決定数だけでなく、決定に至らなかった推薦の量とその理由を測れるかどうかが改善の余地を左右します。
分業では、この「至らなかった理由」がCAとRAのどちらの領域にあるのかを切り分けられることが重要です。推薦通過率が低いのか、通過した後の辞退が多いのか。前者はRAの要件把握、後者はCAの意向把握に課題があります。取引のステージ通過日を残す設計にしておくと、この切り分けが自動で取れます。
レポートとビューを職能別に用意する
権限と担当者の設計ができたら、最後に「日々どの画面を見るか」を決めます。ここまで作って、分業の設計は完成します。
CAが毎日見る画面
CAが見たいのは、自分が担当する求職者のうち、動きが止まっているものです。具体的には次のようなビューが実用的です。
- 推薦済みだが、7日以上ステージが変わっていない選考
- 面談済みだが、まだ1件も推薦していない求職者
- 内定が出ていて、意思決定の期限が近い選考
いずれも「止まっているもの」を出すという共通点があります。順調に進んでいるものは、わざわざ見る必要がありません。
RAが毎日見る画面
RAが見たいのは、求人の充足状況と企業の温度感です。
- 募集中だが、直近14日で推薦が0件の求人
- 推薦は出ているが、書類選考の結果が返ってきていない選考
- 契約はあるが、直近90日でオーダーが出ていない企業
3つ目は特に重要です。取引が止まっている企業は、静かに離れていきます。動きの無さを検知する仕組みがないと、気づいたときには他社に切り替わっています。
管理者が週次で見る数字
管理者が見るのは、CAとRAのどちらにボトルネックがあるかです。推薦数と推薦通過率をCA別・RA別の両方で並べ、どちらの分布が偏っているかを確認します。
ここで片方の職能だけを評価する運用にしないでください。分業は連携で成立するため、片方だけを追い込むと情報の出し惜しみが始まります。共通指標（決定数、リードタイム）を必ず併記するのが、分業を機能させる運用上の要点です。
ダッシュボードは3枚まで
見る画面が多すぎると、誰も見なくなります。CA用・RA用・管理者用の3枚に絞り、それぞれ6つ程度のレポートに留めるのが現実的です。足りなくなってから足す進め方のほうが、定着します。
体制が変わるときに備える
人材紹介の会社では、両面型と分業型を行き来することが珍しくありません。
このとき、求職者・求人企業・求人・選考というレコードの分け方が正しければ、体制変更は「担当者の付け替え」で済みます。逆に、担当者ごとに別の管理表を持っている状態だと、体制変更のたびに作り直しになります。
同じことは事業の拡張にも当てはまります。紹介から派遣へ事業を広げる場合、レコードの単位が「スタッフ×オーダー＝稼働」に変わるため設計の見直しが要ります。関連する設計は次の記事で扱っています。
- 派遣側の設計 ── 人材派遣の稼働管理をCRMで設計する
- マッチングの運用 ── 候補者と求人のマッチングをCRMで運用する
データモデルを職能に依存させない。これが、組織が変わっても壊れない設計の条件です。
よくある質問
RA/CA分業のCRM設計について、ご相談の場でよくいただく質問をまとめました。
Q1. 選考の取引の担当者は、CAとRAのどちらにすべきですか。
日々その取引を前に進める人を標準の担当者にしてください。多くの体制ではCAですが、判断の基準は「進捗が止まったときに、誰に聞くのが自然か」です。もう一方はユーザー型のプロパティーで持てば、レポートも通知も両方で切れます。どちらを標準にするかで機能差はほぼありません。
Q2. CAが求人企業の情報をどこまで見られるようにすべきですか。
次の範囲までは見られるようにすることをおすすめします。
- 求人の内容
- 選考のフィードバック
- 過去の決定実績
逆に、契約条件や手数料率といった商取引の情報は絞る判断が一般的です。提案に必要な情報は開き、交渉に関わる情報は絞るという線引きが実務に合います。
Q3. 分業にすると、候補者から見て担当者が2人いる状態になります。混乱しませんか。
候補者との窓口はCAに一本化するのが基本です。RAが直接候補者とやり取りするのは、面接の日程調整など限られた場面に留めます。CRM側では、候補者への連絡履歴が誰からのものかを記録に残すようにしておくと、二重連絡の事故を検知できます。
Q4. 少人数で分業していますが、権限まで設計する必要はありますか。
10人未満であれば、権限を絞る必要性は高くありません。むしろ絞ることで情報が届かなくなる弊害のほうが大きくなります。先に決めるべきは権限ではなく担当者の設計です。誰がどのレコードを持つかを決めておけば、人数が増えたときに権限を後から足せます。
Q5. RA担当のプロパティーを追加したのに、埋まっていない取引が多くあります。どうすればよいですか。
手入力に任せていることが原因です。取引の作成時に、紐づく求人または企業の担当者を自動でコピーする仕組みを入れてください。既に空欄になっているものは、同じ条件で一括更新できます。今後の入力は自動化し、人が埋める項目を減らす方向で解くのが確実です。
まとめ
RA/CA分業のCRM設計は、組織の形をデータ構造に写す作業です。要点を整理します。
- 分業で切れるのはレコードの担当者。求職者はCA、求人企業と求人はRAという持ち主の設計が起点になります
- 選考の取引には担当者を2人持たせる。標準の担当者にCA、ユーザー型のプロパティーでRAを持つ構成が扱いやすい形です
- 担当は自動で埋める。手入力に任せると必ず空欄が出て、レポートが使えなくなります
- 編集は絞り、閲覧は広く取る。分業は「担当は分ける、情報は共有する」が原則で、絞りすぎると提案も推薦も止まります
- 引き継ぎの項目を構造で固定する。推薦時に必ず埋める項目を必須にすれば、ルールを人の意識に頼らずに済みます
最初の一歩としておすすめしたいのは、「直近で決定に至らなかった推薦を5件挙げ、CAとRAのどちらの情報が足りなかったかを書き出す」ことです。要件の把握が足りなかったのか、意向の把握が足りなかったのか。傾向が見えれば、最初に固定すべき引き継ぎ項目が決まります。
そのうえで、選考の取引にRA担当のプロパティーを1つ足す。ここから始めるだけでも、レポートの見え方が変わります。
自社の体制に合わせたCRMの担当者設計と権限設計を具体的に検討したい場合は、StartLinkの無料相談でご相談ください。現在の分業体制をうかがったうえで、設計の方向性をご提案します。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
