レガシーシステムとは？
レガシーシステムが問題視される背景と刷新するべき理由

レガシーシステムが問題視される背景

レガシーシステムを使用し続けることは、企業にとって大きなリスクがあります。

リスクとなる部分は企業によって異なりますが、さまざまな問題が発生し、市場での競争力を失ってしまうおそれがあります。レガシーシステムが引き起こす主なリスクとして、以下のようなものがあります。

他システムとの連携が困難になる

レガシーシステムは過去に設計と開発が行われており、そもそも他システムとの連携を想定して実装されていないものがほとんどです。

しかし、現代はDX（デジタルトランスフォーメーション）が社会的に推進される時代であり、システム間同士でデータ連携は重要な仕組みとなっています。

経済産業省も経営者向けに「デジタルガバナンス・コード」というデジタル活用や人材育成についてまとめた指針を公式サイトで公開しています。デジタル技術の活用は国家規模で重要視されており、他システムとの連携が難しいシステムは今後あらゆる場面で活用できなくなるでしょう。

DXを推進する社会では、他システムと連携し、データを活用することで付加価値を生み出していきます。

そのため、新規開発されるシステムは、クラウドで実装されるケースが増えました。クラウド上でシステムを実装することで、サードパーティなどが提供するクラウドサービスの利用も容易になるなど、他システムとの連携がスムーズになります。

一方でレガシーシステムの場合、自社ネットワークのような閉じられた環境で実装されていることがほとんどです。

変化の激しい現代社会において、レガシーシステムを単独で運用し続けた場合、ビジネスで新たな価値を生み出すことは難しくなるでしょう。

また、他システムとの連携を実装する場合、すでに提供されている仕組みを利用するのではなく、基本的には連携用のインターフェースを一から実装しなければなりません。

最新技術を利用できない

レガシーシステムの多くは、AIやIoT、ブロックチェーンなどの最新技術を利用できません。理論上は、レガシーシステムに最新技術を導入して利用することは可能ですが、実際にはかなり難しいでしょう。

まず、レガシーシステムに最新技術を利用した機能を実装する場合、適切な人材を集めることが困難です。そのレガシーシステムで利用されている過去の技術と、最新技術の双方を理解している技術者を採用する必要があるためです。

また、レガシーシステムは最新技術の実装に適していない、古いプログラム言語で実装されているものがほとんどです。

AIを実装するうえでは、ライブラリなどのすでにある仕組みをうまく利用して構築する必要があります。しかし、古い言語にはそのような仕組みが整っていない場合が多く、外部のサービスを利用する形での実装も困難です。

前述のとおり、他システムとの連携が難しいため活用範囲が限定的になってしまい、十分な効果を享受できません。

運用費用が膨大になる

レガシーシステムでは、費用面の課題も多くなります。

システムを稼働させるには、運用作業が不可欠です。長年システムを使用し続ける過程で業務を見直し、機能追加やシステム改修などを繰り返した結果、運用作業が最適化できていないことがあります。

たとえば、新入社員のアカウントを追加する際に複数個所で登録作業が必要、仕組みの異なるモジュールが増えた結果パッチ適用作業が煩雑になっている、ログの出力場所が機能ごとにバラバラになってしまっているなど、基本的な業務であっても煩雑な作業が発生しているケースは少なくありません。

システムを使い続けると、運用作業はどうしても増えてしまう傾向があります。

システム開発のプロジェクトでは、予算の都合上新しい要件が実現できない場合、機能に優先順位をつけて優先度の低い要件を手運用とすることがよくあります。

そのため、長年使い続けるシステムであればあるほど、システムを稼働させるために手作業が多くなり、人件費もかさんでしまうのです。

新しい要件への対応が難しくなっていく

レガシーシステムは、さまざまな理由から新しい要件に対応できないおそれがあります。

まず、実装されている機能が属人化しており、一部の社員しか改修ができなくなっていることがあります。長年プログラムを改修してきていることから、ソースコードが複雑化して可読性が下がっており、修正が困難になってしまっているのです。

