レガシーシステム

コンピューティングにおいて、レガシーシステムとは、古い方法、技術、コンピュータシステム、またはアプリケーションプログラムであり、「以前のまたは時代遅れのコンピュータシステムに関連する、またはそれである」ものの、^[1]現在も使用されている。多くの場合、あるシステムを「レガシー」と呼ぶことは、そのシステムがその後の標準への道を開いたことを意味する。これは、システムが時代遅れであるか、交換が必要であることを意味する場合もある。

レガシーコードとは、標準的なハードウェアや環境ではサポートされなくなった古いコンピュータソースコードであり、何らかの点で時代遅れになっているか、時代遅れのものをサポートしているコードベースです。レガシーコードは、もはや最新とは見なされないプログラミング言語で書かれていたり、フレームワークや外部ライブラリを使用したり、アーキテクチャやパターンを使用したりすることがあり、コードベースで作業するソフトウェアエンジニアの精神的負担と立ち上げ時間が増加します。レガシーコードには自動テストがまったくないか不十分な場合があり、リファクタリングが危険でバグが発生する可能性が高くなります。^[2]長期間使用されているコードはソフトウェア腐敗の影響を受けやすく、ランタイム環境や周囲のソフトウェアやハードウェアに変更があった場合、動作を継続するために何らかのメンテナンスやエミュレーションが必要になることがあります。レガシーコードは、レガシーハードウェア、別のレガシーシステム、または古い機能やソフトウェアバージョンを使用しているレガシー顧客をサポートするために存在している場合があります。

この用語は通常ソース コードを指しますが、システムの新しいバージョンでは実行できなくなった実行可能コード、または実行するために互換性レイヤーを必要とする実行可能コードにも適用されます。例としては、 macOSではネイティブに実行されないがClassic 環境内で実行されるクラシックMacintoshアプリケーションや、 XP のWindows on Windows機能を使用してWindows XPで実行されるWin16アプリケーションなどがあります。

レガシー ハードウェアの例としては、 PS/2 ポートや VGA ポートなどのレガシー ポート、および古くて互換性のない命令セット(新しいオペレーティング システムなど)を備えた CPU が挙げられます。レガシー ソフトウェアの例としては、 Adobe Flashの.swfやLotus 1-2-3の .123 などのレガシー ファイル形式、EBCDICなどのレガシー文字エンコーディングでエンコードされたテキスト ファイルなどがあります。

レガシーという用語がコンピュータシステムを説明するために初めて使われたのは、おそらく1960年代です。^[3] 1980年代には、既存のコンピュータシステムを新しいシステムの設計や実装と区別するために、レガシーという言葉が一般的に使われるようになりました。レガシーは、たとえば、レガシーシステムから新しいデータベースにデータを移動するときなど、変換プロセス中によく聞かれました。

この用語は、一部のエンジニアがシステムが時代遅れだと感じていることを示唆しているかもしれませんが、レガシー システムはさまざまな理由で引き続き使用できます。単に、システムが依然としてユーザーのニーズを満たしているだけかもしれません。さらに、古いシステムを維持するという決定は、投資収益率の課題やベンダー ロックインなどの経済的な理由、変更管理の固有の課題、または機能性以外のさまざまな理由によって影響を受ける可能性があります。下位互換性(新しいシステムがレガシーファイル形式や文字エンコーディングを処理できるかどうかなど) は、ソフトウェア開発者が作業に含める ことが多い目標です。

レガシー システムは使用されなくなったとしても、その歴史的役割により組織に影響を与え続ける可能性があります。 履歴データは新しいシステム形式に変換されていない可能性があり、カスタマイズされたスキーマクロスウォークを使用して新しいシステム内に存在するか、データ ウェアハウス内にのみ存在する可能性があります。 いずれの場合も、ビジネス インテリジェンスと運用レポートへの影響は大きくなります。 レガシー システムには、現在のコンテキストではもはや関連がない手順や用語が含まれている可能性があり、使用されている方法やテクノロジの理解を妨げたり混乱させたりする可能性があります。

組織がレガシー システムを維持するには、次のような正当な理由がある場合があります。

