東京証券取引所 IT開発部arrowheadシステム部長 宇治 浩明
arrowhead担当マネージャー 川井 洋毅
これら三つの取り組みを支えたのが標準化である。ドキュメントの記述ルールや粒度などが統一されていないと、バグが紛れ込む確率が高まる。
まずは成果物の記述ルールや粒度をそろえるための標準化指針を整備した。要件定義書の記述指針はもちろん、UI（画面）標準、帳票標準、メッセージ（電文インタフェース）標準などの標準化指針を用意した。
プロジェクト内に設けた品質管理チームとIT部門全体の品質管理を担う「品質管理部」が協力しながら標準化を推進した。さらにレビュー時の確認項目を統一するチェックリスト、成果物の内容を担当者が自ら確認するセルフチェックシートを用意した（図6）。担当者による属人性を極力排除するように努めた。
画面イメージや電文フォーマットなどを記した外部設計書は最終的に2500ページに達した。1500ページの要件定義書と合わせて4000ページの成果物を東証自身で作成した計算になる。
この4000ページのドキュメントがベンダーの作成する設計書やプログラムに確実に反映されなくてはなんの意味もない。そこで、要件定義書や外部設計書から1万項目に及ぶ要件項目を抽出し、それらが詳細設計書などに確実に展開されているかどうか確認することにした。
具体的には、縦軸に要件項目、横軸に設計書をマッピングしたチェックシートを作成し、東証とベンダーとで漏れがないかどうかひとつ残らず確認した。こうした「要件トレーサビリティ」を確保して初めて「上流工程は完璧だ」と言える。
さらに、各工程の完了基準も決めた。基準を達成したかどうかを見極めた上で、次の工程に進むというプロセスを明確にした。
ドキュメントの変更管理も徹底した。1字1句直すだけでも「変更」扱いとして、しかるべき手順を踏んで修正することにした。担当者が勝手に直すと、最新版がどこにあるのかわからなくなってしまうからだ。
変更の際は、前後の工程への反映作業も漏らさないように注意した。ここの管理が甘いと修正漏れによる不具合が生じてしまうと考えた。これまでも標準化や変更管理の管理基準はあったが改善の余地があった。
結果的に変更項目は1700件弱に達した。厳重な変更管理は、進捗や品質の管理強化にもつながった。機能面の変更が頻発するチームは、品質面でのゴールは程遠いと判断できる。実現方式の制約を解消したり誤字脱字を直したりするような変更案件が中心となれば、対象となる工程の作業が完了に近づいているとみなせる。
会社の将来を背負う覚悟で臨む
過去の標準的なプロジェクトと比べて、要件定義・外部設計にかけた工数は3倍に増えた。だがその分、この年末からの総合テストや2009年春からの検収テストではバグの発生による手戻りが減るとみている。総合テストと検収テストはこれからだが、これまでの積み重ねが目に見える効果として表れると確信している。
3年がかりのプロジェクトは、いよいよ最後の1年を迎える。プロジェクトの失敗は東証の存続にかかわるとの覚悟でプロジェクトメンバー一同は最終テストに臨む所存だ。
