クラウド移行は「スタート」である：モダナイゼーションの本当の目的

はじめに

経済産業省が「DXレポート」で「2025年の崖」を指摘したのは、2018年のことです。それから8年がたち、その2025年も過ぎました。この間に、データセンターからクラウドへの移行に取り組んだ企業も多いでしょう。

一方で、移行を終えた企業から、こんな声を耳にすることも少なくありません。「クラウドに移したのに、機能追加にかかる期間は以前と変わらない」「運用の手間も、思ったほど減っていない」。移行が無駄だったわけではありません。

ただ、移行だけでは、機能を加えたり直したりするたびに時間と手間がかかりすぎる「変えにくさ」は解消しません。クラウドへの移行は、モダナイゼーションのゴールではなくスタートです。目的は、ビジネスの変化にシステムが素早く対応できるようにすることにあります。

レガシーシステムの本当の課題は「変えにくさ」

レガシーシステムというと、古い言語や保守期限の迫ったハードウェアを思い浮かべるかもしれません。ただ、問題の本体は古さよりも、変更に時間と手間がかかりすぎることにあります。

法改正に合わせて社内システムの入力項目を1つ足すだけで、数か月かかる。お客様向けのサービスに新しい機能を加えたくても、次にまとめてリリースする日まで数か月待つことになる。こうした状態に、心当たりはないでしょうか。

変更が重くなる原因は、1つではありません。アプリケーション側では、長年の改修で処理やシステム間の依存関係が複雑になり、1か所の変更がどこに影響するのか見通しにくくなります。インフラ側では、環境の準備や設定が手作業のままで、テスト環境をすぐに用意できないこともあります。

こうした状態では、毎回広い範囲を手作業でテストするしかなく、リリースも月に1回や四半期に1回にまとめることになります。変更の大きさにかかわらず、一定のテストやリリース作業が必要になるため、小さな変更ほど割に合わなくなりがちです。

私たちがご支援してきた中にも、こうした例があります。あるお客様では、1台のサーバーで複数の事業会社のシステムが動き、環境の設定はすべて手作業でした。会社ごとのテスト環境も用意しにくく、変更のたびにテストに大きな手間がかかっていました。

別のお客様では、会員向けサービスを支えるWeb基盤が、顧客管理や決済などの周辺システムと密接に結びついていました。そのため、周辺システムが変わるたびに、基盤のどこを直すべきかを把握しにくい状態でした。

注目したいのは、どちらのシステムもすでにクラウド上で動いていた点です。動く場所がクラウドに変わっても、変えにくい構造や進め方は、そのまま残ることがあります。

止められない、間違えられないシステムでは、変更の重さがさらに増します。決済のように24時間止められないお客様向けのサービスや、多くの業務やシステムとつながっていて誤りが許されない基幹システムが、これに当たります。慎重に進めること自体は正しい判断ですが、それを人の注意力と手作業で支えている限り、変更の重さは減りません。

2018年のDXレポートは、企業のIT関連予算の約8割が現行ビジネスの維持・運営に充てられていると指摘しました。2022年のDXレポート2.2でも、この状況は続いているとされています。

変えにくいシステムは、維持するだけで予算と人を使い、新しいサービスや機能に投資する余力、いわゆる「攻めのDX」の余力を奪っていきます。

クラウド移行は、モダナイゼーションのスタートライン

では、クラウドに移行すると、この変えにくさは解消するのでしょうか。移行の進め方を整理する枠組みに、AWSが示す7つの移行戦略（7R）があります。

Microsoft AzureやGoogle Cloudも、システムの特性に応じて移行方式を選ぶ考え方を示しています。分類や名称に違いはありますが、その考え方はクラウド事業者を問わず共通です。

7Rでは、システムごとに次のどの方式を取るかを選びます。

出典：AWS 規範ガイダンス「移行戦略について」をもとにBeeX作成

リホストは、データセンターの契約満了などの期限があるときに、比較的短期間で移行できる方法です。

ただし、リホストで主に変わるのは、システムが動く場所と、サーバーなど環境の調達の仕方です。アプリケーションの構造、テストのやり方、リリースの手順はそのまま残ります。入力項目1つの追加に数か月かかる原因が構造や、手作業の環境準備とテストにあるなら、その期間は大きくは縮まりません。冒頭の「移したのに変わらない」という声が出るのは、このためです。

リプラットフォームでも、アプリケーションの構造はほぼそのまま残ります。構造まで見直すのはリファクタリングですが、移行と同時に行うと、移行そのものが複雑になり長期化しやすくなります。

AWSも、7Rと同じガイドの中で、大規模な移行では、まずリホストやリプラットフォームで移し、移行の完了後に構造を見直す進め方を勧めています。