• システムはうまく機能しており、所有者はそれを変更する理由がないと考えています。
• システムが大きく、モノリシックで、複雑であるため、システムの再設計または交換にかかるコストは高額です。
• 新しいシステムでの再トレーニングは、それを置き換えることで期待される大きなメリット（ゼロの可能性もあります）と比較すると、時間と費用の損失が大きくなります。
• システムにはほぼ一定の可用性が求められるため、サービスを停止することはできず、同様の可用性レベルを持つ新しいシステムを設計するにはコストが高くなります。例としては、銀行の顧客口座を処理するシステム、コンピュータ予約システム、航空管制、エネルギー分配（電力網）、原子力発電所、軍事防衛施設、 TOPSデータベースなどのシステムなどがあります。
• システムの動作方法が十分に理解されていません。このような状況は、システムの設計者が組織を離れ、システムが十分に文書化されていないか、文書が紛失した場合に発生する可能性があります。
• ユーザーは、必要になったときにシステムを簡単に交換できることを期待しています。
• 新しいシステムは、(特に個人または非組織ユーザーにとって) 望ましくない二次機能を実行します。たとえば、a ) ユーザー アクティビティの追跡とレポート、および/またはb ) 自動更新により「バックドア」セキュリティの脆弱性が生じ、エンド ユーザーは更新を提供するベンダーの誠実さと正直さに頼らざるを得なくなります。この問題は、新しいシステムのこれらの二次機能を無効にできない場合に特に深刻です。

レガシーシステムは、いくつかの理由から、一部のソフトウェアエンジニアによって潜在的な問題を抱えていると考えられています。^[4]

• レガシーソフトウェアが旧式のハードウェアでのみ動作する場合、何らかのエミュレーションや下位互換性によってソフトウェアが新しいハードウェアで動作しない限り、システムを維持するためのコストが最終的にソフトウェアとハ​​ードウェアの両方を交換するコストを上回る可能性があります。^{[5] [6]}
• これらのシステムは、システムに対する一般的な理解が不足しているため、維持、改善、拡張が困難です。システムの専門家だったスタッフは退職したり、システムについて知っていたことを忘れたり、システムが「レガシー」になった後にこの分野に入ったスタッフは、そもそもシステムについて学んでいません。これは、ドキュメントの不足や紛失によって悪化する可能性があります。コムエア航空会社は、社内の誰も知らなかった制限に遭遇した時代遅れのレガシー乗務員スケジュールシステムの障害により、2004年にCEOを解雇しました。^[7]
• レガシーシステムでは、セキュリティパッチが利用または適用されていないために、古いオペレーティングシステムやアプリケーションに脆弱性が存在する可能性があります。また、セキュリティ上の問題を引き起こす運用構成が存在する可能性もあります。これらの問題により、レガシーシステムは攻撃者や知識のある内部関係者によって侵害されるリスクにさらされる可能性があります。^[8]
• 新しいソフトウェアではまったく異なるテクノロジが使用される可能性があるため、新しいシステムとの統合も難しい場合があります。テクノロジ間の統合はコンピューティングでは非常に一般的ですが、新しいテクノロジと大幅に古いテクノロジ間の統合は一般的ではありません。統合テクノロジの開発に対する需要が十分にないだけかもしれません。この「接着剤」コードの一部は、特定のレガシー テクノロジのベンダーや愛好家によって開発されることがあります。
• 予算の制約により、企業はレガシー システムの交換や移行の必要性に対処しないことがよくあります。しかし、企業はサポート コストの増加 (人​​、ソフトウェア、ハードウェアなど、前述のすべて) を考慮しないことが多く、レガシー システムに障害が発生した場合の機能やビジネス継続性の大きな損失も考慮しません。これらの考慮事項を十分に理解すると、実証済みの ROI に基づいて、新しい、より安全な更新されたテクノロジ スタック プラットフォームは、他の方法ほどコストがかからず、予算が見つかります。
• レガシープログラマーのほとんどが定年退職を迎えており、彼らに代わる若いエンジニアの数は非常に少ないため、労働力の不足が深刻化しています。その結果、レガシーシステムの維持が困難になり、経験豊富なプログラマーの調達コストが増加しています。^[9]
• 一部のレガシー システムでは、総容量に厳しい制限があり、今日のニーズには不十分な場合があります。たとえば、多くの古いx86 CPU の 4 GB のメモリ制限や、IPv4の40 億のアドレス制限などがその例です。

アプリケーション廃止の実践によってレガシー システムを置き換えることが不可能な場合でも、それらを強化 (または「再設計」) することは可能です。開発のほとんどは、レガシー システムに新しいインターフェイスを追加することに費やされます。最も顕著な手法は、ターミナル ベースのメインフレーム アプリケーションに Web ベースのインターフェイスを提供することです。これにより、応答時間が遅くなり、マウス ベースのオペレータ操作が遅くなるため、スタッフの生産性が低下する可能性がありますが、インターフェイス スタイルが未熟なユーザーにも馴染みがあり、使いやすいため、「アップグレード」と見なされることがよくあります。John McCormick は、ミドルウェアを含むこのような戦略について説明しています。^[10]

