 |
ネット証券の開業まで7カ月。「何としても遅延は避けたい」（システム部長 田島利充氏）という状況で，開発プロジェクトはスタートした。
要求定義のメンバーは，ITエンジニア出身の社長を含め4人。検討結果を機能一覧表としてまとめ，それを外部委託先を含む設計/開発チームに渡すという形で開発を進めた。
要求定義のメンバー4人で，必要と思われる業務仕様をどんどん書き出した。「株式の約定ができる」「約定の結果が一覧表で見られる」「約定の結果がメールで通知される」などを整理すると，顧客が必要とする機能が約200項目，社内の管理者が必要とする機能が約200項目に上った。このほか外部システムとのインタフェースがいくつか挙げられた。さらに，書き出した業務仕様の重要度を検討し，優先度を決定。こうした資料を，設計/開発チームに渡した。
設計/開発チームがモデルを作成
「本来なら要求定義のメンバーがユースケース仕様書を作成し，設計/開発チームに渡す。しかし，要求定義メンバーの人手が不足し，その時間がなかった」と田島氏は振り返る。そこで，設計/開発チームのメンバーが，ユースケース図やユースケース仕様書を作成することにした。
結果的に，このやり方は効果的だった。ユースケース図やユースケース仕様書を作成するには，機能ごとに，どういう場合にどういう使われ方をするかを正しく理解していなければならない。ユースケース図を作成することで業務の理解が深まった。一つのユースケースは，ドキュメントの作成から設計，実装，テストの完了まで2週間で区切った。一部，調整は発生したが，大きな手戻りはなかった。
そのほか効果的だったのは，処理の流れ全体を記した業務フロー図。一つの処理が複数のサブシステムをどのように経由して完了するかが一目で分かるようになっている。要求定義チームで作成し，設計/開発チームの全員に配った。
この業務フロー図により，担当しているシステムが全体の中でどういう位置付けになっているかを理解したうえで仕様書を書くことができる。全体最適を考えられるというわけだ。「例えば，そことここは同じような処理なのに仕様が違っているのはなぜなのか，といった疑問を設計/開発チームがぶつけてくる。そうしたやり取りから仕様バグもいくつか発見できた」（田島氏）という。
システムは，予定通り2006年5月に無事稼働し，開業に至った。
