LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

クラウド移行に「戦略」が要る理由 — 一律リフト＆シフトの限界

クラウド移行戦略とは、保有システムを重要度・改修余地・投資対効果に応じて分類し、システムごとに適した移行方式（6R）を割り当てる意思決定の枠組みを指します。AWS Prescriptive Guidanceでは、大規模移行における移行方式は7種類に整理され、7R（セブンアール）と呼ばれています^*1。

保有システムをすべて同じ手順でクラウドに移すリフト＆シフト（そのまま移設する方式）は、移行期間を短縮しやすい一方で限界もあります。老朽化した基幹システムをそのまま移しても、クラウドの従量課金や自動スケーリングといった特性を活かしきれないためです。

一律の移行方針を採ると、改修不要なシステムにまで検証工数をかけてしまう事態も起こりえます。逆に、業務への影響が大きいシステムを他と同じスケジュールで拙速に移すと、想定外の障害につながりかねません。

投資対効果の観点でも、戦略の有無は結果を左右します。移行後にクラウドの利点を引き出せるかどうかは、事前にどの方式を選ぶかという判断に大きく依存するからです。全システムを同一方式で扱うのではなく、システムごとに方式を組み合わせる発想が移行戦略の出発点になります。

6R(7R)とは — 6つの移行方式とAWSが加えたRelocate

6Rとは、クラウド移行の代表的な6つの方式（Rehost・Replatform・Refactor・Repurchase・Retire・Retain）の頭文字を取った分類の呼び方です。AWSは大規模移行のガイダンスにおいて、これにRelocate（仮想化基盤ごと移す方式）を加えた7方式を「7R」として整理しています^*1。

Rehost — アプリケーションを変更せずそのまま移す

Rehost（リホスト）は、アプリケーションに手を加えずオンプレミスからクラウドへ移す方式です。AWSでは「lift and shift」とも呼ばれています^*1。移行元のプラットフォーム（物理・仮想・他クラウド）を問わず多数のマシンを移せる点が特徴です。

移行中も利用者へのサービス提供を継続しやすく、混乱を最小限に抑えられるとされています。ただし、クラウド最適化を伴わないため、移行直後はコスト削減効果が限定的になりやすい点には留意が必要です。

Relocate — 基盤ごと移しアーキテクチャに手を入れない

Relocate（リロケート）は、複数のサーバーやアプリケーションをまとめて、オンプレミス基盤からクラウド版の基盤へ一括で移す方式です。VPC（仮想プライベートクラウド）やリージョン、アカウントの間で移す用途にも使われます^*1。

新規ハードウェアの購入やアプリケーションの書き換えを必要とせず、アーキテクチャ全体への影響が小さい点が特徴です。AWSはRelocateを「最も迅速に移行・運用を開始できる方式」と位置づけています^*1。

Replatform — 一部を最適化してから移す

Replatform（リプラットフォーム）は、移行と同時にいくつかの最適化を加える方式です。「lift, tinker, and shift」とも呼ばれ、フルマネージド型サービスへの移行やOS更新によるセキュリティ強化などが代表的な用途に挙がります^*1。

既存アプリケーションの骨格を保ちながらコストや性能を改善できる点が利点です。仮想マシンをコンテナへ移行する取り組みも、この方式に含まれます^*1。

Refactor(Re-architect) — クラウドネイティブへ再設計する

Refactor（リファクタ、または再設計）は、クラウドネイティブな機能を全面的に活用できるようアーキテクチャを作り直す方式です。俊敏性・性能・拡張性の改善を強い事業要請から進める場合に選ばれます^*1。

老朽化したモノリシック（一枚岩型）なアプリケーションが機能追加の足かせになっている場合や、保守できる担当者がいない場合に有効とされる一方、6方式の中で最も複雑度が高い点には注意が必要です^*1。AWSは大規模移行においてRefactorを推奨せず、移行後の段階で個別に検討する進め方を挙げています^*1。

Repurchase — SaaS等の異なる製品へ乗り換える

