特開 2022-59328 採用支援システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022059328

(43)【公開日】2022-04-13

(54)【発明の名称】採用支援システム

(51)【国際特許分類】

   G06Q 10/10 20120101AFI20220406BHJP

【ＦＩ】

G06Q10/10 322

【審査請求】有

【請求項の数】8

【出願形態】ＯＬ

(21)【出願番号】P 2020166990

(22)【出願日】2020-10-01

(11)【特許番号】

(45)【特許公報発行日】2021-10-06

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＺＩＧＢＥＥ

(71)【出願人】

【識別番号】512313953

【氏名又は名称】株式会社ビズリーチ

(74)【代理人】

【識別番号】110002815

【氏名又は名称】ＩＰＴｅｃｈ特許業務法人

(72)【発明者】

【氏名】石井 智之

【テーマコード（参考）】

5L049

【Ｆターム（参考）】

5L049AA08

(57)【要約】

【課題】 採用活動を効率的に実施することを可能とする採用支援システムを提供する。
【解決手段】 採用支援システムは、求職者に関する求職者情報を管理する管理部と、前記求職者情報を出力する出力部と、を備え、前記管理部は、採用者が前記求職者に注目しているか否かを示すフラグ情報を前記求職者情報と対応付けて管理し、前記出力部は、前記フラグ情報を前記求職者情報と対応付けて出力する。
【選択図】 図２

【特許請求の範囲】

【請求項1】

求職者に関する求職者情報を管理する管理部と、
前記求職者情報を出力する出力部と、を備え、
前記管理部は、採用者が前記求職者に注目しているか否かを示すフラグ情報を前記求職者情報と対応付けて管理し、
前記出力部は、前記フラグ情報を前記求職者情報と対応付けて出力する、採用支援システム。

【請求項2】

前記管理部は、前記求職者が求職に応募した経路、前記求職者が求職に応募した職種及び前記求職者の選考の状態を示すステータスの少なくともいずれか１つを含む選考情報を前記求職者情報と対応付けて管理し、
前記管理部は、前記選考情報として２以上の選考情報を前記求職者情報と対応付けるとともに、前記フラグ情報として１つのフラグ情報を前記求職者情報と対応付ける、請求項１に記載の採用支援システム。

【請求項3】

前記選考情報は、前記求職者に対する前記採用者の評価を含む、請求項２に記載の採用支援システム。

【請求項4】

前記管理部は、前記フラグ情報の削除を制限する、或いは、前記フラグ情報の変更に関する権限を設定する、請求項１乃至請求項３のいずれか１項に記載の採用支援システム。

【請求項5】

前記フラグ情報は、前記採用者が注目するレベルを２段階以上で表す情報である、請求項１乃至請求項４のいずれか１項に記載の採用支援システム。

【請求項6】

前記管理部は、前記フラグ情報の登録者を前記フラグ情報と対応付けて管理する、請求項１乃至請求項５のいずれか１項に記載の採用支援システム。

【請求項7】

前記管理部は、前記フラグ情報が有効であると判定される有効期限を前記フラグ情報と対応付けて管理する、請求項１乃至請求項６のいずれか１項に記載の採用支援システム。

【請求項8】

前記管理部を制御する制御部を備え、
前記管理部は、前記求職者情報として、第１タイミングで登録された第１求職者情報と、前記第１タイミングよりも後の第２タイミングで登録された第２求職者情報と、を管理し、
前記制御部は、前記第１求職者情報と前記第２求職者情報とが同一の求職者に属すると判定された場合に、前記第１求職者情報及び前記第２求職者情報を統合求職者情報として統合する統合処理を実行する、請求項１乃至請求項７のいずれか１項に記載の採用支援システム。

【請求項9】

前記制御部は、前記統合処理において、前記第１求職者情報と対応付けられた前記フラグ情報及び前記第２求職者情報と対応付けられた前記フラグ情報を１つのフラグ情報に統合する、請求項８に記載の採用支援システム。

【請求項10】

前記求職者情報は、前記求職者に関する識別情報と、前記求職者に関する属性情報と、を含み、
前記制御部は、前記統合処理において、前記第１求職者情報に含まれる前記属性情報よりも前記第２求職者情報に含まれる前記属性情報を優先して、前記第１求職者情報及び前記第２求職者情報を前記統合求職者情報として統合する、請求項８又は請求項９に記載の採用支援システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、採用支援システムに関する。

【背景技術】

【0002】

従来、求職者の情報を管理することによって採用活動を支援するシステムが開示されている。求職者の情報は、氏名、年齢、住所、電話番号、メールアドレスなどの個人情報を含む。求職者の情報は、希望職種、就業希望時間、就業希望日、就業希望場所などの就業情報を含む（例えば、特許文献１）。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００３－２４８７６３号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

ところで、採用活動においては、同一の求職者が異なるタイミングで求職に応募するケースが想定される。例えば、インターンの際に求職者の情報が採用支援システムに登録された後に、本採用の際に求職者の情報が採用支援システムに登録されることが考えられる。このようなケースにおいて、求職者が応募する求職の経路（以下、求職経路）、求職者が応募する求職の職種（以下、求職職種）などが異なることが考えられる。

【0005】

ところで、求職経路又は求職職種などの選考情報が異なる場合に、求職者を特定する識別情報などを付与することによって同一の求職者を特定する運用がなされず、同一の求職者に対する採用者の評価も選考情報毎に別々に管理される。従って、過去に生成された採用者の評価を参照することができず、採用活動を効率的に実施することができない。

