制作・引き渡し
顧客が更新しやすいWordPress管理画面
顧客がWordPressの入力欄で迷わず更新するために、何を整えるか。採用サイトの勤務地変更を例に、入力順、項目名、記入例、必須条件、エラー表示、公開後の確認先をつなぎ、担当者が一件の更新を終えられる管理画面を考えます。

求人の勤務地を変えたいのに、「勤務地」の欄へ支店名を書くのか、住所を書くのか分からない。保存はできても、どのページが変わったのか確信が持てない。入力欄があるだけでは、担当者が更新を終えられるとは限りません。
顧客へWordPressを引き渡すときは、実際の更新依頼を一つ選びます。その作業に沿って、入力する順番、欄の説明、誤りの直し方、公開後に見る場所をつなげておきます。
更新の依頼を、そのまま試せる作業にする
営業職の勤務地を、大阪本社から名古屋支店へ変更する場面を考えます。募集条件は社内で確認済みで、担当者がサイトへ反映する、という例です。
まず、どの求人を開き、何を書き換え、どこを見れば完了なのかを決めます。この例では、対象求人の勤務地名と住所を変更し、求人詳細と求人一覧の勤務地表示を確認します。
「採用情報を更新できるようにする」という要望も、この粒度にすると画面を検討できます。担当者が求人を探すなら、一覧に職種と勤務地を並べる。似た求人が複数あるなら、雇用形態など、見分けるための情報も加えます。
最初から管理画面全体を作り替える必要はありません。一件の更新を追い、どこで探し直すか、何を聞き返したくなるかを見つけます。
関連する入力欄を、作業順にまとめる
勤務地名、住所、交通案内が別々の場所にあると、担当者は画面を往復します。ひと続きで更新する内容は「勤務地」というまとまりに置き、拠点名、住所、補足の順に入力できる案を考えます。
この順序は、データを登録した順ではなく、担当者が確認済みの資料を見ながら入力する順です。画面上では縦に並んでいても、キーボードで移動すると順序が飛ぶ、といった食い違いも確かめます。
同じ住所を本文と別の入力欄の両方へ書く必要があるなら、表示の整理だけでは解決しません。採用サイトのデータ設計へ戻り、どこを更新すれば各ページへ反映されるかを決めます。
拠点があらかじめ決まっている案件では、拠点を選ぶ方式も候補です。自由入力が必要か、候補から選べるかで部品を変えます。WordPressの入力部品TextControlの公式資料でも、固定選択肢がある場合は選択用の部品を案内しています。
項目名と記入例で、入力する内容を伝える
「所在地」だけでは、会社の本社住所か、働く場所かが曖昧です。「勤務地の住所」と書けば、入力対象を絞れます。項目名には何を書くか、説明にはどこまで書くかを載せます。
今回の例で、拠点名と住所を入力する方式を選んだ場合は、次のように整理できます。
| 入力順・項目名 | 欄のそばに置く案内 | 記入例 | 公開後の確認先 |
|---|---|---|---|
| 1. 勤務地名 | 公開時に必須。勤務する拠点の名称を入力 | 名古屋支店 | 求人詳細と一覧の勤務地名 |
| 2. 勤務地の住所 | 公開時に必須。都道府県・市区町村・番地・必要な建物名を入力 | 愛知県名古屋市中区サンプル町1-2-3 サンプルビル5階 | 求人詳細の住所 |
| 3. 勤務地の補足 | 任意。交通案内など、応募者に伝える補足を入力。不要なら空欄 | 最寄り駅から徒歩5分 | 求人詳細の勤務地欄。空欄なら補足を表示しない |
表の住所は架空の記入例です。実際の画面では、社内で確認済みの住所表記を例に使います。番地や建物名をどこまで書くかが、説明と例で食い違わないようにします。
デジタル庁の入力欄の設計指針でも、入力条件と例を具体的に示すことを勧めています。説明は長く増やすより、担当者が迷う点へ絞ります。
記入例を、入力すると消える薄い文字だけで示すのは避けます。書き始めた後にも見比べられるよう、欄のそばに残してください。プレースホルダーに関する注意も、この確認のしにくさを説明しています。
独自の入力画面を作る場合、先ほどのTextControlには項目名のlabelと補助説明のhelpがあります。既存プラグインを使う場合も、同じ役割の案内を設定できるか確認します。
エラーを見て、本人が修正できるようにする
この例では、勤務地名と住所がそろわない状態を公開しない方針にします。任意の補足まで埋めさせる必要はありません。必須の範囲を決めてから、どの操作で入力を検査するかを決めます。
住所を空欄にして保存を試したとき、「入力に誤りがあります」だけでは直す場所が分かりません。「勤務地の住所を入力してください」と、項目名と必要な修正を示します。赤枠だけに頼らず文章を添え、入力済みの勤務地名や補足は消さずに残します。
エラーをページ上部にまとめる場合も、該当する入力欄へ移動できるようにします。訂正して保存できた後は、古いエラーが残らず、保存の完了が分かることまで確認します。
画面に「必須」と書くことと、保存時に不備を拒否することは別です。独自実装では、サーバー側でも必要な項目と値を検査します。WordPressのREST APIで入力を検証する方法には、そのための仕組みがあります。値を整える処理だけで、住所の未入力や条件不足まで検出できるとは考えません。
下書きの保存にも同じ条件を掛けるかは別に決めます。公開済みの求人について、未完成の変更を一時保存したいなら、そのための仕組みがあるかも確かめます。
また、住所として形式が整っていても、別の支店の住所を入力した誤りは残ります。そこは確認済みの募集条件と照合します。
保存後に見るページまで案内する
入力欄の説明には、何を入力するかに加えて、どこに表示されるかも添えます。表の「公開後の確認先」を、担当者が開けるページへの案内にします。
WordPressには、編集画面の幅を変える表示や、別タブでのプレビュー機能があります。独自に追加した勤務地の項目が、未保存の変更も含めて表示されるかは、採用した構成で確かめます。求人詳細のプレビューを開けても、一覧まで変更後の値で確認できるとは限りません。
公開後は、ログインしていない閲覧者と同じ状態で、求人詳細と一覧を開きます。勤務地名が名古屋支店へ変わったか、住所と補足が意図どおりかを確認します。補足を空欄にしたなら、古い交通案内が残っていないことも見ます。
一覧に大阪本社の表示が残っていれば、保存完了の表示だけで作業を終えません。別の保存元や表示の更新処理がないか、制作者が調べる必要があります。担当者には、表示が一致しないときの連絡先も渡しておきます。
担当者に、一件の更新を通して試してもらう
引き渡し前に、本番と同じ構成の検証環境で、顧客が使う権限のアカウントを用意します。勤務地変更の依頼と確認済みの資料を渡し、求人を探すところから表示確認まで操作してもらいます。
制作者が横から入力欄を指し続けると、画面だけでは分からない箇所を見落とします。まず担当者に進めてもらい、迷った項目名、開き直した説明、確認できなかったページを記録します。
途中で住所を空欄にする場面も試します。エラーを読んで修正できるか、すでに入力した内容が残るかを確かめます。補足は空欄でも更新でき、公開表示に不要な文章が残らないかも確認します。
操作ができない原因が権限なら顧客へ渡す権限を見直します。レイアウトを動かせる範囲や戻し方は誤操作を防ぐ設計の範囲です。内容確認や公開の担当が決まっていない場合は、先に更新の役割分担を決めます。
画面の説明で止まった箇所は、マニュアルへ追記する前に、項目名や案内を直せないか考えます。目指すのは、担当者が「何を入力し、何を直し、どこまで確認すれば完了か」を画面から判断できる状態です。
2GUを候補にする場合は、今回の更新作業と商品構成を照合してください。商品で対応する範囲と、個別に整える範囲を分けておきます。