Web担当が変わる時にスムーズに引き継ぐためのチェックポイント

2026年1月3日

Web担当が変わる時にスムーズに引き継ぐためのチェックポイント

この記事でわかること

なぜWeb担当の引き継ぎはトラブルになりがちなのか
引き継ぎ前に必ず準備しておくべき情報と資料
実際の引き継ぎ当日に確認すべきチェックポイント
引き継ぎ後1〜3ヶ月のフォロー体制の作り方

「前任のWeb担当が急に退職」「気づいたらパスワードを知っているのは本人だけ」──そんな状態で引き継ぎの日を迎え、冷や汗をかいた経験はないでしょうか。
Web担当の引き継ぎは、一般的な業務マニュアルだけではカバーしきれません。ドメインやサーバー、WordPressなどのCMS、Googleアナリティクスや広告アカウント、制作会社との契約条件、さらには社内の暗黙ルールまで、さまざまな情報が複雑に絡み合っています。

この記事では、「引き継ぎ Web担当」をテーマに、担当者が変わるタイミングで押さえておきたいポイントを整理しました。なぜトラブルが起こりやすいのか、事前にそろえるべき情報、当日に一緒に確認したい事項、そして引き継ぎ後1〜3ヶ月のフォロー体制まで、順を追ってチェックできる内容になっています。

「とりあえず口頭で説明して終わり」にしないための具体的な視点をまとめていますので、これから引き継ぐ側・引き継がれる側のどちらの立場でも、準備の土台としてお使いください。

Web担当の引き継ぎが難しい理由

属人化しやすいWeb担当業務

Web担当の仕事は、CMS（WordPress等）での日々の更新、外部制作会社や広告代理店とのやり取り、SEOやアクセス解析に基づく判断など、多岐にわたります。特にSEOや改善判断は、担当者の頭の中に蓄積された暗黙知に依存しやすく、口頭だけでは伝わりにくいのが特徴です。

また、WordPressのテーマやプラグインの選定理由、過去のABテスト結果、MQL／SQLの境界設定など、「なぜそうしているのか」という背景が説明されないまま運用されているケースも多く、担当者が変わると判断基準がゼロからの手探りになりがちです。

サーバー設定やセキュリティ対策（WAF設定、バックアップポリシーなど）も、IT部門とWeb担当のあいだで暗黙の分担になっていることが多く、「どこまでがWeb担当の守備範囲か」があいまいな点も、引き継ぎを難しくする要因です。

よくある引き継ぎトラブルのパターン

ログイン情報や保管場所が不明で作業できない
制作会社が「他社は触れません」と対応を拒否する（ロックイン）
過去のトラブル履歴や社内でのNG事項が共有されておらず、同じ失敗を繰り返す

こうしたトラブルは、単に「メモが足りない」だけでなく、ドメイン・サーバー・CMS・広告アカウントなどの名義や権限管理が曖昧なことも原因です。特に、制作会社名義でドメインやサーバーが契約されていると、リプレイス時に移管がスムーズにできず、最悪の場合は法的な交渉が必要になるケースもあります。

また、Webサイト特有のトラブル（SEOのインデックスエラー、プラグイン更新による表示崩れ、脆弱性放置など）は、その場しのぎで解決されがちです。記録が残っていないと、後任者が同じ問題に再度直面してしまいます。

引き継ぎ前に整理しておく全体像と基本情報

自社サイト運用の全体マップを作る

サイトの目的（採用、問い合わせ、EC等）とKPIを明記し、日常から月次までの運用フローをフローチャートにまとめておきます。関係部署や外部パートナーの役割を図示すると、責任範囲が明確になります。

このとき、「誰が」「いつ」「どのツールを使って」動くのかを具体的に書き込むと、後任者は着任初日から全体の動きをイメージしやすくなります。例えば、次のような単位で整理します。

日次：問い合わせフォームの確認 → 営業へのエスカレーション
週次：新着情報・ブログ更新 → 承認フロー → SNS連携投稿
月次：アクセス解析レポート作成 → 上長・営業共有 → 施策検討会

welogや社内Wikiなどのノートツール上でフローチャートと説明文をセットで管理し、修正が発生した際にリアルタイムで更新できるようにしておくと理想的です。

必須のアカウント・権限リスト

ドメイン管理者情報、サーバー（ホスティング）ログイン、CMS管理者アカウント、Google関連（GA4、Search Console、Tag Manager）や各種SaaS（MA、チャットボット、フォーム）について、アカウント名・権限・管理者連絡先を一覧化しておきます。

この一覧には、次の情報も追記しておくと安全です。

