第5回モダナイゼーションの壁｜公益業界におけるプラットフォームの現状と方向性

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

第5回公益業界におけるモダナイゼーションの壁

前回に続いて今回もモダナイゼーションについて整理したいと思います。モダナイゼーションを実現する上で、「サービス」と「データ」は大きなテーマ（下図参照）となることは前回も記載しましたが、それぞれのテーマにおいて現行システムの構成によっては障壁となるものが存在します。

図:取り組むべき２つのテーマ

まず「サービス（サービス指向）」について考えてみます。地域生活者を支えるエコシステムは下図のようなイメージになると想像してみて下さい。図はイメージを表したものであり、実現性及び採用技術等の検証を検討は行なっていません。

図:地域生活者を支えるエコシステム

地域生活者は生活インフラストラクチャー・サービスを利用して、エネルギーに関する様々な情報（契約内容、料金、使用量実績等）を照会します。一度の要求でエネルギーに関するすべての情報を取得するようなサービスを期待するかもしれません。電力・ガスだけでなく通信も含めて自分のライフスタイルに最も適したバンドル・サービスを検索することも考えられます。通信で使いきれなかったギガ（GB）を電力量に変換してエネルギー利用に活用するようなサービスも出現するかもしれません。

一方、バックエンドにおいては契約種別ごとに処理するシステムが異なるケースが存在します。

下図を参照下さい。上部にシンプルなケースを示しています。このケースでは利用するサービス（機能）が特定されれば連携するシステムも特定されます。公益業界におけるサービス指向の壁の一つは、同一の業務プロセスを処理するシステムが複数存在するケースがあることです。例えば、料金実績照会サービスを要求する場合を考えてみます。契約メニュー（契約種別）によっての処理を実施しているシステムが異なる場合には、サービス利用者に複数のバックエンド・システムの存在を意識させない工夫が必要となります。複数のシステムは構築された年代も様々であるため、利用されている技術も多種多様です。カスタム開発とCOTS（commercial off-the-shelf）が混在しているケースもあります。システム運用がまったく異なる可能性もあります。夜間バッチ処理中はオンライン更新処理が出来ないようなシステムも存在します。つまりサービス指向の壁として

• 同一業務プロセスに対して複数のシステムが存在
• 24時間365日対応が困難なシステムが存在

があります。この壁を克服するためには

• 複数のシステム（夜間対応を含む）をAPIオーケストレーションで論理的に統合
• 必要に応じて「夜間対応システム」を準備

というような対応を実施することになります。

図:サービス指向の壁

次に「データ（データ活用）」について考えてみます。

下図はデータ活用のフレームワークDIH（デジタル・インテグレーション・ハブ）を示しています。オープンソース・ベースの様々な接続部品を活用できるため、幅広いシステムにデータ連携可能です。データを一定期間キャッシュしていますので、利用したいシステムが利用したいタイミングで柔軟にデータを取得可能です。このフレームワークを活用すれば、例えば金融システムの勘定系データの更新ごとに、ほぼリアルタイムでクラウド環境等の自由な場所にデータを連携することが出来ます。

金融システムにおいては、犯罪防止等の目的でリアルタイムにトランザクションを監視する仕組が期待されており、イベントに対してアクションを行うサービスは今後も拡張すると予想されます。
この方式は勘定系に手を加えることなく様々な追加サービスに対応する仕組みだと言えます。

図:デジタル・インテグレーション・ハブ（DIH）

DIH（デジタル・インテグレーション・ハブ）はコマンド・クエリ責務分離 （CQRS: Command and Query Responsibility Segregation）の一つの形体と言えます。

ここでご紹介したDIHは、下図のシンプルなケースに該当します。更新処理が発生するたびに、リアルタイムで照会系のシステムに更新情報を転送出来れば、コマンド・クエリ責務分離構成を取りやすく、様々なデータ要求に対応することが可能となります。つまりDIHの構成はCQRSを活用したデータ利活用基盤のリファレンス・アーキテクチャーとも言えます。

一方、公益業界のシステム（営業系システム）においてはいくつかの考慮点があります。

図:データ活用の壁

根底にある原因はサービス指向と同じです。同一業務プロセスが複数のシステムに分かれていることでデータソースが多くなります。つまり単純にコピーされたデータが複数存在することになりますので、照会側のシステムでこれら複数のデータを単一のテーブルに見せるための仕組みが必要になります。データモデルが異なるシステムのデータを統合することは簡単ではありません。また、そもそも簡単に転送出来ないケースがあります。一般的に更新データの転送は変更データ・キャプチャー（CDC）という方式で実現しますが、採用しているパッケージによっては、CDCでは対応出来ないようなケースも存在します。つまり、データ活用の壁として

• 同一種のデータが複数のシステム上に存在
• カスタム開発とCOTSの混在によって照会用DB構築の難易度が高い

が挙げられます。対応するためには、必要な情報および求められる情報鮮度を整理して対象範囲を限定してサービスを提供する等の検討が必要となります。例えば30分の電力量はリアルタイムに近い方が良いかもしれません。通常時と異なる電力消費量のリアルタイム通知は1日後では意味がなくなります。一方、インセンティブ型DRの結果通知は1日後の送付でも十分な役割を担います。データを生成するシステムの変更も視野に入れる必要がありますので業務処理を行なっているシステムの廃止や統合の計画がある場合には、それらを加味して方式を検討することになります。

次回は公益業界におけるクラウド・サービスの活用について整理してみます。

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

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