ソーシングのどこで時間が溶けているか

候補者を探す作業が終わらないという相談は、探す件数の話として出てきます。実際に時間を取られている場所を分けると、探すこと自体より、その前後にあります。

同じ条件を媒体ごとに入れ直している。 求人媒体や人材データベースを複数使っていると、検索の項目名も選択肢も媒体ごとに違います。「経験年数」で絞れる媒体、職種の分類から選ぶ媒体、フリーワードしか無い媒体が混ざります。1つの募集要件を、媒体の数だけ翻訳し直すことになります。

結果を並べて比べる形になっていない。 媒体ごとに一覧を書き出しても、載っている項目が違います。ある媒体には直近の在籍企業が出るが、別の媒体には出ない。ある媒体は経験年数を数値で持つが、別の媒体は自己紹介文の中に書かれている。この状態では、どの候補者から声をかけるかを決められません。

同じ人が何度も出てくる。 複数の媒体に登録している候補者は、探すたびに別々の件として現れます。過去の募集で見送った人、以前にスカウトを送って返信が無かった人も、記録が別管理だと初めて見る人として並びます。

条件を変えた履歴が残っていない。 条件を緩めて広げた、絞って減らしたという操作は、担当者の手元で行われて消えます。次の募集で同じ職種を扱うとき、どの条件がどれだけ該当したかを思い出すところから始まります。

自動化で減らせるのは、この4つです。誰に声をかけるかという判断は減りません。ここを取り違えると、機械が出した候補者リストを採用担当が全件見直すことになり、作業が増えます。

もう1つ、工程の外側に原因が置かれている場合があります。募集要件が検索できる言葉になっていないと、条件をどう組み立てても該当が噛み合いません。詰め方は後述します。

工程を分けて、どこまでを機械に渡すか決める

ソーシングを工程に分けます。

  1. 募集要件の受け取り … 職種、必要な経験、勤務地、雇用形態、募集の背景を受け取る
  2. 検索条件の組み立て … 要件を、媒体の検索項目で表現できる形に変換する
  3. 媒体をまたいだ収集 … 各媒体で検索し、結果を1か所へ集める
  4. 項目を揃える … 媒体ごとにばらばらの項目を、同じ意味の項目へ寄せる
  5. 同じ人を1件にまとめる … 重複と、過去に接触した人を突き合わせる
  6. 比較できる一覧に整える … 候補者を要件の軸で横に並べ、確認が必要な点を添える
  7. 声をかける人を決める … 採用担当が選ぶ
  8. スカウト文を確認して送る … 文面を人が見てから送信する
  9. 記録 … 使った条件、該当数、送信の結果を残す

機械に渡すのは2から6です。7と8は人が持ちます。9は仕組みで支えます。

候補者ソーシングの工程と、機械に渡す範囲 募集要件の受け取りのあと、検索条件の組み立て、媒体をまたいだ収集、項目を揃える処理、同じ人を1件にまとめる処理、比較できる一覧への整理を機械が行う。声をかける相手の決定とスカウト文の送信は採用担当が持ち、使った条件と結果は記録として残す。 機械に渡す工程 採用担当が判断を持つ工程 1. 募集要件の受け取り 職種・経験・勤務地・背景 2. 検索条件の組み立て 媒体の項目へ言い換える 3. 媒体をまたいだ収集 結果を1か所へ集める 4. 項目を揃える 同じ意味の項目へ寄せる 5. 同じ人を1件にまとめる 重複と過去の接触を突合 6. 比較できる一覧 要件の軸で横に並べる 7. 声をかける人を決める 誰に送るかを人が選ぶ 8. 文面を確認して送る 下書きは機械、送信は人 9. 記録 条件・該当数・返信を残す 機械側は候補者を絞り込まない。条件に該当した理由を添えて並べるところまでを担う 9の記録が2へ戻り、次の募集の条件の起点になる
検索条件の組み立てから一覧の生成までを機械に渡し、誰に声をかけるかと文面の送信は採用担当が持ちます。使った条件と結果は記録に残し、次の募集で使います。

工程を分けておくと、うまくいかないときの直し先が決まります。該当が少なすぎるなら2、集めた件数と媒体の画面の件数が合わないなら3、一覧の列が埋まらないなら4、同じ人が並んでいるなら5、担当者が結局プロフィールを全部開いているなら6です。全体を1つの指示で通す作りにすると、この切り分けができません。

