ビジネス価値の見極めが、開発効率を決める：システム開発、成功のポイントを聞く（2）（1/2 ページ）

[内野宏信，＠IT情報マネジメント編集部]

東証「arrowhead」に込められた開発成功の真のポイントとは？

　たとえ1週間のタイムロスでも大きな機会損失につながる現在、システム開発には一層のスピードと品質が求められている。これに伴い、アジャイル開発が注目されている中、ウォーターフォールによってスピードと品質を両立した東京証券取引所の株式売買システム「arrowhead」の開発事例は多方面で注目を集めることになった。

　2010年1月、本番稼働を開始したarrowheadは、200台のリナックスサーバを連携させたシステム。インメモリデータベースを活用し、「ユーザーから株の売買注文を受け、システムで処理し、注文受付情報を返す」といった一連の処理に、従来、約2秒かかっていたところを、約1000分の1の2ミリ秒まで短縮することに成功した。

　注目されたのは、そうした機能面はもちろん、その開発の在り方だ。特に、要件定義から基本設計、詳細設計、プログラム設計、コーディングというV字モデルの前半において、次のフェイズに進む際、「前のフェイズに誤りがある」ことを前提とし、各フェイズのレビューを確実にこなしながら進め、後半の手戻りを防いでスピードを担保する、「フィードバック型V字モデル」の概念は、多くの開発関係者に示唆を与えることになった。

　だが一方で、本プロジェクトでは富士通の全面的な協力を得るなど、「開発にお金を掛けられる企業だから実現できた事例であり、予算に余裕がない会社にとっては参考になりにくいのでは？」というシニカルな見方もあった。しかしこの事例には、そうした見解からもある教訓を引き出す“開発成功のための真のポイント”が隠されていた――。

早稲田大学で開催された日本科学技術連盟主催「ソフトウェア品質シンポジウム2011」。その企画セッションには多数の受講者が詰め掛けた

　2011年9月7日〜9日にかけて、東京・早稲田大学で日本科学技術連盟主催「ソフトウェア品質シンポジウム2011」が開催された。この企画セッションに、arrowhead開発のプロジェクトマネージャを務めた、東京証券取引所 IT開発部 株式売買システム部長の 宇治浩明氏と、プロジェクトマネージャとして実作業を担当した、富士通 保険証券ソリューション事業本部 東証事業部 プロジェクト統括部長 三澤猛氏が登壇。

　静岡大学の森崎修司氏、広島修道大学の脇谷直子氏の進行により、本事例の成功のポイントをあらためて分析した。今回は多数の聴講客が詰め掛けた中、森崎氏らが客観的見地からあらためて明らかにした“開発成功の真のポイント”を紹介したい。

【関連リンク】
「ソフトウェア品質シンポジウム2011」（日本科学技術連盟）

「発注者責任を果たす」あらゆる施策が注目を集めたarrowhead

　まずは本プロジェクトの概要を簡単に紹介しよう。

　2010年1月、本番稼働を開始した「arrowhead」は、世界各国の証券取引所で高頻度取り引き（High Frequency Trading：HFT）が主流になっていく中で、競争力と信頼性の向上を狙いに開発したシステムだ。ニューヨークやロンドンの証券取引所が、ミリ秒単位の取り引きを実現している中、東証は約2秒と大差をつけられていた。このままでは世界の投資家が東証から離れてしまうため、約1000分の1の2ミリ秒まで短縮することを目標に設定。約3年のプロジェクト期間内でその実現に成功した。

　システム開発会社には、国内外18社の中からコンペによって富士通を選定。「インメモリデータベースを使って2ミリ秒レベルの高速性を確保しながら、3台のサーバで同期コピーを取って信頼性も担保する」という「東証向けのまったく新しいミドルウェア開発」の提案が決め手となった。

　一般的に、多くの企業は開発会社を選定してしまうと“丸投げ”にしてしまう例が多い。だが東証では「日本経済に影響が及ぶ使命を負っている」ことを深く認識。また2005年、システムトラブルを起こし、一時、投資家の信頼低下を招いた過去もあった。このことから、「発注者責任を全うすべき」と決意。株式の売買監理部門、デリバティブの商品管理部門など業務部門から25人のプロジェクト専任メンバーを選抜。さらに協力会社から50人、富士通の500人で1つのプロジェクトチームを構成した。

　この陣容で、まず東証側で責任を持って正確な要件定義書を作り、協力会社など第三者に客観的な見地から漏れや齟齬がないかチェックしてもらい、さらに、この要件定義書で実際に構築可能かどうかを富士通にチェックしてもらうという三段階の流れとすることで、狙い通りのシステムを確実に開発できるよう配慮したのだ。

　特に開発体制の軸となったのが、前述したウォーターフォールにおけるフィードバック型V字モデルだ。要件定義から基本設計、詳細設計、プログラム設計、コーディングというV字モデルの前半で、次のフェイズに進む際には『前のフェイズに誤りがある』ことを前提とし、各フェイズのレビューを確実にこなしながら工程を進めたのである。

図1　開発体制の軸となったフィードバック型V字モデル。各フェイズのレビューを確実にこなしながら工程を進めた

　具体的には、要件定義書にまとめた各要件をリスト化。実に1万項目にも及ぶ要件を、東証のメンバー30人で「各要件が設計書のどこに記載されているのか」、富士通のスタッフに明確化してもらった上で、記載されていることを自分たちの目でチェックした。

　これにより、コーディング段階で設計漏れが判明するような開発の手戻りを抑止。受け入れテストで発見されるようなバグも設計時点で確実に解消した。テスト項目も同様にレビューし、テストの確実性・有効性も担保。その結果、V字モデルの前半は時間がかかったが、問題をつぶして手戻りを防いだことで後半はスピーディに展開。品質を確実に担保しながら、予定通り2010年1月のカットオーバーに間に合わせることができたのである（詳細は本連載第1回参照）。

要件が担保されていることを、自分の目で確実に確認

　これには複数のポイントが存在する。1つは「要件トレーサビリティ」をしっかりと担保したこと。東証側で策定した要件が設計書のどこに書かれており、どのテスト項目で確認できるのか、要件が成果物に100％反映されていることをチェックして、実装する機能の漏れを防いだのだ。

図2　東証側で策定した要件が設計書のどこに書かれており、どのテスト項目で確認できるのか、要件が成果物に100％反映されていることをチェックした

　2つ目は「○○のような条件では○○のように動作する」といった具合に、性能、信頼性、拡張性という非機能要件も明確に定義したこと。3つ目はフィードバック型V字モデルにより、前工程の不具合を確実に解消しながら工程を進め、無駄な手戻りを抑制したことだ。

　そして4つ目は、概要では触れなかったが、東京・有明のビルの2フロアを借り切って、全メンバーが一同に集うプロジェクトオフィスを構えた上で、「Challenge“10”msec！高速性と信頼性を両立する、世界一の取引所システムを創る」というスローガンを作成、これをチームの“コアバリュー”に設定したこと。さらに「One Team,One Dream 世界一のシステムを目指して頑張ろう！」という“会社間をつなぐスローガン”も策定して1つの目標を共有、チーム文化を醸成したことがプロジェクトを大きく後押しすることになった。