ソフトウェアの近代化

ソフトウェアの近代化には、さまざまな推進要因と戦略があります。

• アーキテクチャ主導型近代化（ADM）とは、既存システムのビューを標準化することで、コード分析や理解、ソフトウェア変革といった共通の近代化活動を可能にするための取り組みである。
• ビジネス重視のアプローチ：近代化戦略は、近代化によって付加されるビジネス価値と結びついています。これは、アプリケーションのビジネスに対する重要性と技術的な品質の交点を定義することを意味します。^{[ 1 ]}ガートナーが推進するこのアプローチでは、アプリケーションポートフォリオ分析（APA）をアプリケーションポートフォリオの近代化決定の前提条件とし、ソフトウェアの健全性、リスク、複雑性、コストを測定して、アプリケーションの強みと弱みについての洞察を提供します。^{[ 5 ]}
• モデル駆動型エンジニアリング(MDE) は、ソフトウェア コードのリバース エンジニアリングとフォワード エンジニアリングのアプローチとして研究されています。 ^{[ 6 ] [ 7 ] [ 8 ]}
• ルネッサンス^{[ 9 ]}技術、ビジネス、組織の観点からレガシーシステムを反復的に評価する方法。
• WMU（保証、保守、アップグレード）は、目標とする顧客満足度レベルとそれに対する影響に基づいて適切な保守戦略を選択するためのモデルです。^{[ 10 ] [ 11 ]}

ソフトウェアの近代化^{[ 12 ]}は、複数のステークホルダーが関わる、リスクが高く、困難で、長期にわたる、高度な知的プロセスです。ソフトウェアの近代化タスクは、オブジェクト管理グループ のモデル駆動型アーキテクチャに関連するさまざまなツールや、 ISO/IEC 14764:2006やサービス指向移行および再利用技術（SMART）などのプロセスによってサポートされています。 ^{[ 13 ]}ソフトウェアの近代化には、専門知識を持つ労働者によって実行されるさまざまな手動および自動化されたタスクが含まれます。ツールはプロジェクト参加者のタスクをサポートし、コラボレーションと作業の順序付けを整理するのに役立ちます。

リスク（技術的目標とビジネス目標の両方）を明示的に考慮に入れた一般的なソフトウェア近代化管理アプローチ^{[ 14 ]は、以下の要素から構成される。}

• 既存ポートフォリオの分析：技術的品質とビジネス価値の測定。技術的品質とビジネス目標を照らし合わせ、適切な戦略（置き換え、不採用、優先度低、有望候補）を策定する。
• 利害関係者を特定する：ソフトウェアの近代化に関わるすべての人：開発者、テスター、顧客、エンドユーザー、アーキテクト、…
• 要件を理解する：要件は、ユーザー、システム、制約、非機能要件の4つのカテゴリに分類されます。
• ビジネスケースを作成する：ビジネスケースは、意思決定者がさまざまなアプローチを検討する際に、意思決定プロセスを支援するものです。
• 近代化対象システムを理解する：これは非常に重要なステップです。ソフトウェアのドキュメントは最新の状態に保たれていることが少なく、プロジェクトは社内外の多数のチームによって作成され、長期間にわたって関係者の目に触れないことが多いためです。アプリケーションの内容とアーキテクチャ設計を抽出することで、システムについて理解を深めることができます。
• 対象技術を理解し評価する：これにより、要件や既存システムに対して、技術や機能を比較検討することが可能になります。
• 近代化戦略を定義する: ^{[ 15 ]}この戦略は変革プロセスを定義します。この戦略は、近代化プロセス中に発生する変化 (技術の変化、追加の知識、要件の進化) に対応する必要があります。
• 戦略とステークホルダーのニーズを調和させる：潜在的なステークホルダーは、何が重要で、どのような進め方が最善かについて、それぞれ異なる意見を持っている可能性がある。ステークホルダー間で合意を得ることが重要である。
• 資源の見積もり：これまでの手順が明確になれば、コストを評価できます。これにより、経営陣は利用可能な資源と制約を考慮した上で、近代化戦略が実現可能かどうかを判断できます。

• Softcalc（Sneed、1995a）は、COCOMOとFPAに基づいて開発された、入ってくる保守依頼のコストを見積もるためのモデルおよびツールです。
• EMEE（早期保守作業量見積もり）^{[ 16 ] [ 17 ]}は、実際の保守を開始する前に保守作業量を迅速に見積もるための新しいアプローチです。
• RENAISSANCEは、まずリエンジニアリングを使用して安定した基盤を回復し、その後、一連の漸進的な変更によってシステムを継続的に改善することで、システムの進化をサポートする手法です。このアプローチは、さまざまなプロジェクト管理プロセスとうまく統合されています^{[ 18 ]。}

