WordPressの制作会社を変更するとき、何を引き継ぐ？権限・データ・コードの確認順

制作会社を替える前に、管理先と担当を分ける

最初に、自社と旧制作会社が管理している場所を分けます。ドメインはサイトの住所、サーバーはサイトを動かす場所です。WordPressの管理画面、コードと変更履歴の保管場所、メールなどの連携サービスも、同じ人がすべて管理しているとは限りません。

担当者には「現在の管理者」「新担当が必要とする操作」「引き継ぐ資料」「確認する日」を、それぞれの管理先について聞きます。たとえばドメインでは契約名義と更新担当、サーバーでは契約先と運用担当、WordPressでは更新する人の役割を確認します。管理画面に入れるかだけで、契約や更新費用まで引継ぎ済みとは判断しません。

契約に自社が所有すると書かれていても、実際に資料を受け取れるか、新担当が操作できるかは別に確かめます。提供できるコードや素材、利用条件、旧担当が管理する仕組みを契約と担当者の説明で照合してください。この記事では、個別契約の所有権や譲渡の可否を判断しません。

WordPressに入れても、更新・バックアップまでできる？

WordPressの「役割」は、担当者が実行できる操作を分ける設定です。公式説明では、編集者は投稿の公開や管理を行う役割、管理者は一つのサイトの管理機能を使う役割です。ただし、コードやプラグインで権限が変わるため、役割名だけで自社の操作範囲を決めつけません。

新担当に任せたい仕事を具体的にします。文章や画像の変更だけか、テーマやプラグインの更新、バックアップ、障害時の復旧も任せるのかで、必要な操作が違います。権限のある担当者と、新担当が各作業を行えるか確認してください。WordPressの管理者でも、ドメイン契約やサーバー、コード保管場所まで管理できるとは限りません。

認証情報を渡す方法は、権限のある担当者同士で決めます。共有する作業資料には管理者と受渡し方法を残し、パスワードや鍵の実値を貼り付けません。旧担当のアクセス整理は、新担当による運用確認と切替条件がそろってから、担当者が行います。

出典：WordPressの役割と操作範囲

復元用のバックアップは、ファイルとデータベースをセットで受け取る

一般的なWordPressサイトを元に戻すには、サイトのファイルとデータベースの両方が必要です。ファイルにはテーマ、プラグイン、画像などがあり、データベースには投稿や設定などが保存されています。サイトのフォルダーを受け取っても、別の場所にあるデータベースまで含まれるとは限りません。

旧担当には、ファイルとデータベースが同じ時点の更新状態に対応するセットか、どこに保管し、新担当がどの方法で復元するかを確認します。一方だけが古い状態だと、受け取った資料がそろって見えても、同じ状態を再現できるとは判断できません。バックアップの対象と作成時点を組にして読めるようにしてください。

受領した記録と、復元を試した記録は別です。新担当は、許可された安全な試験環境で復元し、対象ページや画像、更新操作など、合意した確認項目を確かめます。ファイルが存在することや、受領欄が埋まったことだけで、復元成功や引継ぎ完了にはしません。

図の内容を文章で読む

復元用セットを受領した架空例。ドメイン・ホスト名義の記録は自社、WordPress役割の記録は管理者、コード保管先の記録は自社の組織。サイトファイルとデータベースを受領し、同じ時点のセットも確認済み。復元試験、有料プラグインの更新担当、メール関連の確認は未確認。新担当が安全な試験環境で確かめ、更新費用・通知先・旧担当のアクセスも別に確認する。実移管・実復元を認定しない。

PC原寸画像を開く · モバイル原寸画像を開く

出典：WordPressのバックアップと復元用セット

GitHubなどのコード保管場所は、提供方法と移管条件を確認する

制作会社が使う「リポジトリ」は、コードと変更履歴を保管する場所です。公開中のサイトと同じ状態のコードがどこにあるか、変更履歴や独自テーマの作り方を新担当へどう提供するかを、現在の管理者と確認します。実際に動くサイトのファイル、復元用のデータベース、コードの保管場所を同じものとして扱いません。

GitHubを使っている場合、公式の移管手順には、移管する人の管理者権限や、受取先のアカウント・組織の条件があります。移管できるか、別の提供方法になるかは、現在の管理者がサービスの条件と契約を確認して決めます。コードを受け取ったことを、サイトの公開や更新の成功と置き換えないでください。

GitHubでは、移管後も共同作業者や外部連携、鍵などが残る場合があります。移管そのものと、担当者のアクセスやサイトへの反映方法を見直す作業は別です。新担当には、どの保管版を使い、どの手順でサイトへ反映するかも確認します。ほかの保管サービスでは、そのサービスの現在の手順を確認してください。

出典：GitHubのコード保管場所を移管する条件

新担当の運用試験と、旧担当のアクセス・更新費用を分けて確認する

新担当が必要な資料と権限を受け取ったら、合意した更新を行えるかを確かめます。文章や画像の変更、バックアップ、復元、フォームの通知などを別の確認項目にし、担当者が確かめた結果を残します。一つの操作ができただけで、すべての運用が続くと判断しません。

メール、決済、外部サービス、有料プラグインなどを使っている場合は、それぞれの契約先、更新日、支払う担当、通知先を確認します。旧制作会社の契約に含まれていたものが、新担当へ切り替えた後も同じ条件で使えるかは個別に確かめてください。

確認を終えた範囲と未確認の範囲を分け、誰がいつ切り替えるかを決めます。その後、権限のある担当者が旧担当のアクセスと残る連携を点検し、合意した不要なアクセスや更新責任を整理します。データの受領、新担当の試験、旧担当との契約終了を、一つの完了欄だけで済ませないようにします。

受領の記録だけで、引継ぎ完了を判断しない

次の3例は、確認記録の読み方を示す架空例です。実顧客や実アカウントの移管結果ではありません。役割名や受領の記録から、実際の復元成功を推測しないように読みます。

ファイルの受領だけ確認できる例では、データベースを受け取ったかも確認が必要です。セットを受領した例でも、復元試験や更新費用、メールの連携まで確認済みとは限りません。保管先が分からない例を、データなし、権限なし、移管済みなどへ埋めないでください。

最初の一歩は、旧制作会社と新担当に、管理先と担当、ファイルとデータベースのセット、コード履歴の提供方法、試験で確かめる作業を同じ内容で示すことです。受領済みと試験済みを分け、未確認の項目には確認する人と日を決めます。

• ファイルの受領だけ確認できる例

  WordPressの役割は編集者、ファイルの受領は受領確認、データベースの受領は未確認、同じ時点のセットは未確認、復元試験は未確認です。

  ドメイン・ホストの名義の記録は自社、コードの保管先は旧制作会社です。必要な操作の権限、同じ時点のデータベースを含むセット、コード履歴の受渡し条件を管理者へ確認します。

• 復元用セットを受領した例

  WordPressの役割は管理者、ファイルの受領は受領確認、データベースの受領は受領確認、同じ時点のセットは確認済み、復元試験は未確認です。

  ドメイン・ホストの名義の記録は自社、コード保管先は自社の組織です。有料プラグインの更新担当とメール関連の確認は未確認です。安全な試験環境で確かめ、更新費用・通知先・旧担当のアクセスも別に確認します。

• 保管先が未確認の例

  WordPressの役割は未確認、ファイルの受領は未確認、データベースの受領は未確認、同じ時点のセットは未確認、復元試験は未確認です。

  管理先や資料、試験の記録をまだ取得していません。権限なし・データなし・移管済みへ変えず、元担当と権限のある担当が保管先と確認予定を確かめます。