二つの利用目的を、一つの運用基盤で支えた企業・求人サイト

同じ会社のサイトでも、会社を知りたい人と仕事を探したい人では、必要な情報、画面に滞在する理由、次に取りたい行動が異なります。両方を一つの情報順へまとめると、企業情報は求人一覧に埋もれ、求人側は検索や比較に必要な操作が弱くなります。

求人領域には、検索結果、仕事詳細、応募フォーム、お気に入り、閲覧履歴、検索条件保存など複数の機能があり、画面だけでなくデータと状態をつなぐ必要がありました。一方、コーポレート領域では事業紹介と問い合わせが中心です。素材が限られる中でブランドの統一感を保ちながら、二つの目的を明確に区別することが課題でした。

最初に、利用者の目的を「企業を理解する」と「仕事を探して応募する」に分け、入口、主要情報、完了行動を別々に定義しました。見た目を色だけで分ける案ではなく、コーポレート側は事業理解と問い合わせ、求人側は検索、詳細、比較、再訪、応募の順で情報構造を組み立てています。

求人領域では、検索して終わりにせず、お気に入り、閲覧履歴、条件保存を、候補を比べて後から戻る行動へ接続しました。ただし、保存対象ごとに保持条件が異なるため、同じ仕組みとして安易にまとめず、データと復元処理を分けています。

公開後もフォーム、計測、セキュリティ、サーバー移行を両領域の共通課題として扱いました。この方法は目的の異なる複数サイトを同一運用で支える場合に有効ですが、利用者情報を共有する場合は権限と同意を別途確認する必要があります。

同一ブランドとしての信頼感は保ちながら、コーポレート領域と求人領域で情報密度と操作の見せ方を変えました。企業側は事業内容や会社情報を順に読める構成、求人側は検索条件と候補を見比べやすい構成を採用しています。

素材が限られる中で複数のTOP案を作り、写真の違いだけではなく、最初に伝える情報と導線の違いを比較しました。求人側ではカード内で判断できる項目を絞り、詳細へ進む前の比較を支えています。

お気に入りや履歴は機能名を置くだけでなく、保存された状態、解除、空の状態を画面として設計しました。同じ会社のサイトを無理に一つのテンプレートへ押し込まず、利用目的に合わせた差を設けています。

求人領域では、検索条件、結果一覧、詳細、お気に入り、閲覧履歴、条件保存、応募フォームを一連の状態として接続しました。保存対象が異なるため、データと復元処理を分け、利用者が戻ったときに同じ条件や候補を確認できるようにしています。

コーポレート領域の問い合わせと求人応募は、入力内容や通知先が異なるため別のフォームとして扱いながら、確認、エラー、完了、計測の共通基準を揃えました。

公開後は、計測設定、フォーム調整、セキュリティ対応、サーバー移行を継続して確認しました。複数サイトでは、画面目的は分けても、保守責任、ログ、通知、公開手順を分断しないことが重要です。保存機能を使う場合は、端末変更や保持期間など適用できない条件も事前に説明する必要があります。