東京証券取引所 IT開発部arrowheadシステム部長 宇治 浩明
arrowhead担当マネージャー 川井 洋毅

 三つの取り組みを詳しく説明しよう。まず一つめの3階層に整理した機能要件の定義資料が図3だ。

図3●要件定義・外部設計の成果物の例<br>上はarrowheadの全体機能と利用者や接続システムを示す「全体業務フロー図」。中は業務単位で機能間の連携をまとめた図。下は機能をさらに細分化して要件を記述したもの
図3●要件定義・外部設計の成果物の例
上はarrowheadの全体機能と利用者や接続システムを示す「全体業務フロー図」。中は業務単位で機能間の連携をまとめた図。下は機能をさらに細分化して要件を記述したもの
[画像のクリックで拡大表示]

 最上位層に当たるのが左上の「全体業務フロー図」。arrowheadを中心に配置し、接続先システムやシステムの利用者を周辺に並べて、それらの関係性を図式化した。

 全体業務フロー図の狙いは、1枚の資料でシステム全体を俯瞰できるようにすることだ。「注文処理」や「情報配信」「取引規制」などの機能群を、どの粒度でどのように分類するのが最善かを検討しやすくなると期待した。

 記述が細かすぎると全体を直感的に把握できない。かといって大ざっぱすぎても意味がないので、粒度には気を配った。今回は外部に位置する接続先システムや利用者などの「アクター」と呼ぶ存在に着目して機能群を分けた。arrowheadが処理するデータはアクターから入ってくる。出力先もアクターだ。アクターの種類に応じて機能群を分類すれば、機能群のつながりが疎結合となり、プログラム構成を最もシンプルかつ正規化した形にできると考えた。

 全体業務フロー図は、UML(統一モデリング言語)のユースケース図に似ている。ただし完全に準拠してはいない。UMLを熟知したメンバーばかりではないので、完全準拠にはこだわらず使いやすい形にカスタマイズした。

 2階層目の「業務フロー図」には、「注文処理」「情報配信」などの具体的な業務処理を進めるとき、機能群がどのようにメッセージをやり取りするかを記述した。さらに「注文処理」といった機能群を細分化した業務要件を3階層目の「要件定義書」に記載した。

「Wモデル」で上流から検収準備

 二つめの挑戦的な取り組みは、「検収テスト」フェーズで使うチェックリストの作成開始を大幅に早めたこと。検収テストの直前に作るのではなく、要件定義フェーズから着手し、手戻りの削減を狙った。

 要件定義書の内容は検収テストで、外部設計書は総合テストで、プログラムは単体テストで、それぞれ誤りがないか確認するのが一般的だ。「V字モデル」と呼ぶテスト方法である。

 この方法だと検収テストで不具合が見つかったときの手戻りが膨らむ。要件定義書を直してそこから関連する設計書を直し、プログラムを直して単体、結合、総合、検収の各テストをやり直さなければならない。

 そこで今回のプロジェクトでは、V字モデルの欠点を補う「Wモデル」という考え方を取り入れた。テストの実施を待たずに、テスト計画書やチェックリストの作成に上流工程から取り掛かる手法だ。例えば要件定義と同時に検収テストを、外部設計と同時に総合テストを始める。