古い設計思想やソースコードの理解は非常に難易度が高いため、ドキュメントによる新規社員への引継ぎも限界があるでしょう。

また、ソースコードが修正可能なレベルであったとしても、品質担保のための工数が膨大になります。他機能への影響が大きいことが多く、修正により不具合が発生するリスクも高い状態です。

ほんの少しの修正であっても、テスト工数がかさんでしまうおそれがあります。

業務効率が悪くなっていく

レガシーシステムを利用して構築されている業務プロセスは、最適化されていないことが多いです。一見すると、新しい要件が発生するたびに業務プロセスは改善されるため、現在の要件に適していると考えられるかもしれません。

しかし、その軸となっているのはレガシーシステム開発当時の業務プロセスであるため、根本的な部分は改善されていない場合がほとんどです。

部分的には業務要件にかなった実装がされていても、全体的には目的を達成するためにふさわしいプロセスになっていないことがあります。

その結果、業務効率が下がり、企業が市場価値を高めていくうえでの障害となってしまうでしょう。

具体的には、自動化可能な業務にも人手を使っているなどが考えられ、とくに人件費の面で企業に悪影響を及ぼすおそれがあります。

セキュリティ面で大きな問題がある

レガシーシステムは、セキュリティ面が脆弱であることも課題の1つです。

時代の変化に合わせて、求められるセキュリティ対策も当然変わっていきますが、レガシーシステムでは変化に対応できないことがあります。極端な例を挙げると、ハードコーディングされたパスワードが使われている場合もあるようです。

システムがブラックボックス化してしまっており、要件を満たせるセキュリティ対策が行われているかの確認すら困難なケースもあります。

適切なセキュリティ対策が行える状態であったとしても、セキュリティ専任の担当者を自社で雇用しなければならないなど、費用面でデメリットが大きくなります。

コンプライアンス上の問題が発生する

レガシーシステムの利用は、コンプライアンス上の問題につながってしまうおそれもあります。企業はビジネスを続けていくうえで法の遵守が求められ、法改正にも迅速かつ適切に対応しなければなりません。

システムが現代の法律に適応できていない場合や、セキュリティホールが原因でデータ漏洩など重大なインシデントが発生した場合、事業を継続できなくなってしまう危険性があります。

また、コンプライアンス意識が低い企業としてイメージの低下につながるおそれもあるでしょう。

近年は個人情報の管理がますます重要視されており、たとえばヨーロッパではGDPR（EU一般データ保護規則）が施行されています。

データが侵害された際の迅速な検知や通知、本人からデータ削除があった場合の対応、セキュリティの強化や明確化など、個人情報を厳正に管理することを定めた法令です。

レガシーシステムの場合、時代遅れの技術を利用している、新しい要件への対応が難しい、などの観点からコンプライアンス関連の問題が発生しやすくなります。

「2025年の崖」への直面（サポートが切れてしまう）

レガシーシステムを使い続けるなかで、システムベンダー側からサポートの終了が発表されて製品の継続使用が不可能になる場合もあります。

たとえば、SAP社の「SAP ERP 6.0」の標準サポートは2027年に終了することが発表されています。

利用している製品やサービスのサポートが切れた場合、ベンダーからセキュリティパッチの適用などの重要な対応が行われなくなり、システムを使い続けることが困難になります。最終的には、外部からのサイバー攻撃による情報漏洩といった重要なインシデントが発生するリスクも高まるでしょう。

現在では、企業の約8割がレガシーシステムを抱えており、日本全体の課題としてとらえられています。レガシーシステムの継続的な利用は、DXの妨げや経済的損失の発生につながりかねません。

経済産業省は「日本企業がDXなど現代に適応できないシステムを利用し続けることで2025年以降に年間最大で12兆円の経済損失が生じる可能性がある」と警鐘を鳴らしており、これを「2025年の崖」と呼んでいます。

レガシーシステムを刷新するためのポイント

レガシーシステムからの脱却を目指すには、従来の業務要件を満たすことはもちろん、将来的な要件も意識してシステムを構築することが重要です。

