採用サイトで何をCMS化するか｜更新範囲の決め方

採用サイトのCMS化範囲は、「更新頻度が高そうだから」という理由だけでは決められません。変更が起きる条件、更新する人、公開を承認する人、入力時に検査したい項目、項目間の参照関係、募集終了等の状態、必要な表示自由度まで見て決めます。

受注から公開・引き渡しまでの全体順を先に整理したい場合は、WordPress採用サイトの制作・引き渡しチェックリストを参照してください。この記事では、その中の「顧客が更新する範囲」を一段深く掘り下げます。

結論：CMS化する範囲は「更新頻度」だけで決めない

最初に、採用サイトの情報を次の3つへ分けます。

1. 定型CMSで顧客が更新するもの：同じ単位の情報を繰り返し追加・変更し、入力検証や公開状態の管理が必要なもの
2. 固定ページとして更新するもの：ページ単位で意味とレイアウトを保ち、必要時に文章や画像を直すもの
3. 制作者対応に残すもの：項目定義、テンプレート、デザイン、外部連携等、変更の影響がサイト構造へ及ぶもの

ここでいう「定型CMS化」は、WordPressに保存すること全般ではありません。専用の入力項目、一覧、状態、参照、検証等を用意し、担当者が決められた手順で運用できるようにすることを指します。固定ページもWordPress上で編集できますが、毎日の運用対象として専用データ化するかは別の判断です。

「全部CMS化」とすると、管理画面、検証、権限、移行、テスト、マニュアルの対象まで増えます。反対に固定しすぎると、募集を終了するたびに制作者対応が必要になります。大切なのは、編集できる箇所の数ではなく、運用を最後まで成立させることです。

先に確認する7つの判断軸

ページ名から決めず、情報の更新単位ごとに次の7点を確認します。

判断軸	確認すること	CMS化へ寄る条件
変更のきっかけ	新規募集、異動、制度改定等、何をきっかけに変わるか	きっかけと変更手順を定型化できる
頻度・件数	何件を、どの期間で追加・更新するか	同じ単位が繰り返し増減する
更新責任者	正式情報を持ち、入力する担当者は誰か	継続して担当できる責任者がいる
公開承認	誰が内容を確認し、公開を決めるか	入力と承認の流れを決められる
入力検証	必須、条件付き必須、日付、URL等をどこまで検査するか	公開前に機械検査したい項目が多い
参照・状態	他項目から参照されるか、終了・非公開等があるか	関係や状態を複数の表示へ連動させたい
表示自由度	同じ型で表示できるか、毎回構成を変えるか	一覧・詳細等の共通型を維持できる

7項目のうち一つだけで決めません。たとえば年1回しか変わらない会社名でも、求人全件で共通利用するなら、一つの共通設定から参照する価値があります。逆に毎月追加する特集でも、毎回構成が大きく変わり、編集者が自由な誌面を必要とするなら、定型データへ細分化しすぎない方が扱いやすいことがあります。

更新責任者が決まっていない情報をCMS化しても、更新は続きません。入力画面を作る前に、「誰が正しい情報を持つか」「誰が公開を止められるか」を決めます。

採用サイトの情報を更新単位で分ける

「採用ページ」という大きな単位ではなく、変更理由が同じ情報を一つの単位として棚卸しします。

• 求人は、募集開始、条件変更、応募停止、募集終了で変わる
• 社員紹介は、異動、役職変更、公開許可の変更で変わる
• インタビューは、企画、取材、校正、公開終了で変わる
• FAQは、問い合わせの増加、応募方法、選考手順の変更で変わる
• 会社・事業情報は、正式情報や組織の変更で変わる
• 仕事紹介は、部門や職種の再編で変わる
• 福利厚生・制度は、制度改定や適用条件の変更で変わる

同じページに表示する情報でも、変更のきっかけが異なれば保存・承認単位を分けます。会社情報を求人ごとに再入力したり、一人の社員プロフィールを複数のインタビューへコピーしたりすると、変更時に差が生じやすくなります。

