1社にまとめるか業務ごとに分けるか

採用代行を使うとき、業務をまとめて一社に任せるか、工程ごとに違う相手に頼むか。この選択は費用の問題ではなく、情報を集約したいのか、専門性を取りたいのかという設計の問題です。どちらにも噛み合う場面があり、途中で切り替えることもできます。判断の軸と、移行するときの順番を整理します。

集約と分散で何が変わるか

集約の最大の利点は、工程のあいだで情報が落ちないことです。スカウトを送った相手の反応が、応募対応にも日程調整にも引き継がれる。同じ担当者が全体を見ているので、途中の判断も速くなります。

分散の最大の利点は、工程ごとに得意な相手を選べることです。スカウトの運用に強い会社と、事務の処理量が出せる会社は、必ずしも同じではありません。

集約が向く場面

社内に採用の司令塔がいない。管理する人がいないなら、窓口は少ないほうが回ります。複数社を並行させると、管理だけで時間が埋まります。

職種が少なく、採用の型が決まっている。同じ職種を継続的に採るなら、一社が学習した内容がそのまま蓄積します。

立ち上げの段階にある。要件の整理から運用の設計までを一続きでやるなら、分けると引き継ぎが発生します。

採用の規模が大きくない。分けるほどの業務量がなければ、分けることで生まれる管理の手間のほうが大きくなります。

分散が向く場面

職種の性質が大きく違う。技術職と営業職では、候補者の見方も文面の書き方も違います。工程ではなく職種で分ける形になります。分け方の設計は複数社に同時発注してよいかで扱っています。

特定の工程だけ量が突出している。日程調整だけが大量に発生するなら、その工程を処理量の出せる相手に切り出す形があります。

依存を避けたい。一社にすべてを預けると、その会社を止めたときに採用が全面的に止まります。分けておけば、部分的に止められます。

社内に管理できる人がいる。複数の窓口を捌ける人がいるなら、分散の利点を取りにいけます。

エラベルの見解

集約か分散かを考えるとき、依存という言葉の中身を分けて見てください。依存には二種類あります。

一つは業務の依存です。その会社に頼まないと採用が回らない状態。これは分散すれば減ります。ただ、分散にも管理の手間という代償があります。

もう一つは情報の依存です。求人原稿も、検索条件も、候補者データも、判断の基準も、代行会社の側にしかない状態。こちらは分散しても減りません。むしろ、分散したほうが情報が散らばって、自社に集まらなくなることがあります。

そして実際に困るのは、二つめのほうです。業務の依存は、時間をかければ別の会社に移せます。情報の依存は、移す元がなければどうにもなりません。

だから、集約か分散かを決める前に、情報を自社に置く設計を作るほうが先です。採用管理システムを自社で持つ、成果物を編集できる形式で受け取る、判断の基準を文書に残す。ここができていれば、集約しても依存は生まれにくい。できていなければ、分散しても安心にはなりません。

集約するときに決めること

一社にまとめるなら、次を決めておきます。

• 範囲を工程で書く。まとめるからこそ、何が入って何が入らないかを明確にします
• 成果物の帰属。集約すると、その会社に情報が溜まりやすくなります。引き渡しの形式を決めます
• 担当体制。一社にまとめると、担当者一人の負荷が上がります。何人で見るのか、交代時にどうするのか
• 止めるときの手順。全面的に止まるリスクがあるため、引き継ぎの範囲を先に決めておきます
• 範囲外が出たときの追加ルール。まとめて頼むほど、隣接業務が発生しやすくなります

このうち、止めるときの手順を締結時に決めておくのが効きます。集約の不安は「止められなくなること」なので、止め方が決まっていれば集約の判断はしやすくなります。

分散するときに決めること

工程や職種で分けるなら、次を決めておきます。