印刷機能の向上は、従来のソフトウェア システムでは書式設定の指示が追加されなかったり、最新の PC/Windows プリンタでは使用できないプロトコルが使用されていることが多いため、問題があります。プリント サーバーを使用してデータを傍受し、最新のコードに変換することができます。リッチ テキスト形式 (RTF)またはPostScriptドキュメントは、従来のアプリケーションで作成され、印刷前に PC で解釈される場合があります。

生体認証セキュリティ対策をレガシー システムに実装するのは困難です。実行可能な解決策としては、ユーザーとメインフレームの間にTelnetまたはHTTP プロキシ サーバーを配置して、レガシー アプリケーションへの安全なアクセスを実装することが挙げられます。

一部の組織で行われている変更は、完全なシステムを生成する自動ビジネス プロセス (ABP) ソフトウェアへの切り替えです。これらのシステムは、組織のレガシー システムとインターフェイスし、データ リポジトリとして使用できます。このアプローチには、いくつかの重要な利点があります。ユーザーはレガシー システムの非効率性から保護され、変更を ABP ソフトウェアにすばやく簡単に組み込むことができます。

モデル駆動型の リバースエンジニアリングとフォワードエンジニアリングのアプローチは、レガシーソフトウェアの改善にも使用できます。^[11]

アンドレアス・M・ハインはミュンヘン工科大学で宇宙探査におけるレガシーシステムの使用について研究しました。ハインによれば、組織が検証、妥当性確認、テスト、運用履歴の機能を備えている場合、レガシーシステムは再利用に魅力的です。^{[12] [13]}これらの機能は、開発、実装、使用、保守などのさまざまなソフトウェアライフサイクルフェーズに統合する必要があります。ソフトウェアシステムの場合、システムを使用および保守する機能は非常に重要です。そうしないと、システムはますます理解しにくく、保守しにくくなります。

Hein 氏によると、検証、妥当性確認、テスト、運用履歴により、システムの信頼性と品質に対する信頼が高まります。ただし、こうした履歴を蓄積するには、多くの場合、費用がかかります。NASA の現在は廃止されたスペース シャトルプログラムでは、1970 年代の技術が大量に使用されていました。飛行認証の要件が高額だったため、交換には費用がかかりすぎました。元のハードウェアは、飛行に必要な高額な統合と認証の要件を満たしていましたが、新しい機器はすべて、そのプロセス全体をもう一度やり直す必要がありました。この長くて詳細なプロセスでは、スペース シャトル プログラムで 1 つのユニットを使用する前に、新しい構成で新しいコンポーネントを徹底的にテストする必要がありました。したがって、認証プロセスを開始した新しいシステムは、飛行が承認されるまでに、 事実上のレガシー システムになります。

さらに、地上および打ち上げ機の資産を含むスペースシャトルシステム全体が、クローズドシステムとして連携して動作するように設計されていました。仕様が変更されなかったため、認定されたシステムとコンポーネントはすべて、設計された役割を十分に果たしました。^[14] シャトルが2010年に退役する予定になる前でさえ、NASAは、システムをアップグレードして新しいコンポーネントを再認定するよりも、1970年代の技術の多くを使い続ける方が有利であると判断しました。

ソフトウェアエンジニアリングの分野では、「レガシーコード」を時代遅れという意味合いを含まずに表現することを好む人もいます。最も一般的な中立的な概念には、他の誰かから継承したソースコードと、ソフトウェアの古いバージョンから継承したソースコードがあります。TypemockのCEOであるEli Lopianは、これを「開発者が変更を恐れるコード」と定義しています。^[15] Michael Feathers ^[16]は、テストのないコードとしてのレガシーコードの定義を導入しました。これは、自動化された回帰テストが不足していることもあって、レガシーコードの扱いが難しいという観点を反映しています。彼はまた、レガシーコードのテスト を開始するための特性評価テストを定義しました。

ジニー・ヘンドリーは、コードの作成を、現在のプログラマーにとって「挑戦」であり、「私たちの生活における他の遺産、つまり、大切にされ、世代から世代へと愛情を込めて受け継がれる骨董品、家宝、物語のような」コードを作成することであると特徴づけました。「レガシーコードが私たちが誇りに思うものだったらどうなるでしょうか?」^[17]

レガシー サポートという用語は、レガシー システムと組み合わせて使用​​されることがよくあります。この用語は、最新のソフトウェアの機能を指す場合があります。たとえば、 「レガシー サポート」を備えたオペレーティング システムは、古いハードウェアを検出して使用できます。この用語は、ビジネス機能を指すために使用される場合もあります。たとえば、古い製品をサポートしたり、ソフトウェア メンテナンスを提供しているソフトウェア ベンダーやハードウェア ベンダーなどです。

