2010 年 4月

東京証券取引所システムの成功の陰には、、、

今年の1月4日、東京証券取引所の新システムが稼動しました。TVで大発会のニュースは見ましたが、システムの大きなトラブルなどはなかったため、そういうニュースにはならなかったようです。

http://journal.mycom.co.jp/news/2010/01/04/003/index.html

4年がかりで開発された次世代システム「arrowhead」(アローヘッド)は、大成功を収め、その成功事例としての報告セミナーに参加してきました。

東証のCIOや業務部門の責任者、プロジェクトマネージャー、開発した富士通などから報告がありましたが、要するに基本的にはずっと以前(10年前、15年前)から言われ続けて来たことをあいまいにせずに実行した、ということでした。

ポイントは
1.上流工程(要件定義から基本設計の一部まで)に東証側が完全に責任を持った

→ 普通はアバウトなRFPをユーザー企業が作成し、それをベンダーに投げてあとはベンダー任せにしてしまうことが多い

2.作業工程で見つかったエラーを前工程にフィードバックすることを徹底した(フィードバック型V字モデル)

→ 前工程の結果が正しいとして次の工程の作業を進めるので、次の工程の作業時に前工程の問題点を見つける意識は普通持たないし、もしおかしいと思っても前工程に反映させることは通常はやらない(スケジュールが遅れる、お金がかかる、担当が違う、など)

3.工程ごとに要件トレースを行い、最終的に100%実現が確認されるまで追求した。内部設計、詳細設計、ベンダ側テスト、受入テストのそれぞれの段階でつぶしていって、最終的に100%まで追求した

→ 要件項目を最後まで徹底して握って、本当に100%消しこむまで管理することはほとんどない。手間も大変だし、最後まで上流工程の文書が正確でないといけないし、、、

4.開発のトータルについて東証側が責任を持つ。

詳細設計書数万ページを東証側ですべてチェック

→ 今回は詳細設計書数万ページをすべて東証側でチェックした。そこまでユーザー企業が踏み込んでチェックする例はほとんどない

5.背景にあった東京証券取引所の危機感

→ 本当はこれが一番大きな成功要因かもしれない。ライブドアの時にシステムが止まったり、間違った価格で売られたり、数年前のトラブルで東証の信頼度は大きく崩れてしまった。日本に対する国際的な信頼低下につながるような事態は、絶対に避けなければならない、という危機感が、経営陣の中に強かった

因みに、要件定義書は1800ページ、外部設計書は2000ページに達し、すべて東証側のプロジェクトメンバーが作成したそうです。要件定義項目も11000項目あり、工程の節目ごとに1件1件実現されているかどうか、どの設計書のどこに書かれているか、をチェックしました。

東証側の体制は70名。プロジェクトリーダーを含め、3分の1がシステム開発の未経験者でしたが、業務に熟達しているメンバーだったそうです。

やはりやるべきことをきちんとやることが品質を保証する王道だと感じました。報告を聞く前は、何か特別な手法があったのかと思っていましたが、そうではないんですね。もっとも、中小企業向けのシステム開発時の品質確保をどうするか、については経営資源の問題もあるので、基本的な考え方は同じだとしても、独自の工夫が必要になるかもしれません。

桜の季節

佐野SAでは桜が満開。

sakura1.jpg  sakura2.jpg

上り線と下り線の境目では、桜の木の足元でレンギョウも咲き始めていました。

rengyo1.jpg

うちの庭では、クリスマスローズが満開です。

http://mugidesign.blog9.fc2.com/blog-entry-32.html