探し始める前に、募集要件を検索できる言葉まで詰める

条件を組み立てても該当が噛み合わないとき、原因が検索の書き方ではなく、その手前の募集要件にあることがあります。求人票に書かれた「即戦力となる方」「主体的に動ける方」は、媒体の検索項目にも、候補者のプロフィールの記述にも対応しません。この状態で検索条件を作ると、担当者がその場の解釈で条件を決めることになり、該当が外れた理由を後から追えなくなります。

要件が詰まっていないまま進むと、次のような形で表に出ます。

  • 条件を変えると該当数は動くが、どの要件が効いて動いたのかが分からない
  • 一覧の該当の印を信用できず、担当者が結局プロフィールを全件開く
  • 前回の条件を見ても意図が読めず、募集のたびに条件を作り直す
  • 面談まで進んだ段階で、配属先から「求めていた人と違う」と戻る

いずれも検索条件を直しても解消しません。要件を詰める作業は募集の初期に時間を取られるように見えますが、詰めないまま条件をやり直す時間のほうが、募集の期間を通すと長くなります。

要件を詰める手順

手順 誰と決めるか 出す形
1. 募集の背景を1文にする 採用担当と配属先の責任者 増員か欠員の補充か、いつまでに何を担ってほしいか
2. 入社後の半年で担う業務を3つまで挙げる 配属先 業務の名前と、その業務に関わる範囲・頻度
3. その業務を今担っている在籍者の経歴を言葉にする 配属先 社内の呼び方ではなく、職務経歴書に書かれる表現へ言い換える
4. 挙がった経験を「無いと成立しない」と「あると早い」に分ける 採用担当 必須と歓迎の二分。必須は5つ以内に抑える
5. 必須の各項目を、プロフィール上で確かめられる記述に置き換える 採用担当 「経験3年以上」ではなく「その業務を担当したと読める記述があるか」
6. 外す条件を書き出す 採用担当 同名の別職種、対象外の業種、接触済みの範囲

1で背景を1文にすると、後の判断の基準になります。 欠員の補充で着任の時期が決まっている募集と、体制を厚くするための増員では、条件を緩める方向が変わります。背景が共有されていないと、条件を広げるかどうかの相談が毎回振り出しに戻ります。

2で業務を3つまでに絞ります。 配属先に聞くと、担ってほしい業務は10個以上出ます。全部を要件にすると、該当する候補者がいない条件になります。上限を決めて、外した業務は「入社後に覚える範囲」として別に書き留めます。

3が要件の言語化で最も効きます。 求める人物像を抽象的な言葉で聞くと抽象的な答えしか返りませんが、今その業務を担っている人の経歴を挙げてもらうと、経験の中身が具体的な言葉で出てきます。それを職務経歴書に書かれる表現へ言い換えたものが、そのまま検索の言い換えの候補になります。ここで挙げる在籍者は要件を言葉にするための材料であって、同じ経歴の人だけを探す趣旨ではありません。年齢や性別のように職務と関係しない属性は、法令上の制約もあるため、条件に入れる前に人事で確認します。

4で必須を5つ以内に抑えます。 必須が10個ある要件は、実際には優先順位が付いていない状態です。該当がゼロに近くなり、結局どれかを無視して探すことになります。無視される項目が出るなら、最初から歓迎に置きます。

5で「確かめられる記述」まで下ろします。 経験年数は媒体に数値の項目があれば使えますが、多くはプロフィールの文章から読み取る形になります。何が書かれていれば該当と見なすかを先に決めておくと、一覧に載せる根拠の抜粋も、その基準で拾えます。

6の外す条件を、要件を詰める段階で書きます。 後回しにすると、該当数が多い状態のまま条件を確定させることになります。同名の別職種は職種によっては該当の半分近くを占めます。

ここで作った必須と歓迎の分け方は、選考でもそのまま使えます。判定できる粒度まで下ろす手順と、記載が無い場合の扱いは 書類選考をAIで自動化する で扱っています。ソーシングで詰めた要件を選考へ引き継ぐと、声をかけた基準と合否の基準がずれず、見送った理由も同じ言葉で残ります。

要件は募集ごとに書き換わります。この6手順を採用担当と配属先で1回通す時間を確保できないうちは、検索条件の自動化に着手しても、条件を直す作業が残り続けます。

