客が本気にならないといいシステムができない。東証arrowhead成功の鍵とは ～ Innovation Sprint 2011
2010年から東京証券取引所で稼働を始めた新しい株式売買システムのarrowhead（アローヘッド）は、高速化が進む世界の証券取引所の中でも世界トップレベルのレスポンスを達成したと伝えられています。
そのarrowheadのプロジェクトはどのように運営されていたのか、そしてトラブルなくシステムが稼働した成功の背景に何があったのでしょうか？
1月14日に都内で行われたイベント「Innovation Sprint 2011」で、東証側のシステム構築担当者だった宇治浩明氏が講演を行いました。
世界の高速化競争とトラブルによる危機感が背景に
東京証券取引所 株式売買システム部長 宇治浩明氏。1年前に投入した東証の新しい株式売買システム「arrowhead」は、それ以前に比べてレスポンスを1/1000にすることができた。そのプロジェクトの内容と成功の鍵について紹介する。
arrowheadを開発した背景には、アルゴリズム取引、いわゆる高頻度取引（High Frequency Trading：HFT）が増えてきたことがある。海外の取引所ではHFTを取り込むための高速化競争が始まっていたが、東証だけは秒単位の遅いシステムを使っていた。
また、東証では2005年にシステム障害を起こし市場の参加者に迷惑をかけてしまったため、高信頼で拡張性の高いシステムを再構築する必要もあった。
おもにこの2点から、新しい売買システムを作ることになった。
開発にあたり、基本的なコンセプトと定量的な目標をとりまとめた。特に高速性については、売買の注文の受付を10ミリ秒以下、情報配信のレイテンシを5ミリ秒以下と、当時世界のトップレベルを目標にした。信頼性は99.999％以上の可用性の確保を目標にした。
実際に、稼働開始後は注文受付、情報配信ともに平均2ミリ秒と、目標を大きく上回ることを実現した。
これがシステム概要図。以前のシステムはいわゆるメインフレームだったが、arrowheadは200台ほどのオープンなサーバを高速ネットワークで接続したものとなった。
銘柄ごとに機能分散し、ハードディスクを使わずすべてインメモリデータベースを使うことで2ミリ秒レベルの高速性を実現。3台のサーバで同期コピーを行うことで信頼性を確保した。
500名以上のメンバーが有明のプロジェクトオフィスに集結
arrowheadプロジェクトのスケジュールは、まず2006年3月に欧米を視察し、マイルストーンを公表。その後、証券会社などと実務者ミーティングを行った。その後も節目節目にはミーティングをしている。
2006年クリスマスに開発ベンダが富士通に決定。2007年から本格的な開発が始まり、2009年にパイロットテストとして一部の証券会社と接続テストを開始。2010年1月に本番稼働をした。
プロジェクトのメンバーは、東証のプロパーが25人、協力会社メンバーが50人。これに富士通のメンバーがピークで500名以上。有明にプロジェクトオフィスを造り、そこに全員が集結した。
また、東証内部のユーザー部門との連係も欠かせない。コンセプト作りから設計、UIの作成まで、合意をしたらハンコをもらう、という日本的なプロセスでやっていた。
プロジェクトを通して、ユーザー部門と業務マニュアルの作成、運用の準備などを一体感を持ってやってきた。おかげでユーザー部門からの不満も少なく、手戻りも少なくできた。
上流工程完璧主義を大事にした
arrowheadの開発では「上流工程完璧主義」を大事にした。
そのために行ったのは、要件定義をしっかり書き、それが設計書に反映されていることを確認し、富士通さんのテストの中でそれが検証されているかをしっかりチェックしたことだ。
富士通さんとの契約は請負契約だったので、そこまで東証がやる意味があるのか、という議論もあった。しかしユーザーが本気でやっていることを示す意味でもここはしっかりやった。
なぜ上流工程完璧主義なのか。従来は東証で要件を書き、入札後にベンダが要件確認書を作り、これが実際の要件定義となって請負で作っていた。しかしこれだとテストのときに要件漏れが発見される、ということが多かった。
arrowheadではこれを改善するために、まずは詳細な要件定義書を東証の責任で書ききることにした。1500ページのRFPを東証が作り、富士通に決まった後では全体で4000ページになった。
さらに非機能要件は富士通や外部にチェックしてもらい、機能用件は東証内部の類似のシステムをベンチマークとして過不足がないかをチェックした。
「要件定義書が開発のバイブル」とした。高速性を示す10ミリ秒とはどういう環境でのものなのか、なども詳しく決め、さまざまな観点でチェックして要件定義書の完璧を期した。
要件定義書のレビューは、30人が会議室に1カ月缶詰になった。この過程で、要件に対する考え方などを共有できた。
発注者責任を果たすために、要件定義書と外部仕様書をしゃかりきになって作った。そしてそのあとのレビューもしゃかりきになってやった。
要件をトレースするために1万項目の要件を抽出してトレース表を作った。どの要件が、設計書のどこに記載されているかをベンダに書き込んでもらい、それをもとに、たしかに要件が設計されていることをレビューした。
これによって設計書のレビューの観点が明確になった。同じことをテスト項目のレビューでもやった。
この効果はずばり、手戻りの解消だ。従来は受け入れテスト工程でしか発見できなかったバグが、設計時点でつぶせるようになった。そして要件トレースをテスト工程にも行うことで、テストの十分性をユーザーの観点で評価できるようになった。
従来のV字モデルでは、コーディングのときに設計漏れなどが分かる。それを前工程にフィードバックして、再度品質強化を行うのがフィードバックV字モデル。詳細設計書を作る中で、その前の基本設計書を評価していく、といったことになる。
つまり、次工程の成果物を作る過程で前の工程の品質評価を行い、もし結果が悪ければ、前行程に戻って品質強化を行うのだ。
プロジェクトの前の方で工数がかかることになるが、後になってからの手戻りも抑えられプロジェクトリーダーとしては安心してプロジェクトが進められる方式だ。
客がやるべきことをきちんとやる
最後に、arrowhead成功の鍵について。
1つは危機意識の共有。かつてシステムトラブルを起こし、マーケットからの信頼を失った。それを回復するにはこれを成功させるのが絶対条件。しかも海外と比べてスピードが負けており、それを呼び寄せるには早くしなければならない。そういった危機意識が社員ひとりひとりを、俺がやるんだという気持ちにさせた。
2つ目は、発注者責任の明確化。客が本気にならないといいシステムができない。客がやるべきことをきちんとやるんだと。
3つ目は上流工程完璧主義。フィードバックV字モデルを用いてその工程の中で品質を作り込み、だめなら次に進まない勇気を持つことだ。
関連記事
- スクラムの生みの親が語る、スクラムとはなにか？ たえず不安定で、自己組織化し、全員が多能工である ～ Innovation Sprint 2011（前編）
- 重要なテクノロジーは10名以下のチームで作られた ～ Innovation Sprint 2011（後編）
東京証券取引所のシステム開発
あわせて読みたい
Amazon、Azure、Niftyクラウドのいいところ、悪いところを本音で語り合う ～ クラウドごった煮パネルディスカッション（IaaS編 前編）
≪前の記事
ソフトバンクとオリコがAndroidスマートフォンとNFCで決済サービスの実証実験
