AWS移行プロジェクトで最初に決めること｜目的・範囲・切戻し・判断者の整理

こんにちは。Lamb です。 AWS移行の話では、構成図より先に確認したいことが意外と多いです。

AWS移行では、サービス構成を考える前に、目的・範囲・停止時間・切戻し条件・判断者をそろえる必要があります。 ここが曖昧だと、設計が進んでもプロジェクトとして判断できません。 この記事では、移行初期に合意しておきたい前提を、現場で確認しやすい順番に整理します。 若手リーダーやPM、情シス担当者が計画を見直すときにも使える内容です。

最初に握るのは、構成よりも前提

AWS移行の話が始まると、つい構成の検討から入りたくなります。

どのサービスを使うのか。
ネットワークをどう分けるのか。
可用性をどこまで持たせるのか。

もちろん、どれも必要な検討です。

ただ、移行プロジェクトの最初に握っておきたいのは、AWSの細かな構成よりも前提条件です。曖昧なままだと、技術検討が進んでもプロジェクトとして判断できなくなってしまいます。

設計が固まってから前提の違いに気づくと、構成や見積もり、スケジュールを見直すことになります。正直、かなりつらい手戻りです。

AWS移行の初期に何を確認し、どこまで合意しておきたいのか。
今回は、現場で使いやすい順番に整理します。

移行初期の認識ずれは、技術用語の理解だけで起きるわけではありません。

たとえば「AWSへ移行する」という言葉だけでも、関係者ごとに思い描いている状態が違うことがあります。

• 現行環境をほぼそのまま移したい
• データセンターの期限までに移行したい
• 老朽化した部分だけを置き換えたい
• 運用負荷を下げたい
• 可用性やセキュリティを見直したい
• 将来の拡張に備えたい

目的が違えば、優先する観点や意見も変わります。

短期間での移行が最優先なら、最初からすべてを最適化する進め方が合わない場合があります。運用改善が目的なら、現行構成を移すだけでは期待した状態にならないかもしれません。

だからこそ、最初に「なぜ移行するのか」を言葉にし、背景と目的として整理します。

「今回の移行で、何が改善されれば成功と言えるのか」
「今回だけでは解決しないことは何か」

この2つを関係者の共通認識にできるだけでも、その後の判断は進めやすくなります。

移行対象と対象外をセットで決める

移行範囲を決めるときは、対象だけでなく対象外も明確にします。

「このサーバや機能を移行する」という一覧があっても、それだけでは足りません。システムにはさまざまな依存関係があるからです。

• 接続元と接続先
• バッチやジョブ
• ファイル連携
• 外部サービスとの通信
• 運用端末からの接続
• バックアップや監視
• 証明書や名前解決
• 手作業で実施している運用

対象範囲を確認するときは、機器やサーバの一覧だけで終わらせず、業務と運用のつながりも見ます。同時に、今回やらないこと・対象外とするものを残していきます。

たとえば、アプリケーション改修、データ整理、運用プロセスの全面変更を今回の範囲に含めないなら、その前提を記録します。移行するものと対象外にするものを、セットで決めるイメージです。

対象外が曖昧だと、プロジェクトの途中で「これも移行作業に含まれると思っていた」という話が出てきます。一方、対象外を決める考え方が整理されていれば、新しい論点が出ても同じ基準で判断できます。

範囲を狭くすること自体が悪いわけではありません。大事なのは、どこで線を引いたのかを関係者が同じように理解していることです。

停止時間は「何時間」だけで考えない

切替計画では、停止できる時間が大きな制約になります。

ただし、「3時間止められる」「夜間なら作業できる」といった時間枠だけでは、まだ判断材料が足りません。

最低限、次の点を分けて確認します。

停止可能時間のすべてを移行作業に使えるとは限りません。

バックアップ、データ移行、設定変更、動作確認、業務確認に加えて、問題が起きたときの調査時間や切戻し時間も必要です。

作業を詰め込みすぎると、切戻しを判断した時点ですでに戻す時間がない、という状態になりかねません。

時間を決めるときは、正常に進んだ場合だけでなく、想定どおりに進まなかった場合の対応計画も含めて考えます。

切戻しは、手順より先に条件を決める

切戻し手順を作るだけでは、切戻しできる状態になりません。

現場で迷いやすいのは、「いつ、その手順を使うのか」という発動条件です。

• どのエラーまでなら調査を続けるのか
• 何分解消しなければ切戻すのか
• 性能が基準を満たさない場合はどうするのか
• 一部機能だけに問題がある場合は続行するのか
• 誰が切戻しを提案し、誰が決定するのか

この条件が曖昧だと、切替当日に議論が始まります。ただでさえ時間と責任の制約があるなかで、最適な判断を下すのは簡単ではありません。

作業者は原因をもう少し調べたい。
業務側は早く再開してほしい。
責任者は影響範囲を確認してから判断したい。

それぞれの思いや考えがあって自然です。だからこそ、当日になって初めて話すのではなく、事前に判断基準を置いておきます。計画時点で想定できるリスクを減らしておく必要があります。

切戻し条件は、技術チームだけでは決められません。業務影響や再開期限も関係するため、顧客側の判断者を含めた合意が必要です。

現行環境調査は、パラメータや構成把握だけでは終わらない

