WordPress採用サイト制作を標準化する5つの方法

WordPress採用サイト制作を標準化することは、同じ見た目のテンプレートをすべての案件へ当てることではありません。求人情報の状態、入力確認、公開前テスト、引き渡し等の繰り返す部分を共通化し、採用ターゲット、原稿、写真、ブランド、応募先、社内責任等は案件ごとに決めることです。

制作土台には、過去案件の流用、自作starter、汎用Theme＋Plugin、採用特化kit、full scratchという5つの方法があります。本記事では、機能数や価格で順位を付けず、6つの確認軸で自案件へ当てます。最後に、候補を1案件pilotで測り、次案件へ残す・直す・捨てるものを決めます。

求人媒体、採用サイト、ATSのどこが何を担うか決まっていない場合は、先に求人媒体・採用サイト・ATSの役割分担を確認してください。WordPress制作を選ぶ前提が成立している案件を、本記事の対象とします。

結論：見た目ではなく、繰り返す要件・data・testを標準化する

最初に、過去2〜3案件または今回の要件から、毎回現れる作業と企業固有の作業を分けます。次に、再利用する単位を表示、site機能、data、content、test・handoffへ分解します。そのうえで5方式を比較し、候補を実案件で測ります。

一つの方式がすべての案件に向くとは限りません。案件ごとに次を記録できれば、方式選択の一般判断は進められます。

• 繰り返す要件と、今回だけの要件
• 候補方式が満たすこと、満たさないこと、未確認のこと
• どこまで変更でき、update時に何を再確認するか
• 誰がtestし、顧客へ何を引き渡すか
• 障害、契約終了、Theme変更時に何を復旧・移行できるか
• 1案件で何を測り、次案件へ何を残すか

制作工程そのものを洗い出す場合は、WordPress採用サイトの制作・引き渡しチェックリストを入力にしてください。本記事では、その工程のどこを再利用するかに絞ります。

まず標準化するものと案件ごとに決めるものを分ける

標準化の対象は、完成した見た目だけではありません。次の5層へ分けると、共通化によって案件固有の表現や責任まで固定することを避けられます。

層	標準化する候補	案件ごとに決めるもの
presentation	responsiveの基本構造、共通component、状態表示、accessibilityの確認方法	brand、art direction、写真、animation、案件固有layout
site機能	公開状態、入力検証、一覧・詳細、編集保護、基本の確認手順	必要機能、外部連携、既存siteへの影響、security要件
data	求人・社員等のfield候補、状態、参照関係、終了処理	実際の項目、情報の正本、定義、移行、保存期間
content・layout	編集可能なpattern、原稿収集欄、確認status	採用target、訴求、文章、写真、情報の優先順位
test・handoff	test観点、受入記録、manual、account棚卸し、rollback確認	担当、承認者、期限、保守契約、障害連絡、顧客環境

たとえば、求人に「公開前・公開中・募集終了」の状態を持たせる考え方は再利用できます。一方、実際の求人条件、情報の定義、募集終了の判断者は案件ごとに確認します。厚生労働省の職場情報提供に関する手引・第3版も、求職者が求める情報や提供時期は多様で、一律に定めることが適切でない場合があること、情報は実態に近い正確な内容とし、長期間更新されていない情報等を見直すことを示しています。

これは、すべての採用サイトに同じ項目や更新頻度を設定する根拠ではありません。標準化するのは、事実を集め、確認し、更新する枠です。公開する事実と判断は企業・求人ごとに確認します。

採用サイトで何をCMS化するかを使うと、社内更新、固定page、制作者対応へ分けた結果を、dataとcontentの案件差分へ入力できます。

WordPressでは再利用する単位が一つではない

WordPress公式のTheme Handbookは、Themeをcontentのpresentation、Pluginをsiteのbehaviorやfeatureの担い手とし、site-criticalな機能をThemeへ置かないことをbest practiceとして示しています。Themeを替えたときにも残す必要がある機能やdataは、見た目と分けて考えます。

layoutの再利用にも複数の単位があります。WordPress公式のpattern、template part、synced patternの比較では、site構造、同期するcontent、案件ごとに変更するlayoutを分けています。求人等にcustom post typeを使う場合も、WordPress公式はcontentの可搬性を理由にThemeではなくPluginへ置くことを推奨しています。

