チームが確認し、実装につなげられる設計に。

現在の環境とワークロードから始める。

業務負荷、現行アカウント、構成資料、今回変更する理由を共有してください。想定トラフィック、データ量、アクセス制限、リソース制約が設計に影響します。動作する試作がある場合は、残せる部分と検証が必要な前提を確認します。設計範囲は、合意した業務と接続先のシステムに基づいて決めます。

リクエストとデータの経路を描く。

ユーザーの要求がモデルやアプリケーションに届く経路、依存するサービス、データと利用記録を扱う場所を示します。アカウントやプロジェクトの帰属も設計の一部として確認します。

• 計算資源とストレージ：負荷の特性、容量の前提、データアクセス、実行ソフトウェアなどの依存関係。
• ネットワークとアクセス：接続経路、サービスの所在、許可する利用者、システム連携の境界。
• 運用と費用：監視の要件、障害時の処理、計量単位、リソース見積もりの前提。

切り替えと復旧を同時に計画する。

移行や環境変更では、影響を受けるシステム、前提条件、検証順序、担当者を明らかにします。切り替えの判断方法と、以前の設定に戻せる条件を示します。データ変更や外部サービスへの依存で復旧が制約される場合は、その限界と実装前の確認事項を記録します。実施時間と作業は、お客様の変更管理責任者と調整します。

実装の拠り所になる資料を提供する。

成果物として、構成案、ネットワーク図・データフロー図、リソースと設定の概要、移行手順、復旧計画などを取り決めます。容量と費用の説明には、想定負荷、課金基準、未確認の入力情報を記載します。運用の概要には監視、アクセス、引き渡し要件をまとめます。文書の詳しさは、作業範囲と実装担当チームに合わせます。

技術レビューで設計を確認する。

関係チームと、呼び出し経路、権限、依存関係、障害シナリオ、費用を確認します。合意済みの判断と、試作や提供元の確認が必要な事項を区別します。設計の前提、担当者、実装時の受入条件を残します。製品の提供状況、アクセス権、最終的なリソース見積もりは、注文前に選定したアカウントとリージョンで確認します。