パスワードそのものではなく、「どのパスワード管理ツールに保管しているか」
2段階認証の有無と、バックアップコード・代替承認者
契約更新日と支払方法（クレジットカード／請求書）
管理者権限を持つアカウントと、閲覧専用などのロール区分

特に、退職者個人のメールアドレスで作成されているアカウントは、早めに共通アドレス（web@……など）への移管を検討し、「人に紐づく権限」から「組織に紐づく権限」へ整理しておくことが重要です。

管理しているWebサイト・サービスの一覧

コーポレートサイト、LP、オウンドメディア、EC、会員サイト、キャンペーンサイト、サブドメインなどを漏れなくリスト化し、それぞれの目的と担当者を付記します。

あわせて、次の情報も1枚にまとめておきます。

使用しているCMS／フレームワーク（WordPress、独自CMS、ノーコードツールなど）
インフラ環境（自社サーバー、レンタルサーバー、AWS／Azure等クラウド）
運用・保守を委託している外部パートナーの有無
ドメイン更新・SSL証明書更新の担当

こうした情報を整理しておくと、後任者が「どのサイトから優先的に把握すべきか」を判断しやすくなります。短命なキャンペーンLPや休眠中のサービスが埋もれている場合も多いため、このタイミングで棚卸し・整理を行うことをおすすめします。

実務ごとに整理する業務引き継ぎチェックリスト

日々の定常運用（ルーティン業務）

更新頻度（毎日／週次／月次）と、典型的な更新パターン（ニュース、採用情報、ブログなど）を明示し、社内承認フローと締切時間、テンプレートを揃えておきます。

チェックリスト化する際は、次の観点もセットで残しておきます。

「やる／やらない」の判断条件（PVや問い合わせ数などの閾値）
締切遅延時に誰へ相談・エスカレーションするか
不在時の代理対応ルール（営業部門や総務との連携など）

Teachme Bizやwelogなどのツールを使えば、1つのルーティンを1ノート（1マニュアル）として、画像や動画付きで残すことも可能です。

コンテンツ制作・公開フロー

原稿作成から校正、入稿、公開までの手順を番号付きで記述し、素材保管場所（共有フォルダURL）、画像の著作権ルールも明記しておきます。

加えて、次のようなチェックポイントを整理しておくと、品質のばらつきを減らせます。

原稿の依頼テンプレート（依頼元に送るフォーマット）
校閲・法務チェックが必要なケースの基準
公開前チェックリスト（誤字脱字、リンク切れ、OGP設定、計測タグ確認など）
公開後の確認項目（インデックス確認、サーチコンソールでのエラー確認など）

可能であれば、Dojoウェブマニュアルのような画面キャプチャ自動記録ツールでCMS入稿の操作手順を動画・ステップ化しておくと、後任者や兼任メンバーの教育コストを下げられます。

SEO・アクセス解析の引き継ぎ

重点キーワードや狙っている検索クエリ、月次で見ているレポート項目、過去に行った主要施策の履歴（実施日・効果）をまとめておきます。

ここには、次の内容も含めておきます。

成功の基準（自然検索流入数、コンバージョン数、検索順位など）
これまでに試した施策（タイトル改修、内部リンク強化、コンテンツ追加、構造化データ導入など）と結果
触れてはいけないページ・ディレクトリ（過去に編集して不具合が出た箇所）
定期的に確認しているレポートフォーマット（GA4やデータポータルのURL）

これらが整理されていれば、後任者は「いまどこまでできていて、どこから着手すべきか」をすぐに把握できます。

また、検索アルゴリズムやツール仕様は頻繁に変わるため、「毎月このタイミングで指標を見直す」「SEOトラブルが起きた場合の社内・外部相談先」を明記しておくと安心です。

サイトの技術・保守まわり

CMSの構成（テーマ・プラグイン・カスタマイズ箇所）、サーバー構成、バックアップ方法、復旧手順、セキュリティ対策（WAF、2要素認証、プラグイン更新ルール）を明文化しておきます。

特にWordPressの場合は、次のような内容を「技術資産リスト」としてまとめておくことが重要です。

使用中プラグインの一覧と役割、更新してはいけない／注意が必要なプラグイン
functions.phpや独自プラグインなど、カスタマイズしているコードの所在
ステージング環境の有無と、本番反映までのフロー
自動バックアップの実行タイミング・世代管理ルール、リストア手順
過去に発生した脆弱性・マルウェア感染と、その対策履歴

あわせて、OSやミドルウェア（Apache／nginx、MySQLなど）、クラウド基盤（AWS／Azure等）に関する責任分界点（インフラ担当／制作会社／Web担当のどこが見るか）を明確にしておくと、障害時の初動がスムーズになります。

マーケティング／リード連携

