レガシーシステムのモダナイゼーションとマイグレーションはどうあるべきなのか：基幹業務のSoRはどこまでクラウド化できるのか（終）（1/2 ページ）

[皆川元, 徳山衛，日本アイ・ビー・エム株式会社]

　「基幹業務をはじめとする既存アプリケーションを、どのような観点でクラウドプラットフォームへ移行すべきか」を探る本連載「基幹業務のSoRはどこまでクラウド化できるのか」。これまで3回の連載では、基幹業務のクラウドにおける稼働に向けて、アーキテクチャ、移行、運用の観点で論じてきましたが、一方で、基幹業務がメインフレーム上で稼働している企業は多くあり、レガシーシステムとクラウドを組み合わせた「ハイブリッドIT」（※）の実現が必要です。今回は、その課題と対応について考察します。

※ハイブリッドIT：クラウドコンピューティングと従来型のコンピューティングの両方のスタイルを使って、全てのITサービス（IT部門と社外プロバイダーが提供するサービスを含む）を提供する（詳細は連載第1回参照）

レガシーシステムとは

　情報システムの導入の歴史は人手作業の効率化、自動化から始まりましたが、近年ではITのサポートによりビジネスの成長性を実現する傾向が強まっています。

　分散コンピューティングの発展と普及に伴い、長い歴史を持つメインフレームとその上で稼働する情報システムが「レガシーシステム」と呼ばれるようになりました。「レガシー」（遺産）には、「システムが旧式／旧型であるため、最新のビジネスモデルに対応しにくい」というネガティブなニュアンスが込められています。一方で、企業のビジネス活動を数十年にわたって支え続けている基幹システムは、世代を超えて受け継いだ「IT資産」としての価値を持っていることも見過ごせません。

　近年、ビジネスニーズの変化に対応が困難な情報システムは「技術的負債（Technical Debt）」と呼ばれるようになっています（※1）。技術的負債に関する国際的なカンファレンス「International Workshop on Managing Technical Debt（MTD）」は、2010年のピッツバーグでの第1回開催以後、毎年開催されています。2016年には、技術的負債の分析に絞ったカンファレンス「International Workshop on Technical Debt Analytics（TDA）」も開催されました。

※1：Philippe Kruchten et al., Technical Debt: From Metaphor to Theory and Practice, IEEE Software, Vol. 29, No. 6, pp.18-21

　技術的負債に関する議論もありますが、本稿では、経年劣化により拡張性や保守性に問題を抱えるシステムを、慣例に従って「レガシーシステム」と呼ぶことにします。

　やや古いデータになりますが、図1に示すように、約20％の企業が新規システム構築に取り組む一方、残りの企業はシステム再構築と従来システム運用に取り組んでいる、という経済産業省の調査結果があります。後者に相当する約80％の企業の取り組み対象にレガシーシステムも含まれると考えられることから、今回のテーマが注目に値することが分かると思います。

図1　情報システムの取り組み状況（出典：平成25年情報処理実態調査報告書, 経済産業省、2014年5月）

レガシーシステムの課題

　レガシーシステムの典型的な課題は、本連載第1回で以下の3点にあるとまとめました。

1. 利用技術の老朽化
2. システムの肥大化、複雑化
3. ブラックボックス化

　上述の課題を単純化していうと、「ビジネスニーズへの対応が困難であり、そのため機能拡張や保守に多大な時間と費用を要する」ということになります。実際には、複数の側面での課題が複合的に絡んでいます。レガシーシステムの典型的な課題を、テクノロジー、人、アプリケーション資産の3つの視点で表1に整理してみました。なお、対策はここに例として挙げたもの以外にもいろいろあると思います。

表1-1　レガシーシステムの課題（テクノロジー）

No.	課題	具体例	対策例
T1	ベンダー製品（ハードウェア、ソフトウェア）の継続使用に伴うリスクが、時間の経過とともに高くなる	・該当のプラットフォームに対する投資をベンダーが止めており、将来性がない ・使用中の製品がサポート切れを控えている	・多くの企業で使われており、将来の存続が期待できる製品への移行を検討する ・特別なサポート契約を締結する
T2	マイナーな製品を使っている	・ユーザー数が少なく、採算性が悪いため、ベンダーがライセンス費用を値上げする ・市場が小さいため、他製品への移行ソリューションが存在しない	より多くの企業で使われている製品への移行を検討する
T3	クローズドな旧世代のテクノロジーで現行システムを実装しているため、最新のテクノロジーを適用することができない	OSおよびミドルウェアが業界標準に十分に対応していないため、他プラットフォームとの間で相互運用性（interoperability）や移植性（portability）が実現できない	オープンシステムの要件を満たすプラットフォームへの移行を検討する

表1-2　レガシーシステムの課題（アプリケーション資産）

No.	課題	具体例	対策例
A1	現行システムのドキュメント整備が不十分なため、機能拡張も再構築も困難である	新システム稼働直後は最新状態だったが、保守に入って体制縮小したため、プログラムやデータの修正で手いっぱい。ドキュメントを更新する余裕がない	・SaaS利用への切り替えや、パッケージソフトウェアの導入を検討する ・あるいは、現状のまま保守を継続せざるを得ないと判断する
A2	長年の保守の間にソースコードが肥大／複雑化し、保守が困難になる場合がある	他メンバーが書いたソースコードに手を入れるとき、ロジック全体を理解する余裕がないため、正常に稼働中の現行ロジックを残しつつ迂回し、修正ロジックを追加する	・構成管理ツールを導入し、過去のソースも閲覧できるようにする ・定常的なアプリケーション保守作業にリファクタリングを組み込む
A3	ある変更要求に対して、修正が必要な箇所とテストが必要な範囲を特定するのが難しい	・小さな変更でも、本番リリースまでに1カ月以上かかる ・影響調査を人手で行うため、手間と時間がかかるだけではなく、調査漏れがあるとエラーや誤作動などのトラブルにつながる	プログラム構造やデータフローを分析するツールや手順の整備により、影響調査の効率化を図る

