Webサイト運用の引き継ぎ資料を作る方法【担当者交代に備える】

引き継ぎ資料はサービス名とパスワードを並べた一覧ではありません。新しい担当者が状況を判断し、日常作業と緊急対応を再現できる運用の地図です。制作会社から権限を受け取る作業とは分け、担当者が交代した後も更新される情報の置き場所を設計します。

資料の目的を「次の判断ができること」に置く

最初に、資料を読む人がどの業務を引き継ぐかを決めます。記事更新や契約更新など必要な判断を並べます。障害連絡も含め、その判断に要る情報を逆算します。画面の操作手順だけでは、例外が起きたときに担当者が止まってしまいます。

各手順には目的と開始条件を記載します。完了条件と困ったときの連絡先も必要です。普段の作業と年に一度の更新では必要な詳しさが異なります。すべてを一枚に詰め込まず、入口となる索引から用途別の資料へたどれる形にします。

対象読者の知識も記載すると、説明を省ける範囲が明確になります。前提知識がない担当者向けには、用語の意味より確認先と相談先を具体的に示します。

ドメイン・DNS・サーバー・CDN・SSL・メール・CMS・解析を資産として記録します。サービス名だけでなく契約者と運用責任者を添えます。請求先と更新日も同じ場所で管理します。Webサイトを移すとメールにも影響するような依存関係は、矢印や文章で明示します。

委託先がいる場合は、会社名よりも作業範囲と権限境界が重要です。どこから先を自社が判断し、何を委託先へ依頼するかを書きます。契約書・設計資料・バックアップの保管先も資産へ結び付けると、障害時に探す時間を減らせます。

WordPress更新なら、実行前のバックアップと検証環境の有無を記します。確認するページと切り戻す条件も一つの流れにします。単に「更新ボタンを押す」と書いても安全な運用は再現できません。記事公開やアカウント追加も、承認者と確認結果まで残します。

障害対応の手順には監視先と一次確認を記載します。社内連絡と保守窓口も同じ流れに置きます。よくあるエラーを断定的な原因一覧にせず、どの段階で誰へ渡すかを示します。過去の事例は手順本文へ継ぎ足さず、時系列記録として別に参照できる形にします。

資料には管理画面のURL、アカウントの用途、保管庫での項目名を記載します。実際のパスワードや秘密鍵を共有文書へ貼り付けません。機密情報はアクセス履歴と権限を管理できる保管庫に置き、個人の端末やメールへ残さない運用にします。

緊急時に保管庫へ入れる人が一人だけでは、資料があっても作業できません。復旧手段と管理責任者を複数用意し、退職時の停止手順も決めます。画面例にトークンや個人情報が写り込む場合があるため、画像の公開範囲も本文と同じ基準で扱います。

同じ手順が共有ドライブとチャットに複製されると、どれが最新か分からなくなります。正本の場所を一つ決め、他の場所からはリンクで参照します。ページごとに所有者、最終確認日、次回確認日を付けると放置された情報を見つけやすくなります。

サーバー移転や担当変更などの作業には、資料更新を完了条件として組み込みます。変更履歴には何を直したかだけでなく、どの判断や依存関係が変わったかを残します。定期棚卸しではログイン可否より、現在の契約と実際の運用が一致するかを確認します。

新担当者には説明を聞くだけでなく、資料を見ながら検証用の更新を実行してもらいます。迷った場所や不足した権限を記録し、その場で資料へ反映します。口頭で補足しなければ完了できない部分は、まだ引き継げていない情報です。

演習では通常作業に加え、更新失敗や連絡先不通など小さな例外も試します。前任者は答えを先回りせず、資料から正しい連絡先と切り戻し条件へ到達できるかを見ます。資料を読める状態ではなく、次の担当者が使える状態を完成とします。

交代後に見つかった不足は、前任者の記憶へ戻さず正本へ反映します。最初の作業で迷った箇所を改善記録に残すと、次回の交代にも同じ学びを渡せます。