採用サイトは誰が更新する？人事・広報・Web担当の役割分担

採用サイトにCMSがあっても、更新できる人がいるだけでは運用は続きません。求人条件を決める人、WordPressへ入力する人、公開を承認する人、サイトを保守する人、担当不在時に代わる人は、同じとは限らないためです。

本記事では、人事・広報・Web担当という部署名を固定解にせず、採用サイトの仕事を5つの責任と7つの作業へ分けます。一人が複数を兼務する小規模な組織でも、責任の種類を分けて記録すれば使えます。

求人媒体、採用サイト、ATSのどこが何を担うか決まっていない場合は、先に求人媒体・採用サイト・ATSの役割分担を確認してください。本記事は、その中で採用サイトが担う範囲を、社内担当と外部の制作会社へ割り当てるところに絞ります。

結論：更新担当を一人決めるだけでは足りない

採用サイトの運用では、作業ごとに次の5つを決めます。

責任	決めること	記録する結果
内容責任	どの情報が正しく、変更してよいか	正式な情報源、内容責任者
操作責任	誰がCMSや外部サービスへ入力するか	操作担当、使用するアカウント
公開承認	誰が公開・変更・終了を承認するか	承認者、承認方法
技術・一次確認	誰が表示不具合、応募先、WordPress、サーバー等を最初に確認するか	技術担当、外部の連絡先、依頼条件
代行・引き継ぎ	担当者が不在または変更になったとき誰が代わるか	代行者、引き継ぎ先、見直し日

同じ人が複数の責任を持ってもかまいません。たとえば、一人の採用担当者が求人条件の確認、WordPressへの入力、公開まで行い、制作会社が技術保守を担う形もあります。ただし「採用担当者が全部担当」と一行にまとめず、どの責任を兼ねているか、休職・退職時は誰が代わるかを別々に残します。

人事・広報・Web担当の役割は会社ごとに変わる

部署名から担当を自動的に決めるのではなく、その人が持つ情報、権限、技術、対応時間から割り当てます。

関係者	担当候補になりやすいこと	自動的には決まらないこと
人事・採用担当	採用計画、求人条件、募集開始・終了、応募先の確認	brand表現、WordPress保守、サーバー復旧まで担うとは限らない
広報	会社message、社員content、表現・媒体の整合	求人条件を確定できる、技術更新を実施できるとは限らない
社内Web・IT担当	CMS account、技術変更、保守会社との連絡	求人内容や社員情報を承認できるとは限らない
経営・部門責任者	採用方針、制度、配属先の正式情報、重要変更の承認	日常の入力や公開確認を行うとは限らない
現場社員	仕事の実態、社員contentの素材、掲載内容の本人確認	全社方針や求人条件の最終承認者とは限らない
制作・保守会社	CMS操作、改修、backup、update、障害調査等の契約範囲	社内情報の正しさや公開可否を企業に代わって自動判断しない

人事と広報が同じ部署、Web担当が不在、経営者が採用責任者を兼ねる会社でも考え方は同じです。人の名前を一つ書く前に、その人が「内容」「操作」「承認」「技術」「代行」のどれを担うかを分けます。

採用サイトの7作業を洗い出す

採用サイトで継続する作業は、少なくとも次の7つに分けて確認します。

作業	主な変更のきっかけ	内容責任者の候補	操作担当の候補	完了確認
求人情報	新規募集、条件変更、募集終了、再募集	人事、採用責任者、配属部門	人事、広報、Web担当、制作会社	公開求人、応募導線、終了表示、求人向け構造化データ
会社・制度情報	制度、拠点、組織、数値、会社方針の変更	制度担当、人事、広報、経営	広報、Web担当、制作会社	関連ページ、定義、更新時期、他の公開情報との不一致
社員・仕事content	入退社、異動、職務変更、掲載内容の見直し	人事、広報、本人、所属部門	広報、Web担当、制作会社	本人・部門の確認、公開ページ、関連リンク
お知らせ・event	説明会、選考日程、公開日、終了日	人事、採用責任者	人事、広報	日付、申込先、終了後の非公開・archive
応募先・privacy導線	form・ATS・privacy pageの変更、障害	人事、個人dataの社内責任者	Web担当、制作会社、外部サービス担当	ログアウト状態の到達、送信・受入の確認、障害時案内
計測・改善	定期review、採用施策、site改修	人事、広報、marketing	Web担当、制作会社	指標の定義、閲覧権限、変更前後の記録
WordPress・基盤保守	core・Theme・Pluginの更新、障害、契約・期限の通知	Web・IT責任者、委託管理者	Web・IT、制作・保守会社	backup、更新後の主要経路、復旧方法、domain・serverの期限

厚生労働省の職場情報提供に関する手引の概要では、求職者へ提供する情報を実態に近い正確な内容とし、長期間更新されていない情報を見直すこと、更新した時期等を併せて提供することが示されています。これは「すべてを毎週更新する」という意味ではありません。情報が変わるきっかけと、変わっていないかを確認する時期を、情報の種類ごとに決めます。

求人情報については、虚偽や誤解を生じさせる表示を避け、正確かつ最新の内容に保つことが求められます。制度と個別案件への適用は、厚生労働省の公式通知と必要な専門判断を確認してください。本記事の役割表だけで、掲載内容の適法性を判定することはできません。

更新のきっかけ・期限・代行者を決める

「月1回確認する」のような定期点検だけでは、急な募集終了や応募先の障害に間に合わない場合があります。定期確認と出来事による更新を組み合わせます。

1. 変更を検知する人を決める
2. 正式な情報源と内容責任者を確認する
3. 操作担当が下書きまたは変更案を作る
4. 公開承認者が内容と公開時期を確認する
5. 公開後に、ログアウト状態の表示と必要な導線を確認する
6. 更新日時、確認者、未完了項目を記録する