ただし、すべての採用サイトでcustom post typeや特定のpatternが必須という意味ではありません。次を別々に選びます。

• presentationを担うTheme、style、template
• siteに残す機能とdataの保存先
• 案件ごとに変更するpatternとcontent
• 入力検証、公開状態、応募先等の運用logic
• test、manual、更新、復旧の手順

既存WordPressへ組み込むか、別WordPressに分けるかで前提が変わる場合は、採用サイトを既存WordPressに入れるか別にするかを先に確認してください。

制作土台の5方式を比較する

5方式は排他的ではありません。自作starterへ通常patternを組み合わせる、汎用Themeへ採用data用Pluginを加える等の併用もできます。ただし、責任境界とupdate経路を記録できない組み合わせは候補から外します。

方式	向く可能性がある起点	早期停止する例
過去案件流用	類似案件があり、元案件の権利、data、依存、変更履歴を確認できる	元顧客のdata、秘密、契約、固有設定を安全に分離できない
自作starter	継続案件があり、自分たちでowner、保守、test、documentを持てる	一人しか直せず、version、利用案件、rollbackが記録されない
汎用Theme＋Plugin	採用固有要件が少なく、既存製品の組み合わせで要件を満たせる	求人data、終了状態、handoffを毎回大幅に追加する
採用特化kit	共通要件が製品責任と合い、案件差分を残せる	外す機能や上書きが増え、企業固有表現と運用を保てない
full scratch	固有要件、既存基盤、契約、性能等が既存の土台を上回る	固有要件の根拠がなく、既存手段との差分を説明できない

1. 過去案件を流用する

完成済み案件を複製すると、画面だけでなく顧客固有のdata、素材、account、URL、計測、license、不要code、古い設定まで引き継ぐ可能性があります。「動いた案件」であることと、「次案件の安全な土台」であることは同じではありません。

流用する前に、顧客固有情報を含まない再利用元を作れるか、第三者素材やPluginの利用条件を確認できるか、元案件と次案件の差分を追えるかを確認します。分離できない場合は、過去案件そのものではなく、共通部分だけをstarterまたはpatternとして作り直します。

2. 自作starterを育てる

自作starterは、採用サイトの共通要件と変更範囲を自分たちで決められます。同時に、WordPressやPHPの対応、依存関係、security、release、test、manual、rollback、利用中案件への案内も自分たちの責任になります。

codeを置くだけでなく、owner、version、変更記録、利用中の案件、検証環境、復旧方法を持てるかで判断します。保守時間を確保できない、担当者が一人に固定される、利用案件を追えない場合は、共通化する範囲をpatternやchecklistへ縮小します。

3. 汎用Theme＋Pluginを組み合わせる

採用固有のdataや運用が少なければ、汎用Theme、form、SEO、custom field等の既存製品を組み合わせる方法があります。確認するのは個々の機能だけではなく、組み合わせた状態の保存先、権限、update、競合、終了処理、受入、license、supportです。

求人や社員情報をどこへ保存するか、Theme変更後に何が残るか、募集終了時に一覧・詳細・応募先・構造化dataをどう揃えるかを案件ごとに設計する必要があるなら、その設計とtestを見積もりへ含めます。応募受付先は共通templateへ固定せず、採用サイトの応募先をどこに置くかで案件ごとに決めます。

4. 採用特化Themeまたはkitを使う

採用特化製品は、募集、社員紹介、採用ページ等の共通部をまとめている場合があります。ただし、機能が多いことだけでは案件適合を判断できません。demo、管理画面、dataの保存先、Theme変更、override、不要機能の外し方、対応環境、license、update、support、契約終了時の挙動を確認します。

製品の責任と案件要件が合い、企業固有のcontent・brand・応募先・運用を残せる場合に候補とします。具体的なTheme候補へ進んだ後は、WordPress採用サイト向けThemeの選び方で、表示だけでなく受入状態まで確認してください。

5. full scratchで作る

