ホームページの修正依頼は「ここを直す」だけでなく公開pageと正本と確認方法を渡す

ホームページの修正を頼むときは、「ここを直す」だけを送らず、公開しているpageのURL、正しい原稿や画像、変更する理由、公開後に確認する人を渡します。修正箇所が小さくても、別のpage、古い原稿、共通headerへ影響すると、意図しない表示が残ります。作業を依頼することと、何を正しい内容として公開するかを決めることは別です。

WordPress 4.9には、Customizerのdesign draft、予約公開、preview link、design lockingが加わりました。WordPress.orgは、変更を公開前に共有してfeedbackを集められると案内しています。previewは便利ですが、見る人と判断する内容を決めなければ、linkを送っただけで確認が終わったことになります。 WordPress 4.9

修正箇所と公開pageを一対にする

「トップの文章を直す」「電話番号を替える」という依頼だけでは、作業する人はどのpageを見ればよいか決められません。top pageに同じ電話番号があり、footer、contact page、会社案内、PDFにも同じ番号があるかもしれません。見た目の場所と、公開するURLと、情報の正本を一対にします。

たとえば、営業時間を変更する場合を考えます。依頼には、変更前のURL、表示されている場所、変更後の文、適用開始日、通常営業時間へ戻す日、確認する人を書きます。営業時間の正本が店舗側の表なのか、管理画面の設定なのか、原稿fileなのかも決めます。文章を直す人が正しい時間を推測する必要がなくなります。

この形にすると、制作担当者は実装の範囲を決めやすくなります。依頼する側も、変更が一つのpageだけで足りるかを見直せます。修正の文章をきれいに書くことより、どのURLで誰が読む情報なのかを明らかにする方が先です。

正本がない状態で文章を直さない

siteの文章には、複数の原稿が残りがちです。以前のWord file、メールで送った文、管理画面の下書き、公開pageの文章が食い違うことがあります。そのなかから制作会社が選んだ原稿を正本にすると、公開後に「その条件ではない」となります。修正依頼の前に、今回の内容を誰が承認するか決めます。

料金、対応地域、納期、在庫、受付方法のように事業条件へ関わる内容は、表現だけを制作側へ任せません。事業者側が条件を確かめ、公開してよい文を渡します。制作側は、その文をpageへ置き、画面で読めるようにします。文章の校正と、条件の正しさの確認は同じ仕事ではありません。

仮に、service pageへ「最短三日」と追加したい場合、何から三日なのか、対象外の地域や作業があるのか、いつまで適用するのかを決めます。これが決まらない状態で短い見出しだけを替えると、読者は約束として受け取ります。本文、問い合わせform、電話で答える内容もそろえられません。書く前に条件を確定し、書いた後に公開画面で読めるかを確認します。

previewで見ることを先に決める

WordPressのpreview linkは、公開前の見た目を共有するために使えます。ただし、「確認してください」と送るだけでは、確認する人が画像を見るのか、文章を見るのか、formを送るのかが分かりません。previewを送るときは、見るURLと確認項目を短く指定します。

文章を替えたなら、主題、料金や条件、link先、電話番号を見ます。画像を替えたなら、表示位置、画像の内容、mobile画面で欠けないかを見ます。formを替えたなら、入力、送信先、送信後の案内、受信する人を確認します。themeの共通部分を替えたなら、top pageだけでなく、記事、固定page、contact pageも見ます。変更内容によって確認するpageを変えます。

previewで問題がなければ、そのまま公開してよいとは限りません。予約公開の日時、公開後に見るURL、古い案内を外す場所も確認します。公開前のpreviewは、変更案を確かめる場所です。公開後のbrowser確認は、実際のsiteで同じ内容が読めるかを確かめる場所です。二つを分けます。

修正履歴は次の人が判断するために残す

修正が終わった後に残すのは、完成した画面の画像だけではありません。何を、なぜ、どのURLで、誰の確認で変えたかを一行で残します。WordPressのPost Revisionsがあっても、なぜ文章を替えたか、どの条件が正本だったかまでは分かりません。管理画面の履歴と、事業上の判断の記録を分けて持ちます。

外部へ保守を頼む場合は、依頼メール、承認済み原稿、preview link、公開後の確認結果をまとめます。domain、server、CMSのaccountだけでなく、公開する情報を判断した記録もsite側に残ります。担当者が変わったとき、修正を元へ戻すのか、さらに更新するのかを判断できます。

最初の一手は、次に直すpageのURLを一つ開き、依頼文の先頭に「このURLの何を、何のために変えるか」を書くことです。続けて、正本の原稿と確認する人を付けます。修正依頼は作業を早く始めるための文章ではありません。公開後に読者へ正しい情報を残すための設計図です。

修正が複数あるときも、依頼を一通にまとめるだけで終わらせません。URLごとに変更内容と確認者を分けます。共通部分の変更なら、影響するpageの種類を先に並べます。個別pageの変更なら、同じ文章が別のpageへ残っていないかを確認します。この区別があれば、急ぎの文言修正と、templateまで直す改修を混同せずに進められます。