【0006】

さらに、採用活動においては、多数の求職者の中から実際に採用する求職者を決定するため、多数の求職者を見比べる必要があり、求職者を一律に見比べる作業は効率的ではない。

【0007】

そこで、本発明は、上述した課題を解決するためになされたものであり、採用活動を効率的に実施することを可能とする採用支援システムを提供することを目的とする。

【課題を解決するための手段】

【0008】

第１の特徴は、採用支援システムであって、求職者に関する求職者情報を管理する管理部と、前記求職者情報を出力する出力部と、を備え、前記管理部は、採用者が前記求職者に注目しているか否かを示すフラグ情報を前記求職者情報と対応付けて管理し、前記出力部は、前記フラグ情報を前記求職者情報と対応付けて出力する、ことを要旨とする。

【0009】

第２の特徴は、第１の特徴において、前記管理部は、前記求職者が求職に応募した経路、前記求職者が求職に応募した職種及び前記求職者の選考の状態を示すステータスの少なくともいずれか１つを含む選考情報を前記求職者情報と対応付けて管理し、前記管理部は、前記選考情報として２以上の選考情報を前記求職者情報と対応付けるとともに、前記フラグ情報として１つのフラグ情報を前記求職者情報と対応付ける、ことを要旨とする。

【0010】

第３の特徴は、第２の特徴において、前記選考情報は、前記求職者に対する前記採用者の評価を含む、ことを要旨とする。

【0011】

第４の特徴は、第１の特徴乃至第３の特徴のいずれかにおいて、前記管理部は、前記フラグ情報の削除を制限する、或いは、前記フラグ情報の変更に関する権限を設定する、ことを要旨とする。

【0012】

第５の特徴は、第１の特徴乃至第４の特徴のいずれかにおいて、前記フラグ情報は、前記採用者が注目するレベルを２段階以上で表す情報である、ことを要旨とする。

【0013】

第６の特徴は、第１の特徴乃至第５の特徴のいずれかにおいて、前記管理部は、前記フラグ情報の登録者を前記フラグ情報と対応付けて管理する、ことを要旨とする。

【0014】

第７の特徴は、第１の特徴乃至第６の特徴のいずれかにおいて、前記管理部は、前記フラグ情報が有効であると判定される有効期限を前記フラグ情報と対応付けて管理する、ことを要旨とする。

【0015】

第８の特徴は、第１の特徴乃至第７の特徴のいずれかにおいて、前記採用支援システムは、前記管理部を制御する制御部を備え、前記管理部は、前記求職者情報として、第１タイミングで登録された第１求職者情報と、前記第１タイミングよりも後の第２タイミングで登録された第２求職者情報と、を管理し、前記制御部は、前記第１求職者情報と前記第２求職者情報とが同一の求職者に属すると判定された場合に、前記第１求職者情報及び前記第２求職者情報を統合求職者情報として統合する統合処理を実行する、ことを要旨とする。

【0016】

第９の特徴は、第８の特徴において、前記制御部は、前記統合処理において、前記第１求職者情報と対応付けられた前記フラグ情報及び前記第２求職者情報と対応付けられた前記フラグ情報を１つのフラグ情報に統合する、ことを要旨とする。

【0017】

第１０の特徴は、第８の特徴又は第９の特徴において、前記求職者情報は、前記求職者に関する識別情報と、前記求職者に関する属性情報と、を含み、前記制御部は、前記統合処理において、前記第１求職者情報に含まれる前記属性情報よりも前記第２求職者情報に含まれる前記属性情報を優先して、前記第１求職者情報及び前記第２求職者情報を前記統合求職者情報として統合する、ことを要旨とする。

【発明の効果】

【0018】

本発明によれば、採用活動を効率的に実施することを可能とする採用支援システムを提供することができる。

【図面の簡単な説明】

【0019】

【図1】図１は、実施形態に係る採用支援システム１００を示す図である。

【図2】図２は、実施形態に係る支援サーバ３０を示す図である。

【図3】図３は、実施形態に係る管理部３２に格納されたデータの一例を示す図である。

【図4】図４は、実施形態に係る管理部３２に格納されたデータの一例を示す図である。

【図5】図５は、実施形態に係る統合処理を説明するための図である。

【図6】図６は、実施形態に係る統合処理を説明するための図である。

【図7】図７は、実施形態に係る統合処理を説明するための図である。

【図8】図８は、実施形態に係る統合処理を説明するための図である。

【図9】図９は、実施形態に係る採用支援方法を示す図である。

【図10】図１０は、変更例１に係る管理部３２に格納されたデータの一例を示す図である。

【図11】図１１は、変更例２に係る管理部３２に格納されたデータの一例を示す図である。

【発明を実施するための形態】

【0020】

以下において、実施形態について図面を参照しながら説明する。なお、以下の図面の記載において、同一又は類似の部分には、同一又は類似の符号を付している。

【0021】

但し、図面は模式的なものであり、各寸法の比率などは現実のものとは異なる場合があることに留意すべきである。従って、具体的な寸法などは以下の説明を参酌して判断すべきである。また、図面相互間においても互いの寸法の関係又は比率が異なる部分が含まれている場合があることは勿論である。

【0022】

