公開後の「更新」には、文章の差し替え、フォームの改修、CMSやPHPの更新、障害への緊急対応など、影響の異なる作業が含まれます。同じ更新として扱うと、確認範囲と戻し方が曖昧になります。
私たちが保守の相談を受けるとき、「更新」という言葉だけでは作業を始めません。文章を変えるのか、機能を直すのか、動作環境を上げるのかで、触る範囲も戻し方も変わるからです。コンテンツ、機能、環境、緊急対応に分け、確認方法、バックアップ、切り戻しを作業前に決めます。
同じ「更新」でも、変わる対象は違う
文章の変更は公開内容へ影響し、共通部品や機能の変更は多くのページや保存データへ影響します。PHP、データベース、CMS、追加機能の更新はサイト全体が動く条件を変えます。
依頼の呼び方ではなく、何が変わるかで作業を分類します。一つの依頼に複数種類が含まれる場合も、影響と確認結果を分けて記録します。
保守作業を四つに分ける
- コンテンツ更新：文章、画像、PDF、公開日時の変更
- 機能改修：フォーム、検索、管理画面、外部連携の変更
- 環境更新：CMS、PHP、データベース、追加機能、証明書の更新
- 緊急対応：障害、脆弱性、誤公開、送信不具合への対応
作業区分を先に決めることで、確認する人、検証環境、公開時間、戻す単位を選びやすくなります。
コンテンツ更新は、表示箇所と元データを確認する
同じ会社情報が、トップページ、会社概要、採用ページ、PDF、検索用データなど複数箇所に出ることがあります。どこが元データで、どこへ表示されるかを確認します。
入力、プレビュー、公開状態、公開画面までを通し、文章や画像を変えた場合はPCとスマートフォンを確認します。発注側と制作側のどちらが更新する範囲かも決めます。
機能改修は、利用者の一連の操作で確認する
検索条件の追加なら、管理画面への登録、保存、一覧、詳細、検索結果、既存データの空欄まで影響します。メール送信先の変更なら、入力、確認、送信、保存、自動返信、管理通知を一続きで見ます。
変更した画面だけでなく、利用者が目的を終えるまでの流れと、変更前に保存されたデータを確認します。
環境更新は、検証環境で互換性を確かめる
テーマや独自機能、フォーム、検索、画像処理、予約公開、外部連携が新しい環境で動くかを確かめます。検証環境は、公開環境と主要な条件を揃えます。
バックアップ、更新、主要機能の確認、切り戻しを一組にします。大きなバージョン差は段階を分け、画面だけでなく定期処理や予約処理も確認します。
コンテンツ更新と環境更新を同じ日に重ねない
大きな文章変更と環境更新を同時に行うと、表示不具合の原因を特定しにくくなります。可能なら日程を分け、同日に行う必要がある場合は順序と担当者を決めます。
切り戻すときも、環境だけを戻すのか、同日に登録した内容まで戻るのかを確認します。
緊急対応でも、影響範囲を記録する
脆弱性や障害への対応でも、対象、現在の版、独自機能、公開への影響、停止時間を確認します。必要なら一時停止、アクセス制限、代替案内で被害を抑えます。
変更内容、確認結果、残った作業を記録し、緊急対応後は通常の検証と保守へ戻します。応急処置を恒久対応のままにしません。
定期保守は、毎回すべてを更新することではない
常に最新版へ上げることだけが目的ではありません。掲載内容、バックアップ、容量、証明書、メール送信、各ソフトウェアの更新状況を確認し、必要性と影響から対応を決めます。
不要な追加機能やアカウントは整理します。更新を見送る場合は、理由、残るリスク、次に確認する時期を記録します。
この方法が向いているケース
- 会社情報や採用情報を継続して更新する
- CMSや独自機能を長期間利用する
- 同じサーバーやCMSで複数サイトを運用する
- 公開後もフォーム、検索、外部連携を改修する
- PHPやCMSを定期的に更新する
保守契約を分けた方がよいケース
日常の文章更新と、監視・緊急対応では、必要な速度、担当者、対応時間が異なります。定期点検、軽微な更新、機能改修、緊急対応の条件を分け、他社制作部分やサーバー管理者との連絡範囲も決めます。
公開後保守チェック
- コンテンツ、機能、環境、緊急対応に分類したか
- 元データと表示箇所を確認したか
- 利用者の一連の操作を確認したか
- 公開環境に近い検証環境があるか
- バックアップと切り戻す範囲を決めたか
- 大きな変更を同時に重ねていないか
- 結果、残作業、次回確認を記録したか
- 不要な追加機能やアカウントを整理したか