• 情報の置き場所を一本化する。自社の採用管理システムに集約し、各社にアクセス権を渡す
• 受け渡しの形式。どのタイミングで、何を、どこに記録して渡すか
• 重複の判定基準。同じ候補者に複数社が接触しないための記録の運用
• 定例の持ち方。社数分の定例をどう回すか。合同で行うか、個別にするか
• 社内の司令塔。全体を見る人を決める。決めないと、誰も全体を把握していない状態になります

受け渡しの形式が決まっていないと、引き継ぎのたびにやりとりが発生します。この手間が積み上がると、分散の利点を打ち消します。

切り替えの順番

途中で形を変えることもできます。よくある移行の順番です。

分散から集約へ。うまく回っている工程を軸にして、そこを担当している会社に範囲を広げる形が自然です。範囲を広げる前に、他社が持っている情報を回収しておきます。

集約から分散へ。まず一つの工程を切り出して試します。いきなり全部を分けると、情報の受け渡しが整わないまま運用が始まります。切り出すなら、受け渡しの線が明確な工程からです。

どちらの移行でも、情報の回収が先です。求人原稿、検索条件、候補者データ、稼働報告の履歴。これらを自社に集めてから体制を変えます。集めずに変えると、新しい体制がゼロから始まります。

移行の時期は、契約の更新に合わせると手続きが一度で済みます。更新の予告期限については自動更新条項で気をつけることにまとめています。

エラベルの見解

集約か分散かという問いは、多くの場合会社の単位で考えられています。ただ、実際に業務を担っているのは個人です。

一社に集約しても、社内で担当者が工程ごとに分かれていれば、実態は分散に近くなります。逆に、分散していても、それぞれの会社で同じ人が長く担当していれば、情報は人の中に蓄積します。

だから、集約と分散の判断をするときは、その体制で誰が全体を見るのかを確認してください。一社に集約するなら、その会社の中で全体を見る人がいるのか。分散するなら、自社の中に全体を見る人がいるのか。どちらの体制でも、全体を見る人が一人はいる必要があります。

そして、その人が替わるときに何が引き継がれるのかを聞いておきます。体制の議論は、最後には人の議論になります。会社の数を決める前に、誰が全体を見るのかを決める。この順番で考えると、集約と分散のどちらを選んでも運用は安定します。

まとめ

• 集約か分散かは費用ではなく、情報を集めるか専門性を取るかの設計の問題
• 集約が向くのは、司令塔がいない・職種が少ない・立ち上げ期・規模が大きくない場合
• 分散が向くのは、職種の性質が違う・特定工程の量が多い・依存を避けたい・管理できる人がいる場合
• 依存には業務の依存と情報の依存がある。後者は分散しても減らない
• 体制を決める前に、情報を自社に置く設計を作る
• 集約するなら止めるときの手順を、分散するなら受け渡しの形式を決める
• 移行は情報の回収が先。契約更新の時期に合わせる
• 会社の数より、誰が全体を見るのかを先に決める

よくある質問

集約したほうが費用は安くなりますか

まとめることで交渉の余地が生まれることはあります。ただ、範囲が広がるぶん稼働量も増えるので、単純に安くなるとは限りません。比べるなら、集約した場合と分散した場合で、同じ範囲・同じ稼働量になるようにそろえてから総額を出します。比較の手順は見積もりの読み方にまとめています。

一社に集約すると足元を見られませんか

情報が自社に残っていれば、切り替えの選択肢は保てます。求人原稿、検索条件、候補者データ、判断の基準。これらを編集できる形式で受け取る契約にしておけば、依存の度合いは下がります。集約そのものより、成果物の帰属を決めているかどうかが効きます。

分散していると採用の全体像が見えません

情報の置き場所が一本化されていない可能性があります。自社の採用管理システムに候補者と接触履歴を集約し、各社にアクセス権を渡す形にすると、全体像が保てます。あわせて、社内で全体を見る人を決めてください。分散の運用は、司令塔がいることが前提になります。