レガシーシステムはモダナイズが必要か？見逃してはいけないサイン

レガシーシステムに次のサインが 一つ以上見られるなら、モダナイズが必要です。技術がベンダーのサポート対象外になっている、一人の担当者または 一社の委託先しか理解していない、電子インボイスや銀行、新しいアプリとは手作業のエクスポートでしかつながらない、あるいは小さな変更のたびに数週間かかる、といったサインです。たとえば Microsoft によると、SQL Server 2014 の延長サポートは 2024 年 7 月に終了し、.NET 8 と .NET 9 のサポートは 2026 年 11 月 10 日に終了します。システムが安定していて、隔離されており、維持費が安いなら、待つことが正しい判断かもしれません。

このシリーズの第 1 回では、会社が 一日たりとも欠かせないシステムを書き出しました。ここでは、それぞれについて「本当にモダナイズが必要か」を問います。

サイン一：技術がベンダーのサポート対象外になっている

購入した製品や、その上に構築した製品には、必ずサポート終了日があります。その日を過ぎると、ベンダーは新しいセキュリティ修正を提供しないため、後から見つかった脆弱性はシステムに残り続けます。各システムについての最初の問いは、「どの技術の上に構築されていて、そのサポートはいつ終わるのか」です。以下の例は Microsoft の製品ライフサイクルのページからのもので、業務システムの基盤として最も一般的な技術の一部です。

出典：Microsoft の Windows Server 2012 R2、SQL Server 2014、.NET の各ページ。サポートが終わっても、システムが明日止まるわけではないことに注意してください。リスクが毎月高まっていくということであり、有償のセキュリティ更新は計画のための時間を与えてくれますが、決断そのものをなくしてはくれません。

知識のサイン：誰が理解していて、何の上で動いているか

• 一人しか理解していない。あらゆる修正が 一人の社員や 一人の外部開発者を待っているなら、システムはその人の休暇や退職に左右されます。これは最も危険なサインです。不在が実際に起きるまで、どの報告書にも現れないからです。
• 誰もそのマシンに触れようとしない。脇の部屋に置かれ、再起動してはいけないと誰もが知っているサーバーで、交換部品ももう販売されていない。止まれば業務も止まり、すぐに使える代替機はありません。
• 業務ルールを知っているのはコードだけ。割引、手数料、権限がどう計算されるかはソフトウェアの中にしかなく、説明する文書がありません。まさにこれを、第 4 回で AI を使って引き出します。

連携とスピードのサイン：システムが会社の足を引っ張っている

• 回避策なしでは電子インボイスに接続できない。ザカート・税・関税庁（ZATCA）の電子インボイス導入フェーズのページによると、第一フェーズは 2021 年 12 月 4 日に始まり、ZATCA のシステムとの統合フェーズは 2023 年 1 月 1 日から段階的（ウェーブ単位）に始まりました。各事業者には自社のウェーブの少なくとも 六か月前に通知されます。システムが仲介プログラムや手作業を通じてしか要件を満たすインボイスを発行できないなら、ウェーブ 25 と ZATCA 統合に関するガイドをお読みください。
• 銀行やアプリには手作業のエクスポートが必要。誰かが毎日システムからファイルをエクスポートし、銀行やオンラインストア、配送プラットフォームにアップロードしている。手作業のステップは、どれもミスと時間のロスの原因になります。
• 簡単な変更に数週間かかる。項目やレポートの追加、価格の変更をするにも、依頼を出して待つことになります。どんな変更も、誰も理解していない別の部分を壊すおそれがあるからです。
• レポートを毎月 Excel で作り直している。状況を把握するためにチームがデータをエクスポートし、手作業で並べ替えているなら、システムはデータを保存しているだけで、あなたの問いには答えていません。そもそも実際のシステムがスプレッドシートなら、スプレッドシートが答えでなくなるときから始めてください。

まだモダナイズしない方がよい場合