レガシーシステムの主な問題点としては、ドキュメントが不足している非常に古いシステム、レガシーシステムに関する専門家や知識の不足、レガシーシステムが実装された技術スキルの不足などが挙げられます。^{[ 19 ]}典型的なレガシーシステムは20年以上前から存在しています。移行には多くの課題が伴います。

• 大規模なアプリケーションポートフォリオ全体における可視性の欠如 – 大規模なIT組織は、数百、場合によっては数千ものソフトウェアシステムを抱えています。技術と機能に関する知識は、本質的に分散し、希薄化し、不透明になっています。経営陣やエンタープライズアーキテクトにとって、これらのシステムに関する必要な定量的および定性的なデータがなければ、ソフトウェアシステムの近代化に関する意思決定を行うことは困難です。
• 組織変革管理 – ユーザーは、新しいアプリケーションやプラットフォームを効果的に使用し理解できるよう、再訓練を受け、必要なツールを提供される必要がある。
• レガシーシステムと新システムの共存 – レガシーシステムのフットプリントが大きい組織は、一度にすべて移行することはできません。段階的な近代化アプローチを採用する必要があります。しかし、これには、十分に理解され実装された重複機能による完全なビジネスカバレッジの提供、データの重複、中間段階で必要となるレガシーシステムと新システムをつなぐための使い捨てシステムなど、独自の課題があります。^{[ 20 ]}
• 構造品質の管理が不十分なため（ソフトウェア品質を参照）、最新化されたアプリケーションは、元のシステムよりもセキュリティ、信頼性、パフォーマンス、保守性に関する問題が多く発生する。
• 近代化にかかる費用と期間が相当なものになる可能性がある - 複雑でミッションクリティカルなレガシーシステムの近代化には多額の投資が必要になる場合があり、完全に稼働する近代化されたシステムが稼働するまでには数年かかる可能性があり、その過程で予期せぬ不確実性が発生する可能性も無視できません。
• ステークホルダーのコミットメント - 近代化への投資は、投資コストに見合うだけのメリットや即時の投資対効果が得られない可能性があるため、主要な組織ステークホルダーは、近代化への投資に納得する必要があります。
• ソフトウェア構成 – 2010 年以降に構築されたもので、開発者が 100% オリジナルのコードを作成することは、今日では非常にまれです。^{[ 21 ]}効率性、スピード、再利用性を得るために、サードパーティやオープンソースのフレームワークやソフトウェア コンポーネントを使用することがよくあります。これにより、次の 2 つのリスクが発生します。1) サードパーティ コード内の脆弱性、2) オープンソース ライセンスのリスク。

最後に、近代化において万能な解決策は存在しません。近代化には数多くの商用および特注の選択肢があるため、顧客、販売者、および実施者は、さまざまな近代化手法の複雑さ、最適な実装方法、特定の状況における適合性、および適切な近代化アプローチを選択する前に従うべきベストプラクティスを理解することが不可欠です。

長年にわたり、レガシーシステムの近代化にはさまざまな選択肢が登場し、それぞれ成功度や普及状況は異なってきました。現在でも、以下に説明するように、さまざまな可能性があり、すべてのレガシーシステム変革イニシアチブにとって「唯一の選択肢」は存在しません。

