Loading article…
コンピューティングにおいて、レガシーシステムとは、古い方法、技術、コンピュータシステム、またはアプリケーションプログラムであり、「以前の、または時代遅れのコンピュータシステムに属する、またはそれに関連する、もしくはそれである」[ 1 ]ものの、依然として使用されているシステムを指します。システムを「レガシー」と呼ぶ場合、多くの場合、そのシステムが後続の標準の先駆けとなったことを意味します。これはまた、そのシステムが時代遅れであるか、交換が必要であることを示唆する場合もあります。
レガシーコードとは、標準的なハードウェアや環境ではもはやサポートされていない古いコンピュータソースコードであり、何らかの点で時代遅れであるか、時代遅れのものをサポートしているコードベースです。レガシーコードは、もはや現代的とはみなされないプログラミング言語で記述されていたり、フレームワークや外部ライブラリを使用していたり、アーキテクチャやパターンを使用していたりする可能性があり、コードベースを扱うソフトウェアエンジニアの精神的負担と習得時間が増加します。レガシーコードには、自動テストがまったくないか不十分な場合があり、リファクタリングが危険で、バグが発生する可能性が高くなります。[ 2 ]長期間使用されているコードは、ソフトウェアの腐敗の影響を受けやすく、実行環境や周囲のソフトウェアまたはハードウェアの変更により、動作を維持するために何らかのメンテナンスやエミュレーションが必要になる場合があります。レガシーコードは、レガシーハードウェア、別のレガシーシステム、または古い機能やソフトウェアバージョンを使用しているレガシー顧客をサポートするために存在している可能性があります。
この用語は通常ソースコードを指しますが、システムのあるバージョン以降では実行できなくなった、または実行するために互換性レイヤーを必要とする実行可能コードにも適用できます。例えば、macOS上ではネイティブに実行できないものの、Classic環境内で実行される従来のMacintoshアプリケーションや、Windows XPのWindows on Windows機能を使用してWindows XP上で実行されるWin16アプリケーションなどが挙げられます。
レガシーハードウェアの例としては、PS/2やVGAポートなどのレガシーポート、および（新しいオペレーティングシステムなどと互換性のない）古い命令セットを持つCPUが挙げられます。レガシーソフトウェアの例としては、Adobe Flashの.swfやLotus 1-2-3の.123などのレガシーファイル形式、およびEBCDICなどのレガシー文字エンコーディングでエンコードされたテキストファイルなどがあります。
レガシーという用語がコンピュータシステムを説明するために初めて使われたのは、おそらく1960年代でしょう。[ 3 ] 1980年代までには、既存のコンピュータシステムを新しいシステムの設計や実装と区別するために、レガシーという言葉が一般的に使われるようになりました。レガシーという言葉は、例えばレガシーシステムから新しいデータベースにデータを移行する際など、変換プロセス中によく耳にされました。
この用語は、一部のエンジニアがシステムが時代遅れだと感じていることを示唆するかもしれませんが、レガシーシステムはさまざまな理由で引き続き使用されることがあります。単に、そのシステムが依然としてユーザーのニーズを満たしているという場合もあります。さらに、古いシステムを維持するという決定は、投資収益率の課題やベンダーロックインなどの経済的な理由、変更管理の固有の課題、または機能性以外のさまざまな理由によって影響を受ける可能性があります。後方互換性（新しいシステムがレガシーファイル形式や文字エンコーディングを処理できる機能など）は、ソフトウェア開発者がしばしば作業に含める目標です。
レガシーシステムが使用されなくなったとしても、その歴史的役割ゆえに組織に影響を与え続ける可能性があります。過去のデータは新しいシステム形式に変換されておらず、カスタマイズされたスキーマクロスウォークを使用して新しいシステム内に存在している場合もあれば、データウェアハウスにのみ存在している場合もあります。いずれの場合も、ビジネスインテリジェンスや運用レポートへの影響は甚大になる可能性があります。レガシーシステムには、現在の状況ではもはや適切ではない手順や用語が含まれている場合があり、使用されている方法や技術の理解を妨げたり、混乱させたりする可能性があります。
組織がレガシーシステムを維持するのには、次のような説得力のある理由がある。
レガシーシステムは、いくつかの理由から、一部のソフトウェアエンジニアによって潜在的に問題のあるシステムだと考えられています。[ 4 ]
アプリケーションの廃止という方法でレガシーシステムを置き換えることが不可能な場合でも、それらを強化（または「再設計」）することは可能です。開発の大部分は、レガシーシステムに新しいインターフェースを追加することに費やされます。最もよく見られる手法は、端末ベースのメインフレームアプリケーションにWebベースのインターフェースを提供することです。これは、応答時間の遅延やマウスベースのオペレーター操作の遅延によりスタッフの生産性を低下させる可能性がありますが、インターフェースのスタイルが未熟練ユーザーにとって馴染み深く、使いやすいため、「アップグレード」と見なされることがよくあります。ジョン・マコーミックは、ミドルウェアを含むこのような戦略について論じています。[ 10 ]
印刷機能の改善は、従来のソフトウェアシステムでは書式設定命令が追加されていない、あるいは最新のPC/Windowsプリンターでは使用できないプロトコルを使用していることが多いため、困難を伴います。プリントサーバーを使用すれば、データを傍受してより現代的なコードに変換できます。従来のアプリケーションでリッチテキスト形式（RTF）またはPostScript形式のドキュメントを作成し、印刷前にPCで解釈することも可能です。
生体認証によるセキュリティ対策は、レガシーシステムへの実装が困難です。現実的な解決策としては、ユーザーとメインフレームの間にTelnetまたはHTTPプロキシサーバーを配置し、レガシーアプリケーションへの安全なアクセスを実現する方法があります。
一部の組織で実施されている変革は、完全なシステムを生成する自動化ビジネスプロセス（ABP）ソフトウェアへの移行です。これらのシステムは、組織の既存システムと連携し、既存システムをデータリポジトリとして利用できます。このアプローチには、多くの重要な利点があります。ユーザーは既存システムの非効率性から解放され、変更をABPソフトウェアに迅速かつ容易に組み込むことができます。
モデル駆動型のリバースエンジニアリングとフォワードエンジニアリングのアプローチは、レガシーソフトウェアの改善にも使用できます。[ 11 ]
アンドレアス・M・ハインは、ミュンヘン工科大学で宇宙探査におけるレガシーシステムの利用について研究した。ハインによれば、組織が検証、妥当性確認、テスト、運用履歴の能力を備えている場合、レガシーシステムは再利用に適している。[ 12 ] [ 13 ]これらの能力は、開発、実装、使用、保守など、さまざまなソフトウェアライフサイクルフェーズに統合されなければならない。ソフトウェアシステムにとって、システムの使用と保守の能力は極めて重要である。そうでなければ、システムはますます理解しにくく、保守しにくくなる。
ハイン氏によれば、検証、妥当性確認、試験、および運用履歴は、システムの信頼性と品質に対する信頼を高める。しかし、こうした履歴を蓄積するには費用がかかることが多い。NASAの現在は退役したスペースシャトル計画では、1970年代の技術が大量に使用されていた。飛行認証の要件が高額だったため、交換は費用的に不可能だった。オリジナルのハードウェアは、飛行に必要な高額な統合と認証要件を満たしていたが、新しい機器は、そのプロセス全体を再び経なければならなかった。この長くて詳細なプロセスでは、スペースシャトル計画で単一のユニットを使用する前に、新しい構成で新しいコンポーネントを広範囲にテストする必要があった。そのため、認証プロセスを開始した新しいシステムは、飛行が承認される頃には事実上のレガシーシステムになってしまう。
さらに、地上設備や打ち上げロケットを含むスペースシャトルシステム全体は、閉鎖システムとして連携して動作するように設計されていました。仕様が変更されなかったため、認証されたすべてのシステムとコンポーネントは、設計された役割において優れた性能を発揮しました。[ 14 ] シャトルが2010年に退役する予定だった以前から、NASAは、システムをアップグレードして新しいコンポーネントを再認証するよりも、1970年代の技術の多くの部分を使い続ける方が有利だと考えていました。
ソフトウェアエンジニアリングの中には、「レガシーコード」を時代遅れという意味合いなしに表現することを好む人もいます。最も一般的な中立的な概念としては、他の人から引き継いだソースコードや、ソフトウェアの古いバージョンから引き継いだソースコードなどがあります。Typemock の CEO である Eli Lopian 氏は、レガシーコードを「開発者が変更を恐れるコード」と定義しています。[ 15 ] Michael Feathers [ 16 ]氏は、レガシーコードをテストのないコードと定義しました。これは、レガシーコードが扱いにくいのは、自動回帰テストが不足しているためという見方を反映しています。彼はまた、レガシーコードをテスト対象にするための特性評価テストも定義しました。
ジニー・ヘンドリーは、コードの作成を、現在のプログラマーにとって「挑戦」であると表現し、「私たちの人生における他の遺産、つまり、大切にされ、愛情を込めて世代から世代へと受け継がれていく骨董品、家宝、物語のようなもの」となるコードを作成するように求めた。「もしレガシーコードが、私たちが誇りに思えるものだったらどうだろうか？」[ 17 ]
レガシーサポートという用語は、レガシーシステムと併せて用いられることが多い。この用語は、最新ソフトウェアの機能を指す場合もある。例えば、 「レガシーサポート」を備えたオペレーティングシステムは、古いハードウェアを検出して使用できる。また、この用語は、ビジネス機能を指す場合もある。例えば、古い製品のサポートやソフトウェア保守を提供するソフトウェアベンダーやハードウェアベンダーなどが挙げられる。
「レガシー製品」とは、販売が終了した製品、市場シェアを大幅に失った製品、あるいは現行モデルではない製品を指します。レガシー製品には、最新製品に比べて何らかの利点があり、顧客が使い続ける理由となる場合もあります。製品が真に「時代遅れ」となるのは、誰にとっても利点がなく、合理的な判断をする人が誰も新たに購入しようと思わない場合のみです。
「レガシーモード」という用語は、多くの場合、後方互換性を特に指します。以前のバージョンと同じように動作できるソフトウェア製品は、「レガシーモードで動作している」と言われます。このような機能は、多くのアプリケーションがこれらの基盤となるコンポーネントに依存しているオペレーティングシステムやWebブラウザでよく見られます。
コンピュータのメインフレーム時代には、多くのアプリケーションがレガシーモードで稼働していました。現代のビジネスコンピューティング環境では、n層アーキテクチャや3層アーキテクチャは、単一のシステムを構成するコンポーネントが多数含まれているため、レガシーモードに移行するのがより困難です。
仮想化技術は比較的新しい技術であり、古いオペレーティングシステムやブラウザを、古いハードウェアをエミュレートするソフトウェアシステム上で実行することで、既存のシステムを最新のハードウェア上で動作させ続けることを可能にする。
プログラマーは、ブラウンフィールドという用語を建設業界から借用しており、そこでは以前に開発された土地（多くの場合、汚染され放棄されている）がブラウンフィールドと呼ばれている。[ 18 ]
1999年のドットコムバブル崩壊以降、レガシーシステムとは単に稼働中のコンピュータシステムのことであるという、別の肯定的な見解も広まりつつある。
「レガシーコード」は、代替案と比べて、実際に動作し、拡張性がある点で異なる場合が多い。
ITアナリストは、システム障害やセキュリティ侵害のリスクを除外しても、ビジネスロジックの置き換えコストは再利用コストの約5倍になると推定している[ 19 ] 。理想的には、企業はコアビジネスロジックのほとんどを書き直す必要がない。借方＝貸方というのは、常に必要な要件である。
IT業界は、「レガシー近代化」と「レガシー変革」で対応しています。これは、既存のビジネスロジックを新しいユーザーインターフェースで刷新するもので、場合によってはスクリーン・スクレイピングやWebサービスを介したサービス対応アクセスを利用します。これらの技術により、組織は既存のコード資産を理解し（ディスカバリツールを使用）、既存のコードに新しいユーザーインターフェースとアプリケーションインターフェースを提供し、ワークフローを改善し、コストを抑え、リスクを最小限に抑え、従来のサービス品質（ほぼ100%の稼働率、セキュリティ、スケーラビリティなど）を享受できます。[ 20 ]
この傾向は、レガシーシステムがなぜこれほど長持ちするのかという問いにも向き合うきっかけを与えています。技術者たちは、コストとリスクの高い書き換えを避けるために、最初から健全なアーキテクチャを構築することの重要性を改めて認識し始めています。最も一般的なレガシーシステムは、綿密な計画と厳格な方法論に基づいて実装され、よく知られたITアーキテクチャの原則を採用している傾向があります。設計の不十分なシステムは、摩耗するだけでなく、固有の欠陥によって交換が必要になるため、長持ちしません。そのため、多くの組織が、レガシーシステムとその理論的基盤の両方の価値を再認識し始めています。
ウィキメディア・コモンズにあるレガシーシステム関連のメディア