［開示の概要］
開示の概要に係る採用支援システムは、求職者に関する求職者情報を管理する管理部と、前記求職者情報を出力する出力部と、を備える。前記管理部は、採用者が前記求職者に注目しているか否かを示すフラグ情報を前記求職者情報と対応付けて管理する。前記出力部は、前記フラグ情報を前記求職者情報と対応付けて出力する。

【0023】

開示の概要では、採用支援システムは、採用者が求職者に注目しているか否かを示すフラグ情報を求職者情報と対応付けて出力する。このような構成によれば新たに導入されたフラグ情報を利用することによって、多数の求職者を一律に見比べる必要がなくなり、採用活動を効率的に実施することができる。

【0024】

例えば、フラグ情報の利用は、採用者が求職者に注目している旨を示すフラグ情報が対応付けられた求職者情報を抽出して出力することであってもよい。採用者が求職者に注目している旨を示すフラグ情報が対応付けられた求職者に対して、採用活動のリマインド設定を行うことであってもよい。採用者が求職者に注目している旨を示すフラグ情報が対応付けられた求職者に対して、企業説明会などのイベントの案内を送付することであってもよい。採用者が求職者に注目している旨を示すフラグ情報が対応付けられた求職者について各種の集計（例えば、辞退率など）を得ることができる。

【0025】

［実施形態］
（採用支援システム）
以下において、実施形態に係る採用支援システムについて説明する。図１は、実施形態に係る採用支援システム１００を示す図である。

【0026】

図１に示すように、採用支援システム１００は、第１端末１０と、第２端末２０と、支援サーバ３０と、を有する。第１端末１０、第２端末２０及び支援サーバ３０は、ネットワーク１１０によって接続される。特に限定されるものではないが、ネットワーク１１０は、インターネットによって構成されてもよい。ネットワーク１１０は、ローカルエリアネットワークを含んでもよく、移動体通信網を含んでもよく、VPN（Virtual Private Network）を含んでもよい。

【0027】

第１端末１０は、採用者が用いる端末である。採用者は、第１端末１０を示す用語として用いられてもよい。例えば、第１端末１０は、パーソナルコンピュータであってもよく、スマートフォンであってもよく、タブレット端末であってもよい。

【0028】

第２端末２０は、求職者が用いる端末である。求職者は、第２端末２０を示す用語として用いられてもよい。例えば、第２端末２０は、パーソナルコンピュータであってもよく、スマートフォンであってもよく、タブレット端末であってもよい。図１では、第２端末２０Ａ～第２端末２０Ｄが例示されている。

【0029】

支援サーバ３０は、採用活動を支援するオペレータによって管理されるサーバである。オペレータは、支援サーバ３０を示す用語として用いられてもよい。支援サーバ３０の詳細については後述する。

【0030】

（支援サーバ）
以下において、実施形態に係る支援サーバについて説明する。図２は、実施形態に係る支援サーバ３０を示す図である。図２に示すように、支援サーバ３０は、通信部３１と、管理部３２と、制御部３３と、を有する。

【0031】

通信部３１は、通信モジュールによって構成される。通信モジュールは、IEEE802.11a/b/g/n、ZigBee、Wi-SUN、LTE、5Gなどの規格に準拠する無線通信モジュールであってもよく、IEEE802.3などの規格に準拠する有線通信モジュールであってもよい。

【0032】

例えば、通信部３１は、求職者に関する求職者情報を第２端末２０から受信してもよい。通信部３１は、求職者が応募した求人に関する選考情報の一部を第２端末２０から受信してもよい。選考情報は、求職者が求職に応募した経路（以下、経路情報）、求職者が求職に応募した職種（以下、職種情報）及び求職者の選考の状態を示すステータスの少なくともいずれか１つを含んでもよい。経路情報及び職種情報は求人情報と称されてもよい。

【0033】

通信部３１は、管理部３２によって管理されるデータ（例えば、求職者情報、選考情報、フラグ情報）を第１端末１０に送信してもよい。実施形態では、通信部３１は、後述するフラグ情報を求職者情報と対応付けて出力する出力部の一例である。なお、第１端末１０は、支援サーバ３０から受信するデータ（表示データとも称する）に基づいて、求職者情報、選考情報、フラグ情報）を表示する。

【0034】

管理部３２は、不揮発性メモリ、HDD（Hard Disk Drive）、SSD（Solid State Drive）、磁気テープなどの記憶媒体によって構成される。

【0035】

実施形態では、管理部３２は、求職者に関する求職者情報を管理する。管理部３２は、採用者が前記求職者に注目しているか否かを示すフラグ情報を求職者情報と対応付けて管理する。管理部３２は、求職者が応募した求人に関する選考情報を求職者情報と対応付けて管理してもよい。

【0036】

例えば、管理部３２は、図３に示すように、求職者情報を管理する。管理部３２は、図４に示すように、選考情報及びフラグ情報を求職者情報と対応付けて管理してもよい。

【0037】

求職者情報は、求職者に関する識別情報と、求職者に関する属性情報と、を含んでもよい。例えば、識別情報は、求職者の姓名であってもよい。属性情報は、求職者のメールアドレス、電話番号、住所及び学歴を含んでもよい。属性情報は、求職者に関する他の属性情報（例えば、卒業高校、卒業中学、資格など）を含んでもよい。

【0038】

