面談日時が決まっても、選考状態と通知が別々なら、採用業務はまだつながっていません。

面談予約だけでなく、選考状態の引き継ぎまでを対象にする

対象は、企業と求職者をつなぐ採用支援サービスです。移行元のAMELAケース資料では、候補者管理、面談日程調整、応募書類と通知、企業アカウントの審査・マスタ管理が、同じ業務フローの設計対象として記録されています。

AMELAが担当した範囲として確認できるのは、Reactを用いた候補者・応募者向け画面、Laravelを用いた業務処理、MySQLのデータ管理、運営向け管理画面です。企業名、プロジェクト名、候補者名、企業名、日付、件数、状態、画面は、機密保持のため承認済みの仮名またはモックに置き換えています。

候補者・企業・運営の操作を、状態でつなぐ

公開資料では、React、Ant Design、React Query、Laravel、MySQLを用いた構成が示されています。公開デモでは、候補者一覧の状態・職種による絞り込み、候補者詳細、面談枠の提示・確定、応募者による枠選択と書類登録、運営による企業アカウント審査とマスタ確認を操作できます。

面談枠は「提示中」「候補者が選択」「確定済み」を分け、確定操作後に選考状態と通知を更新する流れです。これは公開用モックの動作であり、本番環境の処理件数や通知到達率を示すものではありません。

この事例の根拠と読み方

• 根拠：AMELAの移行元ケース資料、CMS登録内容、2026年8月27日に確認した公開デモの動作と画面。
• 対象期間：公開資料に記載された開発範囲と、上記確認日時点のデモ。
• 確認できること：候補者の絞り込みと詳細、面談枠の提示・選択・確定、応募書類、状態連動、通知の操作、企業アカウント審査、業種・通知テンプレートの管理、React・Laravel・MySQLを用いた構成。
• 確認できないこと：本番データ量、処理性能、調整時間・工数の削減、採用成果、利用率、権限設計の詳細、個人情報保護の運用、監査・認証・法令適合、障害・可用性の実績。
• 公開上の扱い：企業名、プロジェクト名、候補者名、企業名、日付、件数、状態、画面は機密保持のため仮名またはモックです。実在する個人、顧客、採用結果を示すものではありません。

個人情報と例外処理は、別途受入条件にする

候補者情報と応募書類には個人情報が含まれます。閲覧権限、保存期間、削除・訂正、ダウンロード、操作記録、退職・異動時の権限削除は、導入企業の規程と法務確認に合わせて設計する必要があります。公開デモの表示だけで、これらの運用や法令適合を確認することはできません。

面談には辞退、再調整、重複予約、タイムゾーン、オンライン会議URLの未発行、通知失敗などの例外があります。正常系の予約操作だけで受入を終えず、誰が復旧し、どの状態へ戻すかを決めてください。

読者が使える実践ツール

要件定義の前に、次の「責任分界・例外処理・受入確認シート」を埋めると、採用担当、候補者、運営、システムの境界を整理できます。以下は公開デモで確認できる操作を使った記入例であり、HireLoop本番環境の運用値ではありません。

• 選考状態：「面談調整中」から「面談予約済」へは企業の確定操作で進める。戻せる担当者と変更理由の記録方法を別途決める。
• 面談枠：企業が複数枠を提示し、候補者が一つを選び、企業が確定する。辞退・再調整・重複時の優先ルールを決める。
• 書類：履歴書を候補者記録にひも付ける。閲覧者、保存期間、差し替え、削除、持ち出しの可否を決める。
• 通知：面談確定を通知の起点にする。宛先、テンプレート、再送、失敗検知、手動連絡への切り替え条件を決める。
• 運営審査：企業アカウントの申請と承認を分ける。承認者、却下理由、再申請、権限付与の記録方法を決める。
• 受入確認：状態・職種の絞り込み、枠の選択・確定、書類登録、通知表示、審査の承認・却下、権限外アクセス、例外からの復旧を役割別に確認する。

実データで評価する場合は、候補者数、同時利用者、面談枠のルール、通知チャネル、保存期間、外部カレンダー・会議・採用管理システムとの連携、除外条件をそろえて受入基準を定義してください。