人材紹介サービスで扱うデータのテーブル-デジタルテクノロジー統括部紹介1

はじめに
人材紹介サービスの扱うデータ
- 人材紹介のビジネスモデル
- 人材紹介のデータ
  - 2.求人データ
  - 3.進捗データ
まとめ

はじめに

デジタルテクノロジー統括部の採用活動の場で、どのようなデータ*1が扱われるのかを知りたいという声が多く寄せられています。

この記事では、人材紹介で扱うデータの種類や特徴について、擬似的なデータテーブルと共に紹介し、それらの声に答えるために書かれています。また所々に「転職希望者の都道府県毎の平均年収を求めるSQLはどのようになるか？」などといった問題をはさみ、よりイメージしやすくなるようにしております。

また、弊社の事業内容は「人材紹介サービス、求人広告、新卒採用支援や副業・フリーランス領域など」も提供しておりますが、今回は主に人材紹介サービスで扱うデータに絞って紹介してあります。

人材紹介サービスの扱うデータ

人材紹介のビジネスモデル

データの前にビジネスモデルを説明します。人材紹介の主目的は転職希望者と企業の求人をマッチングすることです。転職希望者に対しては、弊社のキャリアアドバイザーがこれまでの経歴や希望などをヒアリングし、適切な求人を探し、提案し、内定獲得、入社までサポートします。
企業に対しては、弊社の営業担当が相談を通じて、求める人材のタイプや最適な求人票の作成方法などを提案し、人材採用までサポートします。転職希望者が求人に応募し、書類審査や面接などの選考を経て、最終的に企業への転職が決まった段階で料金を企業から頂くというビジネスモデルです。

人材紹介のデータ

次にデータのテーブルを紹介します。パーソルキャリアの人材紹介では大別すると以下の3種類のデータを使用します。

転職希望者データ
求人データ
進捗データ

1は転職希望者の属性データで、職種や年収、学歴や希望条件などのデータ

2は求人の属性データで、求人の内容や年収や応募条件などのデータ

3は人材紹介に特徴的なデータ構造になっていて、転職希望者と求人の組が、いつ応募されて、いつ書類通過/書類非通過になったか、いつ面接通過/非通過になり...最終的に決定/非通過/辞退になったかを時系列毎に保存してあるデータ

です。

以下で実際のデータベースのテーブルを模した表を見ていきます。

※パーソルキャリアのデータにまつわる仕事をより具体的にお伝えするため、データベースのテーブルを模して表現していますが、記載されているテーブル名やカラム名、ID名などは、すべて記事用に作られたものであり、実際のものとは量や内容、名称なども異なります。

また、テーブルIDやカラムIDも記事執筆中に考案しており、特に命名規則等を考慮しておりません。あらかじめご了承ください。

1.転職希望者データ

転職希望者データは転職希望者ID（applicant_id）をキーとして、転職希望者基本情報，希望条件，学歴などがリレーショナルに保存されています。

テーブル名	テーブルID	カラム名	カラムID	説明
転職希望者基本情報	applicant01	転職希望者ID	applicant_id	主キー。転職希望者にユニークに割り振られるID
		姓	family_name
		名	personal_name
		職務経歴書ID	resume_id	職務経歴書のID
		都道府県ID	prefecture_id	北海道=1~沖縄=47まで都道府県がID化されている
		転職回数	n_jobs
		学歴ID	edu_background_id	博士，修士，学士，高等学校卒などがID化されている
		専攻ID	major_id
		TOEIC	toeic
		現職区分	emp_unemp	就職中なら1、離職中なら0
		作成日時（登録日時）	create_datetime	転職希望者が登録した日時
		更新日時	update_datetime	何らかのデータが更新された日時


転職希望者希望条件	applicant02	転職希望者ID	applicant_id
		業種大分類ID1	industry_category_id1	IT、機械メーカー、金融など業種大分類がID化されている
		業種小分類ID1	industry_subsubcategory_id1	ITの中のシステムインテグレータなど業種小分類がID化されている
		職種大分類ID1	occupation_category_id1	営業職、システムエンジニア、企画・管理など職種大分類
		職種小分類ID1	occupation_subsubcategory_id1	IT営業の中のIT法人営業（直販）、Web系ソリューション営業など職種小分類
		業種大分類ID2	industry_category_id2	第二希望の業種
		︙
		職種小分類ID2	occupation_subsubcategory_id2
		都道府県ID	prefecture_id
		希望年収	desireed_salary
		転職タイミングID	timing_id	「今すぐ」、「3ヶ月以内」等がID化されている
		転職理由	reason	転職理由（自然言語で書かれている）
		転職理由ID	reason_id	転職理由を区分けしてID化したもの
		作成日時	create_datetime
		更新日時	update_datetime


