クラウドは管理者のログイン情報を受け取れば終わりではありません。契約主体、請求、実行環境、データ、権限、監視、変更と復旧のつながりを確認し、会社が日常運用できる状態をつくります。分からない項目は無理に埋めず、読み取り中心の調査課題として残してください。
最初に確認する7項目
AWSとGoogle Cloudでは、組織・アカウント・プロジェクトなどの呼び方が異なります。用語をそのまま比べるのではなく、契約主体、環境、データ、権限がどの単位に結び付いているかを確認します。打ち合わせでは、各項目を「確認できた」「要調査」「対象外」に分けて記録してください。
横幅が狭いときは左右にスクロールできます
| 項目 | 確認すること | 残すもの |
|---|---|---|
| 1〜2会社の管理へ戻す | ||
| 1. 契約主体・アカウント | AWSアカウント、Google Cloudの組織・プロジェクト、契約者、管理者、多要素認証（MFA） | アカウント一覧、組織やプロジェクトの対応、管理者の連絡先 |
| 2. 請求・契約 | 請求先、予算、契約期限、サポート窓口、費用の通知 | 請求情報、更新期限、予算と通知を確認する方法 |
| 3〜5つなげて読む | ||
| 3. 構成 | 本番・検証環境、ネットワーク、リージョン、実行中のサービス | 構成図、環境ごとの違い、外部連携の一覧 |
| 4. データ | データベース、ファイル、個人情報、保存期間、バックアップ | データ一覧、保持方針、復元手順と確認記録 |
| 5. 権限 | 人・サービスごとの権限、鍵、退職者や前担当者のアクセス | 権限表、棚卸し日、変更申請と承認の手順 |
| 6〜7実際に試す | ||
| 6. 監視・障害 | ログ、稼働状況を示す数値、異常通知、通知先、対応順 | 監視項目、連絡網、障害対応と復旧の手順 |
| 7. 変更・復旧 | レビュー、バックアップ、公開、変更前へ戻す作業、緊急変更 | 変更履歴、公開手順、戻し方、判断者 |
パスワードや秘密鍵そのものを一覧へ書く必要はありません。どこに安全に保管され、誰が取り出せるかを記録し、受け渡しは適切な方法で行います。
1〜2. アカウントと請求を会社の管理へ戻す
クラウド環境が動いていても、前の担当者の個人メールや開発会社のアカウントが唯一の管理者だと、障害時や契約終了時に操作できません。会社が契約主体か、管理者が複数いるか、多要素認証を誰が管理するかを確認します。AWSのアカウント、Google Cloudの組織・プロジェクト、請求先がどの会社や部署に結び付くかも図に残します。
請求先、利用中の契約、サポート窓口、予算の異常を知らせる通知も同じ資料へまとめます。利用料金を下げる施策を先に実行するのではなく、まず所有者と用途を確認し、変更の承認者を決めてください。使っていないように見えるリソースでも、停止すると業務やバックアップへ影響する場合があります。
3〜5. 構成・データ・権限をつなげて読む
構成図だけを見ても、どのデータがどこへ流れ、どの権限で処理されるかは分かりません。本番・検証の違い、データベースとファイルの保存先、外部連携、定期処理、サービス間の認証を、業務の流れと対応づけます。読み取りだけの権限で現状を確認し、必要な変更権限は作業単位で付与します。
- 個人情報や業務上重要なデータはどこにあり、いつまで残すか
- バックアップはどの頻度で、どこへ保存し、復元を試したか
- 本番へ変更を加えられる人と、承認する人は誰か
- 外部サービスの鍵や証明書の更新期限はいつか
- 権限を削除したときに、定期処理や連携が止まらないか
当社のシステム開発ではAWS・Google Cloudを使ったクラウド環境の構築を支援し、既存システムの引き継ぎ・継続改修ではコードだけでなく運用環境と管理権限の確認から進めます。環境名や構成はシステムごとに異なるため、一般的な用語だけで完了とせず、実際の画面と業務を照合してください。
6〜7. 監視と変更手順を実際に試す
異常通知が設定されているだけでは、運用できるとは限りません。何が異常で、誰へどの経路で通知され、どの順番で切り分けるかを確認します。AWSならCloudTrailやCloudWatch、Google CloudならCloud Audit LogsやCloud Monitoringなど、実際に使っているサービス名と役割を一覧にしてください。
- 01
通常時の状態を記録する
画面、ログ、稼働状況を示す数値、定期処理の実行結果を、確認日時とともに残します。
- 02
小さな変更を検証環境で試す
レビュー、バックアップ、公開、動作確認、監視までを一つの流れとして確認します。
- 03
戻す条件と判断者を決める
問題が起きたときに原因を調べ続けるのではなく、どの状態なら変更前へ戻すかを先に合意します。
共有アカウントを見つけても、すぐに削除しない
共有アカウントや前担当者の権限を見つけた場合も、いきなり無効化しないでください。定期処理や外部連携がその認証情報で動いている可能性があります。影響を確認し、個人や役割単位の権限へ移行する計画を立ててから変更します。引き継ぎ前の確認項目は、他社開発システムを引き継ぐときのチェックリストも参考になります。
引き継ぎ後の資料を完成形にする
資料は引き継ぎの日に完成するものではありません。最初の構成図、権限表、データ一覧、監視表、変更手順を作り、実際の作業で分かった差分を更新します。法人向けクラウドアプリマーケットプレイス開発事例でも、管理、認証、決済、インフラ構築・運用保守支援を含む構成を紹介しています。自社の環境と同じとは限りませんが、機能と運用を切り分けて確認する視点の参考になります。
注意点と相談の進め方
クラウドの引き継ぎは、アカウントを渡されれば完了ではありません。会社が管理できる契約、復元できるバックアップ、最小限の権限、異常を知らせる監視、戻せる変更手順がそろって初めて、日常運用へ移れます。資料が足りない場合は、いきなり構成変更をせず、読み取り中心の調査とドキュメント化から始めます。
現在分かる資料から引き継ぎを相談するなら、クラウドの種類、管理者の所在、稼働中のURL、困っている作業をお知らせください。現状を確認し、必要な保守・改修と資料整備の範囲を分けてご提案します。