サイト更新担当者が変わっても困らないために、引き継ぎ前に確認しておきたいこと

サイト更新担当者が変わっても困らないために、引き継ぎ前に確認しておきたいこと

Webサイトの引き継ぎは「ログイン情報」だけでは足りない

Webサイトの更新担当者が変わるとき、管理画面のURL、ID、パスワードだけ引き継げばよいと思われがちです。 しかし実際には、それだけでは不十分です。

ログインできても、

  • どこを更新すればよいか分からない
  • どこまで触ってよいか分からない
  • 画像やPDFの掲載ルールが分からない
  • 公開前に何を確認すればよいか分からない
  • エラーが出たとき誰に相談すればよいか分からない

という状態になりやすいからです。

特に企業サイトや団体サイトでは、担当者が変わってもお知らせ・採用情報・イベント情報・実績紹介などの更新は続きます。 そのため、担当者交代のタイミングでは、作業手順だけでなく、運用全体を整理しておくことが大切です。


まず確認したい基本情報

引き継ぎ時に最初に確認したいのは、サイトの基本情報です。 最低限、以下は整理しておきたいです。

  • サイトURL
  • 管理画面URL
  • CMS、サイト制作サービスの種類 例:WordPress、独自CMS、Studioなど
  • 管理画面のログイン情報
  • サーバー情報
  • ドメイン管理会社
  • SSL証明書の管理方法
  • メールフォームの送信先
  • 外部制作会社・保守会社の連絡先
  • 緊急時の問い合わせ先

ここで重要なのは、Webサイトは管理画面だけで成り立っているわけではないという点です。

サイト本体、サーバー、ドメイン、メール、アクセス解析、広告タグ、フォーム、外部サービスなどが関係している場合があります。

担当者が変わる場合は、 「普段の更新に必要な情報」と「トラブル時に必要な情報」を分けて整理しておくと分かりやすくなります。

例えば、次のように分けて整理しておくと確認しやすくなります。

  • 日常の更新に必要な情報:管理画面URL、ログイン情報、更新手順
  • トラブル時に必要な情報:サーバー、ドメイン、制作会社、保守会社の連絡先
  • 管理者が把握しておく情報:契約者、請求先、外部サービスの管理者

普段どこを更新しているかを確認する

次に確認したいのは、日常的な更新範囲です。 例えば、以下のような項目です。

  • お知らせ
  • ブログ・コラム
  • 採用情報
  • イベント情報
  • 実績紹介
  • 商品・サービス情報
  • 営業日・休業日
  • バナー画像
  • トップページの一部
  • PDF資料
  • 料金表
  • よくある質問

ここで大事なのは、 「更新できる場所」ではなく「実際に更新している場所」を確認することです。

CMS上では多くのページを編集できても、実際には触ってよい場所と、制作会社に依頼した方がよい場所が分かれていることがあります。

例えば「お知らせは自社で追加するが、トップページのメイン画像やフォーム項目の変更は制作会社に依頼する」など、判断に迷いやすい作業を分けておくと安心です。

引き継ぎ時には、次のように整理しておくと実務で困りにくくなります。

項目 担当者が更新する 制作会社に依頼する
お知らせ追加
ブログ投稿
トップページのメイン画像変更
会社概要の大幅変更
フォーム項目の変更
メニュー構成の変更

このように、 自分たちで更新する範囲と、外部に依頼する範囲を分けておく ことが大切です。


更新手順は「画面単位」で確認する

引き継ぎでは、口頭説明だけだと抜けが出やすいです。 特にCMSの更新作業は、画面を見ないと分かりにくいことが多いです。

例えば、お知らせを追加する場合でも、 「タイトル」「本文」「カテゴリ」「アイキャッチ画像」「公開日」のどれを入力する必要があるか、 入力した内容がサイトのどこに表示されるかを確認しておくと、次の担当者が迷いにくくなります。

最低限、次の作業は実際の画面を見ながら確認しておくと安心です。

  • お知らせを新規追加する
  • 既存ページを修正する
  • 画像を差し替える
  • PDFをアップロードしてリンクする
  • 下書き保存する
  • 公開予約する
  • 公開済み記事を非公開にする
  • 公開後にサイト上で表示確認する

このとき、単に操作方法を聞くだけでなく、

  • どの入力欄がどこに表示されるか
  • 空欄にしてよい項目はどれか
  • タイトルの文字数に目安や制限はあるか
  • 画像は必須か
  • カテゴリやタグはどう選ぶか
  • 公開日時は変更してよいか
  • 過去のお知らせを修正してよいか