表1-3　レガシーシステムの課題（人）

No.	課題	具体例	対策例
P1	属人的な体制で現行システムを保守しており、メンバーの高齢化による引退が近い	ドキュメントがなく、プログラムのソースコードが唯一のよりどころであるため、属人的にならざるを得ない	プログラム構造やデータフローを分析するツールや手順の整備により、影響調査の効率化を図る
P2	必要スキルを保有するエンジニアが少なく、保守要員を調達するのが困難になる（T2に関連）	メインフレームのアセンブラーを読み書きできるエンジニアが少なくなり、現行システムの保守が困難になる	より開発者人口が多いプログラミング言語による実装し直しを検討する
P3	現行システムの保守に必要なスキル育成が困難である	・旧式テクノロジーの習得に対する若手社員のモチベーション向上が難しい ・若手社員の将来のキャリアを考えると、旧式テクノロジーを長期間経験させることができない	若手社員には、SoEシステムの開発をフルライフサイクルで経験した後、SoRの開発保守を担当させる
P4	現行システムの保守メンバーは、業務を知らず、要件定義や設計の体験がないため、再構築プロジェクトの体制を組めない	開発を経験せず保守を担当すると、プログラム内のコード値やフラグには詳しいが、該当システムの設計思想を理解せず、ユースケースまで想像力が及ばず、システム全体を見る視点を持つことができない	ビジネスプロセスが変わらなければ普遍的に通用する業務プロセスや概念データモデルなどを、社内の有識者が健在な内に整備し、体系的なナレッジの伝承を図る

　これらの課題は、いずれもIT部門にとっては深刻な問題や課題です。しかし、ビジネスや経営の視点で見ると、シェア拡大、売上増加、コスト削減のいずれにも（直接的には）関係せず、その改善の意義や必要性が理解されにくいため、厄介です。

　上に挙げた中で最も根が深く、解決が難しいのが、人に関わる課題ではないでしょうか。長年稼働している基幹システムがビジネス上重要であるが故に、多くの人材が現行システムの保守を担当することになります。結果的に表1-3のP4のような組織的、構造的な問題を抱えてしまうジレンマを伴います。

　また、上記の課題は必ずしもメインフレームに限ったものではなく、分散系のプラットフォーム上で稼働する情報システムに見られるものもあります。比較的歴史が浅いJava EEでも、2000年代前半に構築されたシステムが稼働後10年を超えており、メインフレームが経験したようなアプリケーション資産の経年劣化の問題に直面するケースが増えています。

システムのライフサイクルにおけるモダナイゼーションの位置付け

　ITシステムは、画面やDBにデータ項目を追加するような小改善から、システム全体の作り直しまで、レベルはさまざまですが、稼働開始後も継続的に進化を続けます。図2の出典元では、3つのカテゴリーでシステムのライフサイクルを捉えています。

• 保守：システムに対してインクリメンタルに変更を加えるプロセス
• モダナイゼーション：保守と比較すると、より広範なシステムの拡張、変更を伴う
• リプレース：保守やモダナイゼーションでは、ビジネスニーズの変化に対応し切れなくなったとき、システム全体を再構築やパッケージ導入などにより、全く新しいものに置き換える

図2　情報システムのライフサイクル（出典：Santiago Comella-Dorda et al., Technical Note：A Survey of Legacy System Modernization Approaches, Software Engineering Institute (SEI), Carnegie Mellon University (CMU), April 2000）

　モダナイゼーション実施に当たって、どのレベルで現行システムを理解するかにより、「ホワイトボックスモダナイゼーション」「ブラックボックスモダナイゼーション」に分類されます。

　前者は、システム内部の実装の理解を前提とします。例えば、ソースコード解析ツールを活用してプログラム構造を理解し、リファクタリングにより改善する場合がホワイトボックスモダナイゼーションに該当します。

　後者は、システムの外部仕様、すなわち入力と出力の解析に基づき、モダナイゼーションを実施します。レガシーマイグレーションは、現新照合テストによって機能検証を行うため、ブラックボックスモダナイゼーションに該当します。

　モダナイゼーションは、システムのどの部分を拡張、変更するかによって、多様なバリエーションがあります。従来ある下記のようなアプローチに加えて、本連載第2回で示したような、API化やマイクロサービスも増える傾向にあります。

• エミュレーターベースのCUI（Character User Interface）のWeb化
• 稼働するプラットフォームをメインフレームからサーバにリホストするレガシーマイグレーション

　重要なのは、現行システムが抱える課題に対して、適切なアプローチを選択して解決を図ることです。例えば、表1-2のアプリケーション資産の課題A2「長年の保守の間にソースコードが肥大／複雑化し、保守が困難になる場合がある」を考えてみましょう。

　仮にレガシーマイグレーションによってサーバ環境に移行したとしても、ソースコードの複雑さは解消せず、本質的な解決にはなりません。しかし、サーバ環境への移行により、メインフレームの計算機資源の消費を気にする必要がなくなり、統合開発環境を活用して対話的なデバッグが可能になるならば、日々のアプリケーション保守業務にリファクタリングを組み込むことで、問題の解決に向けた準備ができることになります。

　一方で、メインフレーム上のプログラミング言語が使える統合開発環境やテスト環境を活用することにより、メインフレームを残したまま問題の解決を図るアプローチも考えられます。