募集要件から検索条件を組み立てる

求人票の文章をそのまま検索窓に入れても、該当は出ません。要件を、媒体が扱える形へ分解します。

分解の単位は次の4つです。

絞り込みに使う条件。 勤務地、雇用形態、必要な資格の保有など、媒体の項目で指定できるものです。ここは要件をほぼそのまま移せます。

言葉の候補を広げる条件。 職種名と業務の呼び方は、企業ごとに違います。同じ仕事が別の名称で登録されていることが多く、1つの名称だけで検索すると取りこぼします。1つの要件に対して、実際に使われている呼び方を複数持ち、いずれかに当たれば拾う形にします。この言い換えの一覧は、募集ごとに使い回せる資産になります。

外す条件。 同名の別職種、明らかに対象外の業種、自社グループの在籍者などです。外す条件を書いておかないと、該当数は増えるのに使える候補者が増えません。

機械では絞らず、後段で見る条件。 業務の進め方、扱った規模、経験の深さのように、プロフィールの文章を読まないと分からないものです。これを検索条件に入れると、書き方が控えめなだけの候補者が最初から外れます。検索では拾っておき、一覧の列として持つほうが取りこぼしが減ります。

前節で詰めた必須と歓迎の項目を、この4つの分解に振り分けます。1つの要件から検索条件と選考の評価軸の両方を導く形にすると、ソーシングと選考で別々の基準を持たずに済みます。

条件を組み立てたら、該当数を先に見ます。数十件しか出ない条件と、数千件出る条件では、その後の扱いが変わります。極端に少ないなら言い換えの候補が足りず、極端に多いなら外す条件が足りていません。条件を確定させる前に、この2つを調整します。

媒体をまたいだ情報を同じ項目に揃える

集めた情報は、そのままでは横に並びません。媒体ごとに、持っている項目も、値の書き方も違います。揃える対象を先に決めます。

揃える項目 媒体ごとに起きるばらつき 揃え方
候補者の識別子 媒体ごとに別のIDが振られ、氏名は非公開のことがある 媒体名とIDの組を主キーにする。氏名は主キーにしない
直近の在籍企業と期間 企業名のみ、業種のみ、非公開が混在する 取れた粒度をそのまま記録し、取れなかったことを空欄と区別する
経験年数 数値の項目を持つ媒体と、文章にしか書かれない媒体がある 数値は数値のまま、文章からは推定せず「文章から要確認」とする
業務内容 選択式の分類と、自由記述が混在する 自社の要件の軸に対して該当の有無で持つ。分類名をそのまま列にしない
勤務地・希望条件 表記の揺れ、都道府県と市区町村の粒度差 粒度を都道府県まで落として揃え、詳細は原文で残す
最終ログイン・更新日 項目名も更新の意味も媒体ごとに違う 「その媒体で最後に活動が確認できた日」として統一する
取得元と取得日 記録されないことが多い 全件に必ず付ける。後から情報が古いかを判断できなくなる

取れなかった項目を、値が無いことと区別します。 「非公開のため取得できなかった」と「その候補者に該当が無い」は別です。同じ空欄にすると、一覧を見た担当者は後者と読み、条件を満たす候補者を外します。

文章から数値を作らないようにします。 自己紹介文から経験年数を推定させると、もっともらしい数値が入ります。数値として一覧に載った時点で、担当者はそれを媒体が持つ数値と同じものとして扱います。推定した値を持つなら、推定であることが一覧上で分かる形にします。

取得元と取得日は全件に付けます。 候補者の情報は時間が経つと古くなります。3か月前に集めた情報と今週集めた情報が同じ列に並んでいると、在籍企業が変わっている候補者に古い前提で声をかけることになります。

分類名をそのまま列にしないようにします。 媒体の職種分類は、その媒体の都合で作られています。列を媒体の分類に合わせると、媒体が増えるたびに列が増えます。自社の要件の軸を列にして、媒体の値をその軸へ寄せる向きにします。

同じ人を1件にまとめる

重複の解消は、ソーシングで最も手作業が残りやすい部分です。氏名が非公開の媒体があるため、名前で突き合わせる方法は使えません。

突き合わせに使えるのは、複数の項目の組み合わせです。

