オンプレからクラウドへ！インフラ移行計画の教科書｜PM・リーダーが押さえるべき確認観点リスト

インフラ移行プロジェクトにおいて、計画の成否を分けるのは技術力だけではありません。最も重要なのは、不測の事態を想定した「確実性」と「リスクコントロール」です。

本記事では、サービスマネージャーとして数多くの大規模現場を統括してきた視点から、計画段階で網羅しておくべき実戦的な確認観点を徹底解説します。

移行方式の選定：オンプレ・クラウドの並行稼働をどう設計するか

移行方式を選定する際、多くのエンジニアは「作業効率」を優先しがちですが、PMやリーダーが重視すべきは「リスクの許容度」です。

段階的移行（新旧並行稼働）を第一選択に

一度にすべての機能を切り替える「一括移行（ビッグバン移行）」は、万が一トラブルが発生した際の影響範囲が全サービスに及び、切り戻しの判断も極めて困難になります。そのため、可能な限り「段階的移行」を検討するのが鉄則です。

• 判断基準： データレプリケーション（同期）が容易か。
• 具体例： ADサーバ、DNSサーバ、WEBサーバなどは同期の仕組みが確立されており、新旧環境を並行稼働させながら、少しずつトラフィックを移していくのに適しています。

システムを「切り分ける」2つの視点

段階的移行を実現するためには、システムをどのように分割して移行するか、以下の2つの視点で戦略を立てます。

① モジュール（機能）単位での切り分け

システムの階層構造（WEB/AP/DB）や、機能コンポーネントごとに切り分ける手法です。

• 例： まずは影響の少ないWEB層のみをクラウドへ移行し、残りのDBなどはオンプレミスに置いたまま専用線で通信させる。動作が安定したことを確認してから、後続のAP層、DB層を順次移行する。
• 注意点： 移行途中で新旧環境を跨ぐ通信が発生するため、データ連携の遅延（レイテンシ）や、ネットワーク帯域の確保が不可欠です。

② 対象範囲（ユーザ・拠点）単位での切り分け

システムそのものを分割するのではなく、システムを利用する「ユーザ側」を切り分ける手法です。

• 例： 全国の支店へ提供しているシステムであれば、まずは「特定の1支店」のみを新システムへ移行し、1週間様子を見る。問題がなければ「地方ブロック単位」、最後に「本店・全拠点」へと段階的に拡大していく。
• メリット： 万が一不具合が発生しても、影響を受けるユーザを限定できるため、ビジネスへの打撃を最小限に抑えられます。また、最初の移行で得た知見（トラブル事例や操作の不明点）を、次回の移行計画にフィードバックできるため、後半ほど移行の確実性が高まります。

コンティンジェンシープラン：失敗を前提とした「出口戦略」

移行当日にリーダーが直面する最大の試練は「予定通り進めるか、撤退（切り戻し）するか」の決断です。この判断を現場の空気や焦りで行わないために、コンティンジェンシープランの策定が不可欠です。

コンティンジェンシープランとは何か

コンティンジェンシープランとは、予期せぬ事態（システムダウン、深刻なバグの発見、作業の著しい遅延など）が発生した際に、被害を最小限に抑えるための「緊急時対応計画」です。 単に「失敗したら戻す」と決めるだけでなく、「どのような状態になったら」「誰が」「いつまでに」判断し、「どうやって」旧環境へ復旧させるかを具体的に定義したものを指します。

切り戻しの「デッドライン」と逆算思考

計画には必ず「Go/No-Go判断ポイント」と、物理的な「デッドライン（最終判断時刻）」を設定します。

• 計算式： サービス開始時刻 － 切り戻し作業時間 － 予備時間 ＝ 最終判断時刻

例えば、翌朝9時のサービス開始に対し、旧環境への復旧に4時間かかるのであれば、午前5時が限界点となります。この時間を1分でも過ぎた場合は「Point of No Return（後戻り不可）」となり、何が何でも新環境でサービスを継続しなければなりません。

「Point of No Return」後の備え

もしデッドラインを超えた後に致命的な問題が発覚した場合、どう対処するかまで決めておくのが真のリーダーの仕事です。