移行は、その後の見直しに向けた足場です。まず移行して運用を安定させ、その先で段階的に構造を見直す。この「移してから変える」進め方は、影響範囲の広い基幹システムや、止められないサービスにとってむしろ現実的です。

実際に、私たちがご支援したあるお客様では、OSのサポート終了を機に、クラウドの仮想サーバー上で動いていたAPIをサーバーレスの構成に置き換えました。あわせて、構築もコードで管理する形にしました。その結果、OSやサーバーの運用負担が軽くなっただけでなく、新しいAPIも追加しやすくなっています。

クラウドの真価を引き出すには、移行を到達点とせず、移した後に何を見直すかまで見据えておく必要があります。

モダナイゼーションとは、変化に柔軟なシステム基盤へ進化させること

BeeXでは、モダナイゼーションを「システム基盤を、変化に柔軟で、継続的な成長を可能にする形へ進化させる取り組み」と考えています。この考え方に立てば、成果は移行したサーバーの台数より、どれだけ速く、壊さずに変えられるようになったかで測ります。たとえば、「変更を決めてから本番に届くまでの期間」や「リリースで障害が起きる割合」です。

変更の速さと安全さは、インフラとアプリケーションの両方で決まります。アプリケーションの構造を整理しても、環境の構築やリリースが手作業なら本番に届くまでに時間がかかります。反対に、インフラを自動化しても、1つの変更が広く波及する構造なら、テストと調整の重さは残ります。

変更を素早く安全に届けるには、IaCやCI/CDで構築、テスト、リリースを自動化することに加え、変更の影響範囲を抑えられるシステムの構造が必要です。

そのうえで、システムの特性に応じて、システム間の連携をAPI経由に整理して結びつきを緩めることや、モジュール化やマイクロサービスへの分割、コンテナやサーバーレスの活用などを組み合わせます。

自動化したテストを毎回通し、変更を小さく分けて出せるようになれば、手作業のミスや、まとめてリリースすることによる障害も減らせます。

こうした変えやすさは、AIが活用できる状態（AI Ready）をつくることにもつながります。たとえば、業務システムのデータや機能をAPIなどで連携しやすくしておけば、生成AIを既存の業務に組み込むときの選択肢が広がります。

全部を一度に変える必要はない

とはいえ、すべてのシステムを作り直す必要はありません。企業のシステムには、社内の業務を支えるものからお客様向けのサービスまであり、変更の頻度もビジネスへの影響もさまざまです。変更の必要が少ない安定したシステムなら、リホストや現状維持で十分なこともあります。

一方、競争力に直結し、頻繁に変更を求められるシステムには、構造の見直しに投資する価値があります。経費精算のように、変更は求められても競争力には直結しない業務なら、自社で作り込むより、SaaSなどの製品への置き換えも選択肢になります。

求められる変更の頻度とビジネスへの影響の2つの軸で、方式の目安を整理すると次のようになります。

（図：システムの見分け方マトリクス）

実際には、ほかのシステムとの依存関係や保守期限なども含めて判断します。そこで最初に取り組みたいのが、システムごとの現状の把握です。見るべき点は2つあります。

1つは、ビジネスとしてどれだけ変える必要があり、競争力にどれだけ関わるかです。変えにくさのせいで変更を見送っているシステムもあるため、いまの変更の回数だけでは判断できません。

もう1つは、いまどれだけ変えにくいかです。1回の変更にかかる期間と工数や、どこで待ちが発生しているかが手がかりになります。こちらは、どこから手を付けるかを決める材料になります。

こうした事実を集めると、投資すべき場所と今は触らなくてよい場所が見え、7Rのどの方式をどの順番で取るかを決められます。

なぜBeeXがご支援するのか

変えにくさの原因がインフラにあるのか、アプリケーションにあるのか、両方にあるのかは、システムによって異なります。

BeeXは、クラウド専業のインテグレーターとして、AWSを中心としたインフラの移行・構築と、アプリケーションの設計・開発の両方を担ってきました。これまでの経験をもとに、両面から原因を見極めます。そのうえで、既存システムへの影響や投資対効果を踏まえ、必要な部分から段階的に見直すモダナイゼーションをご支援します。

サーバーレスやコンテナの特性を活かしたアーキテクチャ設計や、お客様と短いサイクルで改善を重ねる共創型のアジャイル開発も含め、アセスメントから稼働後の運用・保守まで一気通貫で伴走します。

おわりに

クラウドに移したシステムが、次の変化にどれだけ素早く応えられるか。モダナイゼーションで問われるのは、その点です。

まずは担当しているシステムについて、本来どれだけ変える必要があるのか、直近の変更にどれだけの期間と手間がかかったのかを確かめてみてください。

BeeXでは、現状のアセスメントからご一緒します。お気軽にご相談ください。