「レガシー」製品とは、販売されなくなった製品、市場シェアを大幅に失った製品、または最新ではないバージョンの製品です。レガシー製品は、最新製品よりも優れているため、顧客がそれを使い続けることに魅力を感じる場合があります。製品が本当に「時代遅れ」になるのは、誰にとっても利点がない場合、つまり合理的な判断をする人が誰もその製品を新品で購入しようとしない場合のみです。

「レガシー モード」という用語は、多くの場合、特に下位互換性を指します。以前のバージョンのように動作できるソフトウェア製品は、「レガシー モードで実行されている」と言われます。この種の機能は、多くのアプリケーションがこれらの基礎コンポーネントに依存しているオペレーティング システムやインターネット ブラウザーで一般的です。

コンピュータメインフレームの時代では、多くのアプリケーションがレガシー モードで実行されていました。現代のビジネス コンピューティング環境では、n 層または3 層 アーキテクチャは、単一のシステムを構成する多くのコンポーネントを含むため、レガシー モードに配置するのがより困難です。

仮想化テクノロジーは、レガシー ハードウェアをエミュレートするソフトウェア システム上で古いオペレーティング システムとブラウザーを実行することにより、レガシー システムを最新のハードウェア上で引き続き動作させることを可能にする最近のイノベーションです。

プログラマーは建設業界から「ブラウンフィールド」という用語を借用しており、建設業界では以前に開発された土地（多くの場合、汚染され、放棄された）がブラウンフィールドとして説明されている。^[18]

• ブラウンフィールド アーキテクチャは、レガシー システムを組み込んだソフトウェアまたはネットワーク アーキテクチャの一種です。
• ブラウンフィールド展開とは、レガシー コンポーネントを保持する既存のソフトウェアまたはネットワーク アーキテクチャへのアップグレードまたは追加です。

1999 年のドットコム バブルの終焉以来、レガシー システムとは単に実用的に使用されているコンピュータ システムであるという、別の好意的な意見が広まっています。

「レガシー コード」は、実際に機能し、拡張する点において、提案された代替コードとは異なる場合があります。

—  Bjarne Stroustrup、C++ の作成者

ITアナリストは、ビジネスロジックの置き換えにかかるコストは、システム障害やセキュリティ侵害のリスクを考慮しても、再利用の約5倍になると見積もっています^[19] 。理想的には、企業はコアビジネスロジックのほとんどを書き直す必要はなく、借方=貸方は永続的な要件です。

IT業界は「レガシーモダナイゼーション」と「レガシートランスフォーメーション」で対応しています。これは、スクリーンスクレイピングやWebサービス経由のサービス対応アクセスを使用して、既存のビジネスロジックを新しいユーザーインターフェイスで刷新することです。これらの技術により、組織は既存のコード資産を理解し（検出ツールを使用して）、既存のコードに新しいユーザーおよびアプリケーションインターフェイスを提供し、ワークフローを改善し、コストを抑え、リスクを最小限に抑え、従来のサービス品質（ほぼ100％の稼働時間、セキュリティ、スケーラビリティなど）を享受できます。^[20]

この傾向は、レガシー システムの耐久性を支えているものについても考えるきっかけとなります。技術者は、コストがかかりリスクの高い書き換えを避けるために、最初から健全なアーキテクチャの重要性を再認識しています。最も一般的なレガシー システムは、よく知られた IT アーキテクチャの原則を採用し、実装時に綿密な計画と厳格な方法論を採用したシステムです。設計が不十分なシステムは、摩耗するだけでなく、固有の欠陥によって交換が必要になるため、長持ちしないことがよくあります。そのため、多くの組織が、レガシー システムとそのシステムの理論的基盤の両方の価値を再発見しています。

• AM ハイン、「初期段階での遺産システムの評価方法」 SECESA 2014、2014 年 10 月 8 日～10 日、シュトゥットガルト大学、ドイツ
• 「レガシー ハードウェアのヒントとコツ」 2011 年 7 月 8 日にWayback Machineにアーカイブされました。著者: Danny Budzinski、Control Design Magazine、2011 年 1 月
• 「コムエアーのクリスマス大惨事：破綻必至」ステファニー・オーバービー著、CIO マガジン、2005 年 5 月 1 日
• 「デジタルコンピュータの失敗」アダム・N・ローゼンバーグ著
• Bisbal, J.; Lawless, D.; Wu, B.; Grimson, J. (1999). 「レガシー情報システム: 問題と方向性」. IEEE ソフトウェア. 16 (5): 103–111. doi :10.1109/52.795108.
• Jim McGee (2005-11-10)。「レガシー システム: 歴史が重要な理由」。Enterprise Systems Journal。
• 「レガシー システムの危険性」、Steve R. Smith 著、2011 年 5 月 3 日。

• ウィキメディア・コモンズのレガシーシステムに関連するメディア