すでに求人管理システムを使っている人材会社がホームページを制作するとき、求人一覧のデザインから決めると、公開後に同じ求人を二か所へ入力する仕事が残ることがあります。反対に「連携する」とだけ決めても、募集終了が反映されない、応募した求人が管理側で分からない、といった問題を見落としかねません。

制作前に整理したいのは、求人を直す場所、公開する情報、応募を受ける場所、その間で受け渡す内容です。現在の管理を使い続けながら、ホームページに何を持たせるかを具体的にします。

求人一件の更新を、公開画面までたどる

最初に、担当者が普段行っている求人の追加や変更を一件見せてもらいます。企業から条件の変更を受けたとき、どの画面を直し、誰が確認し、いつホームページへ載るのか。募集を終了するときも、同じ流れで確認します。

求人管理システムに最新情報があっても、公開サイトは担当者が手で書き写している場合があります。管理側を直すだけでサイトが変わると思い込まず、現在の反映方法を確かめます。CSVなどのファイルで移しているなら、書き出しと取込を行う担当、頻度、取込後の確認も記録します。

これからも手作業で更新する方法が直ちに不適切とは限りません。公開する求人が少なく、変更時に確実に確認できる運用もあります。ただ、同じ給与や勤務地を二か所で変更するなら、その作業が残ることを前提に制作範囲を決めます。「新しいサイトになれば二重入力がなくなる」という期待だけを残さないことが大切です。

管理項目のうち、何を外へ出すかを決める

社内の求人管理には、公開用の仕事内容や勤務地に加え、担当者のメモ、企業とのやり取り、社内管理番号などが入っていることがあります。管理項目をそのまま全件表示するのではなく、公開する項目と社内だけで使う項目を分けます。

同じ「企業名」でも、求人ごとに公開の扱いが異なる場合があります。公開の可否をどこで判断し、どの状態の求人だけをサイトへ出すかを決めます。空欄をそのまま表示するのか、非公開という案内にするのかも、求人の担当者が確認した方針にそろえます。

項目名が似ていても、内容が同じとは限りません。社内では勤務地を都道府県だけで管理し、公開側では勤務する地域の説明も必要なことがあります。給与も、数字と単位、補足条件が別々の欄になっている場合があります。表示したい文章と元の項目を並べ、足りない情報をどこで用意するかを確かめます。

公開情報の内容や募集条件は、人材会社が確認する情報です。制作会社は、確認した項目をどのように表示し、変更を反映するかを設計します。表示が整っていることと、求人条件の確認が済んでいることを同じ扱いにしないようにします。

求人の掲載と、応募情報の受け取りを分けて考える

管理システムから求人をホームページへ表示できても、応募情報が同じシステムへ戻るとは限りません。求人の公開と、求職者からの送信は、別々の流れとして確認します。

既存管理から公開求人へ必要項目を渡す流れと、応募受付から管理側へ応募内容と求人番号を戻す流れを分けた図
求人を出す流れと、応募を受ける流れは、それぞれ対応範囲を確かめます。

例えば、求人詳細の応募ボタンから既存システムの受付画面へ移るなら、今回のホームページで応募者情報を新たに保存せずに済む構成を検討できます。その場合も、移動先に対象の求人が引き継がれるか、一般の登録画面へ進むだけなのかで案内が変わります。

ホームページ側に応募フォームをつくるなら、入力内容をメールで受けるのか、管理システムへ自動登録するのかを決めます。「フォームがある」と「管理側に応募が登録される」は別の仕事です。求人を特定する番号、応募者情報、送信日時など、受け渡す内容を具体化します。

また、求人への応募と、求人を指定しないサービス登録は分けます。前者ではどの求人から来たかが必要になり、後者には応募先の求人がありません。日々の担当者が、その違いを管理画面で見分けられるかまで確認すると、受付後の仕事につながります。

リンク、提供機能、個別の連携を比べる

最も簡単な構成は、サービスの説明を新しいホームページで行い、求人一覧や応募は現在の公開画面へ案内する方法です。画面の移動はありますが、既存の更新方法を維持できる場合があります。求人ごとの案内先やスマートフォンでの使いやすさを確かめて選びます。

利用中のシステムが、サイトへ設置できる求人表示や応募フォームを提供している場合もあります。例えば、PORTERSのホームページ連携の案内では、専用アプリ「Web Parts」とAPIによる連携を紹介しています。提供済みの機能を使う方法と、個別に連携をつくる方法があるという確認材料になります。

APIは、システム間で情報を受け渡すための仕組みです。ただ、APIがあるだけで希望する項目や操作がすべて扱えるとは限りません。現在の契約で利用できるか、追加申込みや費用があるか、必要な項目を読み出し・登録できるかを提供元へ確認します。

独自の求人画面や検索、会員ページを希望する場合は、提供機能でどこまで実現できるかを比べます。画面の自由度だけで決めず、公開後の保守やシステム側の変更への対応も含めて見積りを確認します。提供元の説明にある連携機能が、ホームページ制作費へ自動的に含まれるわけではありません。

募集終了と、連携が止まった場合まで試す

テストは新しい求人が表示されるかだけでは足りません。条件を変更したとき、非公開にしたとき、募集を終了したときに、公開画面と応募先がどう変わるかを確かめます。終了した求人のURLへ直接来た方に何を案内するかも決めます。

情報を一定間隔で取り込む仕組みなら、管理側を変更してから公開側へ反映するまでに時間差があります。担当者がその時間差を理解し、急いで掲載を止めたい場合にどうするかを共有します。常に即時反映される前提の案内は、実際に確認できるまではしません。

条件変更の公開画面、募集終了時の表示と応募先、応募送信後の対象求人と受付記録を確かめる図
追加だけでなく、変更・終了・送信後の記録まで確認します。

応募では、完了画面だけでなく管理側に対象求人と内容が一件届いているかを確認します。失敗した送信を再処理したときに重複して登録されないか、届いていないことを誰が確認するかも、採用する方式に合わせて決めます。検証にはテスト用の情報を使い、実際の求職者への連絡や通知が発生しない方法を用意します。

制作の相談には、サービス名と契約内容、現在の求人公開URL、匿名化した項目見本、応募受付の流れがあると役立ちます。連携仕様を自社で読み解き終えてから依頼する必要はありません。提供元へ確認する事項も含め、調査と制作の範囲を分けて相談できます。

Bämの人材・採用支援のホームページ制作では、今の求人・応募管理を伺い、既存画面へのリンクと自動連携を分けて検討します。必要な原稿と画面、追加機能の範囲を整理し、求人内容の確認や応募者への連絡は人材会社の担当者が行う形で制作を進めます。

参考資料