大きな変更を2週間で吸収

　実際それが功を奏す事態が起きた。「下手をすればシステム全体に影響し，大幅なスケジュール遅延を招きかねなかった」と奥山氏は振り返る。

　これは，2003年1月に入って，「注文の束ね処理」が必要になったことに起因する。束ね処理とは，ある顧客からの複数の注文を，対インターバンク市場（銀行や証券会社の間で取引する市場）への注文として渡す際に1つにまとめること。当初の仕様では，顧客の注文（反対取引の場合）とインターバンクへの注文は1対1にする形だった。画面の仕様では，1回の入力で1つの注文のみだったからだ。しかし，画面のプロトタイプで仕様を詰めた結果，複数の注文が同時に入力できる仕様に変わってしまった。

　急きょ，開発中のシステムへの影響分析を実施した。束ね処理の変更内容と，アプリケーション間のインタフェースへの影響，そのインタフェースの変更で影響が及ぶアプリケーションを特定した。結果的には，画面部分の変更に伴うロジック変更は，注文・約定管理の変更だけで済んだ。1月末に仕様変更のミーティングを実施し，2週間の遅れをユーザー側に認めてもらった。最終的には，スケジュールへの影響は2週間以内に収まった。

　仕様変更はこれだけではなかった。変更要求を開発現場に持ち帰るたび，奥山氏は開発者から突き上げられていた。しかし一方で，仕様変更に時間を要し納期が遅れるとなれば，ユーザーに仕様のスリム化をかけあうこともあった。実際，ネット銀行からデータを受けて顧客の入金処理を行う仕様が当初スコープに入っていたが，優先順位が低いことから第2フェーズの開発に回した。

画面とロジックをAPIで分ける

図3●画面とロジックの切り分け方法 画面や画面遷移の部分は，アプリケーション・フレームワーク「Struts」を用いて開発。ロジック部分は，ファイテックラボ・ジャパンのミドルウエア「xTrade」を用いた。StrutsのモデルでxTrade上のロジックをAPIで呼び出す形にしており，APIを変えなければロジックと画面のお互いの変更に影響がない

　束ね処理では画面の変更がロジックの変更に影響した。しかし，画面と注文方法などのロジックは，できるだけお互いに影響を及ぼさないようにしたかった。そのためにまず，画面部分の開発には，オープンソースのアプリケーション・フレームワーク「Struts」を使った。Strutsで画面と画面遷移を開発するが，ロジックを記述する“モデル”部分には，ロジックを呼び出すAPIだけを置く形にした（図3[拡大表示] ）。

　ロジックは，金融系のアプリケーション・フレームワーク「xTrade」（ファイテックラボ・ジャパンが開発）を使って開発した。Strutsのモデルからロジックを呼び出すAPIはxTradeのクライアントとなる。このAPIに変更がない限り，画面を変更してもロジックに影響が出ない。

　このような階層構造を採れば，一般的に性能への悪影響があるが，「トータルでの性能目標はクリアしている」（奥山氏）と言う。xTradeは，開発のフレームワークであると同時に，オブジェクト-リレーショナルのマッピング機能を持つデータベース・アクセスや，データのキャッシング機能を備えるミドルウエアでもある。このキャッシング機能が「性能面で効いている」（奥山氏）との見方だ。

　また，こうしたミドルウエア部分の開発をフレームワークに任せたことも，短期開発につながった。これにより，基盤部分の開発は飛ばし，ロジックの開発から入る「ジャンプ・スタート」となった。また，開発作法をフレームワークが持つルールに合わせたことで，標準ルールの作成作業を省けたことも大きいという。大勢で開発する場合，標準化や基盤の開発が必要で，それには時間がかかるものだ。

　これらの工夫はしたものの，「仕様変更がうまく吸収できたとは言えない。結果的に工数追加になった。期間があればもっときれいに進められたはず」と奥山氏は考えている。ただ，期間が短く詳細を詰める時間も取れないなか，なんとか予定を大きく遅れることもなく乗り切った。アジャイル開発プロセスのような手法を意識せずに進めたが，振り返ってみれば，アジャイル開発の思想に重なる部分もあった。