既存基盤、独自の情報構造、契約、性能、security、accessibility、外部連携等の固有要件が既存の土台を上回る場合は、full scratchへ戻します。自由度が必要な理由と、設計・実装・test・保守・handoffのownerを説明できることが前提です。

要件がまだ曖昧な段階でfull scratchを選ぶと、共通部まで案件ごとに決め直すことがあります。固有要件と既存手段で足りない点を先に書き、差分が説明できない場合は、より小さい再利用単位から比較し直します。

6軸で自案件へ当てる

次の表は、方式の優劣を採点するものではありません。各cellを適合、条件付き、不適合、未確認のいずれかで自案件に判定するための質問です。mobileでも確認しやすいよう、6軸を二つの表に分けます。

方式	共通要件への適合	案件差分の残し方	dataの可搬性
過去案件流用	元案件の実装が今回も必要か。不要な依存はないか	顧客固有の文章、素材、設定、accountを分離できるか	元顧客dataを複製せず、必要な構造だけ再作成できるか
自作starter	繰り返す要件をtest付きで維持できるか	token、pattern、案件差分の置き場所を決めているか	保存先、export、移行、削除の責任を自分たちで持てるか
汎用Theme＋Plugin	組み合わせ全体で採用要件と終了状態を満たすか	Theme、Plugin、案件設定の差分を分けられるか	各製品の保存先とTheme変更時の挙動を確認したか
採用特化kit	製品責任が案件の共通要件と一致するか	変更可能・固定・対象外の箇所を説明できるか	Theme変更、export、移行、契約終了時のdataを確認したか
full scratch	固有要件と受入条件をすべて定義できるか	案件差分を最も広く持てる一方、固定範囲も決めたか	schema、migration、export、廃止を案件責任として設計したか

方式	変更・override範囲	受入・引き渡しの再現性	更新・復旧・support境界
過去案件流用	元案件からの差分と、updateを受ける箇所を追えるか	元案件の確認結果に頼らず、今回の実accountでtestできるか	古い依存、保守先、backup、復旧方法を確認できるか
自作starter	version管理、拡張点、上書き禁止箇所をdocument化したか	共通test、案件test、manual、未完了を同じ形式で残せるか	owner、release期限、障害連絡、rollbackを継続できるか
汎用Theme＋Plugin	child Theme、hook、設定等の正規な変更経路があるか	組み合わせごとのtestと顧客操作を再現できるか	各提供者と制作側の責任、契約、更新順を分けたか
採用特化kit	製品updateを受けながら案件差分を維持できるか	製品manualと案件固有manual、受入記録を分けられるか	販売者、購入者、制作会社、顧客のsupport範囲を分けたか
full scratch	source、review、release、緊急変更の経路を定義したか	案件固有testと引き渡し資料を自分たちで維持できるか	保守担当、期間、backup、復旧、終了時移行を契約へ落としたか

一つでも不適合があれば直ちに全体を棄却するのではなく、overrideで吸収する範囲と費用を確認します。未確認を「たぶん動く」に置き換えず、demo、document、隔離環境、提供者への確認、案件の受入試験で解消します。解消できない項目が公開・応募・data・復旧・契約の停止条件に触れる場合は、別方式へ戻します。

方式を決める順序

次の順序で、一つの方式または責任を分けた併用案へ絞ります。

1. WordPressを使う前提、既存site、応募system、運用ownerを確認する
2. 繰り返す要件と企業固有の要件を5層へ分ける
3. 現在の土台で共通要件を満たせるか確認する
4. 5方式を6軸で適合、条件付き、不適合、未確認にする
5. overrideで吸収する範囲と、別方式へ戻す停止条件を決める
6. 1案件pilotの観測期間、測定方法、合否ではなく次の判断を先に決める

方式選択だけで案件の法務、security、privacy、accessibility、契約が確定するわけではありません。一般比較を超える要件がある場合は、案件の責任者と必要な専門家、使用する製品・基盤の提供者へ確認します。

1案件pilotで測る

「標準化したから速い」と先に結論を置かず、候補方式を1案件で使い、実績を記録します。比較できる過去案件がある場合は同じ工程区分でBeforeを用意し、ない場合は改善率を出さず、今回の実測だけを次案件のbaselineにします。

