エコリクコラム

2025.2.27
トピック
システム担当が考えるEOLとレガシー問題の解決について
サーバーやOS、ソフトウェアなどのIT関連製品では、技術革新への対応や要望、セキュリティ対応などから定期的に製品の刷新やバージョンアップを行っています。
そのため、多くのIT関連製品を販売・提供している企業では、技術革新の早い商品についてEOS、EOE、EOLを設定していることが多いです。
EOS、EOE、EOLの違いについて
EOSは、End of Salesの略称であり意味は販売終了になります。
似たような言葉でEOA (End of Available)がありますが、こちらは価格表やカタログから商品が消えるという意味です。
EOAの場合は限定的な使用の場合購入できる可能性がありますが、EOSの場合は購入することができません。
EOEは、End of Engineeringの略称であり、EOS以降で、そのシステムなどの商品の修正や新機能の提供を行わないことです。ただし、サポートを継続することが多いです。
つまり、EOE期間がシステムの移行期間のデッドラインになります
EOLは、End Of Lifeの略称であり、メーカーによるサポートが終了することです。
EOLを迎えたシステム、商品を継続して使用する場合はリスクが生じます。
EOLリスクについて
想定されるリスクは3点です。
1点目はサービス停止のリスクです。
EOLを迎えた製品は、メーカーによる修理対応やサポートが終了し、システム停止などのトラブルに対応してもらえなくなります。
公式サポート以外で第三者にトラブル対応を依頼すると、修理対応ができない、完全に修理できない、時間がかかる、高額な費用がかかるなどが想定されます。
また、システムを動かすことが出来ていたとしても、不安定な運用になる、なっていく可能性もあり、業務が停滞する可能性があります。
2点目はセキュリティリスクです。
商品のサポートが終了した後はアップデートが停止されるため、新たに発見されたセキュリティでの脆弱性は修正されないため、ハッキングやデータ漏洩の可能性が高まります。
とくに、OSやアプリケーションは、セキュリティホールが放置されたままとなり、攻撃対象になりやすい状態です。マルウェア感染のリスクも高まり、システム全体の機能停止や業務継続が困難になる可能性があります。
セキュリティ面での情報漏えいは、企業の評判失墜、顧客離れ、法的責任など企業にとって大きな損失につながります。
3点目は生産性低下のリスクです。
EOLを迎えたシステムは、アップデートが提供されなくなるため、何か他のシステムと連携をしていた場合、パフォーマンスの低下、操作性の悪化、システム連携の不具合が発生しやすくなります。
システム連携での不具合などは、サポートが終了しているため、この対応は自社責任となります。
もし、システムが稼働しなくなった場合、復旧までに時間がかかる可能性が高く、生産性が低下するばかりか、事業の継続性にも大きな影響を与えかねません。
レガシーシステム問題
このEOLは多くの企業が抱えている問題です。
それは、多くの企業で「レガシーシステム」と呼ばれる旧来の技術で構築されたシステムを利用し続けているためです。
このレガシーシステムとは、過去の技術や仕組みで構築されている古いシステムのことで、主にメインフレームなどの基幹システムなどが多くの企業で運用をしています。
2018年経済産業省HPにて公開された「DXレポート ~ITシステム「2025年の崖」克服とDXの本格的な展開~」(※1)でもレガシーシステムの存在は問題視されており、日本全体でレガシーシステムからの脱却が必要とされています。
レガシーシステムからの脱却とその課題
(脱却方法)
レガシーシステムから脱却するための対策としては、「レガシーモダナイゼーション」と「レガシーマイグレーション」の2つの対策が挙げられることがあります
- レガシーモダナイゼーションは直訳すると「遺産の近代化」いう意味で、既存システムを活用しながら刷新する方法です。
既存システムの変えられる部分を中心に刷新していくため、ユーザーにとっては使用感が変わらずにレガシーシステムからの脱却が行えます。 - レガシーマイグレーションは直訳すると「遺産の移行」という意味で、既存システムを完全に置き換える方法です。
システムは最新の技術を活かして最適化され、より効率的な業務の実現が期待できますが、使用感が変わることもあるため、ユーザーの意見も取り入れながら移行を進める必要があります。
(課題と解決に向けて)
日本全体としては、レガシーシステムからの脱却の理解は高まってきていますが、依然として、システムを利用している企業では、仕様がブラックボックス化しているため手を付けにくい、現行踏襲への強いこだわりがあり進まない、ITを理解した人材が不足している、インフラを移行したことで落ち着いているように見えるなどの課題があります。
また、経営層においては喫緊性・必要性の認識欠如や、費用対効果や必要期間の理解不足などがあります。
特に基幹システムを大きく変更する場合は費用だけでなく開発スケジュールも長期にわたります。
一方、システム系のベンダー企業においても課題があります。
まず、プロジェクト難易度が高いことがあげられます。
レガシーシステムは独自システムを利用している、独自システムと既存のERPなどと連携しているなど仕様が様々あります。
そのため、ユーザー企業の経営のコミットメントとサポート、現場との協力関係構築が難しいことが多いです。
また求められる品質が高く、システム連携が多いため想定外のリスクも発生しやすいことがプロジェクトの難易度をあげています。
リスクヘッジのためにスモールスタートで進めたいベンダー企業が多いですが、理解を得られることが少ないです。
これらの課題の解決には、レガシーシステム状況を共通の課題として認識するとともに、企業側ではIT資産台帳の整備やシステム連携の把握、定期的な情報収集やベンダーとの交流が必要となります。
また、複雑なレガシーシステムの解明や設計に生成AIを導入する企業もあることからより一層の技術革新により省人化が進む領域でもあります。
ただ、どちらにしても高度な技術者は不足しており、技術スピードと技術者の育成のスピードが追いつかない問題があるため、外部のリソースを活用する企業も増えて来ています。