AWS移行の計画は、現行環境をどこまで理解できているかに左右されます。

構成図、パラメータシート、サーバ一覧は大切です。
一方で、資料だけでは分からない運用や依存関係もあります。

確認したいのは、たとえば次のような点です。

• 日次、月次、年次で動く処理
• 特定の担当者だけが知っている作業
• 障害時だけ利用する接続経路
• 外部組織や別システムとの連携
• 手動でのファイル配置やデータ補正
• 監視通知を受けた後の対応
• バックアップからの復旧方法
• ドキュメントに載っていない例外運用

毎日使う機能だけを確認すると、月末や年度末だけ動く処理を見落とす可能性があります。

資料と実態が一致しているとも限りません。

そのため、現行環境調査では資料確認に加えて、運用担当者へのヒアリングやログ、ジョブの実行状況など、確認できる情報を組み合わせます。

具体的な調査方法や確認可能な情報は環境によって異なります。アクセス権やデータの取り扱いを含め、所属組織や案件のルールは要確認です。

役割分担は、作業者だけでなく判断者まで決める

役割分担表に作業担当者が書かれていても、判断者が見えないことがあります。

移行プロジェクトでは、少なくとも次の役割を区別しておきたいところです。

一人が複数の役割を持つこともあります。問題なのは兼任ではなく、誰が担うのか分からない状態です。

特に顧客、開発、インフラ、運用、ベンダーが関わる案件では、「相手側で決めると思っていた」が起こりやすくなります。

会議の参加者が多いことと、判断者が明確であることは別です。

判断が必要な論点ごとに、誰が材料を用意し、誰に確認し、誰が決定するのかを残しておくと、プロジェクトが止まりにくくなります。

合意した内容は、あとから確認できる形にする

会議で認識がそろっても、記録がなければ時間とともに解釈が変わります。

最初に握った内容は、議事録、課題管理表、計画書など、プロジェクトで合意した場所に残します。

最低限、次の情報が追える状態にします。

• 決めた内容
• 判断の前提
• 対象と対象外
• 未決事項
• 判断者
• 決定日
• 見直しが必要になる条件

一度決めたことを絶対に変えない、という意味ではありません。

現行調査が進めば、新しい事実が見つかることもあります。制約が変われば、計画を見直す必要もあります。

大切なのは、変更前の前提と変更理由が分かることです。「前にそう言っていたはず」という記憶の勝負にせず、現在の合意内容を関係者が確認できる状態にします。

移行初期に確認したいチェックリスト

AWS移行の話が始まったら、まずは次の項目を確認します。

目的と成功条件

• なぜAWSへ移行するのか
• 何が改善されれば成功と言えるのか
• コスト、期限、可用性、運用負荷のどれを優先するのか
• 今回の移行だけでは解決しないことは何か

対象範囲

• 移行対象と対象外は明確か
• システム間の依存関係を確認できているか
• バッチ、外部連携、運用作業を含めているか
• 今回実施しない改修や改善を記録しているか

切替と切戻し

• 停止可能な時間帯は決まっているか
• 技術確認と業務確認の時間を確保しているか
• 続行条件と切戻し条件は明確か
• 切戻しに必要な時間を見込んでいるか

役割と判断

• 作業担当者は決まっているか
• 技術確認と業務確認を誰が行うか
• 続行と切戻しを誰が判断するか
• 問題発生時の連絡先と共有方法は決まっているか

現行環境

• 構成資料と実態に差がないか
• 定期処理や例外運用を確認したか
• 運用担当者しか知らない作業がないか
• 調査できていない範囲を未確認事項として残しているか

すべてをはじめに決める必要はありません。

ただし、未決事項を未決のまま見えるようにして、誰がいつまでに確認するかを置く必要があります。

「まだ分からない」と分かっている状態と、確認が必要なこと自体に気づいていない状態は、大きく違います。

まとめ

AWS移行プロジェクトで最初に握っておきたいのは、AWSサービスの細かな構成だけではありません。

• 移行の目的と成功条件
• 対象範囲と対象外
• 停止時間と作業時間
• 続行条件と切戻し条件
• 現行環境の実態
• 作業者と判断者
• 合意内容を残す場所

これらが見えていると、技術設計で迷ったときに立ち戻る基準ができます。

反対に、前提が曖昧なまま設計を進めると、あとから「そもそも期待していた移行と違う」という話になりかねません。

移行初期に必要なのは、すべての答えを出すことではありません。

決まっていること。
まだ決まっていないこと。
誰が判断すること。
いつまでに確認すること。

この4つを見えるようにすることです。

AWS移行では、技術を決める力と同じくらい、関係者が判断できる状態を作る力が求められます。

次に読みたい記事

今回整理した論点は、要件定義、移行計画、設計レビュー、顧客説明へつながります。

次は、「要件定義で失敗しない進め方」や「AWS移行プロジェクトを計画から切替まで進める方法」で、各工程をもう少し具体的に掘り下げる予定です。

関連テーマのご相談について

AWS移行の前提整理や、現行環境調査・移行計画・切替計画の確認観点について、個別に相談を受け付けています。

構築や正式な設計判断を代行するものではありません。現状を伺いながら、検討が必要な論点や確認観点を整理する形です。

相談時は、顧客名、会社名、認証情報、社外秘情報などの機密情報を送らないようお願いします。