基幹システムをボトルネックからDXのパートナーへ。「DIH」が実現するデータ活用の未来

※新型コロナウイルスの拡大防止に最大限配慮し、写真撮影時のみマスクを外しています。

世界はリアルとバーチャルの融合に向かい、ビジネス領域もDXなしには生き残れない。そんな中、基幹システムはビジネスのコアでありながら、足かせになっている企業が少なくない。

そこで日本アイ・ビー・エム株式会社（以下、IBM）が進めるのが「Digital Integration Hub（DIH）」だ。ほぼリアルタイムに基幹システムにあるデータを連携できる仕組みで、ボトルネックだった基幹システムの有効活用が進むと期待できる。

DIHの概要とその可能性について、IBMの村田、藤田、高瀬の3人が、ビジネス戦略、テクニカル、企業の課題の視点から語った。

ビジネスのコアでありながらデータの活用が進まない基幹系システム

 
ーービジネスにおけるDXを進めようとする企業が増えています。いざ進めるとなると課題にぶつかるところも少なくないようですが、現在の状況をどのように見ていますか。　

村田　2017〜18年頃からソーシャル、モバイル、クラウドが当たり前になり、それらを実現するツールや仕組みが広まりました。DXもこの頃からすでに盛り上がりを見せ始めていました。具体的な取り組みとしては、オープンAPI、店舗のデジタル化、軽量化、デザインの変更などです。その後、パンデミックを経て、社会全体のデジタルへのシフトが加速しました。

今後は、企業単体でのDXから業界をまたがったエコシステムへと可能性が広がっていきます。デジタルは物理的制約を受けません。分散されたものがつながり、サービスの価値を高めていきます。単純に物理からデジタルへの移行というだけではなく、デジタル化により物理的な世界とデジタルの世界を融合させていく、これが次のDXの流れだと見ています。

そうした中で、重要なテーマとなるのが、企業様が抱えている基幹系システムとデータの利活用だと考えています。

 
ーー基幹系システムとデータの利活用を進めるにあたって、大企業は資産があるゆえに難しいという悩みもありそうです。どのようなアプローチが考えられるのでしょうか。

村田　　2018年、IBMはこれからのデジタル時代に向けて「デジタル時代のサービス・アーキテクチャー」を発表しました。その成果として、ダイナミックに変化する顧客接点ニーズに柔軟に対応するべく「デジタルサービス・プラットフォーム（DSP）」を開発しました。

企業のデジタル・シフトが進む中で、現行システムとのつなぎ込みが問題になると見越してのものです。DSPを介することで、新たなアプリケーション開発の際も、容易に基幹システムに接続ができます。2022年10月時点で、APIの数は228に達し、採用いただいているお客様も約30を数えるまでになりました。

ここまでをDXの第一のステップとして、その次のステップとなるのが、「Digital Integration Hub（DIH）」です。

2022年7月、IBMではリアルとデジタルとが融合する時代のビジネスの仕組みや、そこで使われる先進的な技術をまとめて「リアルとデジタルが一体化する時代に対応するITアーキテクチャー」を発表しました。この中の「データコア・サービス」において、デジタルの活用で生まれた新しいデータと、既存の資産やデータをつなぎ合わせて新しい価値を届ける仕組みを構築しました。これがDIHとなります。

一つひとつシステムをつなぐことは技術的に可能ですが、スピード、ビジネスリスクなどの面から見て十分なやり方とは言えません。中間で吸収する層となるのがDSPで、そこで生まれたデータと既存のシステムやデータを組み合わせるためのソリューションです。

 
藤田　銀行のお客様を例に取ると、DX部門の方々から、すぐにでもデータを活用したいという熱量を感じます。一方で、データを外に出すとなると、セキュリティーや整合性の担保などの課題がある。

であれば、ほぼリアルタイムに基幹系システムのデータを反映していて、かつ自由に参照や活用ができるデータを別に用意しておけば良い。それを実現する仕組みがDIHです。

基幹システムに負担をかけることなく、データの参照と活用を可能にするDIH

 
ーーDIHについて、もう少し詳しく教えてください。

藤田　「Digital Integration Hub」という言葉は、調査会社のGartnerも提唱している概念で、基幹系システムにあるデータを、柔軟に使えるように外に出すテクノロジーです。