Repurchase（リパーチェス）は、既存アプリケーションを別製品やSaaS（Software as a Service、月額課金等で利用するクラウド提供型ソフトウェア）に置き換える方式です。「drop and shop」とも呼ばれています^*1。

従量課金モデルやインフラ管理不要という利点を取り込みやすい一方、業務要件との適合確認やデータ移行、認証基盤との統合など、切り替え後に必要な作業も生じます^*1。

Retire — 使われていないシステムを廃止する

Retire（リタイア）は、事業価値がなくなったシステムを廃止する方式です。保守コストの削減やセキュリティリスクの低減を目的に選ばれます^*1。

AWSは、稼働率が低く利用実態のない「ゾンビアプリケーション」や、一定期間インバウンド接続がないシステムを廃止候補の目安として挙げています^*1。移行対象から外すという判断も、立派な移行戦略の一部です。

Retain — 現状のまま残す

Retain（リテイン）は、現時点では移行しない、あるいは移行の準備が整っていないシステムを対象とする方式です。データ所在地に関する規制対応や、専用ハードウェアへの依存、直近で刷新したばかりといった事情が代表的な理由として挙げられています^*1。

将来のSaaS版リリースを待つ場合や、他システムの移行を先に終える必要がある場合も、いったんRetainを選ぶ合理性があります。移行しないという選択も、優先順位づけの結果として扱うことが大切です。

重要度・改修余地・EOLで決める移行方式の選び方

移行方式の選定では、システムの重要度・改修余地・EOL(End of Life、サポート終了時期)・データ移行の難度・SaaS代替の可否という5つの軸を確認する必要があります。軸ごとに整理すると、判断の抜け漏れを防ぎやすくなります。

事業への影響度で優先順位と慎重さを分ける

基幹システムのように停止時の影響が大きいシステムは、拙速な移行がそのまま事業リスクに直結します。AWSも、詳細な評価と計画を要するシステムはRetainで一旦保留する選択肢を挙げています^*1。周辺システムから着手し、知見を蓄積してから基幹に着手する順序が現実的な進め方になるでしょう。

改修余地とEOLでRehost・Replatform・Refactorを分ける

アプリケーションの改修余地が乏しく、かつ早期のクラウド化が優先される場合はRehostが選びやすい方式です。OSやミドルウェアのサポート終了が近く、性能改善も同時に求める場合はReplatformが候補になります。事業要請として俊敏性や拡張性の改善が強く求められる場合に限り、Refactorを検討する進め方が妥当です^*1。

データ移行の難度とSaaS代替の可否を確認する

独自開発の周辺業務システムで、市場に同等機能のSaaSが存在する場合はRepurchaseが有力な選択肢になります。一方、機密データを含み移行元での保持が必要なテーブルがある場合は、該当部分だけ残しつつ他を移すRefactorの適用例としてAWSも言及しています^*1。データの持ち方まで踏み込んで初めて、実行可能な方式が絞り込めます。

方式の選定を誤ると、想定していたコスト削減効果が得られないだけでなく、移行後に再度アーキテクチャを見直す二度手間が発生しかねません。特にRefactorは最も複雑度が高い方式であるため^*1、対象を見誤ると計画全体の遅延につながるリスクがあります。

アセスメントから定着までの移行の進め方

クラウド移行は、アセスメント・方式マッピング・優先順位づけ・段階移行・定着という順序で進めると管理しやすくなります。それぞれの工程で確認すべき事項を整理します。

ステップ1：システム棚卸しとアセスメントを実施する

保有システムを一覧化し、稼働率・依存関係・改修履歴・ライセンス状況を洗い出します。この段階の精度が低いと、後続の方式マッピングの判断材料が不足してしまいます。

ステップ2：システムごとに6R(7R)をマッピングする

棚卸しの結果をもとに、システムごとにRehost・Replatform・Refactor・Repurchase・Retire・Retain・Relocateのいずれかを割り当てます。1つの基幹システムの中でも、機能によって異なる方式を組み合わせる進め方が一般的です。

