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

　前回から引き続き、プロジェクト5 「半年以下で金融基幹連携システムをJ2EEで構築」の事例レポートをお送りします。前回の最後でプロジェクトの実装フェーズに到達しました。後編である今回は、実装チームの運営方法から話を進めていきます。（＠IT編集部）

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

層割と機能割

　実装チーム分けはアプリケーションを「層割」することにより行いました。今回の構築するアプリケーションは、基幹システム連携向けのMQインターフェイスと、オペレーター向けWebインターフェイスの2種類のインターフェイスがモデルを呼び出すものでした。

　 「層」で分かつときに非常に重要な要素が「役割」を明確化することです。この場合、インターフェイスはファサード（受付係）を境に分けることになります。具体的には、役割として今回はJ2EEでしたので、MAPをインターフェイスにしてMQやWebなどのインターフェイス層、ロジックとデータベースのモデル層に分けました。

図1 「アーキテクチャ」図

　インターフェイス層の役割は、画面やMQなどのシステムの外、ユーザー入力や連携するシステムの投げ込んでくる値を共通のビジネスロジックに通すための「通訳」「変換機」「門」のイメージです。「門」の仕事は、HTTPやMQといったプロトコルの異なる要求を共通のインターフェイスにそろえて、ビジネスロジックへとつなぐ役割をします。その際、同じMQでも汎用機ですからさまざまな文字コードへの対応や、そのホストコンピュータ独特のエラー処理や電文の構成方法など、汎用基幹にある細かい差分を吸収する役割も持ちます。

　また、ホストコンピュータのシステムでは、帳票をテキストファイルイメージで送付するケースもあり、その電文のレイアウトを調整して帳票として送付する必要もあります。

　本来、基幹連携システムの帳票や画面のような「View」の部分は、その「役割」からいっても、表示するシステム自身が責任を持つべきです。しかし、実際にはすでに実装され、稼働しているシステムの仕様は、しばしば「あるべききれいな仕様」に勝ってしまいます。

　全国の金融機関の窓口支店で稼働している端末を入れ替えずに、基幹だけを入れ替えるようなケース。あるいは、一部のみの交換のため従来の仕様を背負い続ける運命を、新システムは持っています。

　例えば、システム化される前にあったレシートプリンタ型の業務システムにおいて、そのレシートのイメージをそのままテキストとしてやりとりしているケースが今回当てはまりました。

　正確にはレシートプリンタのイメージを「現在の基幹は、そのままクライアントの画面に表示している。」という状態でした。新システムもそのまま、同じ仕様を要求されたのです。HTMLの代わりにレシートのイメージが飛び交うシステムを想像してみてください。非常に奇妙に皆さんにも思えるでしょう。しかし、前述のようにしばしば、こういたった「奇妙な仕様」を新システムが取りこまなければならないのです。

　このような特別な要件に対応するときは、ベンダが提供する統合ツールを導入してもカバーし切れず、どうしても手作りが必要になります。そのため、カスタマイズどころか結局は、その統合ツールと似て非なる機能を作る羽目に陥ります。その瞬間にコストは大幅に上がり、本当に統合ツールによってコストが下がるかどうか、非常に微妙な判断となります。

　本件では、MQの実装に関して十分な経験があるメンバーから上記のような提言を受け、早々と「手作り」を決定しました。

　もっとも、手作りにも難はあります。

　作るのはかまいませんが、やはり、製品を使えば作らずに済んだ仕様書の作成、テストの実施、テスト仕様書などの文書の作成といったコストは決してバカになりません。ただし、金融機関のようなミッションクリティカルな場面において、稼働後にベンダ製品のリスクを抱え込み、ユーザーとベンダの板挟みになる危険を回避することにしました。手作りにより確実にリスクを自分たちの手で回収できるという状況をコストに置き換えたとき、どちらが長期的視野で低リスク・低コストとなるかは十分検討に値するでしょう。

　話を元に戻しましょう。実装チームの役割を、「層」と「機能」の両方で分けました。具体的には、ファサードを介した「共通」といわれるファサードに至るまでの機能と、Enterprise Java Beans（EJB）に実装されるモデル部です。まず層によるチームの分離です。

　このとき、共通といわれる側の仕様は単純です、MQやWebをMapに変換して、正しく処理すべきモデルに引き渡す。この一言でいい切れてしまいます。それに対して業務機能とは、例えば見積もりがあり、契約があり、……といったふうに説明すればそれだけで、楽に数百ページの仕様書を作ることができます。このことは、システム構築の場合に、「層」で切り分けると、往々にして「仕様は狭いが、技術は深い」機能と、テンプレートの上に業務を記述していくような「仕様は広いが、技術は浅い」部分とに切り分けることができることを示しています。

　「仕様は狭いが、技術は深い」方は、例えば「MQをMAPに効率よく変える仕組みを作ってください」といわれたときに臆することなく、コードを書き始めることができる人に向いています。これに対して「見本をください。見本をもらえれば仕様書をプログラムにします」という実装を望む人がいます。そういう方はむしろ、「顧客と会話をし、話をまとめ実装に落としてテストをする」方が向いているかもしれません。

図2 仕様の広さ、技術の深さ

　 また、ある程度の規模のプロジェクトになり人数を集めると、大抵数人は非常に技術にとがった、あるいは技術が好きな人々がいます。そういった人は、この場面のような「狭くて深い」機能を任せるのに非常に向いています。彼らが、「狭くて深い技術が必要な機能」を担当します。対して、コード実装の前に要件をまとめるには、顧客の多くの担当者から話を聞いたり現場に行ったりしなければいけません。多くの担当者からヒアリングをする時点で、すでに人手は必要になっているのです。この担当者たちは「広くて浅い技術が必要な機能」を担当するようにしました。

　ある程度の規模のプロジェクトで、コード実装の前に要件をまとめるには、顧客の多くの担当者から話を聞いたり現場に行ったりしなければいけません。多くの担当者からヒアリングをする時点で、すでに人手は必要になっているのです。

　今回、手法としてはまず「層」に分けましたが、前述のような理由で、「共通」は数名「各機能」は数十名ほどになりました。短納期ということもあり、詳細設計と実装を並行するために、詳細設計フェーズですでに人員は実装規模の70％程度まで増やしました。このことは、設計と実装の乖離（かいり）を防ぐ効果がありました。また、短納期で、微に入り細を穿（うが）った仕様書を作成せず、そのまま設計者が実装をしたか少なくとも目の前にる設計者に相談して実装に入れたからです。

　また、金融系システムの宿命ともいえるのかもしれませんが、「論理」自体が企業秘密でした。そのため、実装を顧客の社員の方が実際にJ2EEでコーディングし、そのパッケージ（jar）を提供する形でした。実際に金融会社の社員が実装を行うところは非常に面白いともいえます。

　ただ、プロジェクトを請けた方としては、「責任分担があいまいになる」「テストは結局こちら側でしなければならない」「スケジュールや品質の調整コストが掛かる」などの問題も発生します。しかし、実際にやってみて思うのは、現場同士に相互理解が生まれるという大きなメリットもあるようです。また、移行や運用の構築を若干スムーズにする側面もありました。