突き合わせの材料 単独での確からしさ 扱い
同じ媒体の同じID 確実 無条件に同一とする
連絡先(応募や返信で判明したもの) 高い 同一とする。ただし取得できる場面が限られる
在籍企業と在籍期間の一致 他の材料と組み合わせる。大企業では一致しやすい
保有資格の番号や登録番号 高い 取得できていれば有力な材料になる
プロフィール文の一致 同じ文面を複数媒体に貼っている場合に効く
職歴の並びの一致 企業名の並びと年の組み合わせで見る
氏名の一致のみ 低い 単独では同一と判定しない

判定は3つに分けます。同一と確定するもの同一の可能性があるもの別人として扱うものです。真ん中を機械が確定させないのが要点です。

同一の可能性があるものは、まとめずに隣り合わせて出します。「この2件は同じ人かもしれない」と示し、担当者が1回見て決めます。決めた結果は記録し、次回以降は確定したものとして扱います。この判断は繰り返し使えるため、回数を重ねるほど確認が減ります。

まとめるときは、元の件を消さないようにします。どの媒体のどの登録をまとめたかを残しておかないと、片方の情報が更新されたときに追随できません。表示は1件、内部は複数件を束ねた形にします。

過去の接触履歴との突き合わせも、この工程に入れます。 以前スカウトを送って返信が無かった人、選考の途中で辞退した人、他部署が並行して接触している人は、新しい候補者と同じ列に並べません。過去の接触があることを一覧に出し、再度声をかけるかは担当者が決めます。この判定を機械が行うと、送ってはいけない相手に送る事故になります。

比較できる一覧に整える

一覧の目的は、順位を出すことではなく、担当者が短時間で選べる状態を作ることです。

一覧に載せる列は次のようになります。

  • 候補者の識別子(媒体名を含む形)と、束ねた登録の数
  • 要件の軸ごとの該当(該当する/該当しない/情報が無い)
  • 該当と判定した根拠になったプロフィール上の記述(原文の抜粋)
  • 情報の取得元と取得日、その媒体での最終の活動日
  • 過去の接触の有無と、その結果
  • 確認が必要な点(推定値が入っている、情報が古い、同一の可能性がある、など)

総合点で並べ替えないようにします。 軸ごとの該当を合計して点数を出すと、担当者は上から順に見て、下位は開きません。点数の付け方は募集の背景によって変わるうえ、その重み付けは一覧の上に書かれていません。並べ替えるなら、最終の活動日のように選考の内容に踏み込まない順にします。

根拠は原文の抜粋で持ちます。 「該当あり」とだけ書かれた列は、担当者が確かめようとした時点でプロフィールを開くことになり、一覧の意味がなくなります。どの記述をもって該当としたかが1行添えてあれば、その場で当否を判断できます。

情報が無いことを列の中に出します。 非公開の項目が多い候補者は、要件を満たさないのではなく、確かめられていないだけです。これを「該当しない」と同じ表示にすると、そういう候補者が構造的に外れます。

一覧は使い捨てにしません。 同じ職種は繰り返し募集します。今回声をかけなかった候補者にも、見送った理由が残っていれば、次の募集で使えます。一覧を都度作り直す運用にすると、この蓄積が消えます。

誰に声をかけるかは機械に決めさせない

ソーシングは、まだ応募していない人に企業側から接触する行為です。誤った相手に送った場合、後から取り消せません。この性質から、線引きは選考より手前に置きます。

工程 機械側で確定してよいか 理由
検索条件の候補を作る 確定してよい(人が中身を見られる形で) 条件は実行前に確認できる
媒体から情報を集める 確定してよい 取得のルールを先に決められる
項目を揃える、表記を統一する 確定してよい 変換の規則を先に決められる
同じ媒体の同じIDの重複を1件にする 確定してよい 同一であることが確実
媒体をまたいだ同一人物の判定 候補として出す。確定させない 誤ってまとめると別人の情報が混ざる
要件への該当の判定 材料として出す。絞り込みには使わない プロフィールの記述の解釈が入る
候補者の順位付け 行わない 順位が確認の順序を決めてしまう
声をかける相手の決定 行わない 送信の取り消しができない
スカウト文の送信 行わない(人の承認を経る) 誤送信が候補者と自社の双方に影響する
過去に接触した人への再送の判断 行わない 履歴の解釈と関係性の判断が必要