まで確認しておくと、担当者が変わっても迷いにくくなります。


画像・PDF・文章量のルールを整理する

サイト更新でトラブルになりやすいのが、画像やPDFの扱いです。

例えば、

  • 画像を入れ替えたら表示が崩れた
  • 写真の一部が切れてしまった
  • PDFのリンク先を間違えた
  • 以前のPDFを上書きしてしまった
  • ファイル名が分かりにくくなった
  • 一覧ページの文章量が長すぎて見づらくなった

といったことがあります。

引き継ぎ時には、以下のようなルールを確認しておくと良いです。

画像について

  • 推奨サイズはあるか
  • 横長・縦長の指定はあるか
  • 画像内に文字を入れてよいか
  • スマホ表示で見切れないか
  • 古い画像を削除してよいか
  • 代替テキスト(alt)は入力するか
  • 画像を用意する方法(撮影、素材、AI生成等)

PDFについて

  • ファイル名の付け方
  • 差し替え時に上書きするのか、新規アップロードするのか
  • 古いPDFを残すのか
  • リンク切れ確認の方法
  • PDFの内容確認責任者

文章について

  • タイトルの長さ(文字数)
  • 一覧に表示される説明文の長さ(文字数)
  • 日付や曜日の書き方
  • 敬体・常体の統一
  • 表記ゆれのルール
  • 公開前に誰が確認するか

実際には、ここまで細かくなくても、例えば以下のような簡単な目安があるだけでも更新しやすくなります。

  • お知らせのアイキャッチ画像
     横長の画像を使用。
     素材サイトを使う場合は、利用可能なサービスや画像サイズの目安も確認しておく。
     顔の映っている写真を使わない、または使用前に確認を取る。
  • 事例紹介の写真
     正方形または正方形に近い比率。横幅○px前後など、サイトで推奨されているサイズに合わせる。
     現物の撮影写真のみ可。素材・生成AI画像はNG。
  • PDFは年度や日付が分かるファイル名にする。
  • お知らせのタイトルは○文字程度を目安に、内容が予想できるものにする。
  • 一覧文は○文字までで、内容の要約か、誰向けの内容か分かるようにする。

重要なのは、更新時の迷いを減らすこと禁止事項の引継ぎ漏れを起こさないことです。


公開前・公開後のチェック項目を決めておく

Webサイトの更新作業は、管理画面で入力して終わりではありません。 公開前後の確認も含めて、更新作業です。

最低限、次のチェック項目は用意しておくと安心です。

公開前チェック

  • 誤字脱字がないか
  • 日付・曜日・金額・電話番号が正しいか
  • 固有名詞に誤りがないか
  • リンク先が正しいか
  • PDFや画像が正しく開くか
  • 公開してよい情報か
  • 個人情報や社外秘情報が含まれていないか
  • カテゴリや表示場所が正しいか

公開後チェック

  • PCで表示が崩れていないか
  • スマホで読みづらくないか
  • トップページや一覧に反映されているか
  • リンクが正常に動くか
  • 問い合わせ導線に問題がないか
  • SNSなどに共有する場合、表示内容に問題がないか

特に、スマホ確認は重要です。 管理画面では問題なく見えていても、実際のスマホ表示では画像が切れたり、文字が読みにくくなったりすることがあります。


アカウントと権限を見直す

担当者が変わるタイミングでは、アカウント管理も必ず確認した方が良いです。

確認したい項目は以下です。

  • 前任者のアカウントをどうするか
  • 退職者のアカウントが残っていないか
  • 共有アカウントを使っていないか
  • 新担当者に必要な権限だけ付与されているか
  • 管理者権限を必要以上に渡していないか
  • パスワードを使い回していないか
  • 2段階認証の設定が必要か
  • 外部制作会社のアカウントが適切に管理されているか

特にWordPressなどのCMSでは、すべての担当者に「管理者」権限が必要とは限りません。

お知らせ更新だけであれば、編集者や投稿者など、より限定された権限で足りる場合があります。

担当者交代時は、 「誰がログインできるか」「何を変更できるか」 を確認する良い機会です。


外部サービスの管理者も確認する

Webサイト運用では、CMS以外の外部サービスを使っていることがあります。

例えば、

  • Google Analytics
  • Google Search Console
  • Google Tag Manager
  • Google広告
  • Googleビジネスプロフィール
  • reCAPTCHA
  • メール配信サービス
  • 予約システム
  • 決済サービス
  • フォーム管理ツール
  • 地図サービス
  • SNSアカウント

