設計の落としどころ （前編）〜J2EE金融基幹システムの構築現場から〜：開発現場の天国と地獄（5）（2/4 ページ）

[佐藤大輔，オープントーン]

（2）概要設計、要件定義、プロトタイプ作成

要件定義フェーズ

　要件を収集するため特に特殊な手法は利用しませんでした。顧客のシステム部門がまず業務のフローを書き、そのフローの中でシステム化予定部分を洗い出し、その予定部分の実装手段を検討する、という普通の手法です。同時に実装方式やフレームワーク、基盤などの話を進めました。

　その際、Webサービスの利用も検討しました。しかし、SOAPでのXML通信が、金融系基幹システムで処理する膨大なトランザクションを問題なく処理できるかどうか、事前に実証実験を行う必要がありました。また、基幹システムの場合、どうしても既存の汎用機システムとの連携を検討しなければなりません。すでに汎用機で稼働しているシステムに対し、新たに費用を掛けてWebサービスに対応可能な機構を組み込むことは、予算面でも安定稼働面でも非常に困難です。今回もこのような理由でWebサービスは採用しませんでした。結局、MQで実装することになったわけですが、ここで新たな問題が発生しました。J2EEでのMQの実装例が少ないため、既存の汎用機のシステム仕様に合わせて対応しなければならなくなったのです。

　システム連携の場合、既存システム側の仕様に合わせて、新たに構築するシステムに理不尽な仕様を盛り込まざるを得ないケースがよくあります。設計者は、いつリプレースされてもおかしくない汎用機のシステムが、コストを掛けて改修される可能性はほとんどないことを覚えておくべきです。

概要設計フェーズ

　設計の際に非常に気を使ったのが、ほかの金融機関の基幹システムと連携するためのインターフェイスです。効果的だった手法があります。力関係の強い会社があらかじめ「インターフェイスはこれにしなさい」と決めてしまうことです。「きれいな設計」や「十分に実装を踏まえた検討」などを抜きにして、一番強い会社が多少理不尽な仕様でも、これでしなさいと押し付けてしまうのは、意外とリスクを下げる効果があります。

　いくら効果的で、きれいな設計作業を行っても、後から力の強い会社が一方的に仕様変更を要求してきた場合はそれに従わざるを得ません。非常に理不尽な変更でも避けられない場合がほとんどだと思います。ところが、力関係の強い企業が先に「これでいきなさい」と決めてしまうと、実装作業を行う企業（スタッフ）は工夫（無理な工夫を含めて）を凝らしながら、なんとか乗り切ろうとするものです。つまり、実装する作業者から見て多少理不尽な仕様でも、業務要件を満たす、絶対に揺らがない仕様はそれだけで「よりどころ」としてプロジェクトのリスクを大幅に下げる効果を持つのです。

図2-1 「話あって決まらない」する図

図2-2 「一番強い会社が命令」する図

大人数の実装チームにどうやって、フレームワークを伝えるか

　J2EEでよくあるWebシステムと違い、MQを用いた基幹システムには「一般的な」フレームワークというものは存在しません。そもそもMQを前提とした基幹システム連携において、J2EEでのシステム構築はようやく散見される程度の段階であり、まだまだ一般的なシステムの形式とはいい難い状況です。

　結論からいうと、今回はフレームワークとしてObjectWorksを利用しました。ただし、ObjectWorksはWeb実装のためのフレームワークであり、J2EEのMQ実装に向けて作られたフレームワークではありません。そのため、フレームワークによる実装の範囲は、システム全体から見ると狭いものになってしまいました。

　このような場合、ITアーキテクトはどうやって設計を進めればよいのでしょう。ITアーキテクトや実装者の目から見て、従来のツールや経験では補い切れないシステムを構築する場合にはデザインパターンが非常に有効に機能します。

フレームワークはファサード

　今回ファサードのパターンを応用して、モデル部とインターフェイスを分けました。そのうえでプロトタイプを実装し、ひな型をコアメンバーが提供しました。そのひな型に沿ってコード記述を行っているか、アーキテクトが監視しました。

図3 アーキテクチャ簡易図