レガシーシステムをモダナイズする道は 4 つあります。そのままクラウドへ移す、コードを最新のプラットフォームへ変換する、抽出した業務ルールを軸に再構築する、またはパッケージ製品に置き換えてデータだけを残す、の 4 つです。選択を決めるのは 4 つの問いです。ルールは自社固有か。問題はシステムが動く場所か、システムそのものか。コードを理解している人はまだいるか。社員はどこまで変化を受け止められるか。Amazon はこれらの道を 7 つの戦略に、Microsoft は 8 つに整理しており、どちらもシステムごとに判断します。

第 4 回では、システムの業務ルールを抽出し、プロセスの責任者に確認してもらいました。この比較ができるのは、そのルールがあるからです。ルールがなければ、それぞれの道でシステムのどの動きを失うのか分かりません。

四つの道をやさしい言葉で

技術用語はたくさんありますが、どの経営者にも分かる 4 つの判断にまとめられます。次の表で比べます。かっこ内はベンダーから聞く名称です。

道適する場面残るものリスク関わるべき人
そのまま移行(Rehost)システムは安定して役目を果たしており、問題はサーバーやデータセンターにあるすべて:コード、ルール、仕事の進め方古い問題を新しい場所へ持ち込むIT 部門と、セキュリティおよびデータの責任者
コード変換(Replatform または Refactor)ルールは正しいが、言語やプラットフォームのサポートが終わった、またはライセンスが負担になっているルールとシステムの動きを、最新の言語やプラットフォームでまれなケースでしか表に出ない隠れた変換ミス開発者、そして結果を検証するプロセスの責任者
ルールを軸に再構築(Rebuild)ルールが自社固有で差別化の源泉であり、古いシステムでは必要なことをもう収められない確認済みのルールとデータ。コードは新しく書き直す最も時間がかかり、経営判断を最も多く必要とする経営陣、プロセスの責任者、開発チームが一体で
パッケージ製品に置き換え(Replace)その領域の業務が他社と似ている。人事や一般会計などデータのみ社員が製品に合わせて仕事のやり方を変え、製品が対応しないルールは失われる経営陣と、毎日それを使う社員

ソースコードとは、システムが書かれているプログラムの本文です。手元にない、あるいは理解できる人がもういない場合、変換の道は難しくなります。Amazon の戦略ガイドは、保守方法を誰も知らない、またはソースコードが入手できないアプリケーションを、再設計に向かわせるケースの ひとつに挙げています。

AI 変換ツールはどこで役立つか

AWS Transform のようなツールは主に 二番目の道で使われます。古いコードを読み、最新のプラットフォームへ変換します。たとえば古い .NET Framework のアプリケーションを Linux で動く最新版へ移す、といった使い方です。Amazon はこのツールが Windows、メインフレーム、VMware のアプリケーションを最大 5 倍速くモダナイズすると述べていますが、これは Amazon による自社サービスの説明であり、保証された結果ではありません。料金ページによると、料金はエージェント稼働分ごとに 0.035 ドルで、利用者の待ち時間には課金されません。

ただし、ツールが道を選んでくれるわけではありません。変換が正しい判断のときに変換を速めますが、パッケージ製品への置き換えが最善の答えならあまり役立ちません。また、リージョンのページには中東のリージョンが ひとつもなく、データが別のリージョンで処理される場合があると注意書きがあります。一方、サウジ通信によれば、Amazon はサウジアラビア国内のクラウドリージョンを 2026 年 12 月に開設すると発表しています。コードに顧客データが含まれるなら、始める前に処理場所を確認してください。

費用と期間を左右するもの