今後どのような要件が出てくるのか、その要件を満たすにはどのような技術が必要か、要件を達成し続けるためにはどのような仕組みを構築すべきか、などの観点を考慮しましょう。

そのうえで入念な計画を立て、システム刷新を進めていく必要があります。

モダナイゼーションとは

モダナイゼーションとは「現代化」を意味し、レガシーシステムを刷新する際によく使われる言葉です。最新の技術、サービス、データなどを駆使して古いシステムを新しいものへ置き換えていくことを指します。

現代の企業には、モダナイゼーションの推進が強く求められています。

近年ではDXが重要視されており、デジタル技術を利用した新たなサービスが生み出されています。どの企業にとっても、市場価値を高めていくうえでDXの取り組みは欠かせません。

また、AI、IoT、ブロックチェーン、VRなどの最新技術がビジネスでも活用されています。業務の自動化やリアルタイムデータの活用による新たな付加価値を備えるサービスの構築など、今までにない商品や仕組みが数多く開発されています。

そして、新型コロナウイルス感染拡大をきっかけに在宅での勤務が増えたことにより、ITインフラへのセキュリティ対策は必須となりました。社員が外部から社内の情報リソースに安全かつ効率的にアクセスできる必要があり、ゼロトラストのアプローチを取り入れた環境を構築する企業が増えています。

このように、現代では多くの企業にモダナイゼーションが求められています。ビジネス要件の変化が激しい社会において、ステークホルダーの期待に応えていくためにも、最新の考え方、技術、ITインフラの導入が必要です。

従来の仕組みの担保とは

レガシーシステムから脱却する場合も、従来の要件を達成できる環境を整えておく必要があります。

新システムへの移行は、単に新しい要件に対応できれば良いわけではなく、古いシステムで遂行していた業務も引き続き達成していかなければなりません。こうした従来の仕組みの担保も、レガシーシステムを刷新するうえで非常に重要なポイントです

ただし、レガシーシステムはブラックボックス化していることが多く、仕組みの担保は想像以上に難しい課題となるでしょう。

まったく新しいものに作り替える場合は、とくに注意が必要です。既存システムで達成できている要件や機能を詳細に確認し、新しいシステムでも対応可能な状態にする必要があります。

企業の状況によって適切な手段は異なるため、慎重に検討して移行を進めていきましょう。

既存のレガシーシステムで構築していたプロセスをそのまま利用する場合もあれば、まったく新しい仕組みを一から構築するほうが適切な場合もあります。移行する際は、すべてを同時に移行するのではなく、段階的に対応したほうがリスクを軽減できることもあります。

自社の状況に合わせて、最適な方法を採用することが重要です。

データ移行とは

システムを刷新する際に必要なデータ移行は、非常に難しいタスクです。単純にデータを旧データベース（DB）から新DBに移動させるのではなく、新システムに合わせたデータ加工が不可欠です。担当者はデータ移行の仕様を決定する際に、旧システムと新システムの両方について熟知しておく必要があるでしょう。

また、通常は本番環境での移行時のヒューマンエラーを避けるため、データ移行用の処理プログラムを用意することになります。

そのため、移行スクリプトの開発スキルも求められます。旧システムは不具合などが原因でごみデータや不整合データができてしまっていることも多く、そのリカバリーも考慮した移行スクリプトを用意しなければなりません。

さらに、移行が正しく行えるかを確認するためのテストやリハーサルも行います。単純に移行データが想定どおりに加工され新システムが正常に動作するかどうかだけではなく、データ移行が求められる時間内に完了できることの確認も必要です。

基本的には、新システムに移行する際も企業の業務を止めることはできないため、夜間など限られた時間でデータ移行を完了させる必要があるでしょう。時間どおりにデータ移行を完了できない場合は、移行スクリプトの速度改善や要件に優先順位をつけてデータ移行中に一部の業務を停止するなどの対策が求められます。本番環境の切り替え作業中に重大なトラブルが発生することもあるため、その切り戻しプランの準備も必須です。

このように、データ移行は非常に難易度が高いため、事前に入念な計画を立てておくことが欠かせません。

レガシーシステムの刷新方法

