小川 翔太
日本アイ・ビー・エム株式会社
IBMコンサルティング事業本部
アプリケーション・アーキテクト
メインフレーム・モダナイゼーション担当
「レガシー技術の罠」とは？
時代の変化とともに、柔軟性や機動性といった現代の要請に対応することが困難になった技術をレガシー技術と呼びますが、モダナイゼーションにおいてはこれらの技術が困難な課題となることがあります。
例えば、レガシー技術の代表例ともいえるメインフレームのモダナイゼーションでは、既存アプリケーションを新規で設計・開発し置き換える「リアーキテクト：リビルド」、既存アプリケーションのソースコードを別の言語にコンバージョンする「リアーキテクト：言語変換」等を実施します。しかし、システムがブラックボックス化している、現行解析できるエンジニアがいない等の理由で、構築当時の設計思想を変えずに、メインフレームからクラウド環境/オープン環境へ単純移行すると、結果として、構想段階で策定したモダナイゼーションの目的が果たせないことになります。これを「レガシー技術の罠」と呼びます。
モダナイゼーションの目的としてアジリティーの向上を検討される企業は多いと思いますが、このアジリティーの向上には、システム間での影響が少ない疎結合状態になっていることが必要です。しかしながらメインフレームは密結合で実装されていることが多く、単純移行では目的を達成することができません。
メインフレームは1960年台以降に一気に広まり、その当時の設計思想で構築されたシステムが、今もなお基幹システム中心に稼働しています。それに加えて、各メインフレーム・ベンダー独自の言語やミドルウェア、また、ユーザー企業独自に開発されたアプリケーションも存在しています。メインフレームの設計思想は、効率性や整合性を重視した、密結合（モノリシック）アーキテクチャー、プロセス指向設計、バッチ中心処理などが挙げられますが、それに対して、現在では柔軟性や拡張性、開発スピード向上を重視した、疎結合（マイクロサービス）アーキテクチャー、オブジェクト指向設計、オンライン中心処理が一般的になっていると思います。
また使用しているデータベースにおいても、今はリレーショナル・データベースが主流ですが、メインフレームでは木構造で表した階層型データベース、親と子の関係が「多対多」となっているネットワーク型データベースを使用していることも多いです。
基幹システムをモダナイゼーションするウェーブ２においては、メインフレームで使用されている技術がユーザー企業毎に大きく異なるため、ユーザー企業に合わせた現状分析項目の洗い出し、移行計画の策定を行っていく必要があります。現状分析を行う際は、現行システムをよく把握している有識者、もしくは、設計書を頼りに行なっていきますが、メインフレームの場合は、構築されてから数十年経っているシステムも多く、有識者が既に退職している、設計書が作成されていない、または設計書はあるが最新の状態に更新されていないケースがあり、ブラックボックス化しているものも多いです。（参照『1.設計書の罠』）
また、メインフレームのエンジニア数は年々減少してきており、モダナイゼーションを検討する際に適切なエンジニアを見つけることが難しくなってきています。COBOLやPL/Iといった言語の開発エンジニアの減少についての記事を最近ではよく目にしますが、メインフレームは、COBOL言語だけではなく、OSやデータベースの制御機能等で使用されているアセンブラ言語、階層型データベースであるIMS等のDBMSも活用されており、これらの技術はCOBOL言語開発より技術難易度が高く、エンジニアを見つけるのがさらに困難です。
実際に起こっている問題・密結合状態のままでのモダナイゼーション
メインフレームのモダナイゼーションを進める上で、重要検討項目の１つとして疎結合化があります。メインフレームはハードウェアが⾼価な時代に、業務を機能単位で設計し、処理効率性を重視したプロセス設計により構築されてきました。複数のサブシステム間で、プログラムやデータを共通化しており、いわゆる密結合という状態になっているため、１つのサブシステムを修正する場合でも、他のサブシステムの影響調整が前提となります。既存システムの設計思想を変えずに、クラウド環境/オープン環境へ移行しても、結局、システム間のつながりの強い密結合という状態のままになってしまうため、開発スピードや柔軟性が向上することはありません。
図１ 密結合となっているシステム・イメージ
一方で、全てのシステムについて再設計を行うか？ということについては、時間、コストの観点から難しいと考える方が少なくないと思います。
「レガシー技術の罠」乗り越え方
今回は、レガシー技術の罠の中でもメインフレームの設計思想でよく用いられている密結合を題材に記載していますが、その乗り越え方についてご説明します。
まずは、現状のシステムについて、データベース、プログラム等がどれだけサブシステム間をまたがって連携しているかを把握するために結合度分析を実施します。結合度分析を実施する際は、弊社が保有している視覚化分析ツールADDI（IBM Application Discovery and Delivery Intelligence）を活用することにより、設計書や有識者に頼らない客観的な分析が可能となります。その上で、システム変更が多くアジリティーが求められるシステムの優先順位を確認することです。以下の図２のようなポートフォリオを作成することにより、分かりやすく整理することができます。
図2 ポートフォリオ（バブルの大きさはシステム規模を表しています）
疎結合化を検討する上では、全てのシステムを対象とするのではなく、柔軟性や迅速な開発・改修が特に求められるシステムを洗い出し、時間、コスト（投資対効果）の観点から優先順位をつけることが重要となります。
まとめ
メインフレームのモダナイゼーションの検討において、設計当時の設計思想を理解し、目的を達成するためには、どういった検討が必要なのかを分析・評価手法を含めて計画フェーズで漏れなく考える必要があります。加えて、メインフレーム・モダナイゼーションについては、規模の大きなプロジェクトになることが多くありますのでので、期間とコストが限られている中、モダナイゼーションの投資対効果を最大に引き出すための検討や段階的なロードマップも同時に考える必要があります。
本ブログでは、モダナイゼーションを進めるうえで陥りがちな10の罠について、IBMの経験に基づき、傾向と乗り越え方をシリーズでお伝えしております。今後の解説もぜひご覧ください。
次の記事『モダナイゼーション10の罠｜3.サポート切れの罠』を読む