数字はお伝えしません。システムを知らずに出す数字は推測にすぎないからです。どの道でも、費用と期間を押し上げたり押し下げたりする要因は次のとおりです。

  • 規模と絡み合い:画面、帳票、連携するほかのシステムの数。第 3 回の棚卸しで見えたとおりです。
  • ルールの明確さ:確認済みのルールはそれだけ時間を節約し、不明なルールは遅くて高くつく発見を意味します。
  • データの品質:重複や欠けのあるデータは、どの道でも移行前にきれいにする必要があります。
  • 社員にとっての変化の大きさ:そのままの移行は利用者にとって何も変わりませんが、置き換えはほぼすべてが変わり、研修が必要です。
  • システムを理解している人がいるか:経緯を知る社員が ひとりいるだけで、何週間もの手探りが省けます。

手順の順番については、二つの公式情報が助言しています。Amazon のガイドはアーキテクチャの再設計を最も複雑で費用のかかる戦略とし、大規模な移行ではまず移し、移行が終わってからモダナイズするよう勧めています。Microsoft の Cloud Adoption Framework は、そのままの移行が適するのはワークロードが少なくとも 二年は現状のままだと確信できる場合だけで、そうでなければ二度手間を避けるためにすぐモダナイズするほうがよいとしています。移行そのものの手順は、クラウド移行の実践ガイドで解説しました。

誰もが忘れる二つの選択肢:維持と廃止

すべてのレガシーシステムを今モダナイズする必要はありません。Amazon と Microsoft のリストは、どちらもプロジェクト丸ごとの費用がかからない 二つの選択肢から始まります。

  • 廃止:実はもう使われていないシステムがあります。Amazon は、直近 90 日間に受信接続が一度もないアプリケーションや、プロセッサとメモリの使用率が 5% 未満のアプリケーションを例に挙げています。データをアーカイブしてから停止すれば、保守の手間とセキュリティリスクが減ります。
  • 維持:安定して役目を果たし、近いうちに変える理由がないシステム、あるいは代わりのない工場の機械につながったシステムです。この場合の判断は、維持して見守り、あとで改めて検討することです。

パッケージの ERP への置き換えに傾いているなら、まずERP の選び方で紹介した基準でパッケージとオーダーメイドを比べ、確認済みのルールの一覧から出発してください。製品が対応しないルールは、高額なカスタマイズか手作業のどちらかになります。

Origami の視点

私たちは技術からではなく、ルールから始めます。このシステムのどの業務ルールが御社らしさをつくり、どれが他社と共通なのか。御社らしさをつくる部分は丁寧に再構築か変換をする価値があり、共通の部分はほかのシステムとうまく連携したパッケージ製品で十分なことがあります。だから判断はしばしば組み合わせになります。あるシステムは置き換え、別のシステムは変換し、三つ目はそのまま維持する、という具合です。

AI ツールは、コードを読む、変換する、テストするといった本当に時間を節約できる場面で使います。しかし道を選ぶのは、各選択肢で何が残り何が失われるかを見たうえでの経営陣です。私たちの進め方はサービス紹介をご覧ください。

今週の課題:システムごとにひとつの判断

システムの棚卸し表に戻り、各システムに 二つの列を加えてください。ルールは自社固有か、共通か。問題はどこにあるか、動いている場所か、システムそのものか。そのうえで暫定の道を書き込みます。

システムルールは固有か共通か問題は場所かシステムか暫定の道
例:価格設定システム固有システム変換または再構築
例:休暇管理共通システムパッケージ製品に置き換え
例:古いアーカイブ使われていない関係なしデータをアーカイブしてから廃止

これは説明のための例で、御社の表は違うものになるはずです。大切なのは、各システムの道に書面の理由があり、見積もりを依頼する前にプロセスの責任者が確認していることです。

次回予告

各システムの道が決まりました。プロジェクトで最もリスクの高い日はまだ先にあります。切り替えの日です。第 6 回では、AI が書いた、あるいは変換したコードを、同じ実際の取引で新旧システムの結果を比べてテストする方法、決めた期間だけ両方を並行稼働させる方法、そして切り戻し計画が必要になるタイミングを解説します。

出典