[ザ・プロジェクト]

2010年11月30日(火)IT Leaders編集部

リスト

　東京証券取引所（東証）は長年、サイロ化してしまった情報系システムに悩まされていた。取引参加者や上場会社とやりとりする書類を管理する「TARGET」や、マスターデータを管理する「MDB」といった個々のシステムはこれまで、所管部門がそれぞれの要件に基づき導入してきた。このため、20種類近くに上るシステムのあちこちで機能やデータの重複が発生し、コスト増加の要因になっていた。

　システム同士が複雑にからみ合い、一部の変更が影響を及ぼす範囲を特定しづらいという問題もあった。システム変更の際、その影響範囲を調査するだけで1年かかることもあったという。「このままでは、法改正や新サービスの開始といったビジネス変化に、システムが即応できないという危機感があった」（IT開発部デリバティブ・システム部長の池内博氏）。しかし、システムごとに更改時期がずれているため、全面刷新にはなかなか踏み切れなかった。

　同社が一歩を踏み出すきっかけになったのは、そうした情報系システムの1つ、売買審査システムのリプレースだ。

　売買審査システムとは、膨大な取り引きデータから、インサイダーや相場操縦といった不正な証券取引を抽出するためのシステムだ。2009年初春、同システムを刷新する話が持ち上がった。2010年1月に稼働を控えていた次世代株式売買システム「arrowhead」によって取引件数が大幅に増大することが見込まれ、これに合わせてシステムを増強する必要があったからだ。ハードウェアやミドルウェアのサポート切れも近づいていた。加えて近年、アルゴリズム取引をはじめとする取引技術の向上により、審査業務をより高度化させる機能へのニーズもあった。

図1-1　東京証券取引所が構築した新・売買審査システムの主な機能

 

 

システムの変更・拡張は必要最小限の手間で

東京証券取引所IT開発部デリバティブ・システム部の池内博部長

　東証は、売買審査システム再構築に向けた提案をベンダー各社に依頼し、4〜5月にかけてコンペを実施。既存システムを手がけたベンダーによるリプレース案を含め、数社の提案を比較検討した。その結果、SOA基盤上でシステムを再構築するという協和エクシオの提案を採用。従来の延長線上でのリプレースよりも費用を抑えられることや、先々の拡張性や保守性を考慮している点を評価した。

　プロジェクトが始動したのは、2009年6月。目指す新システムのあらましはこうだ。arrowheadの取引データから独自ロジックを用いて不正の疑いがあるものを抽出し、データベースに蓄積。売買審査担当者がそれらを精査するためのレポートや帳票を作成する機能を備える。新たな抽出ロジックを過去のデータに適用し、その有効性をシミュレーションする機能も追加する。

　ESBに日本IBMの「WebSphere Enterprise Service Bus 6.2」を採用。前述の不正取引候補の抽出、シミュレーション、帳票出力といった機能を具現化するプログラムをそれぞれJavaで開発し、SOAP/HTTPといったESBが備える標準インタフェースとの通信機能も実装する。これらがいわゆる「サービス」としての位置付けで、その実行やデータのやり取りは常にESBを介して制御するよう全体を構成する。

　一方、データを管理するDBに対して、各サービスがソースコードレベルで強い依存関係を持つことも避けたかった。そこで、多くのサービスが汎用的に使うOracle Databaseと、主にシミュレーション用途で使う4D DAMの2つのDBについて、常にデータ連携層を介してアクセスする方式を採用。どのサービスにおいても標準化されたアクセスルールを記述することでデータを扱えるようにした。

　法改正などで機能修正を加える際には、該当する既存サービスの一部を手直しすることで対処。事業環境に合わせた機能拡張においても、他への影響波及調査などを逐一することなくESBとの接続性のみを考慮したサービスを追加することで済ませる。必要最小限の手間で、システムに弾力性を持たせられるのがSOAのメリットだ。

●Next：プロジェクトの課題に対して取り組んだこと