モダナイゼーション10の罠｜3.サポート切れの罠

「サポート切れの罠」とは？

サポート切れを契機にレガシー化したシステムのモダナイゼーションやマイグレーションに着手する企業は多いと思います。しかしながら、古くから稼働している基幹システムは改修・機能追加による構築を繰り返した密結合となっている特徴もあわせ持ち、システムが次のような状態に陥っていることがあります。

1. あるソフトウェアをバージョンアップすると、関連システムが正常に動作しなくなるため、サポート切れした状態で使い続ける必要がある
2. ひとつのサポート切れ状態が、さらに関連するソフトウェアやOSのバージョンアップを阻む連鎖が起きている
3. 上記の1.2.を含め、サポート切れ状態、またはサポート切れ間近状態のソフトウェアやOSが積み重なって、いざモダナイゼーションを行おうとしたときに、多くの手間と時間、費用が必要となる

このような状態のシステムをモダナイゼーションする場合、対象システムおよび関連する周辺システムの影響調査と分析が十分に実施できないと、作業範囲が拡大し想定以上のコストや期間が必要となる場合があります。加えて作業期間中にサポート切れが発生する場合、提供先のサポートが得られない状況となり本番運用の品質リスクも高まります。これらを「サポート切れの罠」と呼びモダナイゼーション実行時の足枷となります。

実際に起こっている問題

メインフレーム、オープン系システムに問わず潜んでいる「サポート切れの罠」ですが、ここでは基幹システムがメインフレームで構成されている例でご説明します。メインフレームでは提供メーカー独自のOSやミドルウェアに依存する形でシステム構築を行っているといった特徴があります。基幹システム周辺に時流にあわせたサービスやソフトウェアの導入を検討したものの、連動する基幹システム側のプログラムが対応できず、周辺システムとの連動ができないために導入を断念したケースや最小の機能を手組みで開発したケースがあります。

例えば、取引先との通信に電子データ交換（EDI）システムを利用して構築されている場合、外部のデータを自社の基幹システムに取り込む際には、周辺システムであるEDIシステムとデータ授受を行ってフォーマット変換を行う処理などのプログラムも存在しています。この処理において、近年クラウドの利用が加速していく中で外部との通信の種類が増加しています。

それらの通信プロトコルに対応しようと計画をするものの、長年稼働している基幹システムにはレガシー言語（アセンブラ、COBOL、VBなど）で記述されたプログラムが多く、特にベンダー依存度が高いサポート切れ既存IT資産の場合「サポート切れのためベンダーから情報を取得できない」という事象に陥ることがあります。そうなると「どのようなサーバー、ストレージで構成されたシステムで稼働しているのか」「それぞれのアプリケーションにどのような依存関係があるのか」など現状を正確に把握することが難しく、トラブル時の原因究明や対応が困難になってしまうため、既存IT資産への影響が極小となるように手組みで最小機能のみを開発することを選択し、IT技術負債を先送りしていることがあります。

これでは時流に沿って実装しておくべきであった機能が抜け落ちている可能性があり、モダナイゼーションの本来の目的であるビジネスに寄与していくITを達成できないといった結果を招きます。

また、サポート切れのミドルウェアを利用していることで、テスト環境を新たに構築できずに現行保証で多大な労力をかけてテスト環境を構築するといった状況も発生します。

「サポート切れの罠」の乗り越え方

「サポート切れの罠」を乗り越えるためには、システムのマイグレーションやモダナイゼーションを行うにあたり、自社資産の棚卸が重要です。棚卸の際には、ソフトウェア、ミドルウェア、ハードウェア、OS、接続機器など、すべてのIT資産を対象に実施します。また、インターフェースやDB連携、使用ユーティリティなども含めて現行システム全体構成を明らかにし、システム・オーバービューなどで資産の関連性を整理・確認できる資料を作成します。

具体的には、サーバー稼働ログ収集とシステム運用状況をヒアリングして、IT資産のサーバー環境の概要で各サーバーの稼働状況（CPU使用率やネットワーク通信量、メモリ使用量）、各サーバー/システムの関係図やライフサイクル（稼働状況、EOSのタイムライン、リプレース時期）で明確にするとともに、アプリケーション可視化とあわせて実施することで自社資産の運用状況を明らかにでき、どの単位で影響がおよぶかを検討するための根拠資料となります。

図１ サーバー関係図とライフサイクル図

これらの関係性が明確にわかることで、例えば、サポート切れによって塩漬けする機能や既存活用すべき機能の選択をして、APIを活用して段階的にモダナイゼーションを進めていくことが可能となります。またサポート切れの予定とシステムの関連性が明確に整理されていることで、現実的なモダナイゼーション計画を立案するための材料とすることもできます。

図2 現実的なモダナイゼーション計画の可視化

このように、自社の資産について、サポート切れによって時流に乗り遅れた機能や今後サポート切れが見込まれる資産について可視化をしておくことで、目指すべきシステム・マイグレーションやモダナイゼーションの道筋を描けるようになります。

まとめ

ながらく使用してきたメインフレームのモダナイゼーションは、長丁場で根気強く対応していく必要があります。
単純なオープン化に留まらず、自社の経営戦略との整合性を保ったIT戦略を実行していくためにも構想の初手となる自社の現行資産の棚卸と構想策定をもれなくじっくりと検討することで時流に乗るための成功する確率を高めていくことができます。

本ブログでは、モダナイゼーションを進めるうえで陥りがちな10の罠について、IBMの経験に基づき、傾向と乗り越え方をシリーズでお伝えしております。今後の解説もご覧ください。

次の記事『モダナイゼーション10の罠｜4.パフォーマンスの罠