レガシーシステムの問題点を分かりやすく解説。脱却とクラウド化のポイント

2023年03月31日掲載

レガシーシステムの問題点を分かりやすく解説。脱却とクラウド化のポイント

DX推進が叫ばれる中、レガシーシステムからの脱却を検討しなければいけない経営者・システム責任者の方も多いのではないでしょうか。

本記事では、レガシーシステムは何が問題でどんなリスクがあるのか、マイグレーションとモダナイゼーションのメリットや違いについて分かりやすく解説します。既存システムが老朽化し、クラウド化を検討している方のヒントになれば幸いです。

目次

レガシーシステムとは?

レガシーシステムとは

レガシーシステムとは、一般的には古い技術や仕組みで構築されているシステムを言います。IT業界では1980年代に多くの企業が導入したメインフレームやオフィスコンピュータを使ったシステムを指しています。

「レガシー」には「時代遅れ」というネガティブな意味があります。類義語として、世の中のニーズ変化に対応できない旧式なシステムのことを「技術的負債」と呼んでいます。

レガシーシステムの代表例「メインフレーム」

メインフレームとは、1980年代に金融系のシステムなどで活用され普及した、基幹システムなどに用いられる大型コンピュータシステムのことです。OS、ハードディスク、データベース管理システムなどの技術はメインフレームから生まれ、ほかのコンピュータにも採用されていきました。1990年代以降はUnixやWindowsが台頭しダウンサイジング化の波が訪れたことで徐々にシェアが低くなっていきましたが、現在でも銀行や政府系機関などの基幹システムとして多く利用されています。

なぜレガシーシステムが残ってしまうのか?

  • システム開発や移行の費用や手間がかかる
    大規模な基幹システムを開発・移行しようとすると長期で大掛かりなプロジェクトになるため、膨大なコストとリソースがかかります。また、システム移行時に不具合が発生してしまうと、顧客や社内関係者に大きな影響をもたらすリスクもあるでしょう。
    このような中で、長期的な目線ではシステム刷新したいものの、短期・中期的には部分的なシステム改修を繰り返してしまい、その結果レガシーシステムが長期間稼働し続けてしまう構図があります。
  • ベンダ依存
    日本の産業構造として、システム開発や保守をベンダに委託するケースが一般的です。システムをベンダ任せにしてきた結果、社内人材のIT対応能力が育たず依存が深まることになります。ベンダ側も多重下請けモデルでシステム開発することが多いため利益率を上げにくく、新規の開発投資や人材投資ができません。その結果、レガシーシステムが放置されてしまう構造になっています。

レガシーシステムのデメリット

拡張性やメンテナンスがしにくい

新しい技術や働き方の変化にあわせて、ITシステムは要件を変更してアップデートする必要があります。しかし、レガシーシステムは環境変化に対応できるプログラムではなく、機能や容量の拡張が困難なことも多いです。また、古い設計のためメンテナンスできる人材がいない、時間がかかってしまうという問題もあります。

新しい技術やビジネスモデルに対応できない

レガシーシステムは、最先端のシステムとデータ連携できない可能性もあります。サブスクリプション型やレベニューシェア型などの新しいビジネスモデルが出てきた際にも、既存システムでは柔軟に対応できず取引先の新規獲得のチャンスを失うこともあります。このように、レガシーシステムは単にシステムだけでなく、ビジネス全体にネガティブな影響を与えてしまうのです。

レガシーシステムが引き起こす問題点

レガシーシステムが引き起こす問題点

「2025年の崖」問題とレガシーシステム

平成30年に経産省の発表したDXレポートでは、「2025年の崖」の問題が提起され話題になりました。このままレガシーシステムを放置することで、2025年以降に最大年12兆円の経済損失につながると言われています。

その原因の1つに、2025年には21年以上稼働しているレガシーシステムがシステム全体の6割を占めると予測されていることが挙げられます。老朽化したシステムは、実際にどのようなリスクを持つのかを以下で解説します。

参考:DXレポート|経済産業省(平成30年)

大規模なシステム障害の発生リスク

レガシーシステムを長年使い続けることにより、システム統合や連携を行うことで障害が発生してしまう可能性もあります。例えば、企業合併によりレガシーシステムの統合を繰り返してしまい、システムが肥大化・ブラックボックス化してしまうことがよくあります。レガシーシステムを利用し続けることで単にシステムの稼働効率が悪くなるだけでなく、システム障害により顧客にも影響を与えたり、企業のブランドや信用を損なう事態に発展するリスクもあります。

部分最適によるシステムの複雑化

レガシーシステムに新しい技術を導入したり要件定義を変更しようとすると、部分最適が進みシステムが徐々に複雑化していきます。多くの企業ではコストや時間・リソース要因により、大規模なシステム刷新を避けて部分改修を繰り返しがちです。その結果、短期目的は達成できても、長期的な問題が発生してしまいます。

システムのメンテナンスにかかるコストが増大

レガシーシステムには維持管理にかかるコストが増えやすいデメリットもあります。 システムが老朽化することで、不具合の発生頻度が高くなり、メンテナンスにかかるコストは増え続けていきます。また、COBOLなどレガシーな言語での開発に対応できる人材も今後減少していくことが予想されます。つまり、人材の雇用維持や新規採用にもコストがかかるというわけです。

システムの属人化・サイロ化

レガシーシステムは部分改修を繰り返して存続しているため、時間の経過とともに過去の経緯やシステム構造を把握している人が少なくなり、属人化しやすくなる傾向があります。特定の人物に依存した情報システムは非常にセキュリティリスクが高くなるので避けなければいけません。
複数の部署に属人化したシステムがあると横断的なデータ連携もできず、システムのサイロ化が進行していきます。日本の大企業でDXが進まない主な原因の1つはこのサイロ化にあると言われています。