選考情報は、経路情報、職種情報、ステータス、日付、評価を含んでもよい。経路情報は、求人に用いた媒体を示す情報を含んでもよく、求人に用いたサービスを示す情報を含んでもよい。職種情報は、採用者が募集した職種を示す情報（例えば、“営業”、“事務”、“技術”、“インターン”など）を含んでもよい。ステータスは、求職者の選考の状態を示す情報（例えば、“辞退”、“不合格”、“採用”など）を含んでもよい。評価は、求職者に対する採用者の評価（例えば、「真面目そうなので事務向きである」、「社交性があるので営業向きである」など）を含んでもよい。評価は、求人又は選考（例えば、職種情報）に応じた評価であってもよい。

【0039】

フラグ情報は、採用者が求職者に注目しているか否かを示す情報である。図４では、フラグ情報“○”は、採用者が求職者に注目している旨を示しており、フラグ情報“－”は、採用者が求職者に注目していない旨を示している。

【0040】

後述するように、管理部３２は、タイミングが異なる２つの求人について求職者情報を管理してもよい。具体的には、管理部３２は、求職者情報として、第１タイミングで登録された第１求職者情報と、第１タイミングよりも後の第２タイミングで登録された第２求職者情報と、を管理してもよい。

【0041】

制御部３３は、少なくとも１つのプロセッサを含んでもよい。少なくとも１つのプロセッサは、単一の集積回路によって構成されてもよく、通信可能に接続された複数の回路（集積回路及び又はディスクリート回路（discrete circuits）など）によって構成されてもよい。

【0042】

例えば、制御部３３は、管理部３２を制御する。制御部３３は、タイミングが異なる２つの求人について求職者情報を統合する統合処理を実行してもよい。具体的には、制御部３３は、第１求職者情報と第２求職者情報とが同一の求職者に属すると判定された場合に、第１求職者情報及び第２求職者情報を統合求職者情報として統合する統合処理を実行してもよい。

【0043】

（統合処理）
以下において、実施形態に係る統合処理について説明する。図５～図８は、実施形態に係る統合処理を説明するための図である。

【0044】

第１に、タイミングが異なる２つの求人に対して求職者“AAaa”が応募するケースについて説明する。ここでは、“AAaa”のメールアドレス及び住所が変更されるケースについて説明する。

【0045】

図５の上段に示すように、管理部３２は、第１タイミングの求人において、求職者“AAaa”のメールアドレスとして“aaa@…”を管理しており、求職者“AAaa”の住所として“東京都…”を管理する。

【0046】

図５の中段に示すように、管理部３２は、第１タイミングよりも後の第２タイミングの求人において、求職者“AAaa”のメールアドレスとして“xxx@…”を新たに管理し、求職者“AAaa”の住所として“埼玉県…”を新たに管理する。すなわち、管理部３２は、求職者“AAaa”について、第１求職者情報及び第２求職者情報を管理する。

【0047】

このような前提下において、図５の下段に示すように、制御部３３は、第１求職者情報と第２求職者情報とが同一の求職者に属すると判定された場合に、第１求職者情報及び第２求職者情報を統合求職者情報として統合する統合処理を実行する。

【0048】

ここで、制御部３３は、姓名、メールアドレス、電話番号及び住所の少なくともいずれか１つが一致する場合に、第１求職者情報と第２求職者情報とが同一の求職者に属すると判定してもよい。図５では、制御部３３は、姓名及び電話番号が一致するため、第１求職者情報と第２求職者情報とが同一の求職者に属すると判定する。

【0049】

制御部３３は、統合処理において、第１求職者情報に含まれる属性情報よりも第２求職者情報に含まれる属性情報を優先して、第１求職者情報及び第２求職者情報を統合求職者情報として統合する。例えば、図５に示すケースでは、メールアドレス“xxx@…”、住所“埼玉県…”及び学年“３年”がメールアドレス“aaa@…”、住所“東京都…”及び学年“２年”よりも優先される。

【0050】

優先は、第１求職者情報に含まれる属性情報を登録せずに、第２求職者情報に含まれる属性情報を登録することであってもよい。或いは、優先は、第１求職者情報に含まれる属性情報を及び第２求職者情報に含まれる属性情報を多段で登録可能である場合に、第１求職者情報に含まれる属性情報よりも第２求職者情報に含まれる属性情報を上位に登録することであってもよい。

【0051】

さらに、図６の上段に示すように、管理部３２は、第１タイミングの求人において、第１求職者情報と対応付けられた選考情報を管理する。例えば、経路情報は“XXX”であり、職種情報は“営業”であり、ステータスは“辞退”である。同様に、管理部３２は、第１タイミングの求人において、第１求職者情報と対応付けられたフラグ情報を管理する。例えば、フラグ情報は“○”である。

【0052】

図６の中段に示すように、管理部３２は、第１タイミングよりも後の第２タイミングの求人において、第２求職者情報と対応付けられた選考情報を新たに管理する。例えば、経路情報は“ZZZ”であり、職種情報は“技術”であり、ステータスは“選考中”である。同様に、管理部３２は、第２タイミングの求人において、第１求職者情報と対応付けられたフラグ情報を管理する。例えば、フラグ情報は“－”である。すなわち、管理部３２は、求職者“AAaa”について、第１求職者情報及び第２求職者情報と対応付けられた選考情報及びフラグ情報を管理する。

【0053】

このような前提下において、図６の下段に示すように、制御部３３は、統合処理において、第１求職者情報及び第２求職者情報と対応付けられた選考情報及びフラグ情報を統合する。ここで、制御部３３は、第１求職者情報及び第２求職者情報と対応付けられた選考情報を別々のレコードとして統合する。一方で、制御部３３は、第１求職者情報及び第２求職者情報と対応付けられたフラグ情報を１つのフラグ情報（レコード）として統合する。ここでは、第１求職者情報と対応付けられたフラグ情報が“○”であるため、統合後のフラグ情報として“○”が登録される。

