WordPressの更新を制作会社へ頼むとき、「バックアップを取ってからお願いします」と伝えるだけでは、作業後に何を確かめてもらえるかが残ります。ページが開いていても、申込みボタンやスマートフォンのメニューが以前と同じように使えるとは限りません。
依頼時に揃えたいのは、普段使っている機能、その更新前の状態、不具合があった場合の戻し方、更新後に確かめる操作です。管理画面に更新完了と表示された時点と、自社サイトの確認が終わった時点を分けて考えると、担当者との認識が合いやすくなります。
「全体を確認」より、普段の使い方を伝える
例えば、木工教室のサイトでWordPress本体とプラグインを更新する場面を考えます。以下は説明用の架空例です。このサイトでは、教室一覧から開催日を選び、申込みフォームへ進む流れを使っています。
保守担当者へは、トップページのURLだけでなく、その一連の操作を伝えます。「スマートフォンで教室一覧を開き、開催日を選ぶと申込み画面に移る。入力後は完了画面が出る」という説明なら、更新後に試す場所が具体的になります。
申込み以外にも、会員ログイン、商品検索、資料ダウンロードなど、自社で使っている機能があれば対象を相談します。すべてのページを同じ深さで調べるか、共通の作りを代表するページで確かめるかは、サイトの規模と変更内容で変わります。依頼側は大切な操作を示し、担当者にはテーマやプラグインとの関係を踏まえて確認範囲を提案してもらうとよいでしょう。
更新前からある不具合を分けておく
先ほどの申込みを、更新前にも一度たどっておきます。既に特定の日付を選べない状態なら、その症状を記録して担当者へ渡します。更新後に初めて気づくと、今回の変更が原因なのか、以前からの問題なのかを切り分ける作業が増えるためです。
記録は長い報告書でなくても構いません。対象ページ、操作、起きたこと、使った端末が分かるメモと画面があれば、比較の材料になります。独自の改修や外部サービスとの接続がある場合は、事前に試せる検証環境の有無も確認します。検証用サイトではメール送信や決済が実際に動かないよう、担当者による設定が必要です。
バックアップの有無から、復元できる時点まで確かめる
WordPress公式資料では、通常のサイトを完全に復元するには、ファイルとデータベースの両方が必要と説明しています。記事や設定だけ、画像やテーマだけの保存では、サイト全体を同じ状態に戻せない場合があります。
そこで依頼時には、何をいつ保存するかに加え、誰が復元できるか、必要な接続権限が揃っているかを確認します。バックアップが別の会社の管理下にあるなら、その会社への連絡が必要になることもあります。復元の手順や、以前に復元を試した記録があるかも、担当者に確かめたい点です。
特に注意したいのは、保存した時点より後のデータです。更新中にも予約や注文が入るサイトでは、データベース全体を古い状態へ戻すと、新しく入った記録を失うおそれがあります。「不具合なら全部戻す」とだけ決めず、受付を一時的に止める必要があるか、新しいデータをどう保全するかを先に相談します。
作業時間と、途中で止める判断を共有する
更新日時は、訪問が少ない時間帯だけで決めるものではありません。問い合わせの集中する告知直後や、社内で原稿を直す時間を避けられるかも確認します。作業中に担当者が記事を保存したり、別の人が設定を変えたりすると、前後の状態が分かりにくくなります。
更新対象と、作業中に控える操作を共有したうえで、問題が見つかった場合の連絡先と判断者を決めます。予定時間に収まらないとき、確認できない機能が残ったときに、どこまで進めて報告するかも相談しておきましょう。互換性の懸念で一部の更新を保留する場合は、その理由と次に確認する内容を残し、保留したまま忘れない形にします。
完了報告は「更新済み」と「確認済み」を一緒に受け取る
更新後は、最初に決めた流れを実際に試します。木工教室の例なら、一覧と日付選択だけでなく、テスト用の内容で送信し、完了画面と担当者への通知まで確認する範囲を相談します。テストと分かる名前や宛先を決め、実際のお客様への連絡や申込み件数に紛れないようにします。
自社で記事を更新するなら、管理画面に入れることや、普段使う編集画面も確認対象になります。報告では、更新したもの、保留したもの、試した操作、未確認の箇所を受け取ると、その後に自社で確かめることが分かります。
保守契約によって対応範囲は異なります。Bämの保守・管理へ相談する際も、利用中のサイトと「更新後も使えてほしい操作」を伝え、検証や復元対応を含む依頼範囲を確認してください。
