「絶対落ちないシステムを作れ」という要件に、開発者たちはどう対応したのか。東証arrowheadの当事者が語る

2011年9月26日

「素人的に言えば、絶対落ちないシステムを作れ、というのがユーザーから見た要求条件」と発言したのは、東京証券取引所の株式売買システム「arrowhead」開発のプロジェクトマネージャ宇治浩明氏。

東京証券取引所は2005年にシステム障害を起こし、取引が一時全面停止するという事態を引き起こしました。そのため2010年に稼働を開始した新システム「arrowhead」の開発では、高性能と高可用性という高い品質を実現することが絶対の目標となっていました。

東京証券取引所と、arrowheadの開発に当たった富士通。両社はどのように開発プロジェクトを通して高いソフトウェア品質を実現したのでしょうか？

9月9日、早稲田大学西早稲田キャンパスで行われた日本科学技術連盟主催「ソフトウェア品質シンポジウム2011」の企画セッション「品質がもたらすソフトウェアのビジネス的価値」において、プロジェクトマネージャの宇治氏と富士通の東証事業部プロジェクト統括部長三澤猛氏を招いてパネルディスカッションが行われました。モデレータは静岡大学助教森崎修司氏です。ディスカッションの内容を一部抜粋して紹介しましょう。

ソフトウェアの品質を確保するために何をしたのか？

左から、静岡大学助教森崎修司氏、東京証券取引所宇治浩明氏、富士通三澤猛氏

森崎　私の知るかぎり、ユーザーとベンダーがこれだけしっかりリスクを共有してうまくいった事例は見たことがありませんでした。ただ、東証arrowheadのカットオーバーまではいろいろな事情で話すことができなかったわけです。今日のディスカッションではぜひその秘訣をみなさんと共有したいと思います。

最初に東証の宇治氏への質問は、arrowheadにどのような品質が求められていて、ユーザー側、発注者としてそれを実現するために何をしましたか？ということです。

宇治　たいへん難しい質問ですが、東証は衆人監視のシステムで、非常に高い品質が求められていました。しかし残念なことに過去にシステムトラブルを起こしたし、それでうちのトップも辞めざるを得ませんでした。会社としては非常事態です。だからこそ、全社一丸でこのプロジェクト（arrowhead）ができたわけですが。

求められる品質で言うと、素人的に言えば「絶対落ちないシステムを作れ」、というのがユーザーから見た要求条件。そのために何をしたかというと、当然、100％落ちないシステムなどできない、けれどもできることは100％やろうと。

東証の人間はプログラミングはできない、でもそれ以外は全部やりましょうということで、要件定義書を書くところから、それを徹底的にレビューする、といった部分をやりました。東証の持っているチカラは100％出し切って品質の高いシステムを作ると。

そして富士通には、バックエンド系は落ちても我慢するけれど、フロント系は絶対落ちないようにしてね、という優先度の注文もつけました。

森崎　まとめると、発注側でできることは全部やって、さらに優先度を富士通に指定したと。

富士通の三澤さんにおうかがいします。求められる品質を実現するために、ベンダとしては何をしましたか？

三澤　いろいろと使える技術はないか、要求にうまく応えられるものはないかと社内でも調べたりして、ミドルウェアを作ることができた。ただ、ものが動くだけではなくて保証しなければなりません。そこに注力しなくてはいけなくて、いろんな検証を裏で重ねました。業務アプリケーションで動作がちゃんと保証できる、そこへしっかり持って行く、というところにとにかく注力しました。

過去の障害があったから成功した

会場から質問　もし東証の障害がなかったら、このようなプロジェクトになったと思いますか？

宇治　絶対できなかったと思います。障害が起きた後ではまず、「東証はベンダに丸投げでやっているんじゃないか」と批判されました。もちろんちゃんとやっていたつもりでしたが、結果的にこうなった（障害が起きた）から言い訳はできません。じゃあちゃんとやろう、ということになったのです。

そして今回の取り組み方として東証が全社プロジェクトになったので、富士通さんにも「全社プロジェクトでやってほしい」とお願いできました。

森崎　arrowheadでは、優先順位が低い不具合を修正しないまま運用開始したそうですが、なぜですか？周囲から抵抗はなかったのでしょうか？

宇治　私は以前、中央銀行のシステムにも関わったことがあって、そのときは（不具合を修正しないままというのは）考えられませんでした。プロジェクトのみんなもそうでしたので、不具合を修正しようとしていました。でもあるとき、カットオーバーの3カ月前にCIOが来て、そしたら「こんなのは直さなくていいんや」といわれました（笑）

CIOが直さなくていいといったのですから抵抗も何もなかったですね。

森崎　まとめると、強気のCIOを育てましょうと（笑）。

ただそのためには優先順位が決まっていないとだめですね。

三澤　障害ゼロで稼働を開始できるのはSEとしては誇りになるのですが、結果こうなりました（優先度が低い不具合が残りました）と。

でも不具合を仕分けしたときに「これは運用でどうにかなるよ」といわれたのは大きくて、なぜかというと、ここを直したときには関連するほかの品質をチェックしなければ、となると、やはり怖くて開発の手が止まってしまいます。そういうリスクを発注側とベンダが共有できたところが結果的にうまくいきました。

森崎　リスクを共有できたところが成功の1つのポイントのようですね。

リスクをチームで共有する

ディスカッションの中で強調されていたのは、発注側の東証と受注側の富士通が1つのプロジェクトチームとして開発を進めた点です。両社ともトップを交えて定期的なミーティングを行い、またチーム全体が1カ所で働くためのオフィスまでこのプロジェクトのために借りていたとのこと。

一般に発注側は、「こちらが発注者として金を出したのだから、あとは受注側にまかせた。できなかったら責任とって」と、丸投げに近い体制になりがちです。しかしarrowheadの例では、受注側もチームに入ってリスクを共有することが、「落ちないシステム」という高い目標に対する成功の大きな要因であったことを教えてくれます。