【0054】

このようなケースにおいて、採用者が求職者に注目している旨を示すフラグ情報“○”がある場合には、統合後の１つのフラグ情報として“○”が登録されてもよい。採用者が求職者に注目している旨を示すフラグ情報“○”がない場合には、統合後の１つのフラグ情報として“－”が登録されてもよい。すなわち、求職者情報と対応付けられたフラグ情報が２以上である場合においてフラグ情報を統合する際に、採用者が求職者に注目している旨を示すフラグ情報“○”が１つでも存在する場合には、統合後の１つのフラグ情報として“○”が登録されてもよい。採用者が求職者に注目している旨を示すフラグ情報“○”が１も存在しない場合には、統合後の１つのフラグ情報として“－”が登録されてもよい。言い換えると、各タイミング（求人又は選考）のフラグ情報の中で最も評価の高いフラグ情報が１つのフラグ情報として登録されてもよい。

【0055】

すなわち、管理部３２は、選考情報として２以上の選考情報を求職者情報と対応付けるとともに、フラグ情報として１つのフラグ情報を求職者情報と対応付ける。選考情報は、各タイミング（求人又は選考）における経路情報、職種情報、ステータス、日付及び評価を含んでもよい。

【0056】

第２に、タイミングが異なる３つの求人に対して求職者“BBbb”が応募するケースについて説明する。ここでは、“BBbb”の姓及びメールアドレスが変更されるケースについて説明する。

【0057】

図７の上段に示すように、管理部３２は、第１タイミングの求人において登録された第１求職者情報と、第１タイミングよりも後の第２タイミングの求人において登録された第２求職者情報と、第２タイミングよりも後の第３タイミングの求人において登録された第３求職者情報と、を管理する。

【0058】

このような前提下において、制御部３３は、図７の下段に示すように、制御部３３は、第１求職者情報～第３求職者情報が同一の求職者に属すると判定された場合に、第１求職者情報～第３求職者情報を統合求職者情報として統合する統合処理を実行する。

【0059】

ここで、制御部３３は、姓名、メールアドレス、電話番号及び住所の少なくともいずれか１つが一致する場合に、第１求職者情報～第３求職者情報が同一の求職者に属すると判定してもよい。図７では、制御部３３は、電話番号及び住所が一致するため、第１求職者情報～第３求職者情報が同一の求職者に属すると判定する。

【0060】

制御部３３は、統合処理において、最新の求職者情報（ここでは、第３求職者情報）含まれる属性情報を優先して、第１求職者情報～第２求職者情報を統合求職者情報として統合する。例えば、図７に示すケースでは、メールアドレス“yyy@…”及び学年“４年”が優先的に登録される。なお、図７では、姓が“BB”から“XX”に変更されているため、統合求職者情報では、最新の姓“XX”が登録される。

【0061】

さらに、図８の上段に示すように、管理部３２は、第１求職者情報～第３求職者情報と対応付けられた選考情報及びフラグ情報を管理する。

【0062】

このような前提下において、図８の下段に示すように、制御部３３は、統合処理において、第１求職者情報～第３求職者情報と対応付けられた選考情報及びフラグ情報を統合する。ここで、制御部３３は、第１求職者情報～第３求職者情報と対応付けられた選考情報を別々のレコードとして統合する。一方で、制御部３３は、第１求職者情報～第３求職者情報と対応付けられたフラグ情報を１つのフラグ情報（レコード）として統合する。ここでは、第２求職者情報と対応付けられたフラグ情報が“○”であるため、統合後のフラグ情報として“○”が登録される。

【0063】

すなわち、管理部３２は、選考情報として２以上の選考情報を求職者情報と対応付けるとともに、フラグ情報として１つのフラグ情報を求職者情報と対応付ける。選考情報は、各タイミング（求人又は選考）における経路情報、職種情報、ステータス、日付及び評価を含んでもよい。

【0064】

実施形態では、最新の求職者情報に含まれる属性情報を優先して統合する態様を“更新”と称してもよい。各タイミング（求人又は選考）の選考情報を別々のレコードとして統合する態様を“累積”と称してもよい。各タイミング（求人又は選考）のフラグ情報に基づいて得られるフラグ情報を１つのレコードとして統合する態様を“引継”と称してもよい。

【0065】

（採用支援方法）
以下において、実施形態に係る採用支援方法について説明する。図９は、実施形態に係る採用支援方法を示す図である。

【0066】

図９に示すように、ステップS10において、第２端末２０は、求職者情報を支援サーバ３０に送信する。第２端末２０は、求職者情報とともに選考情報の一部（経路情報及び職種情報）を支援サーバ３０に送信してもよい。

【0067】

ステップS11において、支援サーバ３０は、第２端末２０から受信する求職者情報を管理部３２に登録する。支援サーバ３０は、求職者情報とともに選考情報（経路情報及び職種情報）を管理部３２に登録する。

【0068】

ここで、ステップS11において管理部３２に登録される求職者情報は、第１タイミングの求人で登録される第１求職者情報の一例であると考えてもよい。

【0069】

