WordPress採用サイトの求人一覧・詳細・絞り込み設計

求人一覧では候補を絞り、詳細ページでは条件を確かめ、応募先へ進む。WordPressで採用サイトを作るときは、この一連の操作を先に決めておくと、必要な画面と機能を選びやすくなります。

求人カードが並ぶ画面だけでは、設計は終わりません。同じ職種で勤務地が違う求人を見分けられるか。条件を絞った後に別の求人を比較できるか。該当する求人がないときに、次の操作がわかるか。制作時には、こうした場面も確認します。

この記事では、採用サイトを制作する担当者に向けて、求人を探す側の画面設計を整理します。以下の求人件数や条件の組み合わせは、設計を考えるための仮例です。

一覧と詳細で、判断に必要な情報を分ける

一覧は「詳しく読みたい求人を選ぶ場所」と考えます。仕事内容をすべて載せる必要はありませんが、職種名だけでは区別できない求人もあります。勤務地や雇用形態など、候補を選ぶ際に違いとなる情報を求人カードへ出します。

まず、求人の原稿を使って次の場面を確認してください。

画面・状態	求職者がしたいこと	設計で決める内容
最初の一覧	募集中の求人を見渡す	カードの項目、並び順、表示件数
絞り込み後	希望に合う候補を選ぶ	選択中の条件、該当件数、条件の外し方
求人詳細	条件を読み、応募するか考える	募集内容、応募先、一覧へ戻る方法
検索結果0件	条件を変えて探し直す	該当なしの説明、条件を解除する操作
募集終了の詳細	募集が終わったことを知る	終了表示、応募導線の停止、他の募集中求人への案内

カードに表示する情報と、管理画面で保存する項目は別の設計です。職種や勤務地をどの単位で持つかが未確定なら、先に求人情報のデータ設計を決めます。画面ごとに似た情報を手入力して、一覧と詳細で条件が食い違う状態は避けましょう。

絞り込みは、候補を減らせる条件だけにする

検索項目は、多ければ探しやすくなるとは限りません。たとえば、同じ勤務地で3職種を募集するサイトなら、全件を見比べる方が早いこともあります。複数拠点で30件を募集するサイトなら、職種や勤務地で候補を減らす意味が出てきます。件数だけで一律に決めず、実際の求人を並べて判断します。

検索に使う条件には、採用担当者が継続して正しく登録できる項目を選びます。「東京」「東京都」「東京本社」が別々の選択肢になると、求職者には違いが伝わりません。検索機能を追加する前に、選択肢の名称と使い分けをそろえておきます。

複数選択したときの意味を決める

「営業」「東京」「大阪」を選んだ場合、どの求人を表示するでしょうか。一例は「職種が営業、かつ勤務地が東京または大阪の求人」です。条件の種類をまたぐときはAND、同じ種類の複数選択はORとする考え方です。

これは唯一の正解ではありません。画面のラベル、実際の検索処理、想定する結果が一致しているかを、求人のサンプルで確認します。「勤務地を二つ選ぶと候補が増える」のか「両方の勤務地に該当する求人へ減る」のかは、制作側と採用担当者の間でも合意が必要です。

選んだ条件は、結果を見ながら確認できる位置に残します。一つずつ外す操作と、すべて解除する操作も用意してください。検索結果が0件でも、自動で条件を緩めて別の求人を混ぜず、求職者自身が条件を変えられるようにします。

求人詳細は、条件を読んでから応募できる構成にする

詳細ページには、仕事内容、勤務地、雇用形態、給与・勤務条件、応募資格などを、項目ごとに読める形でまとめます。これは画面構成の例であり、募集時に必要な表示事項を網羅した法務チェックではありません。

求人カードと詳細の対応も確かめます。「営業職」という同じ名前でも、東京勤務と大阪勤務が別の募集なら、開いた詳細でどちらかわかる必要があります。別の求人を比較したくなったときのために、一覧へ戻る手段も残しておきます。

求人情報をGoogleへ伝える構造化データ（JobPosting）を出す場合、対象は求人1件を説明する詳細ページです。求人一覧や検索結果には付けません。この区別はGoogleの技術ガイドラインでも示されています。Googleしごと検索に向けた出力内容の設計と実装は、JobPostingの実装手順で確認できます。

