Webサイトの引き継ぎは、担当者が運用、復旧、適切な窓口への連絡を行える状態になって初めて完了します。デザインファイルと動くトップページだけでは、ドメインの更新担当や、問い合わせが届かなくなったときの対応は分かりません。
公開前や制作会社を変更するときに、以下の項目を確認してください。それぞれに責任者、確認した証拠、未完了の作業を記録します。
アカウントの管理主体と権限を確認する
ドメイン管理、サーバー、CMS、ソースコード管理、アクセス解析、外部連携サービスを一覧にします。契約主体、請求管理者、アクセスが必要な担当者を明確にしましょう。管理者パスワードを全員で共有するのではなく、担当者ごとに必要な権限を付与します。
更新日とアカウント復旧用の連絡先も確認します。退任した委託先担当者の個人メールだけが、重要なサービスを更新・復旧できる状態は避けてください。
納品された仕組みを運用できる資料にする
- ソースコード、画像、承認済み原稿の保存先。
- テスト環境と本番環境の違い。
- 一般の資料に秘密情報を書かずに、設定や認証情報を管理する方法。
- 更新契約や利用許諾が必要なプラグイン、サービス、フォントなど。
- 変更の公開、結果確認、以前の状態に戻す手順。
多言語サイトでは、言語別の原稿責任者と、サービス内容を変更した際に他言語へ反映する流れも定めます。転送設定や問い合わせ経路も資料に含めてください。
バックアップから復元できるか確かめる
保存対象、保存先、保管期間、復元できる担当者を決めます。バックアップの成功通知を受け取ったことと、実際に復元できたことは別です。
代表的なバックアップを隔離した環境に復元し、本文、アップロードしたファイル、重要な設定を確認します。訓練中の復元サイトから、本番の問い合わせや外部通知が送信されないようにしてください。所要時間と不足手順を記録し、その一度の結果を復旧時間の保証として扱わないようにします。
日常点検と障害対応の担当を決める
更新、期限通知、問い合わせ経路、稼働状況を誰が確認するか明記します。障害の連絡方法、調査担当、他社へ引き継ぐ条件も整理します。対応時間と目標は実際の契約で確認し、保守契約が自動的に24時間対応を含むとは考えないようにしましょう。
既存機能の不具合と、新しい機能の追加要望も区別します。費用や運用に影響する変更の承認者を決めておくと、連絡の混乱を減らせます。
引き継ぎ担当者によるリハーサルを行う
受け取る担当者が資料を使い、テスト環境で小さな更新を実施します。最新バックアップ、公開手順、障害時の窓口も自分で探してもらいます。このときに出る質問から、ファイルの納品確認だけでは見つからない不足が分かります。
残った項目には担当者と期限を設定します。大きな変更後も資料を更新し、次の担当者が古い手順を引き継がないようにしてください。
サイト公開や保守の引き継ぎを予定している方は、Web開発サービスをご覧いただき、必要な引き継ぎ内容をご相談ください。