ステップS12において、支援サーバ３０は、求職者情報を表示するための表示データを第１端末１０に送信（出力）する。支援サーバ３０は、求職者情報を選考情報（経路情報、職種情報、ステータス、日付、評価）と対応付ける表示データを第１端末１０に送信（出力）してもよい。支援サーバ３０は、求職者情報をフラグ情報と対応付ける表示データを第１端末１０に送信（出力）してもよい。このようなケースにおいて、ステータスの初期値は“選考中”であってもよく、評価の初期値は空欄であってもよい。フラグ情報の初期値は“－”であってもよい。

【0070】

ステップS13において、採用者は、求職者の選考を実施する。

【0071】

ステップS14において、第１端末１０は、選考結果を支援サーバ３０に送信する。例えば、選考結果は、ステータスを含んでもよい。選考結果は、評価を含んでもよい。選考結果は、フラグ情報を含んでもよい。

【0072】

ステップS15において、支援サーバ３０は、第１端末１０から受信する選考結果を管理部３２に登録する。

【0073】

ステップS10～ステップS15の手順によって、第１タイミングの求人に対する選考が完了したものとして説明を続ける。例えば、支援サーバ３０は、この段階において図５の上段及び図６の上段に示すデータを管理する。

【0074】

ステップＳ20において、第２端末２０から受信する求職者情報を管理部３２に登録する。支援サーバ３０は、求職者情報とともに選考情報（経路情報及び職種情報）を管理部３２に登録する。

【0075】

ステップS21において、支援サーバ３０は、第２端末２０から受信する求職者情報を管理部３２に登録する。支援サーバ３０は、求職者情報とともに選考情報（経路情報及び職種情報）を管理部３２に登録する。

【0076】

ここで、ステップS21において管理部３２に登録される求職者情報は、第１タイミングよりも後の第２タイミングの求人で登録される第２求職者情報の一例であると考えてもよい。例えば、支援サーバ３０は、この段階において図５の中段及び図６の中段に示すデータを管理する。ここでは、同一の求職者（例えば、図５及び図６に示す求職者“AAaa”）に属する求職者情報が登録されているものとして説明を続ける。

【0077】

ステップS22において、支援サーバ３０は、統合候補を第１端末１０に送信してもよい。統合候補は、同一の求職者に属すると判定された第１求職者情報及び第２求職者情報を含んでもよい。ステップS23において、採用者は、統合候補に基づいて、第１求職者情報及び第２求職者情報を統合するか否かを決定する。ここでは、第１求職者情報及び第２求職者情報を統合すると決定するものとして説明を続ける。第1端末１０は、第１求職者情報及び第２求職者情報の統合要求を支援サーバ３０に送信する。

【0078】

なお、第１求職者情報及び第２求職者情報の統合処理を支援サーバ３０が自動で実行する場合には、ステップS22及びステップS23の手順は省略されてもよい。

【0079】

ステップS24において、支援サーバ30は、第１求職者情報及び第２求職者情報を統合求職者情報として統合する統合処理を実行する。上述したように、支援サーバ３０は、最新の求職者情報（ここでは、第３求職者情報）含まれる属性情報を優先して、第１求職者情報及び第２求職者情報を統合してもよい（更新）。支援サーバ３０は、第１求職者情報及び第２求職者情報と対応付けられた選考情報を別々のレコードとして統合してもよい（累積）。支援サーバ３０は、第１求職者情報及び第２求職者情報と対応付けられたフラグ情報を１つのレコードとして統合してもよい（引継）。

【0080】

例えば、支援サーバ３０は、ステップS20～ステップS25の手順によって、図５の下段及び図６の下段に示すデータを管理する。

【0081】

なお、図９では省略しているが、ステップS24で統合されたデータを用いて、第２タイミングの求人に対する選考が行われる。

【0082】

（作用及び効果）
実施形態では、採用支援システム１００は、採用者が求職者に注目しているか否かを示すフラグ情報を求職者情報と対応付けて出力する。このような構成によれば新たに導入されたフラグ情報を利用することによって、多数の求職者を一律に見比べる必要がなくなり、採用活動を効率的に実施することができる。

【0083】

例えば、フラグ情報の利用は、採用者が求職者に注目している旨を示すフラグ情報が対応付けられた求職者情報を抽出して出力することであってもよい。採用者が求職者に注目している旨を示すフラグ情報が対応付けられた求職者に対して、採用活動のリマインド設定を行うことであってもよい。採用者が求職者に注目している旨を示すフラグ情報が対応付けられた求職者に対して、企業説明会などのイベントの案内を送付することであってもよい。採用者が求職者に注目している旨を示すフラグ情報が対応付けられた求職者について各種の集計（例えば、辞退率など）を得ることができる。

【0084】

或いは、フラグ情報の利用は、あるタイミングの求人（選考）において、２以上の選考プロセス（例えば、１次面接、２次面接など）が設定されている場合に、一部の選考プロセス（例えば、１次面接）を免除するか否かの判断であってもよい。採用者は、採用者が注目している旨のフラグ情報と対応付けられていない求職者について一部の選考プロセスを免除せずに、採用者が注目している旨のフラグ情報と対応付けられた求職者について一部の選考プロセスを免除すると判断してもよい。

【0085】

実施形態では、採用支援システム１００は、第１求職者情報と第２求職者情報とが同一の求職者に属すると判定された場合に、第１求職者情報及び第２求職者情報を統合求職者情報として統合する統合処理を実行してもよい。このような構成によれば、異なるタイミングで登録される求職者情報の重複を抑制することができ、採用活動を効率的に実施することができる。

