“ユーザー主体”の姿勢が開発のスピードと質を高める：システム開発、成功のポイントを聞く（1）（1/2 ページ）

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

市場環境変化のスピードが増している近年、ビジネスを支えるITシステムの開発にも一層のスピードと品質が求められている。だが、クラウドサービスをはじめ、企業にとってITを活用しやすい環境が整いつつあるとはいえ、開発のスピードと品質を両立させるのは容易なことではない。しかし、そうした中でも独自のアプローチで成功を手にする企業は存在する。本連載ではシステム開発の成功事例を取材。開発に対する各社の基本スタンスを探る。

レスポンスタイムを1000分の1秒に短縮

　ビジネスの展開スピードが加速している近年、業務を支えるシステム開発にも一層のスピードが求められている。だが、いくら開発期間が短くても障害やバグが頻発するようでは意味がない。ともすれば機会損失、信頼失墜につながってしまうし、社会インフラを支えるシステムなら人々を混乱に陥れてしまう。スピードとともに品質も担保できなければ、開発は成功とは言えない。

　2010年1月、本番稼働を開始した東京証券取引所の株式売買システム「arrowhead」は、そうしたスピードと品質の両立に成功した貴重な事例の1つだ。同社は従来、メインフレームによるシステムを活用していたが、これを200台のリナックスサーバを連携させたシステムに移行。「ユーザーから株の売買注文を受け、システムで処理し、注文受付情報を返す」といった一連の処理に、従来、約2秒かかっていたところを、約1000分の1の2ミリ秒まで短縮することに成功した。

　開発期間は約3年で、プロジェクトは計画期間内に終了。カットオーバー後も安定的に稼働し、世界の投資家からの信頼を獲得している。そして、この2011年7月、レスポンスタイムのさらなる短縮化に向けて新たなプロジェクトをスタート。2012年5月までに1ミリ秒を実現することを目標に、システム基盤に改善を施しているという。

　では、新たなプロジェクトの礎となった「arrowhead」プロジェクトの成功要因とは何だったのか――プロジェクトマネージャを務めた東京証券取引所 IT開発部 株式売買システム部長 宇治浩明氏と、開発の実作業をプロジェクトマネージャとして担当した、富士通の保険証券ソリューション事業本部 東証事業部 プロジェクト統括部長 三澤猛氏に詳しく話を聞いたところ、昨今重視されている「ユーザー主体開発」のスタンスに基づく複数のポイントが、開発のスピードと品質を支えていたことが分かった。

「ITシステムの発注者責任を果たす」とは、どういうことなのか

　そもそも東証が「arrowhead」を開発したのは、世界各国の証券取引所で高頻度取り引き（High Frequency Trading：HFT）が主流になっていく中で、競争力と信頼性を向上させることが狙いだった。ニューヨークやロンドンの証券取引所が、すでにミリ秒単位の取り引きを実現している中で、東証は約2秒と大きな差をつけられていた。また2005年にはシステムトラブルを起こし、一時、投資家の信頼を低下させてしまったこともその背景となっていた。

　「証券取引所も一つの株式会社だ。だがシステムの高速性・信頼性が低ければ投資家が離れてしまい、日本経済に大きな影響を及ぼしかねない存在でもある。海外の主要な証券取引所に対応できる高速かつ信頼性のある、拡張性の高いシステム構築が急務だった」（宇治氏）

　宇治氏のチームは2006年、ニューヨークやロンドンの証券取引所を視察し、開発に向けてシステムの基本コンセプトを策定。処理時間の目標値として、売買注文の受付処理時間を10ミリ秒以下、情報配信のレイテンシを5ミリ秒以下と、世界トップレベルの目標値を設定した。これを基に2006年8月、システム開発会社の入札を行い、応札した国内外18社から二段階のコンペによって富士通を選定した。

　「各社の提案はそれぞれ考え抜かれたものだったが、富士通さんの場合は東証向けのまったく新しいミドルウェア開発を提案してくれた。具体的には、インメモリデータベースを使って2ミリ秒レベルの高速性を確保するとともに、3台のサーバで同期コピーを取ることで信頼性も担保する。求めていた高速性と信頼性の両立が決め手となった」

　ただ一般に、多くの企業は開発会社を選定してしまうと、あとは“丸投げ”にしてしまう例が多い。だが東証では「ここからが本番」と考えた。

　「われわれは日本経済にも影響が及ぶ大きな使命を負っている。過去には一度システムトラブルも起こしている。この危機感から“発注者責任”というものを真剣に考えた」（宇治氏）

　プロジェクトメンバーは、東証のプロパーが25人、協力会社のメンバーが50人、富士通が500人。このうち東証のプロパーは、株式の売買監理部門、デリバティブの商品管理部門など、全員を業務部門から選抜、本プロジェクト専任とした。この陣容で、まずは東証側で責任を持って正確な要件定義書を作り、協力会社など第三者に客観的な見地から漏れや齟齬がないかをチェックしてもらい、この要件定義書で実際に構築可能かどうかを富士通にチェックしてもらうという三段階の流れとすることで「発注者責任を果たそう」と考えたのだ。

　大きなポイントは、要件が設計書やテスト項目にきちんと反映されているかどうか、きちんと確認したことだ。

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

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

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