転職希望者学歴	applicant03	転職希望者学歴ID	applicant_edu_id
		転職希望者ID	applicant_id
		学校名	school_name
		学部	department
		学科	course
		入学年月	entrance_ym
		卒業年月	graduation_ym
		学歴ID	edu_background_id	博士，修士，学士，高等学校卒などがID化されている
		作成日時	create_datetime
		更新日時	update_datetime


転職希望者職歴	applicant04	転職希望者職歴ID	applicant_job_id
		転職希望者ID	applicant_id
		勤務先名	workplacename
		市場ID	market_id	東証プライム、スタンダート、グロース、未上場などの区分
		業種大分類ID	industry_category_id
		業種小分類ID	industry_subsubcategory_id
		職種大分類ID	occupation_category_id
		職種小分類ID	occupation_subsubcategory_id
		勤務期間年月	work_period
		年収	annual_income
		月収	monthly_income
		作成日時	create_datetime
		更新日時	update_datetime

この他に、語学情報、資格情報、スキル・経験情報、ログイン情報、カウンセラーとのコンタクト履歴情報等が転職希望者IDをキーとするテーブルに格納されています。

問．転職希望者の都道府県毎の平均年収を求めるSQLはどのようになるか？
答．パーソルキャリアの分析環境がAmazon Redshiftなのでそれに則った書き方で書きます。また、テーブルやカラムは全て模擬的なもので実際には存在しません。以下同様です。

SELECT
   a1.prefecture_id ,
   AVG(a4.annual_income)
FROM
   applicant01 a1
JOIN
   applicant04 a4
ON
   a1.applicant_id = a4.applicant_id
GROUP BY
   a1.prefecture_id

想定されるアウトプット

prefecture_id	AVG
1（北海道）	・・・
2（青森県）	・・・
︙	︙
46（鹿児島県）	・・・
47（沖縄県）	・・・

2.求人データ

データは求人ID（job_id）をキーとして、基本情報、勤務地、求める資格、求める語学などがリレーショナルに保存されています。

テーブル名	テーブルID	カラム名	カラムID	説明
求人基本情報	job01	求人ID	job_id	主キー．求人にユニークに割り振られるID


		リモート可能フラグ	remote_flg
		企業ID	company_id	求人を出している企業のID
		基本給	base_salary
		求める人物	︙

		勤務地ID	workplace_id
		採用人数	n_hired
		残業手当
		仕事内容	job_description
		仕事名称	job_name
		就業時間
		昇給区分
		必要語学区分	language_id
		筆記試験区分	exam_flag
		文理区分	bunri_flg
		募集部門	department
		未経験可フラグ	inexperienced
		面接回数	n_interview
		予定年収from	annual_income_from	予定年収下限
		予定年収to	annual_income_to	予定年収上限
		労働時間	working_hours
		作成日時	create_datetime
		更新日時	update_datetime


求人勤務地情報	job02	求人ID	job_id
		明細NO	detail_no	1つの求人IDは複数の勤務地を持ち得るので，明細NOで区別する
		求人勤務地ID	job_place_id
		勤務地ID	workplace_id
		町域
		都道府県ID	prefecture_id
		作成日時	create_datetime
		更新日時	update_datetime


求人資格情報	job03	求人ID	job_id
		明細NO	detail_no
		求人資格ID	job_cert_id
		資格ID	cert_id	資格がID化されている
		資格等級ID	cert_level_id	等級がある資格の等級
		資格分類ID	cert_category_id
		必要/歓迎区分	must_want_flg	応募するにあたってその条件が必要か歓迎かの区分
		作成日時	create_datetime
		更新日時	update_datetime


求人語学情報	job04	求人ID	job_id
		明細NO	detail_no
		求人語学ID	job_lang_id
		語学ID	lang_id	英語，フランス語，中国語などがID化されている
		語学レベルID	lang_level_id
		必要/歓迎区分	must_want_flg
		作成日時	create_datetime
		更新日時	update_datetime


求人学歴情報	job05	求人ID	job_id
		明細NO	detail_no
		求人学歴ID	job_edu_id
		学歴ID	edu_background_id	博士，修士，学士，高等学校卒などがID化されている
		専攻ID	major_id
		必要/歓迎区分	must_want_flg
		文理区分	bunri_flg
		作成日時	create_datetime
		更新日時	update_datetime


求人職種業種情報	job06	求人ID	job_id
		明細NO	detail_no
		求人職種ID	job_occu_id
		職種大分類ID	occupation_category_id
		職種中分類ID	occupation_subcategory_id
		職種小分類ID	occupation_subsubcategory_id
		業種大分類ID	industry_category_id
		業種小分類ID	industry_subsubcategory_id
		作成日時	create_datetime
		更新日時	update_datetime

