レガシーシステムとは

レガシーシステムとは

変更が困難になり、中身を分かる人も限られて、事業の足かせになったシステムです。
経済産業省のレガシーシステムモダン化委員会総括レポート（PDF）は、運用維持保守や機能改良が困難な状態に陥り、経営や事業戦略の足かせ、高コスト構造の原因となっているシステムと定義しています。

この状態のシステムを保有していると、新たなサービスの提供や、他のシステム、外部サービスとのデータ連携がシステムの都合で実現できなくなります。
基盤のサポートが終了した後も使い続ければ、セキュリティの修正を適用できないまま業務を運用することになります。

判定するときは開発した年や利用している技術ではなく、次の5つの兆候を確認します。

• 帳票の項目追加や画面の小さな修正のような軽い変更に、目安として数か月かかる、または見積もりの段階で辞退される
• 中身を説明できる人が社内外で1〜2人しかおらず、その人が不在だと障害の原因を特定できない
• 改修をしていないのに保守費が年々上がり、新規の施策への予算を圧迫している
• 基盤やソフトウェアの提供元によるサポートの終了時期が確定している、またはすでに過ぎている
• 設計書が実物と一致しておらず、仕様の確認にはプログラムを読む必要がある

据え置く・延命・置き換え・廃止の仕分け

レガシーシステムへの手の打ち方は、機能ごとに次の4つから選択します。

方針	何をするか	残存する問題と費用
据え置く	改修せずに使い続ける	保守費は上がり続ける。保守会社の撤退や担当者の退職で、ある日から保守できなくなる危険も残存する
延命	中身を変更せずに、OSやデータベース、ハードウェアだけを更新する	更新した基盤のサポート切れは解消する。アプリケーション側の古いライブラリや脆弱性、変更のしにくさ、中身を理解している人の少なさは残存する
置き換え	機能単位で、新たに開発した仕組みや市販のパッケージ、SaaSへ移行する	移行中は新旧の両方を稼働させる費用がかかる。移行した機能は他のシステムや外部サービスとデータを連携しやすくなる
廃止	利用されていない機能を停止する	費用は最小だが、本当に利用者がいないかを利用部門と確認する手間がかかる

据え置きが合理的な場面もあります。
次の3つを満たすシステムは、旧来のものでも急いで改修する必要はありません。

• 業務がほとんど変化しない
• 中身を理解している人と保守の体制を確保できている
• 廃止や置き換えの予定が数年以内に確定している

刷新のコストとリスク

移行期間の負担

• 移行期間は旧システムの保守費と新システムの開発費を並行して負担する。
  上乗せは目安として旧システムの年間保守費の1〜2年分になる
• 大規模なシステムの刷新は数年単位の計画になる。
  総括レポートによれば着手後に問題の発生や停滞で計画を再検討すると、期間はさらに延びる
• 旧システムに埋もれた業務上のルールを調査して明文化する作業が必要になる。
  この作業は見積もりが外れる原因になる
• 切り替えの際に業務が停止する、データが正しく移行されないといった障害の危険がある
• 利用部門が慣れた画面や帳票が変化し、その教育と業務の見直しに工数がかかる

権利と資料

ソースコードや設計書の権利と所在が保守会社の側にあると、保守会社を変更したくても次の会社に中身を引き継げません。
開発時の契約で著作権が開発会社に帰属したままで、最新のソースコードも保守会社の環境にしかない、という状態は珍しくありません。
刷新を検討する前に、契約書で権利の帰属と引き渡しの条件を確認し、最新のソースコードと設計書の一式を受領しておきます。
これが完了していれば、保守会社の切り替えや保守費の価格交渉にも余地が生まれます。

継ぎ目

旧システムを稼働させたまま1機能ずつ移行するストラングラーフィグパターンには前提があります。
利用者の操作や他のシステムからの呼び出しを、新旧のどちらで処理するかを振り分ける窓口を設けられることです。
画面と夜間の一括処理とデータベースが1つのプログラムの中で絡み合い、窓口を設ける継ぎ目がないシステムでは、データの分離から着手することになり、期間と費用が増大します。

刷新した後

刷新後も保守の体制と設計書を維持しないと、新たな技術で開発したシステムでも再びレガシーシステムになります。
総括レポートも大型の汎用コンピュータ（メインフレーム）から脱却した後でも運用維持保守に問題があれば再レガシー化しうると指摘しています。

期限が先に確定しているもの

OS、データベース、ハードウェアには、提供元が定めたサポートの終了時期があります。
終了後は不具合やセキュリティの修正が提供されなくなり、延長サポートを購入できる場合も費用は通常より高いです。
メインフレームでも富士通が販売を2030年度、保守を2035年度で終了すると2022年に発表しています。

方針の決定期限はサポートの終了日から移行にかかる期間を差し引いて定めます。
数機能を置き換えるだけなら目安として終了の1〜2年前、基幹業務を担う大規模なシステムなら3〜5年前には方針を決定しておきます。
富士通のメインフレームで業務を稼働させているなら、2035年度から逆算して2030年代の初めまでが期限になります。
期限を過ぎると延命か一括移行しか選択できなくなり、残り期間の短さから、保守会社や移行先との価格交渉でも不利になります。

経済産業省は2018年のデジタルトランスフォーメーションに関する報告書（DXレポート）で、既存システムの問題を放置したまま2025年を迎えると大きな経済損失が生じうると警告しました。
この予測は2025年の崖と呼ばれます。
総括レポートの調査では回答したユーザー企業の61%が、2025年を過ぎてもレガシーシステムを保有していました。

よくある誤解

旧来のシステムはすべてレガシーシステム

20年以上稼働しているシステムでも、次の状態なら急いで再構築する理由はありません。
基盤のサポート期限を別にすれば、変更が数週間で完了し、中身を理解している人が複数いて、保守費が安定しています。
反対に数年前に開発したシステムでも、設計書がなく、開発した会社と連絡が取れなければレガシーシステムになっています。

クラウドに移行すればレガシーシステムではなくなる

中身を変更せずにサーバーをクラウドへ移行するのは延命にあたります。
ハードウェアの保守切れは解消できるが、変更のしにくさと、中身を理解している人の少なさは残存します。

刷新するなら現行の機能をすべて再現する

現行の機能を一覧にして合意するだけで大きな工数がかかり、一括で切り替える計画につながりやすいです。
旧システムの制約に適合させた業務の手順まで、新たなシステムに持ち込むことにもなります。
総括レポートも現行機能の保証や現行踏襲への強い要望が刷新の妨げになっていると指摘しています。
刷新は利用されている機能と事業の今後に必要な機能を再検討する機会として位置づけます。

レガシーシステムの問題は情報システム部門の問題

予算の配分、業務の見直し、刷新中の現場の協力は、いずれも経営と事業部門が意思決定する事柄です。
技術の問題として情報システム部門や保守会社へ任せきりにすると、刷新の判断は障害や担当者の離脱が発生するまで先送りされます。
総括レポートの調査でも刷新を決定する契機の上位は大規模なシステム障害と保守要員の離脱でした。