• 縮退運転の検討： 一部の機能を制限してでもサービスを継続する。
• 暫定運用の周知： ユーザに対して「一部機能制限中」のアナウンスを行い、手動オペレーションでカバーする体制を整えておく。

移行スケジュールは「失敗すること」を前提に組み、リカバリプランが完了して初めて、プロジェクトの安全が担保されるのです。

---

移行当日の切り替え作業中、想定外の事態が起きた際にリーダーが問われるのは「報告の質」です。一分一秒を争う場面で、関係者が次に動くための情報をどう取捨選択すべきか。

現場の混乱を最小限に抑えるための「戦略的な報告のトライアングル」を知っておくだけで、当日のあなたの精神的な余裕は劇的に変わります。

クラウド移行時の「ライセンス・保守契約」の落とし穴

インフラエンジニアが陥りがちな盲点が、技術以外の「契約面」です。ここを疎かにすると、移行後に巨額の追加費用が発生したり、サポートが受けられないリスクがあります。

ライセンス体系の変化

オンプレミスからクラウドへ移行する場合、従来のライセンスが通用しないケースが多々あります。

• 注意すべきライセンス： CPUコア数や物理ソケット数に依存するもの。クラウド上の仮想コア（vCPU）への割り当てルールが複雑な場合があります。
• 対策： BYOL（Bring Your Own License）が可能か、あるいはクラウド専用ライセンスへの切り替えが必要か、必ず保守ベンダーから「メール等の言質」を取ってください。

旧環境の保守契約「出口戦略」

コスト削減を急ぐあまり、移行完了の翌日に旧環境の保守を切るのは非常に危険です。

• 推奨： 移行後、最低でも1ヶ月の安定稼働が確認できるまでは旧環境の保守を維持します。
• テクニック： 移行当月に解約予定であっても、失敗時に備えて「翌月以降の再契約見積・稟議」を事前に済ませておきます。発注直前で止めておく（いわゆる「塩漬け」状態）にすることで、有事の際に即座に保守を継続し、旧環境へ戻れる体制を整えます。

クラウドのリソース不足への対策：リリース後のチューニング

クラウド移行において、本番環境の負荷を完璧に予測することは不可能です。「性能試験で大丈夫だったから」という過信は捨てなければなりません。

負荷試験と現実の乖離

可能な限り本番同等の負荷試験を実施しますが、インターネット越しの通信特性や、予測しきれないユーザの振る舞いにより、実トラフィックとの乖離は必ず発生します。

顧客への訴求：「コスト最適化」という付加価値

リリース直後にリソース不足（または過剰）で慌てないために、あえて「リリース後のチューニング期間」を公式なスケジュールに組み込みます。顧客（ステークホルダー）には以下のように説明し、合意を得ておきましょう。

「最初から最大負荷を想定した過剰なリソースを確保すると、無駄なコストが発生し続けます。まずは机上計算に基づいた最適サイズでリリースし、初週の実際の挙動データを見てから微調整（ライトサイジング）を行うことで、最小限のランニングコストと安定稼働を両立させます。」

このように、「後から調整が必要になる」ことを「コスト最適化のための戦略」としてポジティブに提示するのがPMの腕の見せ所です。

まとめ：移行の定義は「安定稼働」まで

インフラ移行のゴールは、サーバが新環境で「起動した瞬間」ではありません。以下の3点が達成されて初めて、プロジェクトは完了したと言えます。

1. 運用のバトンタッチ： 構築チームから運用チームへ、手順書や監視項目が過不足なく引き継がれていること。
2. 性能の最適化： 実稼働データに基づき、リソースの過不足が解消されていること。
3. ルーチン化： 予期せぬトラブルの発生頻度が下がり、日々の運用が平時（ルーチン）の状態に戻ること。

ここまでを「移行のスコープ」として定義し、計画段階からリソースを割いておくことで、真に「価値のある」マイグレーションが実現します。技術へのこだわりと、リスクへの冷徹な視点。この両輪を持って、次なる移行プロジェクトを成功に導いてください。

インフラ移行という大規模な荒波を乗り越え、システムを安定稼働へ導く経験は、あなたの市場価値を唯一無二のものにしてくれます。SIerという環境を最大限に利用して、自分だけの『武器』を磨く戦略については、以下の記事もあわせて読んでみてください