問．求人の業種小分類-職種小分類毎の求人数と，予定年収fromの平均を求めるSQLはどのようになるか？

答．

SELECT
   j6.occupation_subsubcategory_id ,
   j6.industry_subsubcategory_id ,
   AVG(j1.annual_income_from) 平均年収from ,
   COUNT(j1.job_id) 求人数
FROM
   job01 j1
JOIN
   job06 j6
ON
   j1.job_id = j6.job_id
GROUP BY
   j6.occupation_subsubcategory_id ,
   j6.industry_subsubcategory_id

想定されるアウトプット

業種小分類	職種小分類	平均年収from	求人数
1（システムインテグレータ）	1(ITコンサルタント（アプリ）)	…	…
1（システムインテグレータ）	2(パッケージ導入コンサルタント)	…	…
1（システムインテグレータ）	3(ITコンサルタント（インフラ）)	…	…
1（システムインテグレータ）	4(プリセールス)	…	…
︙	︙	︙	︙
2（ソフトハウス）	1(ITコンサルタント（アプリ）)	…	…
2（ソフトハウス）	2(パッケージ導入コンサルタント)	…	…
2（ソフトハウス）	3(ITコンサルタント（インフラ）)	…	…
2（ソフトハウス）	4(プリセールス)	…	…
︙	︙	︙	︙

3.進捗データ

進捗データは、人材紹介サービスの特徴的なデータであり、
転職希望者IDと求人IDの組み合わせに対して1つの進捗IDが発行され、
そのステータスが応募→書類選考中→書類通過→...→決定と更新されるに従ってデータが積み上がっていく構造になっています。

テーブル名	テーブルID	カラム名	カラムID	説明
進捗情報	progress01	進捗ID	progress_id	進捗ID。転職希望者IDと求人IDの組に対して振られる
		転職希望者ID	applicant_id	転職希望者ID
		求人ID	job_id	求人ID
		進捗ステータスID	status_id	転職希望者と求人組のステータスがどの状態なのか示すID（例：応募、書類通過など）下記でマスタを記す
		決定年収	annual_income	決定した場合、その年収
		手数料	commission	決定した場合、その手数料
		作成日時	create_datetime
		更新日時	update_datetime

また、進捗ステータスIDのマスタ（を模したもの）は以下の様になります。

status_id（進捗ステータスID）	status_idの意味
1	転職希望者に求人を薦めている状態
2	転職希望者が応募すると意思表示した状態
3	書類チェック中の状態
4	企業に書類を提出した状態
5	1次面接設定中の状態
6	2次面接設定中の状態
7	3次面接設定中の状態
8	4次以降面接設定中の状態
9	適性検査設定中の状態
10	オファー面談設定中の状態
11	選考に通過し、転職希望者の意向を確認中の状態
12	現職の退職交渉中の状態
13	決定
1001	書類提出前にNGになった状態
1002	書類NGになった状態
1003	面接NGになった状態
1004	適性検査NGになった状態
1005	内定取り消しになった状態
2001	書類提出前に辞退になった状態
2002	書類通過後に辞退になった状態
2003	面接中に辞退になった状態
2004	適性検査後に辞退になった状態
2005	内定後辞退になった状態

問．以下のSQLを実行するとどのようなデータが抽出されるかイメージしてください。

SELECT
   progress_id ,
   applicant_id ,
   job_id ,
   status_id ,
   update_datetime
FROM
   progress01
ORDER BY
   progress_id ,
   update_datetime

答．以下のようなデータが抽出されます。

progress_id	applicant_id	job_id	status_id	update_datetime
1234	100	200	1	2023/03/01
1234	100	200	2	2023/03/02
1234	100	200	3	2023/03/03
1234	100	200	4	2023/03/04
1234	100	200	5	2023/03/05
1234	100	200	2003	2023/03/06
1235	101	200	1	2023/03/10
1235	101	200	2	2023/03/11
1235	101	200	3	2023/03/12
1235	101	200	4	2023/03/13
1235	101	200	1002	2023/03/14

問．上の表の進捗ID1234と進捗ID1235はどのような進捗の推移であったか、前述した進捗ステータスIDのマスタを見ながらイメージしてください

答．進捗ID1234に関しては、転職希望者ID100の人に求人ID200の求人を薦めて（ステータスID=1）→応募意思を示し（ステータスID=2）→書類をチェックし（ステータスID=3）→企業に書類を提出し（ステータスID=4）→1次面接設定中（ステータスID=5）になり→面接中に辞退した（ステータスID=2003）
という推移です。進捗ID1235も同様の方法で進捗を追っていきます。