一方、再利用の可能性だけを理由に細かく分割するのも避けます。別々に更新する担当者がおらず、参照先もなく、ページ全体で承認する情報なら、固定ページのまとまりを保つ方が確認しやすくなります。

求人・社員・インタビュー・固定情報の判断表

次の表は初期案です。案件の件数、運用体制、必要な表示に合わせて変えます。

対象	主な変更のきっかけ	特に管理したいこと	第一候補	制作者対応へ戻す条件
求人	新規募集、条件変更、応募停止、終了	必須条件、応募先、公開・終了状態、一覧との連動	定型CMS	項目追加、状態設計、応募先連携、テンプレート変更
社員紹介	入社、異動、役職・公開許可の変更	本人・社内確認、複数ページからの参照、非公開時の扱い	件数と再利用があるなら定型CMS。少数なら固定ページ	項目構成、参照規則、カード表示の変更
インタビュー	企画、取材、校正、公開終了	対象社員との関係、一覧用情報、本文の編集自由度	共通プロフィールはCMS、本文はブロック編集の併用	質問構成や誌面を大きく変える企画
FAQ	問い合わせ増加、手順・方針変更	質問と回答の責任者、並び順、古い回答の確認	少数なら固定ページ。反復追加や分類が必要ならCMS	回答責任の変更、検索・分類・表示仕様の追加
会社・事業	正式情報、事業、組織の変更	正式名称等の共通値、社内承認、ページ全体の文脈	共通値は一元管理、説明は固定ページ	構成、ブランド表現、複数ページへの反映方法の変更
仕事紹介	部門、職種、仕事内容の変更	求人との関係、部門別の更新責任者、一覧化の必要性	少数なら固定ページ。繰り返し単位が明確ならCMS	職種体系、関連付け、比較表示の変更
福利厚生・制度	制度改定、対象・条件の変更	適用条件、施行日、正式承認、旧情報の停止	少数なら固定ページ。件数と改定が多ければCMS	法務・労務確認、表示形式、履歴要件の変更
選考フロー	選考段階、期間、連絡方法の変更	共通手順と求人別例外、公開承認	共通は固定ページ、例外は求人側の限定項目	分岐増加、外部サービス連携、進行管理機能の追加

求人は定型CMSへ向きやすい一方、会社・制度ページまで必ず専用データにする必要はありません。FAQも、10件程度を一つのページで管理する段階と、担当部署・分類・公開期間を持つ多数のFAQを管理する段階では設計が変わります。

「将来増えるかもしれない」だけで仕組みを先行させず、増えた時にどの変更が必要になるかを見積りへ残します。

更新担当・公開担当・技術保守担当を分ける

CMS化する対象を決めるときは、次の3役を混同しないようにします。

役割	主な責任	代替しないもの
更新担当	正式情報を集め、下書きへ入力する	公開可否の最終判断
公開担当	内容、許可、条件を確認し、公開・終了を決める	テンプレートや検証規則の改修
技術保守担当	WordPress、テンプレート、入力項目、検証、連携、復旧を管理する	会社・求人情報の正しさの判断

一人が複数の役割を持っても構いません。ただし、見積りや引き渡しでは役割ごとに名前を記録します。

更新担当・公開担当・技術保守担当へ実際のWordPress操作を割り当てるときは、WordPress採用サイトの権限設計｜顧客に渡す操作の決め方を参照してください。

顧客更新へ渡しやすいのは、用意された項目への入力、下書き、プレビュー、公開・終了、並び順等です。項目の追加、入力規則の変更、ページ構造、Navigation、テンプレート、外部フォーム連携、権限、障害復旧は、影響範囲を確認できる制作者または技術保守担当へ残します。

CMSがあること自体は、安全、低コスト、誰でも更新可能であることを意味しません。担当者が使う実際のアカウントで、入力から公開・終了まで試して初めて、引き渡せる範囲を確認できます。