レガシーシステムから脱却するためのDX手法

レガシーシステムから脱却するためのDX手法

ここまでで、レガシーシステムに潜むリスクをご理解いただけたでしょうか。この章ではレガシーシステムから脱却するための具体的な解決法を紹介します。マイグレーションとモダナイゼーションという2つの選択肢と、それぞれの特長を解説していきます。

マイグレーションという選択

「マイグレーション」または「レガシーマイグレーション」とは、データや機能を維持したまま現在のシステムから新しいシステムに移行することを言います。旧式システムからのデータ移行は「データマイグレーション」と呼び、欠損や重複、形骸化しているデータを整理して新しいシステムに移行します。そのほかにも、ストレージやアプリケーションのマイグレーションなどがあります。

要件や機能、データを変えずにより安全で使いやすいシステムへ段階的に移行できるため、リスクやリソースを抑えながら実行できるのがポイントです。マイグレーションの手法として、クラウド移行や仮想化、コンテナ化などがあります。

クラウド移行

クラウド移行の具体例には以下のようなものがあります。

  • オンプレミスのデータベースやアプリケーションを、クラウド上のサービスに移行
  • オンプレミスのサーバを、クラウド上の仮想サーバに移行
  • オンプレミスのストレージを、クラウド上のストレージに移行

クラウドの特長として、リソースの弾力性が高くスケールアップやスケールダウンが容易であるため、需要に応じてインフラストラクチャを調整することができます。

仮想化

仮想化は、物理的なサーバやストレージを仮想的なリソースに変換する技術です。仮想化により複数のシステムを同じ物理サーバ上で実行することができ、ハードウェアの使用率を最大化することができます。

コンテナ化

コンテナ化は、アプリケーションを実行するための独立した環境を提供する技術です。コンテナはアプリケーションとその依存関係を1つの環境にまとめることができるため、レガシーシステムに必要なアプリケーションをすばやく構築・デプロイ・スケールすることができます。また、コンテナは異なる環境間でアプリケーションを移行するのが容易なため、システム移行やアップグレードを行う際にも役立ちます。

モダナイゼーションという選択

「モダナイゼーション(ITモダナイゼーション)」とは、老朽化した既存システムを現在の要件や環境に合うように刷新することを指します。マイグレーションは既存システム基盤の構造を変えずに移行する形式ですが、モダナイゼーションは現行のシステムを構成するソフトウェアやプログラム、ドキュメントを維持しながらシステム基盤そのものを刷新するという違いがあります。モダナイゼーションでは、業務効率化やセキュリティ向上などを目的として、新機能や新しいインターフェースの導入を行います。

ここではモダナイゼーションの代表的な手法としてラッピング、リライト(リアーキテクチャ)、リホストの3つについて解説します。

手法特長

ラッピング

既存システムのインターフェースや画面機能を再構築

リライト

既存アプリケーションプログラムを、新しいオープン言語で再記述し移行(COBOLからJavaへの移行など)

リホスト

既存アプリケーションに変更を加えず、別プラットフォーム(ハードウェア)へ移行

ラッピング

ラッピングは、既存アプリケーションを再利用してシステムのインターフェースや画面機能を再構築する手法です。
メインフレーム上のアプリケーションをオープンシステムからアクセスできるよう、ラッピング(=システムにプログラムを被せる)します。レガシーシステムは残ってしまうため、近い将来に刷新が必要です。

リライト

リライトは、ビジネス要件を変更せず、プログラミング言語とプラットフォームだけを変更する手法です。
現行構造のままリライトするものやオブジェクト指向へのリライトなどのパターンがあります。リライトにより新規OSや情報セキュリティの向上、システム効率化が期待できます。レガシーなプログラミング言語からモダンなプログラミング言語に移行することで、人材確保と生産性向上の問題を解消できる可能性があります。

リホスト

リホストとは、アプリケーションシステムは変更せずプラットフォームとなるハードウェアのみを変更する手法です。
リフトアンドシフトとも呼ばれ、現在のシステム構成をほぼ変更せずにクラウドに移行し、運用の中で徐々に最適化していくことが多いです。導入期間の短縮やコスト削減ができるというメリットがあります。

マイグレーションとモダナイゼーションの違い

これらの2つの言葉は、一般的に混同して使われがちですが中身は異なります。モダナイゼーションは最新技術を活用して既存のシステム構造を刷新します。一方で、マイグレーションは既存システム構造は変えずデータなどを別のIT環境へ移行します。オンプレミスな業務システムをクラウド移行することもマイグレーションの一例です。

まとめ

レガシーシステムからの脱却

数年以内に迫り来る「2025年の崖」を乗り越えるために、レガシーシステムからの脱却とDX推進は急務です。レガシーマイグレーションの第一歩はクラウド移行です。しかし、自社システムにはどのクラウドが適しているか、移行ステップとして何が最適かは悩ましい問題ではないでしょうか?

こちらの資料「既存のシステムを転用したクラウド移行を実現する「IaaS」」や、ブログ「オンプレからの「クラウド移行」が分かる。移行手順、メリット、よくある失敗事例を解説」にもクラウド移行についてポイントなどをまとめていますので参考にし、自社システムに適したクラウドと移行方法をご検討ください。

関連資料

ストレージサーバ・ファイルサーバからはじめるクラウド利活用のススメ

失敗しないクラウド利用のはじめ方、移行方法、セキュアなクラウド利用環境を構築するための閉域ネットワーク活用をご紹介します。

既存のシステムを転用したクラウド移行を実現する「IaaS」

レガシーシステムからIaaSへ移行するポイントについて解説します。

関連セミナー・イベント

条件に該当するページがございません

おすすめの記事

条件に該当するページがございません