モダナイズはそれ自体が目的ではなく、しばらくそのままにしておくべきレガシーシステムもあります。次の条件がそろっているときは、待つ方がよい選択かもしれません。

• 安定している：長い間深刻な障害がなく、変更が必要になることもめったにない。
• 隔離されている：インターネットに接続されておらず、他のシステムとやり取りする必要もないため、脆弱性のリスクが低い。
• 維持費が安い：複数の人が理解しており、保守にかかるお金や時間が少ない。
• どのみち置き換える予定：近いうちに既製品へ移行するなら、まもなく引退するシステムのモダナイズに投資しないでください。

その場合の正しい判断は、見守ることです。技術がいつサポート対象外になるかを記録し、動作するバックアップがあることを確認し、システムが何をしているかを文書化してください。後でモダナイズを決めた場合の安全な進め方は、ダウンタイムなしのレガシーモダナイゼーションのガイドで解説しています。

Origami の視点

私たちはシステムや連携を構築し、古いシステムのモダナイズも手がけていますが、それでもどのレガシーシステムに対しても最初に問うのは、そもそもなぜモダナイズすべきなのか、ということです。何年も会社を支えてきたシステムは尊重に値しますし、多くのシステムに必要なのは作り直しではなく、新しい連携や優れた文書化です。

そのため私たちは、まず各システムをサポート、知識、連携、変更のスピードの観点で評価し、そのうえでリスクを下げる最小のステップを提案します。それが連携であれ、移行であれ、エンジニアが 一行ずつレビューする AI 支援の書き直しであれ同じです。自社のシステムについて意見が欲しい場合は、サービス紹介をご覧ください。

今週の演習：各システムを 8 点満点で採点する

第 1 回で書き出したシステムのリストを用意し、四つの軸のそれぞれについて各システムに 0 から 2 の点数を付けてください。0 は問題なし、1 は軽微な問題、2 は明確な問題を意味します。

• サポート：その技術はサポートされているか？（サポートが終了している、または 一年以内に終了する場合は 2）
• 知識リスク：何人が理解しているか？（一人または 一社のベンダーだけなら 2）
• 連携：請求、銀行、他のシステムと手作業なしで連携できるか？（連携が手作業なら 2）
• 変更のスピード：簡単な変更にどれくらいかかるか？（数週間かかるなら 2）

これは優先順位を付けるためのツールであり、最終判断ではありません。8 点中 6 点以上のシステムは今すぐ計画に値し、3 から 5 点は見守りつつ再評価の日付を決め、0 から 2 点はそのまま稼働させてよいということです。合計点にかかわらず、知識リスクだけで 2 点のシステムは早急な文書化が必要です。

次回予告

これでシステムのリストと、それぞれの点数がそろいました。第 3 回では、このリストを完全な棚卸しへと発展させます。各システムの責任者は誰か、誰が使っているか、どんなデータを保持していてその中に個人データが含まれるか、何と接続しているか、止まったら何が壊れるか、ライセンスはいつ更新されるか、そして各システムについての 五つの選択肢、すなわち維持、廃止、既製品への置き換え、そのままクラウドへ移行、再構築を取り上げます。

出典

• Microsoft：Windows Server 2012 R2 のライフサイクル — 延長サポートの終了と、有償 Extended Security Updates の年数。
• Microsoft：SQL Server 2014 のライフサイクル — 延長サポートは 2024 年 7 月に終了。有償更新は 2027 年 7 月まで。
• Microsoft：.NET のライフサイクル — .NET 8 と .NET 9 のサポートは 2026 年 11 月に終了。.NET 10 は 2028 年 11 月まで。
• ZATCA：電子インボイスの導入フェーズ — 第一フェーズは 2021 年 12 月 4 日。統合フェーズは 2023 年 1 月 1 日からウェーブ単位で開始。
• AWS Transform：公式サービスページ — 第 1 回で取り上げた AI 支援モダナイゼーションの例。