フォームからの問い合わせフロー、MQL／SQLの定義とアラート設定、MAツールのシナリオや配信スケジュール、営業への受け渡しルールを整理しておきます。

さらに、次のような「営業との約束事」を明文化しておくと、担当者が交代してもリードの取りこぼしを防げます。

どの条件を満たしたらMQLとみなすか（ページ閲覧数、資料DL、セミナー参加など）
営業側でのフォロー期限（何日以内に架電・メールを行うか）
MA上の主要シナリオ（ナーチャリングメール、スコアリングルール、スコア減衰ルール）
落ちこぼれリードの扱い（再ナーチャリングの有無、期間）

マーケティングから営業までのフローは、図やタイムラインで可視化し、どの段階で誰がKPIを見ているのかも併記しておくと、引き継ぎ後のコミュニケーションがスムーズになります。

関係者・外部パートナー情報の引き継ぎ

社内のキーパーソン・相談先リスト

承認者（決裁者）、コンテンツ提供者、IT部門窓口、法務や広報の担当など、相談先と連絡方法を一覧化しておきます。

その際は、次のような情報まで記載しておくと、後任者が「誰にどう話を持っていけば物事が進むのか」を早くつかめます。

それぞれ何について相談すべきか（コンテンツ表現、個人情報、インフラ、ブランディング等）
普段使っている連絡手段（メール、チャットツール、電話など）
緊急時に連絡してよい時間帯・手段
社内で影響力のある「非公式キーパーソン」（実務をよく知る担当者）

制作会社・広告代理店との関係性

主要パートナーの連絡先、担当者、契約内容（保守範囲・SLA・解約条件）、これまでの良かった点や注意点を残しておくと、交渉やトラブル対応がスムーズになります。

あわせて、次のような情報も共有しておきます。

他社への引き継ぎ実績の有無（ロックイン体質か、オープンな運用か）
これまでに起こったトラブルと、そのときの対応姿勢
レスポンスの早さや、得意な分野（デザイン、SEO、広告運用、インフラ等）
契約更新時期と、見直しを検討しているポイント

もし、現在の制作会社が独自CMSや特殊な構成で「他社は触れません」といったロックイン状態であれば、そのリスクを上長と共有し、将来的な標準CMS（WordPress等）への移行方針も記録として残しておくとよいでしょう。

必ず共有したいトラブル・NG事項

過去に起きたトラブルとその対処

サイト障害、セキュリティインシデント、SEOのインデックス問題、タグ設定ミスなどについて、発生事象と対応手順・教訓を時系列で残しておきます。

特に、次の項目を整理しておくと、後任者は「過去に何があったか」だけでなく「今どこにリスクが残っているか」も把握できます。

発生日時と影響範囲（どのページ・どのサービスか）
初動対応者と、社内・社外の連絡経路
原因（ヒューマンエラー／設定ミス／システム不具合／外部要因など）
再発防止策として導入したルール・ツール
まだ暫定対応のままになっている箇所

トラブル一覧は、PDFやノートツールで1つの「トラブル年表」として管理し、タグ付けやカテゴリ分けをして検索しやすくしておくと有効です。

暗黙の運用ルール・社内NG

掲載してはいけない表現、公開時間帯の制約、社内政治的な配慮ポイントなど、文書化されていないルールも必ず明記しておきます。

例えば、次のような内容です。

法的な理由によるNG（比較表現、薬機法・景表法に関わる表現など）
ブランドポリシーによるNG（ロゴ使用方法、フォント・色の制限、トンマナ）
社内事情によるNG（特定部署・特定顧客への配慮、価格表示方針など）
公開・配信を避ける時間帯（システムメンテナンス時間、コールセンター稼働時間との兼ね合い）

「以前これで揉めた」「経営層からNGが出た」といったエピソードも含めておくと、後任者は地雷を避けやすくなります。暗黙知は放置すると属人化の温床になるため、このパートは可能な限り丁寧に書き起こすことが重要です。

引き継ぎ当日の進め方と確認ポイント

引き継ぎミーティングの進め方

事前に資料（マニュアル、アカウント一覧、フロー図）を共有し、当日は画面を共有しながら一連の実演を行います。後任からは、「できないこと」「不安な点」「最初の30日で優先したいこと」を必ず聞き出すようにします。

ミーティングでは、次の流れで進めると、単なる説明会で終わらず実務レベルの確認ができます。

事前共有した資料をベースに、全体像 → 日常業務 → 例外対応の順で説明する
後任者に実際に操作してもらい、わからないポイントをその場で洗い出す
想定されるトラブル（障害、炎上、セキュリティインシデント）のシミュレーションを行う
引き継ぎ後1〜3ヶ月の連絡方法（チャット／メール／定例MTG）と頻度を決める

