クライアント/サーバモデルからRIAへ移行するタイミングと判断
RTGSや次世代RTGSに対応した管理アプリケーションを提供している企業のひとつに電通国際情報サービス(ISID)がある。同社は「流動性管理システム」と呼ばれるシステムを提供している。このシステム、日銀がRTGSの取り組みを開始した当初は、Delphiベースで開発されたUIを使ったクライアント/サーバモデだった。しかし次世代RTGSに対応するにあたって、Flash/Flexを活用したRIAシステムに変更されている。
クライアント/サーバモデルからRIAへ移行した理由として、ISID 金融ソリューション事業部 金融事業企画部長 飯田哲夫氏は次の理由を挙げている。
- クライアントモジュールのアップデートといったメンテナンス性を削減したかった。従来の方式ではサーバとクライアントの双方をアップデートする必要があり、すべてのクライアントをアップデートするのは大変な作業だった
- 採用していた技術の将来性を検討し、別の技術を採用するタイミングと判断した
- クライアント/サーバモデルを採用しなくとも、RIAで同じことを実現できるほどまでにRIA技術が成熟していた
2006年ごろにはアーキテクチャを決定し、1年ほどかけて開発を実施した。最終的に、AIXをベースにアプリケーションサーバとSeasarを稼働させ、SOAコンポーネントとして流動性管理システムを実装。データベースにはOracleを採用するなど堅固な作りになっている。
顧客の要望は「UIを変更しないで!!」
RTGSから次世代RTGSへの拡張にともない、顧客にシステムのアップグレードを通知すると、「とにかくユーザインタフェース(UI)を変えないでほしい」という要望を数多くもらったという。顧客にとっては、アーキテクチャの変更そのものも懸念事項ではあるのだが、UIが変わってしまうのはとにかく困るのだ。バックオフィスの手堅い業務においては、派手なUIは必要ない。使い慣れた画面が出てこなけらば仕事にならないのである。
さて、そうなると、クライアント/サーバモデルのときと同じUIをFlash/Flexで実現できるかどうかが、技術採用の検討事項となる。調査の結果、「当時のFlexで十分実現できるということがわかった」(飯田氏)ため、採用に踏みきったという。「実際には、最後まで"アーキテクチャを変えてほしくない"と主張し続けた顧客もいたが、こうしたシステムは中長期に渡って使われるため、こういうタイミングを逃してしまうと、より優れたアーキテクチャへの刷新が実現できない」(飯田氏)とし、思い切って変更を実施したという。
使えるコンポーネントは使う、開発を迅速に進めるために
開発の途中、Adobe LiveCycle Data Servicesを使いたいと開発者から要望が上がってきたという。流動性管理システムのサーバからRIAクライアントへと、リアルタイムにデータを配信する必要があるわけだが、この部分をイチから開発していては間に合わないことがわかった。レガシーマイグレーションという案件であり、画面は全部作り直しになる。工数的にかなり大変だったため、部品として使えるものは使いたいという、開発側の切実な願望だった。
Adobe LiveCycle Data Servicesは、AdobeがFlashの動画配信で培った技術とプロトコルが投入されたプロダクト。今回の事例のようにリアルタイムでの確実なデータコミュニケーションを求められる場合には最適なソリューションというわけだ。最終的に予定期間どおりで開発は完了したが、「該当部分にLiveCycle Data Servicesを採用せずに自社開発していたらどうなっていたか…と想像すると冷や汗が出る」と飯田氏は当時を回顧する。
次世代RTGSへ対応した流動性管理システムで、UIにFlash/Flexが採用されたこと、すでに同システムを導入した金融機関で活用されていること、従来のクライアント/サーバモデルの置き換えとして満足に機能していること、バックオフィスの堅牢な業務にも適用できていること……同事例がRIA採用について物語っている部分は興味深いところが多い。