表の下4行が、この記事で最も動かしにくい部分です。機械側の出力から送信までを直結させない。 件数が多くて全件を人が見られないなら、一覧の並べ方や表示する列を変えて対処します。閾値を置いて自動で送るのとは別の解き方です。

文面についても同じ線を引きます。候補者の経歴に触れた文面の下書きを機械に作らせるのは、確認を前提にすれば成り立ちます。ただし、下書きは事実の取り違えを含みます。在籍していない企業の名前、担当していない業務が入った文面は、そのまま送れば候補者に伝わります。文面に含めた事実が、一覧のどの記述から来たのかを示せる形にしておくと、確認が速くなります。

候補者の情報を外部のサービスへ渡す構成にする場合は、社内の取り扱い規程との照合が要ります。生成AIを業務で使うときのルールの作り方は 生成AIの社内利用ルールをどう作るか で扱っています。集めた情報の保存場所、保存期間、閲覧できる範囲は、実装より先に決めてください。

条件と結果を記録して、次の募集で使う

ソーシングは1回で終わりません。同じ職種を半年後にまた募集します。記録が残っていないと、そのたびに条件をゼロから組み立て直すことになります。

募集ごとに残す項目は次のようになります。

  • 募集要件の版と、そこから組み立てた検索条件の全文
  • 媒体ごとの検索の実行日時と、該当した件数
  • 集めた候補者の件数、まとめた後の件数、まとめの判定の内訳
  • 担当者が声をかけると決めた件数と、その判断
  • 送信後の返信の有無、面談に至った件数
  • 同一人物の判定について、担当者が機械の候補を採否した記録

条件と該当数を組で残します。 どの言い換えを足したら該当が増えたか、どの外す条件で何件減ったかが分かる形にします。次の募集は、前回の条件の写しから始められます。

担当者が機械の判定を覆した記録を残します。 該当ありとした候補者を担当者が外し続けている軸は、条件の書き方が実務と合っていません。逆に、該当なしとされた候補者に担当者が声をかけているなら、条件が狭すぎます。この履歴が、条件を直す材料になります。

同一人物の判定の採否も残します。 どの材料の組み合わせで判定が当たり、どこで外れたかが見えます。突き合わせの規則は、この記録を見て調整します。

何がどれだけ変わったかの測り方は AI導入の効果測定と投資判断 で整理しています。ソーシングの場合、送信数や返信率だけを見ると採用市場の変動と区別がつきません。条件の組み立てにかけていた時間、重複の解消にかけていた時間のように、この仕組みが直接触る作業の時間を先に測っておくと、比較ができます。

最初に切り出す範囲

全職種を対象に一度に作ると、条件の書き下ろしと媒体ごとの取得方法の確認が並行して膨らみます。範囲を絞ります。

繰り返し募集していて、要件が安定している職種を1つ選びます。 単発の募集は、条件を作る手間に見合いません。

媒体は2つから始めます。 1つでは媒体をまたぐ部分が試せず、この仕組みの中心が確かめられません。最初から全媒体を対象にすると、取得方法の確認だけで止まります。

項目を揃えるところまでを先に動かす選び方もあります。 検索条件の組み立てまで一度に作らず、担当者が手で書き出したファイルを取り込み、同じ項目に揃えて一覧にするところから始めます。効果が出るかを早く確かめられ、条件の書き下ろしを並行して進められます。

過去の募集で声をかけた候補者のリストで答え合わせをします。 実際に担当者が選んだという比較対象があるため、条件が狭すぎる箇所と、外す条件が足りない箇所が同時に見えます。ここで条件を直してから、進行中の募集に使います。

担当者の確認は全件残したまま始めます。 任せる範囲を広げるかは、覆された判定の記録から決めます。ただし、声をかける相手の決定と送信は、広げる対象に含めません。

検証から本番運用までの進め方と、見積の考え方は AIエージェント開発の進め方 で整理しています。ソーシングは、募集要件が変わるたびに条件を直し続ける必要がある領域です。都度外部に依頼する形では更新が止まるため、条件を触れる人を社内に置く前提で設計してください。

