「これ、いつ誰が変えたんだっけ？」
表示崩れが起きてからこの質問が出ると、そこから探す作業が始まります。だいたい、いちばん忙しい時に。
立派な更新管理表は要りません。私は、担当者不在のサイトほど「日時・場所・変更・理由・担当・戻し方」の6項目だけを1変更1行で残す形から始めるのが現実的だと思っています。記録が効くのは、変更した日ではなく、何か起きて「直前に何を触ったか」を探す日です。まずは、あとからたどって元へ戻せること。そこに絞ります。
この記事でわかること
この記事では、スプレッドシート1枚で始められる更新履歴と、記録を続けるための最小ルールを整理します。
- 更新履歴に残す6項目
- 「変更」と「戻し方」を曖昧にしない書き方
- 1変更1行で記録する理由
- パスワードや個人情報を残さない運用
- 社内で続けられる範囲と、外部へ相談する条件
更新履歴は6項目だけで始める
最低限残したいのは、日時・場所・変更・理由・担当・戻し方です。この6つが揃うと、いつ何が変わり、誰に確認すればよく、どこまで戻せるかを1行で追えます。
最初のシートは、次の形で十分です。
| 日時 | 場所 | 変更 | 理由 | 担当 | 戻し方 |
|---|---|---|---|---|---|
| YYYY-MM-DD HH:MM | 対象URLまたは設定画面名 | 変更前 → 変更後 | 変更した目的・依頼内容 | 氏名または役割 | 戻す手順・復元に使う保存先 |
「場所」にはページ名だけでなく、対象URLや管理画面のメニュー名まで入れます。「トップを修正」だけでは、本文、メニュー、共通部品のどこを触ったのか分かりません。
「変更」は作業名ではなく、前と後を書きます。「文章を更新」ではなく、「ボタン文言を『お問い合わせ』から『相談内容を送信する』へ変更」。少し面倒に見えますが、ここを省くと戻せません。半年後の自分は、変更前の文言を覚えていないので。
「戻し方」には、「バックアップから戻す」だけで終わらせず、復元に使うファイルや保存先、WordPressのリビジョンなど、戻るための入口を残します。実際に復元できるか分からない場合は、推測で埋めず「未確認」と書いておくほうが役に立ちます。
1変更1行にすると原因を追いやすい
一つの行へ複数の変更を詰め込むと、不具合が起きたときにどれを戻せばよいか分からなくなります。同じ日に同じ担当者が作業しても、変更箇所ごとに行を分けます。
たとえば、サービスページの文章変更と、全ページ共通の問い合わせボタン変更は別の行です。見た目には一度の更新でも、影響する範囲と戻し方が違います。
記録するタイミングは、変更の直前と直後に分けると続けやすくなります。
- 作業前に「日時・場所・理由・担当」を入れる
- 変更した内容を「変更」へ追記する
- 保存先や復元方法を「戻し方」へ入れる
- 公開後に確認し、問題があれば戻した事実を新しい行へ残す
元へ戻したとき、過去の行を書き換えてしまうと「一度変更した」という履歴が消えます。戻した作業も新しい変更です。元の行は残し、別の行に日時と理由を書き足します。
作業者以外があとから見ても分かることが基準です。担当者の記憶を補うメモではなく、担当者が不在でも次の人が状況をたどれる記録にします。
「変更」と「理由」を分けて書く
変更内容だけ残っていても、なぜ変えたのか分からないと、元へ戻してよいか判断できません。「変更」は事実、「理由」はその時の判断として分けます。
理由は長い議事録にする必要はありません。次のような短い情報で足ります。
- 問い合わせ時の入力ミスを減らすため
- 営業時間の変更を反映するため
- 表示崩れを修正するため
- 計測対象を分けるため
- 社内から更新依頼があったため
誰が依頼したかまで必要なら、理由の中に依頼元の部署や役割を添えます。ただし、個人名や顧客情報をむやみに増やす必要はありません。担当欄も、あとから確認先が分かる範囲で書けば十分です。
「担当」は、実際に操作した人を残します。依頼した人と作業した人が違う場合、担当欄には作業者、理由欄には依頼元を書いておくと混同しにくくなります。
「戻し方」は変更前に考える
公開後に問題が起きてから戻し方を探すのではなく、作業前に戻せるかを確認します。戻す入口がない変更は、更新履歴へ「未確認」と書いた時点でいったん止める判断ができます。
戻し方には、変更の種類に合った入口を残します。
- 固定ページの文章：変更前の文章、リビジョン、下書きの保存先
- 画像：差し替え前の画像ファイルと掲載場所
- テーマやプラグイン：変更前のバージョンとバックアップ
- CSSやJavaScript：変更前のファイルまたは差分
- GA4やGTM：変更した設定名と公開前の状態
ここで大事なのは、更新履歴そのものをバックアップ置き場にしないことです。表には保存先や識別できる名前だけを書き、ファイルは社内で決めた場所に置きます。大きな画像やバックアップを表へ直接貼り続けると、記録を探しにくくなります。
戻せる見込みがなく、サイト全体へ影響する設定を触る場合は、作業を始める前に管理者や制作担当へ確認するほうが安全です。「戻し方を書けない」が、そのまま中断条件になります。
実際に更新後の表示が崩れたときは、最初に戻すもの・触らないものへ進みます。記録しておいた直前の変更から、一つずつ戻す順番を決められます。
パスワードや個人情報は更新履歴に残さない
更新履歴は複数人で見ることがあるため、ログイン情報や秘密情報の保管場所には向きません。作業に使った認証情報をそのまま貼らず、「どの管理情報を使ったか」が分かる参照名だけに留めます。
書かないものを先に決めておくと迷いません。
- WordPress、サーバー、ドメインのパスワード
- APIキー、秘密鍵、アクセストークン
- メールの認証情報
- 顧客や問い合わせ送信者の氏名、メールアドレス、電話番号
- 公開前の機密情報や契約内容
- 個人だけが使う復旧コード
認証情報は、社内で承認された別の保管方法で管理します。更新履歴には「サーバー管理情報を使用」「共有アカウント一覧を参照」といった、秘密を含まない書き方で十分です。
そもそも契約者や管理情報の保管先が分からない場合は、更新履歴へ推測で書かず、保守契約終了前の管理情報チェックリストで確認する項目を分けます。
スクリーンショットをリンクする場合も注意が必要です。管理画面にはメールアドレス、注文情報、アクセス用の値などが映ることがあります。共有前に必要な範囲だけを残し、秘密情報が見えていないか確認します。
記録を続けるために、承認欄や分類を増やしすぎない
更新履歴の目的は、原因と戻し方をあとから追えることです。それ以上でも以下でもありません。最初からステータス、優先度、承認者、作業時間、費用まで列を作ると、記録すること自体が仕事になります。そして、仕事が増えた表は続きません。だいたい3か月で空欄が並びます。
まずは6項目だけで始めて、実際に足りないと感じた情報が出てきたら追加する。この順番がおすすめです。「いつも同じことを書くから」という理由で列を増やすより、理由や戻し方の欄へ短く書くほうが管理しやすいこともあります。
担当者が変わっても続く形にするなら、次のルールだけ共有します。
- 変更した人が記録する
- 1変更を1行にする
- 分からない項目は推測せず「未確認」と書く
- 戻した作業も新しい行にする
- 秘密情報は書かない
記録漏れを見つけたときは、分かる事実だけをあとから追記します。日時や担当を推測で埋めると、肝心なときに記録を信頼できなくなります。
社内で続けられる範囲と、外部へ相談する条件
対象サイトの管理者が分かり、更新前の状態へ戻せるなら、1枚のシートを作り、6項目を1変更1行で残すところまでは社内で進めやすい範囲です。最初からすべての過去作業を埋める必要はなく、運用を始めた日以降の変更から記録します。
外部へ相談したほうが整理しやすいのは、次のような状態です。
- 誰がWordPressやサーバーを管理しているか分からない
- バックアップの有無や復元方法を確認できない
- 制作会社、広告担当、社内担当の変更が一つの表に混ざっている
- 過去の変更が分からず、現状を基準にしてよいか判断できない
- 更新依頼はあるものの、社内で担当を決められない
- 記録だけでなく、実際の更新作業も止まっている
この段階でも、最初から継続支援を決める必要はありません。まずは管理対象と止まっている作業を単発で整理し、社内に残すものと外部へ任せるものを分ける方法があります。
役割を決めるところで止まる場合は、社内に残す管理と外部へ任せる作業の分け方を使うと、承認者と実行者を切り分けやすくなります。
おわりに
更新履歴は、日時・場所・変更・理由・担当・戻し方の6項目があれば始められます。1変更1行にして、変更前と変更後、戻るための入口を具体的に残す。パスワードや個人情報は書かない。この3点が守れれば、立派な管理表でなくても不具合時の手がかりになります。
社内でできるのは、管理者と復元方法が分かる範囲から記録を始めるところです。誰が管理しているか分からない、バックアップを確認できない、更新作業そのものが止まっている。そんな状態なら、現状の整理からお手伝いできます。
