採用サイトの要件定義・RFP｜記入例と受入条件のテンプレート

採用サイトのRFP（提案依頼書）は、背景、解決したい課題、予算や期限などを制作会社へ伝え、提案を求める資料です。要件定義では、その提案を具体的なページ、機能、担当、検証条件へ落とし込みます。呼び方や工程が会社によって異なるため、資料名より、どの時点で何を合意するかを揃えます。

ベイジの採用サイトRFP解説は、採用課題や候補者とのコミュニケーションの課題を整理する観点を示しています。Studioの要件定義解説は、目的、構成、技術や運用等を整理しています。以下の記入例と表は、これらを踏まえた編集部独自の実務案です。

最初に「誰の、どの判断に必要な情報が欠けているか」を一文で書きます。「かっこいいサイトにしたい」だけでは、作るページも完成の条件も揃いません。応募数などの目標は、サイトだけで決まると考えず、募集条件や集客の変更と分けて扱います。

架空の記入例は「地方拠点の営業経験者が、担当エリア、訪問頻度、入社後の引き継ぎを比較できるようにする」です。確認方法は、公開前に当該職種の経験者に募集要項を読んでもらい、上の三点を説明できるかを確認する、とします。人数や評価方法は自社の検証計画として事前に決め、実施していない結果を成果にしません。

次の記入例は、複数職種を募集する企業が制作会社へ渡す初期RFPです。候補者の情報ニーズに直結する内容は必須とし、表現や実装の選び方には提案の余地を残します。未確定の条件は空欄で放置せず、確認者と確定する日を添えます。

「スマホ対応」「SEO対応」「応募フォーム対応」だけでは、対応した範囲が発注者と制作側で食い違います。どの画面で誰が何をし、何が起これば完了かを書きます。W3C WAIのフォーム解説のように、入力欄、説明、入力検証、結果通知を分けると、応募機能も確認しやすくなります。

下表は受入条件の案です。目標の端末・ブラウザー・検査基準は契約前に合意し、試験で使う環境と結果を保存します。全部の問題を自動検査だけで判定する条件にはしません。

依頼先ごとにページ数、取材人数、修正回数、撮影時間、CMS、連携、移行、公開後の保守を同じ表へ並べます。安い見積もりでも、自社で用意する原稿や別料金の作業が多ければ、総額と工数は変わります。予算内で必須要件を満たす方法を提案してもらいます。

支給する素材の有無、写真や動画を使える範囲、解約後に引き継げるもの、追加作業の単価も確認します。未確定の作業を暫定ゼロ円と扱わず、「未見積もり」「条件確定後に再見積もり」と表示します。要件に対応する見積行がない場合は、含まれていると推測せず確認します。

制作中に要望を追加したら、変更理由、対象ページ、費用、日程、担当、受入条件への影響を記録します。打ち合わせの口頭説明だけで範囲を増やさず、承認者が確定した版を制作側と共有します。現場の意見を採用担当がまとめ、同じ箇所へ矛盾する修正が届かないようにします。

架空の変更記録例は「社員記事を1本追加。取材対象と確認者を確定後、費用と公開日を再見積もり。初回公開には含めず翌月追加」です。公開を急ぐときも、募集条件の正確さ、正常な応募受付、必要な情報管理を未確認のまま後回しにしません。公開可否と未解決事項は、確認結果を見て責任者が判断します。

要件定義書は公開時に終わる資料ではありません。求人の追加、ATSの変更、動画や外部ツールの追加が起きたら、担当、検証方法、保存先の条件も更新します。公開後の初回確認日と、誰が募集条件の変更をサイトへ伝えるかまで残します。

全体の日程は制作工程、費用の比較は採用サイトの費用と見積もり、連携の詳細はATS連携の項目表で検討できます。利用できる画面の条件はアクセシビリティの点検と対応づけてください。