まったく新しいものではなく、IBMが持つメインフレームからデータを抜くための技術「チェンジ・データ・キャプチャー（CDC）」とデータ加工と配布のためのオープンソース技術である「Apache Kafka（kafka）」を土台としています。CDCはIBMが以前から提供している技術であり、Kafkaは世界中で使われているデータ・ストリーミング・プラットフォームです。

既存のテクノロジーを使用して、かつオープンな仕組みであるため、立ち上がりが比較的早いという特徴もあります。

少し詳しくお話しすると、コンピューター処理は大きく機能とデータ処理に分けられますが、APIは機能を外から使うためのものです。ところが現在のDXでは、一度APIで定義したもの以上の機能が求められるケースや、より大量かつ複雑なデータ検索を行う要件が増えています。この重たい検索や複雑な検索を基幹系システムで実行しようとすると、システム側が安定的に処理しなくてはいけない更新処理に影響が出る懸念があります。

そこで、機能のAPI化に加えて、自由に検索できるデータを取り出して置いておくのがDIHです。しかも、鮮度の観点ではほぼリアルタイム、数秒遅れの“準リアル”データです。これにより、提供する側に大きな負担はなく、使う側のニーズに対応できます。

 
ーーDIHのメリットについて教えてください。

藤田　DIHはDSPと補完関係にあり、DSPが既存の機能を外部に使わせる仕組みとすれば、その中でDIHは照会系の処理だけを分離する仕組みと整理できます。これを、CQRS（コマンドクエリー責務分離）アーキテクチャーと呼んでいます。これにより、更新系の処理はこれまで通り安心、安全、安定的に行うことができ、照会系の処理は場合によってクラウドを使いながら、可用性のある形で進めることができます。

米国の事例では、イベント駆動型のサービスを提供しています。銀行口座の残高がマイナスになると、それに対する高額な手数料が発生します。DIHを使えば、リアルタイムに顧客の口座をチェックし、ゼロに近づくと自動的にユーザーにアラートを送ることができます。これにより顧客は口座の引き落としの日付をずらすなど、能動的に対策を取れます。銀行にしてみれば、手数料を取るよりも、顧客のロイヤリティーを高める方が最終的に利益につながるという考えがあります。

 
高瀬　イベント駆動型とあわせて、ニアリアルのデータをクラウド側に蓄積されていくことで、DX開発側としてもデータがすぐ近くで使えることから、ビジネスのスピードが加速する点があります。また、今はまだオンプレミス側にマスターデータの大半がある状態ですが、将来的にクラウド活用が進むことによってマスターデータの配置が逆転することも考えられます。その際にも、DIHがハブとなってオンプレミス側へのデータ送信が可能です。将来のクラウドとオンプレのハイブリッド利用に関わる作業の削減にもつながるでしょう。

藤田　基幹系システムのモダナイズとしても期待できます。

基幹システムのモダン化は複雑で、5年、10年のプロジェクトになります。しかし、DIHを活用することで基幹システムの機能の一部を外部に構築することも可能になります。それまで基幹システムにデータがあるため、やむをえずにオンプレミスの基幹系システムに作っていた機能を、DIHによってデータを移動できるようになるため、クラウドでも実現できます。DIHによってステップ・バイ・ステップでのモダナイズができ、さらにリスクも抑えられます。

“DIHはユーザーに寄り添った考え方”

 
ーーDIHはどのような課題を解決できるのでしょうか。事例があれば教えてください。　

高瀬　国内の事例で言うと、ある地方銀行様では、クラウドを活用したデータレイクを開発しており、オンプレミスにあるデータウェアハウスからデータをバッチ転送しています。ただ、このデータウェアハウスのデータカタログやデータディクショナリーは既存システムの保守担当者が使うことを想定して作られていますので誰にでもわかるようなものではありません。

データレイク担当やDXアプリの開発担当側としては、データの鮮度の高さや、自社内にどんなデータがあるのか正確にすぐに知りたいというニーズがあります。ただし、データの管理担当にデータ内容の問い合わせや、もし求めているデータや内部APIがなければ追加で開発をしてもらう必要がありました。これではビジネス・スピードが遅くなります。今後、お客様のクラウド活用が進んでいくことにより、ユーザー自身がもっと自由にデータ・アクセスできる必要性があると考え、IBMからはすでに海外事例のあったDIHをご紹介しました。