• アプリケーション評価：ソフトウェアインテリジェンスを使用して既存のアプリケーションポートフォリオのベースラインを設定し、ソフトウェアの健全性、品質、構成、複雑性、クラウド対応状況を把握することで、さまざまな近代化オプションに向けてアプリケーションのセグメンテーションと優先順位付けを開始します。
• アプリケーションの発見：アプリケーションのコンポーネントは密接に絡み合っているため、ソフトウェアコンポーネントの複雑さを理解し、相互依存関係を解決する必要がある。
• 移行：言語（3GLまたは4GL）、データベース（レガシーシステムからRDBMS、およびあるRDBMSから別のRDBMS）、プラットフォーム（あるOSから別のOS）の移行。多くの場合、効率性を高めるために自動コンバーターやプログラム変換システムが使用されます。これは、レガシーシステムを迅速かつ費用対効果の高い方法で変換する手段です。
• クラウド移行：レガシーアプリケーションをクラウドプラットフォームに移行すること。多くの場合、ガートナーの5Rメソッドなどの方法論を使用して、アプリケーションを異なるモデル（リホスト、リファクタリング、改訂、再構築、置換）に分類し、優先順位付けします。
• リエンジニアリング：レガシーアプリケーションを新しいテクノロジーまたはプラットフォームで再構築し、同じ機能または強化された機能を実現する手法。通常はサービス指向アーキテクチャ（SOA）を採用します。これは、レガシーアプリケーションを変革する最も効率的で俊敏な方法です。^{[ 6 ]}これには、よく知られていない、または文書化されていないレガシーシステムに対するアプリケーションレベルのソフトウェアインテリジェンスが必要です。
• リホスティング：レガシーアプリケーションを大きな変更を加えることなく、別のプラットフォームで実行します。アプリケーションとデータがオープン環境に移行される際に、ビジネスロジックは保持されます。このオプションでは、ミドルウェア、ハードウェア、オペレーティングシステム、データベースの交換のみが必要です。 ^{[ 22 ]}これは、レガシーで高価なハードウェアを排除するための中間ステップとしてよく使用されます。最も一般的な例としては、メインフレームアプリケーションをUNIXまたはWintelプラットフォームでリホストすることが挙げられます。
• パッケージ実装: ERP、CRM、SCM、請求ソフトウェアなどの市販ソフトウェア (COTS) で、レガシーアプリケーションを全体または一部置き換えること^{[ 23 ]}

レガシーコードとは、メインフレームなどの古い技術やハードウェアに基づいて構築され、組織の中核サービスを提供し続けているアプリケーションのことです。レガシーアプリケーションは規模が大きく、変更が困難な場合が多く、それらを廃止または置き換えるには、組織の業務プロセスを再設計する必要が生じることも少なくありません。しかし、 Javaなどのいわゆる最新言語で書かれたアプリケーションも、レガシー化が進んでいます。COBOLなどの「レガシー」言語がレガシーの代表例とされる一方で、新しい言語で書かれたソフトウェアも同様に巨大で変更が困難な場合があり、そのため近代化プロジェクトの対象となる可能性があります。

このようにアプリケーションを新しいプラットフォームに再実装することで、運用コストを削減でき、新しいテクノロジーの追加機能により、Web サービスや統合開発環境などの機能にアクセスできます。^{[ 7 ]}変換が完了し、機能的に同等になった後は、変換されたアプリケーションに新しい機能を追加することで、アプリケーションを現在および将来のビジネスニーズにより密接に合わせることができます。ソフトウェア近代化企業によるプログラム変換などの新しいテクノロジーの最近の開発により、レガシー変換プロセスは、レガシー投資を維持し、それによってまったく新しいソフトウェアへの移行に伴うコストとビジネスへの影響を回避するための費用対効果が高く正確な方法になりました。

レガシーシステムの変革の目的は、新しいプラットフォーム上で既存資産の価値を維持することです。実際には、この変革は様々な形態をとります。例えば、ソースコードの翻訳、既存コードの再利用、そしてビジネスに必要な顧客アクセスを提供するためのWeb-to-host機能の実装などが考えられます。書き換えが必要な場合は、既存のビジネスルールを抽出して、書き換え要件定義書の一部として活用できます。

今日の技術の進化により、一部の企業やグループはレガシーシステムの重要性を認識していません。その機能の中には、使用せずに放置するには重要すぎるものや、再作成するにはコストがかかりすぎるものがあります。ソフトウェア業界と研究者は、生産性を向上させ、市場投入までの時間を短縮するために、コンポーネントベースのソフトウェア開発に最近注目しています。^{[ 25 ]}

一般的に、レガシーシステムの近代化において関心のある情報システム技術は、次の 3 つのクラスに分類されます。 言語やデータベース システムなど、レガシー システムの構築に使用された技術。 数十年前の技術に囚われている人々にとって理想郷となることが多い最新技術。強力で効果的、かつ保守が容易なエンタープライズ情報システムという (しばしば実現されない) 約束を掲げています。 レガシー システム ベンダーが提供する技術。これらの技術は、最新の IT 製品の波に飛び込むには臆病すぎる、あるいは賢明すぎる人々のためのアップグレード パスを提供します。レガシー システム ベンダーがこれらの技術を提供する理由は単純です。それは、「メインフレームの子宮」の快適さから離れる必要のないシステム近代化のためのアップグレード パスを提供することです。これらの技術は、最新のシステムへのよりスムーズな道筋を提供できますが、多くの場合、理想には及ばないものの許容できるソリューションとなります。^{[ 26 ]}