Web運用を引き継ぐための文書整備

Web運用が一人の記憶だけに頼っていると、休暇や異動のたびに更新が止まります。手順書を増やす前に、誰が何を判断し、どこへ記録するかを決めます。

引き継ぎ資料は、分厚い説明書である必要はありません。次の担当者が契約、権限、作業、連絡先を迷わず探せる構成にします。

運用対象を一枚にまとめる

サイト、ドメイン、サーバー、管理システム、フォーム、解析など、運用に関わる対象を一覧にします。各項目へ契約先と社内責任者を対応させます。

使っていないように見える契約も、確認前に外しません。サイトやメールとの依存関係を調べ、不明なものは未確認として残します。

権限一覧には、誰がどの管理画面を使えるかを書きます。パスワードそのものは通常の手順書へ貼らず、会社で決めた安全な管理方法へ分けます。

退職者や委託終了した担当の権限を見直す手順も必要です。追加、変更、削除を行った日と承認者を記録します。

共有アカウントしか使えない場合は、利用者と作業日時を別の記録で追えるようにします。提供元が示す権限機能がある場合は公式案内を確認します。

「毎回同じように更新する」では、例外を判断できません。依頼を受ける条件、必要な素材、確認者、公開後に見る場所まで書きます。

手順には画面操作だけでなく、なぜその確認を行うかを添えます。画面の配置が変わっても、目的が分かれば公式資料を参照して進められます。

変更履歴には、対象URL、変更理由、実施者、確認者、日付を残します。ファイル名だけでは内容を追えないため、依頼や承認の記録と結び付けます。

複数の表へ同じ内容を転記すると、どれが正しいか分からなくなります。正本にする記録を決め、他の資料から参照できるようにします。

表示停止、フォーム不達、不審な変更など、運用を止める症状を挙げます。原因を断定する前に記録する情報と、連絡する順番を決めます。

復元作業は担当者と条件を明記します。バックアップの場所だけでなく、どの時点へ戻すかを誰が承認するかを残します。

緊急対応の記録には、発見した症状、止めた作業、連絡先、未確認事項を残します。復旧した後も、原因が確定した部分と推測を分けて更新します。

引き継ぎ日には、保留中の依頼と次の更新予定も共有します。完了した作業だけでは、直近の優先順位を判断できません。

資料を渡すだけで完了にせず、新しい担当者が一つの更新を行います。迷った箇所、見つからなかった資料、権限不足を記録し、文書へ反映します。