単なる準リアルのデータ転送だけであれば、データベースのレプリケーションで対応できます。しかし、それではデータウェアハウスの延長に過ぎず、ユーザー自身がデータ利用で感じていた課題の解決にはつながりません。DIHはN対N接続を前提に、利用者側の要望にあわせて動的に複数のデータを結合やマスク化などの加工ができますし、連携方法としてもAPIだったりJDBCだったりと多種多様なプロトコルに対応しているため、利用するユーザーの立場に寄り添っている考え方の仕組みだと思っています。

 
ーーDIH導入のプロセスを教えてください。

高瀬　実際の導入では、当時はまだKafkaの導入事例が日本では少ないこともあり、IBM社内のPoC環境で構成を組んで、IBM製品との組み合わせなどの検証を行いました。その後、お客様用にPoC環境を準備させていただき、我々の提案の実現可能性やリスク評価などを行いました。

藤田　　DIHサービス提供の際は、特定の業界にフォーカスしたSaaSのような形式として、実行基盤、ローコード開発ツール、テスト自動化ツール、ドキュメント等を整備し、すぐに利用できるセットアップ済みの環境で提供することを進めています。

 
ーーDIHでのIBMの強みはどこになるのでしょうか？

藤田　DIHを構成するCDCは、我々の重要な差別化ポイントと言えます。実績のある基幹系システム向けのCDCは、データ・レプリケーションとして多くのお客様にご利用頂いています。このCDCにKafkaのアダプターがあることから、Kafkaにデータ連携できます。

Kafkaは世界中で使われているデータ・ストリーミング・プラットフォームで、各社ベンダーが製品として提供しています。

さきほど高瀬から紹介のあった銀行様では、オープン・ソースであるKafkaの多くの開発者が所属するConfluentという企業が提供するKafka製品を採用いただきました。また、IBMやRed Hatも、Kafka製品を提供しています。各社のKafkaにはそれぞれの特徴がありますので、お客様に最適なものを選んでお使いいただけます。

我々は基幹系システムにもオープン・ソースにもノウハウが蓄積されているので、そこは強みだと自負しています。

オープン・テクノロジーを軸に、レガシーと先端技術の橋渡しとなるソリューションを

 
ーー今後DIHをどのように展開していく予定でしょうか。DIH自身の機能強化の予定も含めてお聞かせください。

藤田　まずは、CDCとKafkaをきちんと動作させる作業を優先して進めています。Kafkaのデータ変換については、現段階ではコーディングが必要なので、ローコードのような仕組みも考えています。これが実現することで、バッチベースだったETL（Extract（抽出）／Transform（変換）／Load（格納））のリアルタイム性がより高まるでしょう。

次の段階が、先述したイベント駆動の使い方です。単にデータを検索する仕組みではなく、リアルタイムのストリーミング・データから洞察を得て、そこから価値を生むような使い方に発展できるよう支援します。

これまでは、ユーザーの操作に対して結果が返ってくるというユーザー駆動型でしたが、イベント駆動型ではユーザー自身が意識していない行動により利益が返ってくるという逆方向のデータの動きが可能になります。

高瀬　これまでになかった銀行アプリの実現に、イベント駆動型アーキテクチャーには大きな期待を寄せています。顧客とコミュニケーションが取りやすくなるだけでなく、行動把握に基づく顧客へのアプローチの方法も変わってくるでしょう。
銀行だけでなく、小売、配送など様々な業界でインパクトがあると見ています。　

村田　経営企画部から見ると、今までのIBMのアプローチは、すべて自社でお客様のニーズに合うシステムを作るというものでした。そこでの前提はリアルの要件があることでしたが、このような新しい技術が出てきたことで、答えがない、要件のないところにチャレンジしていく世界になってきたと感じます。

自社の技術にこだわらず、オープン・テクノロジーをベースに、競合関係にあったような会社とも場合によっては手を組みながら、DIHの活用を進めていきたいですね。さらには、お客様が良い事例を構築され、それを他社に提供するホワイトラベルも考えられます。

藤田　DXの第1ステップがDSP、第2ステップがDIHとすれば、第3ステップはモダナイゼーションになります。

基幹システムのモダナイズという点では、「2025年の崖」レポートでも指摘されているように、進めなければならない状況になっています。DIHはそこでいくつかある施策の一つで、重要なものと言えます。

これまで鍵がかかっていた基幹システムとそこにあるデータに対して、鍵を開けて使えるようにするという点で、レガシーと先進技術の橋渡しになるようなソリューションを実現していきたいですね。