ミーティングの録画やメモはwelogや社内Wikiに保存し、後任者が後から見返せるようにしておくと安心です。

当日その場で一緒にチェックしたい項目

主要システムへのログイン確認、テスト更新（下書き → プレビュー → 公開フロー）、緊急時の連絡フロー（担当者・代替手段）を実演で確認します。

あわせて、次の点もチェックしておきます。

CMSの権限レベル（本番公開権限が付与されているか）
GA4／Search Console／広告管理画面へのアクセス権限
バックアップからのリストアテスト（最低限、手順の確認だけでも）
MAツール／チャットボットの設定画面へのアクセス可否

緊急時フローについては、「平日営業時間」「夜間・休日」「担当者不在時」の3パターンを想定し、連絡先と判断権限を整理しておきます。

引き継ぎ後1〜3ヶ月のフォロー体制

移行期間中の役割分担

移行期間はダブルチェック体制を設定し、前任者は段階的に業務を手放していきます。優先度の高い業務から任せ、引き継ぎ完了の基準（ログイン完了、1回の公開実行、問い合わせ対応が可能など）を明確にしておきます。

具体的には、次のような段階的な移行が有効です。

1ヶ月目：主要更新・レポート作成を後任主導で実施し、前任者がレビューする
2ヶ月目：前任者は例外対応・トラブル時のみサポートする
3ヶ月目：定例確認のみとし、実務は後任と外部パートナーで完結させる

この間に発生した質問や改善アイデアは、その都度マニュアルやFAQに反映し、「前任者がいなくても回る状態」をゴールとして設定しておくことが大切です。

ナレッジを蓄積・更新し続ける仕組み

マニュアルやFAQは一本化した保管場所（社内Wikiやノートツール）にまとめ、チャットボットでよくある質問を自動化します。定期的な更新日（例：四半期ごと）を決めて陳腐化を防ぎます。

ツールの例としては、次のような組み合わせが考えられます。

ノートツール（welog等）で、テキスト・画像・動画・PDFを一元管理する
ナレッジ共有ツール（Teachme Biz、Stock等）で手順書を標準化する
チャットボット（さっとFAQ等）で、よくある質問を即時検索可能にする

また、次のような運用ルールを決めておくと、「一度作って終わり」のマニュアルではなく、常にアップデートされるナレッジベースに育てていくことができます。

新しい施策やトラブル対応を行ったら、その都度ノートを1本追加する
半期ごとに「使われていないマニュアル」「古くなった画面キャプチャ」を棚卸しする
部署横断のナレッジ共有会を設け、Web担当だけに閉じない情報共有を行う

最終チェック用の引き継ぎチェックリスト

「引き継ぎ Web担当」最終チェックリスト項目例

基本情報／アカウント情報（ドメイン／サーバー／CMS／GA4等）
業務フロー／運用ルール（更新頻度、承認フロー）
技術情報／保守・セキュリティ（テーマ・プラグイン・バックアップ）
関係者／外部パートナー（連絡先・契約内容）
トラブル履歴／NG事項（対応手順・注意点）

最終チェック時は、上記の各カテゴリごとに「担当者が決まっているか」「資料の所在が明確か」「後任が実際に一度は手を動かしたか」を確認軸にすると、実務レベルで抜け漏れがないかを簡単に洗い出せます。

引き継ぎは一度で完璧に終わらせる必要はなく、チェックリストをベースに、抜けが判明したら追記していく「継続的な改善プロセス」として捉えることが重要です。

テンプレート・資料の案内

無料ダウンロードの「Web担当引き継ぎチェックリスト（テンプレート）」をご用意しています。事例紹介や個別相談も承っていますので、引き継ぎに不安がある場合はお気軽にご相談ください。

テンプレートには、この記事で紹介した観点に加え、実際の「他社からのWebサイト引き継ぎ」や「広告代理店リプレイス」の現場で使われている項目も盛り込んでいます。自社用にカスタマイズしながらお使いいただくことで、属人化を防ぎ、担当者が変わっても安定してWeb運用を続けられる体制づくりに役立てていただけます。

まとめ：誰が担当になっても迷子にならない引き継ぎを

Web担当の引き継ぎは、「誰が何を握っているのか」が曖昧なまま担当者だけが交代してしまうと、あとから思わぬところで詰まりやすい領域です。だからこそ、個人の記憶や善意に頼らず、「全体像」「アカウントと権限」「実務フロー」「技術情報」「関係者」「トラブル・NG情報」をひとつずつ棚卸しし、見える形で残しておくことが重要になります。

この記事で触れたように、