これらは、普段の更新担当者が直接触らないこともあります。 しかし、担当者が変わるときに管理者が分からなくなると、後から困ることがあります。

特に確認しておきたいのは、

  • 誰のアカウントで管理しているか
  • 会社管理のアカウントか、個人アカウントか
  • 管理者権限を持っている人は誰か
  • 退職者の個人アカウントに依存していないか
  • 請求や通知メールの宛先はどこか

です。

特に、個人のGoogleアカウントでGoogle AnalyticsやSearch Consoleを管理している場合、担当者の退職後に確認や変更が難しくなることがあります。 可能であれば、会社として管理できるアカウントや複数人での権限管理にしておくと安心です。

Webサイト本体だけでなく、サイトに関係する外部サービスも引き継ぎ対象として整理しておく必要があります。


困ったときの連絡先を明確にする

引き継ぎで意外と抜けやすいのが、トラブル時の連絡先です。

例えば、

  • サイトが表示されない
  • 管理画面にログインできない
  • フォームが送信できない
  • メールが届かない
  • 画像を入れたら表示が崩れた
  • 更新した内容が反映されない
  • セキュリティ警告が出た
  • プラグイン更新の通知が来た

こうしたとき、誰に相談すればよいか分からないと対応が遅れます。

そのため、

  • 社内の管理責任者
  • 外部制作会社
  • サーバー会社
  • ドメイン管理会社
  • 保守契約の有無
  • 緊急時の連絡方法
  • 対応可能な範囲

をまとめておくと安心です。

「何でも制作会社に聞く」のではなく、 内容によって相談先が違う ことも整理しておくと良いです。


引き継ぎ資料は完璧でなくてもよい

最後に、マニュアルについてです。

Webサイトの引き継ぎ資料というと、完璧なマニュアルを作らなければならないと思われがちです。

しかし、実務では完璧なマニュアルよりも、 最低限、次の担当者が迷わず始められる資料 の方が役に立ちます。

最低限まとめておきたいのは、以下です。

  • ログイン情報の保管場所
  • よく更新するページ
  • 更新手順
  • 画像・PDFのルール
  • 公開前チェック項目
  • アカウント・権限の一覧
  • 外部サービスの管理者
  • 困ったときの連絡先
  • 触ってよい場所・触らない方がよい場所

特に重要なのは、 「触ってはいけない場所」や「分からないときは確認すべき作業」も書いておくこと です。

新しい担当者は、何をすればよいかだけでなく、何をしてはいけないかも分からないことがあります。


まとめ

Webサイトの更新担当者が変わるときは、ログイン情報だけでなく、更新範囲・作業手順・確認方法・権限・外部サービス・連絡先まで整理しておくことが大切です。

特に、企業サイトや団体サイトでは、担当者が変わってもお知らせや採用情報、イベント情報などの更新は続きます。

前任者だけが分かる状態のままにしておくと、更新が止まったり、誤った情報を公開してしまったり、トラブル時の対応が遅れたりする可能性があります。

担当者交代のタイミングは、サイト運用を見直す良い機会です。 日常的に更新する内容、触ってよい範囲、公開前の確認項目、困ったときの相談先を整理しておくことで、次の担当者も安心して運用を引き継ぐことができます。

最後に、引き継ぎチェックリストを用意したので、お役立てください。

引き継ぎ前に確認したいチェックリスト

  • 管理画面URLを確認した
  • ログイン情報の管理方法を確認した
  • CMS、Web制作サービスの種類を確認した
  • よく更新するページを確認した
  • 自社で更新する範囲を確認した
  • 制作会社に依頼する範囲を確認した
  • 画像サイズや比率のルールを確認した
  • PDF掲載・差し替えのルールを確認した
  • 公開前チェック項目を確認した
  • 公開後の表示確認方法を確認した
  • 前任者・退職者のアカウントを確認した
  • 新担当者の権限を確認した
  • 外部サービスの管理者を確認した
  • サーバー・ドメインの管理情報を確認した
  • 困ったときの連絡先を確認した
  • 触ってよい場所・触らない場所を確認した
  • 契約者・請求先・通知先を確認した

このブログの人気の投稿

WordPressプラグインのサプライチェーン攻撃から考える、日々のセキュリティ運用

デザインは売上に影響するのか?

小規模サイトの表示速度改善メモ:第1回 WordPressを毎回動かさないためのキャッシュの考え方