第2回 旧料金システムの終活｜公益業界におけるプラットフォームの現状と方向性

記事をシェアする:

連載「公益業界におけるプラットフォームの現状と方向性」

第2回 旧料金システムの終活

数10年間稼働しているシステムの今後を検討する場合、メーカーが提供するハードウェア・サポートの有無は大きな判断材料となります。メーカーのハードウェア・サポートが終了する（終了が予定されている）場合は、新システムへの移行を余儀なくされます。明確なサポート終了年月が発表されていない場合にも、メーカーの対象機器（シリーズ）に対する投資が縮小されているような場合には、他のプラットフォームへの移行を検討した方が良いかもしれません。この場合には「旧料金システムの終活 ≒ ハードウェアの終活」という式が成り立ちます。

同時に「旧料金システム ⊂ ハードウェア上で稼働する業務システム」という式が成り立ちますから、該当ハードウェアで稼働する業務システムの棚卸が必要になります。公益業界においては古くからメインフレームを活用されているケースが多く、メインフレーム上で稼働しているアプリケーションも多岐にわたります。ソースコードの規模や複雑度、他システムとの連携機能の数や複雑性等判断する情報はいろいろ存在しますが、業務特性による分類（下図）も提供業務整理の取り組み方法の一つです。

採用するプラットフォームやアーキテクチャーの判断には、求められるスピードや利用者、継続的な更新の必要性等様々な要因を含めて検討する必要があります。下図は複数の要因を軸に適用業務を評価したイメージです。

アプリケーションの特性を評価した後は、適切な移行方法を検討する事になります。下表は代表的な移行方法を示したものです。

殆どのケースにおいて、「旧料金システムの廃止（下図の1＆2）」が最も難易度が高い作業となりますから、旧料金システムの廃止のタイミングで該当ハードウェアの廃止（撤去によるランニングコストの抑止）を確実に実現する為のロードマップが必要になります。旧料金システムも必須となる主機能（下図1）とレポート作成等の副機能（下図2）に分類し、副機能は計画的に新システム等へ移行を進めておく事が必要です。また関連するシステム（下図3＆4）についても旧料金システムのロードマップと合わせて移行計画を立案します。メインフレーム上で稼働する料金システム以外のアプリケーション（下図5＆6）についても同様に移行計画及び廃止計画を策定します。

一方、ハードウェア及び保守サービスが今後も提供される場合は、終活のアプローチが若干異なります。例えば 「IBM Z」は1964年に誕生して、2022年4月には生誕58年を迎えますが、今後も継続して新しいモデルが提供される予定です。このようなケースにおいては、ハードウェアの廃止ではなく、最適化を検討する事になります。
対象アプリケーションの棚卸が必要なのは、前者と同様ですが、プラットフォーム移行を前提とするのではなく、残すという選択肢を加えて、最適解を探索する事になります。
2030年、2035年という断面で、何を残してどのような運用を行うのかをしっかり検討して、その為のロードマップを策定する事が終活には必要となります。単純にシステムを残すかどうかを判断するだけでなく、残すシステムの運用・保守を変革する意識が必要です。具体的には以下のような項目を検討する事になります。

• 稼働するアプリケーション及び機能
• システムの運用体制
• アプリケーションの保守
• コスト最適化（クラウド資源及びクラウド技術の活用）

現在ではメインフレームの環境においても最新技術を活用して、コスト削減を実現するソリューションが多く提供されています。例えば下図はIBM Zとクラウド・ストレージを連携させる事でコストを最適化する例です。

2030年以降の時点では利用可能なソリューションが増えている事は確実ですから、新技術（ソリューション）の採用検討をどのように実施するかを含めて計画を立てる事が重要です。下図は4つの視点でロードマップを策定したイメージ図です。10年後の利用可能技術は現時点で予測出来るものと大きく異なっている可能性が高いですから、ロードマップの定期的な見直しも必要です。次回はシステムの運用及びアプリケーションの保守に関する終活を整理したいと思います。

連載「公益業界におけるプラットフォームの現状と方向性」

第1回 統合か共存か、2種の料金システム
第3回 Z世代にバトンを渡す“システム運用”
第4回 “旧料金システム”のモダナイゼーション
第5回 モダナイゼーションの壁
第6回 クラウドサービスの活用
第7回 クラウド・サービスとオンプレミスの共存
第8回 適材適所コンピューティングへのアプローチ

エネルギー・公益事業テクノロジー・ソリューション