【0086】

実施形態では、採用支援システム１００は、統合処理において、第１求職者情報及び第２求職者情報と対応付けられた選考情報を別々のレコードとして統合し（累積）、第１求職者情報及び第２求職者情報と対応付けられたフラグ情報を１つのレコードとして統合してもよい（引継）。言い換えると、採用支援システム１００は、選考情報として２以上の選考情報を求職者情報と対応付けるとともに、フラグ情報として１つのフラグ情報を求職者情報と対応付けてもよい。このような構成よれば、求職者情報と選考情報とが１対他の関係で対応付けられるため、各タイミング（求人又は選考）の履歴として選考情報（例えば、ステータスや評価）を参照することができる。一方で、求職者情報とフラグ情報とが１対１の関係で対応付けられるため、各タイミング（求人又は選考）によらずに、求職者そのものに対するフラグ情報を参照可能とすることによって、採用活動を適切に実施することができる。例えば、インターン求人（選考）について“不合格”とした求職者であっても、採用者が注目している旨のフラグ情報と対応付けられた求職者について、本採用の求人（選考）においてフラグ情報を有効に利用するケースなどが想定される。或いは、事務の求人（選考）について“不合格”とした求職者であっても、採用者が注目している旨のフラグ情報と対応付けられた求職者について、他の求人（選考）においてフラグ情報を有効に利用するケースなどが想定される。

【0087】

実施形態では、選考情報が経路情報を含むため、フラグ情報と組み合わせることによって、経路情報（例えば、求人に用いた媒体やサービス）の有効性を判定することができる。例えば、採用者が注目している旨のフラグ情報と対応付けられた求職者の比率を経路情報毎に集計するケースなどが想定される。

【0088】

［変更例１］
以下において、実施形態の変更例１について説明する。以下においては、実施形態に対する相違点について主として説明する。変更例１では、上述したフラグ情報について説明する。

【0089】

実施形態では、フラグ情報は、採用者が求職者に注目しているか否かを示す情報（“○”又は“－”）である。これに対して、変更例１では、フラグ情報は、採用者が注目するレベルを２段階以上で表す情報であってもよい。

【0090】

例えば、図１０に示すように、フラグ情報は、採用者が注目するレベルを５段階で表す情報であってもよい。図１０では、“１”は採用者が注目するレベルが最も低いことを意味しており、“５”は、採用者が注目するレベルが最も高いことを意味していてもよい。すなわち、フラグ情報の数字が大きいほど、採用者が注目するレベルが高くてもよい。

【0091】

なお、フラグ情報は、“低”、“中”及び“高”などのような３段階で採用者が注目するレベルを表す情報であってもよい。

【0092】

これらのケースにおいて、フラグ情報は、採用者が注目していない旨又はフラグ情報の登録がない旨を示す情報（例えば、“－”）を含んでもよい。

【0093】

採用者が注目するレベルを２段階以上でフラグ情報が表す場合において、上述した引継は、各タイミング（求人又は選考）のフラグ情報の中で最も評価の高いフラグ情報が１つのレコードとして統合する態様であってもよい。引継は、各タイミング（求人又は選考）のフラグ情報の平均値又は中央値を１つのレコードとして統合する態様であってもよい。

【0094】

［変更例２］
以下において、実施形態の変更例２について説明する。以下においては、実施形態に対する相違点について主として説明する。変更例２では、上述したフラグ情報について説明する。

【0095】

例えば、図１１に示すように、支援サーバ３０（管理部３２）は、フラグ情報の登録者をフラグ情報と対応付けて管理してもよい。登録者は、採用者が求職者に注目している旨のフラグ情報の登録者である。フラグ情報と対応付けられる登録者数は、１人であってもよく、２人以上であってもよい。

【0096】

例えば、支援サーバ３０（管理部３２）は、フラグ情報が有効であると判定される有効期限をフラグ情報と対応付けて管理してもよい。有効期限は、採用者が求職者に注目している旨のフラグ情報を登録してから経過した時間（例えば、半年又は１年）によって定められてもよい。

【0097】

［変更例３］
以下において、実施形態の変更例３について説明する。以下においては、実施形態に対する相違点について主として説明する。変更例３では、上述したフラグ情報について説明する。

【0098】

支援サーバ３０（管理部３２）は、フラグ情報の削除を制限してもよい。例えば、選考情報に含まれるステータス又は評価を入力する採用担当者は、フラグ情報を削除することができなくてもよい。但し、採用担当者は、フラグ情報を登録することができてもよい。すなわち、採用担当者は、登録されたフラグ情報を削除する権限を有していなくてもよい。なお、フラグ情報は採用責任者によって削除可能であってもよい。

【0099】

或いは、支援サーバ３０（管理部３２）は、フラグ情報の変更に関する権限を設定してもよい。変更は、登録、削除及び更新を含んでもよい。フラグ情報の登録に関する権限は、フラグ情報の削除に関する権限と異なってもよく、フラグ情報の更新に関する権限と異なってもよい。同様に、フラグ情報の削除に関する権限は、フラグ情報の更新に関する権限と異なってもよい。例えば、採用担当者は、登録に関する権限を有しているが、削除及び更新に関する権限を有していなくてもよい。採用責任者は、登録、削除及び更新に関する権限を有していてもよい。

【0100】

［その他の実施形態］
本発明は上述した実施形態によって説明したが、この開示の一部をなす論述及び図面は、この発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施形態、実施例及び運用技術が明らかとなろう。