ステップ3：投資対効果とリスクで優先順位を決める

マッピングした方式ごとに、想定コスト・期待効果・実施難度を比較し着手順を決めます。周辺システムのRehostやRetireのように影響範囲が小さく効果が見えやすい対象から着手すると、早期に成果を示しやすくなります。

ステップ4：段階移行を実行し検証する

決めた優先順位に沿って移行を実行し、システムごとに動作確認と性能検証を行います。一括移行ではなく段階移行にすることで、問題が起きた際の影響範囲を限定できます。

ステップ5：運用に定着させ継続的に見直す

移行後は監視体制やコスト管理の仕組みを整え、実際の利用状況に応じて構成を見直します。Retainとして保留したシステムも、状況が変われば改めて方式を検討する対象になります。

移行戦略で経営が握るべき3つの論点

クラウド移行戦略の実行段階では、投資判断・リスクと停止許容度・体制という3つの論点を経営が握る必要があります。現場の技術判断だけに委ねると、事業影響の大きい意思決定が後手に回りかねません。

投資判断 — どこにどれだけ投資するかを決める

Rehostのように短期間で終えられる方式と、Refactorのように時間をかけて再設計する方式では、必要な投資規模も期間も異なります。どのシステムにどこまでの投資対効果を求めるかは、現場の技術者だけでなく経営が判断すべき事項です。

リスクと停止許容度 — 業務影響の大きさを事前に握る

移行作業ではシステム停止を伴う場合があります。停止を許容できる時間帯や範囲を事前に業務側と合意しておかないと、移行実行の段階で調整が後手に回るおそれがあります。基幹システムほど、この合意形成に時間をかける価値があります。

体制 — 意思決定できる推進体制を用意する

方式の選定や優先順位づけには、情報システム部門だけでなく事業部門の意見も必要です。経営層が関与する意思決定の場を設けておかないと、部門間の利害調整に時間を要し、移行計画全体が停滞しかねません。

アセスメントから移行後運用までを外部に委託する選択肢

クラウド移行を内製だけで完結させるには、システムごとの技術評価・移行方式の選定・移行実行・移行後の運用設計という複数の専門性を同時に確保する必要があります。社内に十分な人員や経験が揃っていない状況は珍しくありません。

特にアセスメント工程では、システムの依存関係や改修履歴を正確に把握できないまま方式を決めてしまうと、移行後に想定外の手戻りが発生する可能性があります。棚卸しの精度を確保するには、複数システムの移行経験を持つ第三者の視点が助けになる場面もあるでしょう。

移行実行の段階でも、Rehostのような比較的シンプルな方式であっても、切替時のダウンタイム管理やロールバック手順の設計には専門知識が求められます。移行後の運用保守まで見据えると、移行を実行した担当者がそのまま運用を引き継げる体制の方が、障害対応の初動を早めやすくなります。

外部パートナーを選ぶ際は、移行実行だけでなく、移行後の運用保守までを一貫して担える体制かどうかを確認する視点が欠かせません。移行はゴールではなく、クラウド環境での安定運用が始まる起点だからです。

まとめ：クラウド移行戦略で押さえるべき3つの判断軸

本稿では、クラウド移行戦略と移行方式(6R)の選び方を経営視点で整理しました。要点を3つに集約すると次の通りです。第一に、全システムを一律の方式で移すのではなく、Rehost・Replatform・Refactor・Repurchase・Retire・Retain・Relocateの7方式からシステムごとに適した方式を組み合わせる発想が出発点になります^*1。第二に、方式の選定は重要度・改修余地・EOL・データ移行の難度・SaaS代替の可否という軸で判断します。第三に、投資判断・リスクと停止許容度・推進体制という3つの論点は経営が握るべき事項であり、現場任せにしないことが移行を成功させる前提になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Amazon Web Services「Migration strategies – Large Migration Guide」https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html

Tweet