レガシーシステムの刷新は大規模なプロジェクトになることも多く、さまざまな観点を見極めたうえでの判断が求められます。

一般的にはリホスト、リファクタ、リビルドという3つの手段があり、企業の事情によって適切な手段は異なります。モダナイゼーションが必要な領域、実現のためにかかるコストとリスクを十分に吟味し判断します。

「新しい要件への対応」と「既存要件の担保」の両方が求められるため、そのバランスをとることが重要です。

リホストとは

ITインフラのみを入れ替え、アプリケーションのソースコード修正などは行わない方法です。レガシーシステムを刷新する手段のなかで、最もリスクが低いとされています。

具体的には、オンプレミスからクラウドに移行する、クラウド上で動作しているアプリケーションを別のクラウドに載せ換える、クラウド上のインスタンスを最新版にバージョンアップする、などの方法が挙げられます。アプリケーションはそのままでも要件を達成できる場合に、リホストが選択されることが多いでしょう。

たとえば、既存のアプリケーションをオンプレミスからクラウドへ移行する場合、費用面でメリットがあります。クラウドプロバイダーにインフラの管理を任せられるため、費用を抑えることが可能です。

オンプレミスの場合は、運用保守を行う専任のスタッフが必要でサーバールームも用意しなければならないため、メンテナンスコストが高くなります。

リファクタとは

既存のアプリケーションのソースコードを最適なコードに改修する方法を指します。レガシーシステムに最新技術を導入できるようにしたり、新しい要件に対応しやすくしたりすることを目的とした手段です。

基本的にフロントエンド側には大きな変更は加えず、バックエンド側の仕組みを改修します。レガシーシステムは長年使われてきたことが原因で、ソースコードが複雑、無駄な処理が多い、不具合が放置されているなど多くの課題があり、新機能の実装が難しい場合があります。

そこで、リファクタというアプローチによってソースコードを最適化することで、改善できる可能性があります。

既存システムの機能や仕組みに変更を加えたくない、コーディングが不適切で処理速度が遅くなっている、小さな修正でも他機能への影響が大きくテストに時間がかかってしまう、といった場合に有効です。

ただし、ソースコードに修正を入れることになるため、リグレッションテストが必要になる点には注意してください。

リビルドとは

ゼロからシステムを再構築する方法です。業務要件やプロセスを再検討し、それに合わせてシステムを構築します。

既存システムではもはや企業の目的を達成できない、システムの根幹となる技術が完全に時代遅れで改善しようがない、既存のシステムやソフトウェアライセンスの維持費用が高い、など抜本的なシステム刷新が必要な場合に採用される手段です。

ビジネス要件に合わせて、最適なプログラミング言語、データ構造、サービスなどを利用してシステムを構築できます。

リビルドが成功すれば、顧客にまったく新しい付加価値を提供することもできるでしょう。その反面、リスクは大きくなるため注意が必要です。

リビルドは基本的に長期のプロジェクトになるため、事前に成功できるかどうかを徹底的に調査する必要があります。新しい要件への対応は不可欠ですが、既存の要件を担保することも重要であるため、慎重な判断が必要です。

関連資料

• SAP S/4HANA®移行「i-KOU!®」サービスアセスメント＆PoC

  

  2027年迄に求められているSAP S/4HANA®への移行方式で頭を抱えて悩まれているお客様が多くいます。 SAP S/4HANA®移行へ向けては、様々な方式があります。例えば、既存のSAP® ECC環境上にある全てのデータを移行する方式。また、SAP S/4HANA®を新規で構築し、既存データをマイグレーションする方式。データ移行、新規構築には一長一短があり、双方のメリットを合わせた移行方式もあります。 そこで移行方式で悩まれているお客様に対して、NTTデータGSLがSAP S/4HANA®への移行方式の最適解を見つけるサービスアセスメントをご提案します。 ダウンロード

• 基幹システムソリューションガイド（大全）

  

  NTTデータ グローバルソリューションズが提供するお客様のDX（デジタルトランスフォーメーション）を実現するためのソリューションガイドです。ぜひ、ご一読ください。 ダウンロード