求人を終了する場合は、本文だけでなく応募ボタン、外部応募先、一覧、求人向け構造化データ等も確認対象になり得ます。GoogleのJobPosting公式ガイドも、期限切れ求人の処理や、ページ上のcontentと構造化データの一致を案内しています。ガイドに沿っても検索結果への表示や反映時刻は保証されないため、Google上の表示だけを完了条件にしません。

代行者には、担当者と同じ権限を常時渡す必要はありません。担当不在時に、どの連絡先へ、何を根拠に、どの操作を依頼するかを決めます。緊急の募集終了と、通常の社員content追加では、期限と代行方法を分けてもかまいません。

内製と制作会社への依頼を分ける

CMSで社内更新できることと、すべてを内製することは同じではありません。反対に、制作会社へ更新を委託しても、企業側の内容確認と公開承認まで自動的に移るわけではありません。

外部へ依頼する作業ごとに、次を記録します。

確認	記録すること
依頼の起点	誰が変更を検知し、依頼を出すか
依頼する範囲	content入力、画像加工、ページ追加、技術保守、障害調査のどこまでか
企業側の承認	誰が原稿・見積り・公開時期を承認するか
完了確認	誰が公開ページ、応募先、主要画面を確認するか
契約外の対応	緊急連絡先、追加費用、別会社へ戻す条件は何か

日常の文章更新と、WordPress本体・Theme・Plugin・server等の保守は、依頼先が同じでも別の作業として扱います。WordPress公式も、update前にsiteをbackupすることを案内しています。具体的な更新と復旧は、WordPress公式の更新手順と、使用中のTheme・Plugin・hostingの案内を確認してください。

担当変更と障害時の引き継ぎを残す

担当者が変わったときに、管理画面へ入れるだけでは運用を引き継げません。少なくとも次を一つの引き継ぎ先へまとめます。

• 7作業ごとの担当者、代行者、承認者
• 正式な情報源と、公開中・下書き・確認待ちの内容
• WordPressと外部サービスの利用者、管理主体、見直し対象
• 定期確認日と、募集終了・制度変更等の更新trigger
• 制作・保守会社の契約範囲、依頼方法、緊急連絡先
• backup、復旧、主要画面・応募先の確認手順
• 最終確認日、次の確認日、未完了項目

障害時は、最初から原因を断定せず、公開内容の誤り、応募先の不達、WordPressの不具合、server・domainの障害を分けます。応募できない、誤った求人条件が表示される、復旧方法が分からない場合は、新しい公開や追加変更を止め、担当範囲に応じた一次確認先へ連絡します。

一枚の運用責任表を完成させる

次の空欄を、自社の名前と期限で埋めます。部署がない場合は同じ人を複数欄へ書けますが、代行者と技術・外注窓口を空欄にしないようにします。

作業	内容責任者	操作担当	公開承認者	技術・外注窓口	trigger・期限	代行者	完了確認
求人情報
会社・制度情報
社員・仕事content
お知らせ・event
応募先・privacy導線
計測・改善
WordPress・基盤保守

表を埋めた後は、次を確認します。

• 内容を決められない人へ公開承認が集中していないか
• 操作担当だけが正式情報と判断経緯を持っていないか
• 制作会社へ依頼する場合も、企業側の依頼者と完了確認者がいるか
• 緊急の募集終了、応募先障害、担当不在に期限と代行者があるか
• WordPressのcontent更新と技術保守を同じ一語でまとめていないか

ここまで決まれば、採用サイトを誰が更新するかという一般判断は完了です。次は、この責任表を制作会社との引き渡し項目へ接続します。

WordPress採用サイトの制作・引き渡しチェックリストを確認する

WordPressの操作権限へ落とすときの注意

責任表を作っても、社内の肩書とWordPressのroleをそのまま対応させることはできません。「人事だから管理者」「広報だから編集者」と決めず、実際に必要な作成、下書き、公開、終了、設定、更新等の操作から権限を決めます。

• 採用サイトで何をCMS化するかで、社内更新、固定、制作者対応を分ける
• WordPress採用サイトの権限設計で、必要な操作、影響、実accountでの確認へ落とす
• 採用サイトの応募先をどこに置くかで、応募先と受入確認の詳細を決める

権限設定、account管理、技術保守の詳細は各記事と実際のsiteで確認し、本記事の部署別の初期例だけで確定しません。

2GUを使う場合と使わない場合

2GUは、Web制作者がWordPress上で採用siteを制作し、採用担当者へ主要contentの更新を引き渡すための制作キットです。完成済みsite、運用代行、技術保守、ATS、応募者・選考管理、採用代行ではありません。

2GUを使う場合も、この記事で作った責任表は必要です。

• 制作者が案件ごとの文章、写真、brand表現、応募先を整える
• 採用担当者が主要contentを更新する範囲を決める
• WordPress、server、domain、SSL、mail、backupの管理主体を別に決める
• 募集終了と応募先変更の判断者、公開確認者を決める
• 2GUの購入者、license、公式update、購入者supportの管理主体を記録する

WordPressの管理者を発注企業へ渡しても、2GUの購入者や購入者向けsupportの主体は自動で移りません。購入者が制作会社の場合は、発注企業から誰が制作会社へ連絡し、誰が公開結果を確認するかも引き渡し表へ残します。

公開manualでは、導入、募集公開、更新、引き渡しの手順を確認できます。対応環境と公開前に確認することでは、外部応募先、購入者側に残る確認、2GUに含まれない責任を確認できます。

2GUを使わない場合も、同じ5責任と7作業を使えます。利用するCMS、制作会社、ATS、社内体制に合わせて担当名と依頼条件を変え、空欄のない状態を公開前に確認してください。