2009年後半の稼働を目指す東京証券取引所の次世代システム「arrowhead」。システム障害を踏まえ、品質確保を最優先にプロジェクトは始まった。システム開発における発注者の役割を抜本的に見直し、要件定義と外部設計は従来の3倍の工数をかけた。実装フェーズが完了した今、プロジェクト責任者に具体的な取り組みを紹介してもらった。
本記事は日経コンピュータ11月1日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。本「特集2」の全文をお読みいただける【無料】サンプル版を差し上げます。お申込みはこちらでお受けしています。
なお本号のご購入はバックナンバーをご利用ください。
注文の処理スピードを100倍以上に速める――。東京証券取引所が300億円を投じて開発を進める次世代システム「arrowhead」の最大の狙いだ。併せて99.999％の稼働率と注文の増加に応じて1週間以内に処理容量を増強できる拡張性を確保する。もちろんアプリケーションの品質も高めシステム障害を削減する。
証券取引の世界では、できるだけ有利な条件で売買を成立させるため、コンピュータで自動売買する「アルゴリズム取引」を導入する取引参加者（証券会社など）が増えている。これら参加者は100分の1秒、1000分の1秒でも早い注文処理を取引所に求める。
世界規模で企業のM＆A（合併・買収）が進む時代。取引所も例外ではない。2007年には米ニューヨーク証券取引所が欧州のユーロネクストを買収した。東証が生き残るには、世界の取引参加者のニーズを満たすシステムの整備が不可欠だった。
しかし、現行のシステムでは先進的な取引参加者の様々なニーズに応えていくのは難しい。例えば注文処理にかかる時間は1.5～2.5秒前後。海外の取引所の100倍近くかかっている。メインのデータセンターが被災すると取引業務が止まってしまう。システム障害により取引を停止するといった事態があるなど、万全とは言えなかった。
これらの問題を解決するには、市場インフラの提供者としてシステムの発注力強化への取り組みが不可欠と判断した。例えばベンダー選定では、要求を具体的に明記してベンダーに提案を求めなければならない。要件定義書は業務の視点だけでなく非機能要件までより詳細に記述する必要がある。進捗や品質管理についても強化すべき点があると考えた。
今は、発注力を磨きつつ複数の新規プロジェクトを遂行しているところだ。その象徴がarrowheadの構築プロジェクトである（図）。
利用者のニーズを把握する
2005年末から2006年初めに起こしてしまったシステムの全面ダウンや売買取引の緊急停止をきっかけに、arrowheadの構築は始まった。ITガバナンスを立て直すため2006年2月にCIO（最高情報責任者）に着任した鈴木義伯の指揮の下、プロジェクトに取り掛かった。
まず最初に、システムを使う取引参加者における現状の問題やニーズを把握するため、証券会社のCIOやシステム部門長を迎えたワーキングを設置し、ヒアリングした。
その結果、処理スピードの高速化やマーケット情報の拡充を求める声が多かった。現行システムはどちらかといえばスピードよりも機能の豊富さを売りにしていたが、機能をシンプルにしてスピードを上げる方向に方針を転換した。2006年9月に最終報告書としてまとめた。
報告書に沿って1500ページのRFPをまとめ、Webサイトで広く開発ベンダーを公募した。応募があった18グループのうち書類選考を通過した5グループから受け取った提案書を、70の評価項目に従い数値化して評価した。2006年12月、最高点だった富士通への発注を決めた。
RFP作成やベンダー選定といった作業をいきなり自分たちだけでこなすのは大変だった。そこでITコンサルタントを招き、発注力強化に協力してもらった。
ベンダー選定と並行して社内外から業務とITのプロフェッショナルを集め、プロジェクトチームの編成を始めた。業務のプロは社内公募や人事異動によって業務部門から集めた。ITのプロはITベンダーの技術者を中途採用した。業務とITの面で先進的なシステムを実現可能な形で描くのが狙いだ。社外からITのプロをまとめて中途採用したのは初めてである。
続きは日経コンピュータ11月1日号をお読み下さい。この号のご購入はバックナンバーをご利用ください。