応募ボタンは、読んでいる求人に対応する応募先へつなぎます。外部の採用管理サービスを使うなら、その求人の応募画面へ進むのか、外部サイトで再び求人を探すのかを確認してください。ボタンの近くで遷移先を案内し、職種・勤務地が引き継がれる場合は、実際の値まで確かめます。応募先の方式選びは採用サイトの応募導線で扱っています。

一覧へ戻ったときに、探していた条件を失わない

絞り込んだ一覧から詳細を開き、別の求人と比べるために戻る。この操作で検索条件が消えると、求職者は同じ条件を選び直すことになります。

ブラウザーの「戻る」と、詳細ページ内の「一覧へ戻る」の両方で、条件・並び順・ページ位置がどうなるかを決めます。常に全件一覧へ戻すリンクを置く場合も、その動きだとわかる表記にしてください。ページ送りがある一覧では、2ページ目以降にも同じ条件を引き継ぎます。途中で条件を変えたら、結果の先頭へ戻す設計が考えられます。

絞り込んだ状態を共有したいなら、その状態をURLで開き直せるかも確認します。ただし、共有できるURLを作ることと、検索エンジンにすべて登録させることは別です。条件の組み合わせから大量のURLを作ると、クロールの負荷を増やすおそれがあります。Googleの絞り込みナビゲーションの解説を参考に、検索流入を受ける一覧と、操作のためのURLを分けて検討します。

「条件に合わない」と「募集していない」を分ける

同じ0件でも、全体では募集中の求人がある場合と、募集自体がない場合では、伝える内容が違います。

絞り込み後だけ0件なら、「選択した条件に合う求人はありません」と説明し、条件を外せるようにします。全体が0件なら、現在は募集していないことを伝えます。この状態で、検索条件の変更だけを促しても求人は見つかりません。

データの読み込みに失敗した場合も、募集なしと表示しないようにします。再読み込みなど、利用できる操作を案内する設計が必要です。

募集が終了した求人の詳細ページを残す場合は、終了したことを明示し、応募できるように見えるボタンを残さない方針を採ります。他の求人へ案内するなら、現在募集中の一覧へつなぎます。構造化データや終了後のURLを含む運用は、募集終了・期限切れ・再募集の扱いと合わせて決めてください。

WordPressの一覧表示と、検索操作を分けて確認する

WordPressのQuery Loopブロックは、条件に合う投稿を繰り返し表示するためのブロックです。投稿の表示項目に加え、ページ送りや結果がない場合の表示も構成できます。設定できる内容は、WordPressのQuery Loopの説明で確認できます。

ここで区別したいのは、編集者がブロック設定で表示対象を絞ることと、訪問者が公開画面で条件を選ぶことです。編集画面にフィルター設定があるだけでは、求職者向けの検索フォームを用意したことにはなりません。

利用するテーマやプラグインで、必要な求人の種類と項目を表示できるかを確かめます。そのうえで、複数選択、条件解除、URLへの条件の保持が足りるかを確認してください。機能が足りなければ、追加開発の範囲をここで判断します。

検索フォームは、キーボードだけでも条件を選び、実行・解除できるかを確認します。入力欄には意味のわかるラベルを付けます。ページ全体を移動せずに検索結果を更新する方式では、件数や該当なしの通知が、スクリーンリーダーにも伝わるようにします。W3Cのステータスメッセージの解説では、更新後の件数などを支援技術が認識できるようにする考え方が示されています。

代表的な操作を通して、設計を確かめる

制作時の確認には、同じ職種で勤務地が異なる求人と、条件の組み合わせで0件になるサンプルを用意します。完成画面では、次のように一連の操作を通してください。

1. 一覧で求人の違いを見分け、条件を複数選ぶ。
2. 表示件数と求人が想定どおりか確認し、詳細を開く。
3. 応募先を確認してから一覧へ戻り、条件を変えて探し直す。
4. 0件になったら条件を解除し、募集終了の表示も確認する。

スマートフォンの幅とキーボード操作でも、同じ仕事を終えられるかを確かめます。静止した一覧画面が整っていても、条件を変えたり詳細から戻ったりしたときの使い勝手まではわかりません。

先に必要な操作を決め、その操作を実現する表示方法を選ぶ。制作方式を比較する際は、2GUのデモでも表示構成を確認し、今回の要件に使える部分と、追加の作り込みが必要な部分を分けて検討してください。