まとめ:候補者ソーシングの自動化で決めておくこと

  • 減らせるのは、条件を媒体ごとに入れ直す作業、結果を揃える作業、重複を解消する作業、条件の履歴を残す作業。誰に声をかけるかの判断は減らない
  • 工程は要件の受け取り、条件の組み立て、収集、項目を揃える、同じ人をまとめる、一覧化、相手の決定、送信、記録に分ける。機械に渡すのは条件の組み立てから一覧化まで
  • 募集要件は、背景の1文、担う業務3つ、在籍者の経歴の言い換え、必須と歓迎の二分、確かめられる記述への置き換え、外す条件の順で詰めてから検索条件に落とす。必須は5つ以内に抑える
  • 検索条件は、絞り込みに使う条件、言い換えを広げる条件、外す条件、後段で見る条件の4つに分ける。文章を読まないと分からない要件を検索条件に入れない
  • 揃える項目は先に決める。取れなかった項目と該当が無い項目を区別し、取得元と取得日を全件に付ける
  • 文章から経験年数などの数値を推定させない。推定するなら推定と分かる形で出す
  • 同一人物の判定は、確定・可能性あり・別人の3つに分け、真ん中を機械が確定させない。まとめても元の件は残す
  • 過去に接触した候補者との突き合わせを工程に入れ、再送するかは担当者が決める
  • 一覧は総合点で並べ替えず、該当の根拠を原文の抜粋で添える。情報が無いことを列に出す
  • 相手の決定、スカウト文の送信、再送の判断は機械側で確定させない。文面の下書きは事実の取り違えを含む前提で確認する
  • 条件と該当数を組で記録し、担当者が判定を覆した履歴を次の募集の材料にする
  • 最初は職種を1つ、媒体を2つに絞り、過去の募集のリストで答え合わせをしてから進行中の募集に使う

Augueでは、複数の媒体から集めた情報を揃えて名寄せする部分から、どこに人の判断を残すかの設計までを含めて開発に対応しています。自社の採用業務のどの工程から着手できるか整理したい方は、是非ご相談ください。

関連する記事

要件を判定できる粒度に落とす作業と選考への接続は 書類選考をAIで自動化する、開発の進め方と見積の考え方は AIエージェント開発の進め方、社内で扱う情報のルールづくりは 生成AIの社内利用ルールをどう作るか、導入後の効果の測り方は AI導入の効果測定と投資判断 を参照してください。

まずは現状をお聞かせください

弊社では具体的な要件が固まっていない段階でも、無料相談で現状をお聞きしていますので、お困りの際はご相談ください。

無料相談を予約する →

よくある質問

求人媒体に登録されている候補者の情報を、機械で集めてよいのでしょうか?

媒体ごとに扱いが違うため、契約と利用規約を先に確認してください。APIやCSVの書き出しが用意されている媒体もあれば、画面からの自動取得を禁じている媒体もあります。禁じられている媒体は、担当者が手で書き出したファイルを置く場所を決め、そこを起点に揃える設計にすれば、後段の仕組みはそのまま使えます。取得の可否と、集めた情報を社内のどこに保存してよいかは、人事と法務で判断する範囲です。

スカウト代行のサービスに任せるのと、社内に仕組みを持つのとでは何が違いますか?

分かれるのは条件の改善が誰の手元に残るかです。代行は稼働をすぐ確保できますが、どの条件でどれだけ該当したかの記録は先方に貯まります。社内に持つ場合は立ち上げに時間がかかる代わりに、条件の履歴が自社に残り、次の募集の起点にできます。募集が単発なら代行、同じ職種を繰り返し募集するなら社内寄りという分け方が目安になります。

仕組みを入れると、スカウトへの返信率は上がりますか?

上がるとは言えません。返信率は候補者との合致度、文面、送る時期、企業の知名度が混ざった結果で、そのうち仕組みが影響するのは合致度の部分だけです。判断材料にするなら、条件ごとに該当した人数と、その条件から送った分の返信率を分けて記録してください。条件の当たり外れが見えるようになると、次にどこを直すかは決められます。

候補者データベースの検索機能を使うのと、どこが違いますか?

媒体の検索機能は、その媒体の中だけで完結します。複数の媒体を使っていると、同じ条件を媒体ごとに入れ直し、結果を突き合わせる作業が残ります。仕組みを作る値打ちがあるのは、この媒体をまたぐ部分と、同じ人が複数の媒体に載っている場合をまとめる部分です。単一の媒体だけで採用が回っているなら、媒体の機能で足ります。