測るもの	記録方法	次案件で判断すること
制作時間	要件確認、設計、実装、content投入、test、handoffに分け、手戻りを含む実作業を記録する	共通化できた工程、案件差分へ戻す工程
差し戻し	件数だけでなく、要件不足、土台の固定、content不足、操作ミス等の理由を記録する	starterやmanualを直すか、案件固有として残すか
未確認・停止	判断できなかった軸、確認先、停止した工程、解消日を記録する	次回の事前確認へ加えるか、その方式を候補から外すか
受入不具合	PC／SP、実account、求人状態、応募先、主要導線、復旧等の観点で記録する	共通testへ追加するか、案件testへ残すか
引き渡し後の問い合わせ	事前に決めた観測期間で、質問、誤操作、依頼先不明、契約外対応を分ける	manual、権限、責任表、support境界を直すか
更新・復旧	update前後の確認、backup、rollback、障害連絡を実施または机上確認した証拠を残す	継続利用できるか、保守条件を変えるか

測定項目と観測期間は案件開始前に決めます。受動的な待ち時間と実作業時間、追加scopeと土台の手戻りを混ぜないようにします。顧客や応募者の個人data、秘密、account情報をpilot記録へコピーせず、必要な件数・分類・確認結果だけを残します。

pilotでは、顧客が実際に行う操作と権限をWordPress採用サイトの権限設計で確認し、更新・障害・担当変更の責任を採用サイトは誰が更新する？の責任表へ接続します。

次案件で残す・直す・捨てるを決める

pilot終了後は、成果が出たかを一語で判定せず、次の一枚を更新します。

記録欄	書くこと
採用した土台	方式または併用案、選んだ理由、対象version
標準化するもの	再利用する要件、data構造、pattern、test、manual
案件ごとに決めるもの	target、content、brand、応募先、owner、契約、環境
未確認	確認できなかった軸、影響、次の確認先、期限
停止・戻り条件	どの条件でoverrideを止め、別方式またはfull scratchへ戻すか
残す	次案件でもそのまま使うものと根拠
直す	次回までに直すもの、owner、確認方法
捨てる	固定しすぎたもの、使わなかったもの、廃止・移行方法

ここまで記録できれば、WordPress採用サイト制作の土台をどう標準化するかという一般判断は完了です。2GUを使わなくても、過去案件、自作starter、汎用Theme＋Plugin、別の採用特化製品、full scratchへ同じ判断を使えます。

2GUを候補に残す場合の確認点

2GUは、Web制作者向けのWordPress採用サイト制作キットです。2GUテーマがpresentation、2GU Pluginが募集・社員・インタビュー等のdataとlogic、採用キットがページ構成と部品を担います。制作者が案件ごとの写真、文章、色、ページ構成、応募先を整え、採用担当者へ主要contentの更新を引き渡すための制作基盤です。

2GUで候補にできる共通範囲と、案件ごとに残る範囲は次のように分かれます。

共通化の候補	案件ごとに残ること
Themeの基本template、design token、基本pattern	写真、文章、logo、brand、art direction、案件固有CSS
募集・社員・interview、JobPosting、setup、編集保護	実際の項目と内容、公開判断、応募先、外部service、社内責任
採用向けpage構成と部品、公開manual	採用target、使うpage、情報量、受入、保守・引き渡し契約
契約中の公式download、2GU Pluginの公式update、購入者support	WordPress、server、domain、SSL、mail、backup等の管理主体

2GUは完成済みsite、制作代行、運用代行、独自formの送信・mail配送、応募者・選考管理、求人媒体への掲載保証を含みません。案件固有のdesign制作、独自CSS、独自開発、採用成果、応募数、検索順位、Google for Jobs掲載も保証しません。

WordPressを使わない案件、非制作者が完成siteを求める案件、ATSや運用代行が主目的の案件、一般比較を超える固有要件がある案件では、2GUを前提にしません。デモで実表示を確認し、対応環境と公開前に確認することで外部応募先、購入者側の責任、対象外を6軸へ当ててください。

2GUで共通化できる範囲と、案件ごとに残る範囲を確認する