管理画面を作る前に受け入れ条件を決める

実装前に、少なくとも次の結果を合意します。

• 不完全な内容を下書き保存でき、公開に足りない項目が分かる
• 条件付き項目、日付、URL、数値等の誤りを公開前に検出できる
• 公開済み情報から必須項目を消す場合の挙動が決まっている
• 参照先を非公開・削除したとき、参照元を連鎖削除せず安全に扱える
• 募集終了等の状態が、一覧、詳細、応募導線へ矛盾なく反映される
• 0件、画像なし、長い文章でも公開画面が壊れない
• 更新担当が通常作業を完了でき、構造変更は技術保守担当へ戻せる
• PCとスマートフォン、ログアウト状態で結果を確認できる

検査をシステムへ実装しない項目は、人の公開チェックへ明示的に残します。「入力欄があるから確認できる」とは扱いません。

WordPress標準と2GU固有の仕様を分けて見る

WordPress標準で決まっていること

WordPressにはpostやpage等の投稿タイプがあり、独自のCustom Post Typeも追加できます。公式資料では、postは時系列やcategory・tag・feedを持つ用途、pageは非時系列・階層的な用途として説明されています。また、Custom Post Typeはtheme変更時のcontent portabilityを保つため、themeではなくpluginに置くことが推奨されています。詳しくはWordPress公式のPost Types解説を確認してください。

WordPressにはroleとcapabilityの仕組みもあり、利用者が実行できる作業を分けられます。ただし、WordPress標準が「求人はCPT、会社情報は固定ページ」と決めているわけではありません。採用サイトの更新単位、公開承認、検証、状態は案件側で設計します。

2GUではどう分けているか

2GUは一例として、採用基本設定を1サイトに1件、求人、社員、インタビューをそれぞれ複数件の構造化された情報として扱います。求人は公開・募集終了等の状態と公開条件を持ち、社員プロフィールは複数箇所で再利用でき、インタビューは対象社員を参照します。

採用トップと募集一覧を基礎に、会社・事業、仕事、社員インタビュー一覧、数字、福利厚生・制度、選考、FAQ等は、案件に必要な固定ページだけを選びます。固定ページ本文まで過度に項目化せず、求人・社員・インタビュー等の反復データを必要な箇所へ表示します。

2GUでは、採用担当者に相当する編集者が求人、社員、インタビューを扱い、採用基本設定、セットアップ、ライセンス等は管理者へ分けています。生成ページの編集保護は日常更新時の誤操作を抑えるUI上の仕組みであり、アクセス制御やバックアップの代わりではありません。

これは唯一の正解ではありません。求人件数、社内承認、外部システム、表現要件が違えば、固定ページや別の情報設計が適する案件もあります。製造業とITの架空企業デモでは、共通するデータ構造と案件ごとに変えたページ・表現を比較できます。実際の操作範囲は公開マニュアルで確認できます。

見積り・提案へ残す決定事項

CMS化範囲を決めたら、見積りと提案へ次を残します。

1. 定型CMS、固定ページ、制作者対応へ分けた対象一覧
2. 情報ごとの変更のきっかけ、更新担当、公開担当、技術保守担当
3. 必須項目、条件付き項目、人が確認する項目
4. 下書き、公開、終了、非公開、参照切れの扱い
5. 一覧、詳細、関連表示、0件時表示の範囲
6. 顧客アカウントで行う公開前テスト
7. 項目・状態・テンプレート・連携を変更するときの追加作業

この記録があれば、「CMS対応一式」という曖昧な見積りを避け、どこまでを顧客が運用でき、どこからを制作者へ戻すかを説明できます。

一般判断の結果が2GUの分け方に近い場合は、2GUの内容と料金・提供条件で案件への適合を確認してください。先に商品へ合わせるのではなく、必要な更新範囲を決めてから照合する順序が重要です。