【0101】

上述した開示では、支援サーバ３０は、求職者情報を第２端末２０から受信するケースについて例示した。しかしながら、実施形態はこれに限定されるものではない。支援サーバ３０は、採用担当者の入力によって求職者情報を取得してもよい。支援サーバ３０は、就職又は転職サービスを提供する第三者サーバから求職者情報を取得してもよい。

【0102】

上述した開示では、支援サーバ３０は、選考情報に含まれる求人情報（経路情報及び職種情報）を第２端末２０から受信するケースについて例示した。しかしながら、実施形態はこれに限定されるものではない。支援サーバ３０は、採用担当者の入力によって求人情報（経路情報及び職種情報）を取得してもよい。支援サーバ３０は、就職又は転職サービスを提供する第三者サーバから求人情報（経路情報及び職種情報）を取得してもよい。

【0103】

実施形態では、経路情報、職種情報、ステータス、日付、評価の全てを選考情報が含むケースについて例示した。しかしながら、選考情報は、経路情報、職種情報及びステータスの少なくともいずれか１つを含めばよい。例えば、選考情報は、経路情報（求人に用いた媒体やサービス）を含まずに、職種情報（例えば、“インターン”など）を含んでもよい。或いは、選考情報は、経路情報（求人に用いた媒体やサービス）を含まずに、ステータス（例えば、“採用”又は“不合格”など）を含んでもよい。

【0104】

上述した開示では特にふれていないが、第１端末１０の表示態様は、支援サーバ３０から受信するデータに基づいた態様であればよい。すなわち、第１端末１０の表示態様は、求職者情報、選考情報及びフラグ情報が対応付けられた態様であればよい。特に限定されるものではないが、第１端末１０の表示態様は、図４、図６又は図８に示す態様であってもよい。

【0105】

実施形態では特に触れていないが、支援サーバ３０が有する機能は、クラウドサービス又はSaaS（Service as a Software）の形態で提供されてもよい。

【0106】

実施形態では、採用支援システム１００は、第１端末１０及び第２端末２０を含むケースについて例示した。しかしながら、実施形態はこれに限定されるものではない。採用支援システム１００は、第１端末１０及び第２端末２０を含まずに支援サーバ３０を含んでもよい。

【符号の説明】

【0107】

１０…第１端末、２０…第２端末、３０…支援サーバ、３１…通信部、３２…管理部、３３…制御部、１００…採用支援システム、１１０…ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【手続補正書】

【提出日】2021-06-14

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

求職者に関する識別情報及び前記求職者に関する属性情報を含む求職者情報を管理する管理部と、
前記管理部を制御する制御部と、
前記求職者情報を出力する出力部と、を備え、
前記管理部は、
採用者が前記求職者に注目しているか否かを示すフラグ情報を前記求職者情報と対応付けて管理し、
前記求職者情報として、第１タイミングで登録された第１求職者情報と、前記第１タイミングよりも後の第２タイミングで登録された第２求職者情報と、を管理し、
前記制御部は、
前記第１求職者情報及び前記第２求職者情報に含まれる前記求職者の姓名、メールアドレス、電話番号及び住所の少なくともいずれか１つが一致するか否かに基づいて、前記第１求職者情報と前記第２求職者情報とが同一の求職者に属するか否かを判定し、
前記第１求職者情報と前記第２求職者情報とが同一の求職者に属すると判定された場合に、前記第１求職者情報に含まれる前記属性情報よりも前記第２求職者情報に含まれる前記属性情報を優先して、前記第１求職者情報及び前記第２求職者情報を統合求職者情報として統合する統合処理を実行し、
前記出力部は、前記フラグ情報を前記求職者情報と対応付けて出力する、採用支援システム。

【請求項2】

前記管理部は、前記求職者が求職に応募した経路、前記求職者が求職に応募した職種及び前記求職者の選考の状態を示すステータスの少なくともいずれか１つを含む選考情報を前記求職者情報と対応付けて管理し、
前記管理部は、前記選考情報として２以上の選考情報を前記求職者情報と対応付けるとともに、前記フラグ情報として１つのフラグ情報を前記求職者情報と対応付ける、請求項１に記載の採用支援システム。

【請求項3】

前記選考情報は、前記求職者に対する前記採用者の評価を含む、請求項２に記載の採用支援システム。

【請求項4】

前記管理部は、前記フラグ情報の削除を制限する、或いは、前記フラグ情報の変更に関する権限を設定する、請求項１乃至請求項３のいずれか１項に記載の採用支援システム。

【請求項5】

前記フラグ情報は、前記採用者が注目するレベルを２段階以上で表す情報である、請求項１乃至請求項４のいずれか１項に記載の採用支援システム。

【請求項6】

前記管理部は、前記フラグ情報の登録者を前記フラグ情報と対応付けて管理する、請求項１乃至請求項５のいずれか１項に記載の採用支援システム。

【請求項7】

前記管理部は、前記フラグ情報が有効であると判定される有効期限を前記フラグ情報と対応付けて管理する、請求項１乃至請求項６のいずれか１項に記載の採用支援システム。

【請求項8】

前記制御部は、前記統合処理において、前記第１求職者情報と対応付けられた前記フラグ情報及び前記第２求職者情報と対応付けられた前記フラグ情報を１つのフラグ情報に統合する、請求項１乃至請求項７のいずれか１項に記載の採用支援システム。