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

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

詳細設計と実装フェーズ

　本プロジェクトでは先行して「ITアーキテクト」を指名しました。ITアーキテクトは以下の項目を重要な要素として選び、指名します。

• デザインパターンが理解できる＝他者に仕様の概要を伝えられる
• J2EEプログラムに限らず、APPサーバやシェル、DB周りなど、比較的広い技術の適合性を知っているか、知らなくても調査できる
• 他者への展開を前提として、テストや、仕様からPGへの落とし込み方法などまで、意識して検討できる

　今回指名したのは2〜3名です。技術や実装において“とがった”思想を持つ人物に依頼しました。

　彼らは早速、想定されている環境を前提として、ローカルマシンにアプリケーション・サーバやデータベースをインストールし、簡易版の機能を作成しました。いわゆるプロトタイプの作成です。この段階で、技術的な素養、チームへの適合性などを確かめます。そして、実際に機能の1つを適当な仕様で作り、実装者の多くにITアーキテクトの作成したプロトタイプのまねをしてもらい、実装作業の簡素化を目指しました。

　プロトタイプは実装方法の横展開を容易にするだけでなく、コーディング規約を反映させて規約の横展開も容易にします。特に、規約のような（プログラムの動作にあまり影響しない）ものは、実装者がコード上だけで指針を読み取れるようにできる仕組みを作っておくべきでしょう。実装のたびにコード規約を読み直すのは効率のいいことではありません。このような方法は、規約に準拠したコードを得るうえでも非常に効果があります。

　なお、今回、コード規約を作成しましたが、その細かい規定はチェックスタイルで自動化を図りました。結果として、コードの品質を統一することに有効でした。

　実装の一環として行う単体テストにはJUnitを使用しました。失敗したのは、JUnitで完全に自動化すべきところを、SQLだけを外に出したために、データの設置をあらかじめ手で行わねばならず、完全に自動化ができなかったことです。実装者からの評判もあまり良くありませんでした。

図6 「いろいろな基幹システム」図

　MQで苦労したのは文字コードです。金融の基幹システムではどんなささいな文字化けも許されません。システム連携で使用することが決められた文字に関しては、100％フォローする必要があります。このときに、VMベンダ（例えばIBMなど）の文字コード指定は、結構な数の文字を化けさせることがあります。

　よくWebで「〜」などが文字化けしてマッピングをすることと思いますが、それとは別の次元で、全文字のテストが必要です。

　実際金融機関はNEC、IBM、富士通などのそれぞれの汎用機が独自に拡張した文字コードを投げ込んできます。VMの文字コードの指定によってMQは自動的に文字コードをカバーしようとしていますが、実は中には「〜」のように特定の文字だけ化けるケースがあります。その際に化けたコードを対応すればよい……とはなりません。多くの金融基幹システムは、解釈できない文字があるとその場でアベンドします。そのときに、もし本番稼働後であれば、かなり厳しい責任追求が待っているでしょう。

　またVMベンダにクレームを付けても、アプリケーションが動作している環境の問題を理由に完全なフォローをしてもらうのは非常に難しいことが予想されます。

メーカーのMQは使うのが難しい

　基幹システム連携用のアプリケーションはたくさん出ています。MQ、HTTP、FTP、HULFT、Webサービスなどを統合的に扱い、1つのロジックから自由に呼び出せることを想定した、基幹統合プラットフォームはかつて、CORBAも含めさまざまな試みが行われてきました。しかし、それらのアプリケーションを使うには、いくつかの重要なリスクを伴います。

それは、

1. 非常に高価
2. 利用できるアーキテクト、実装者が少なく、サポートをベンダに依頼すればコストがかさむ
3. 基幹システムの連携は、往々にして連携すべきシステムが複数のベンダにまたがる。統合を提案したベンダも、「他ベンダの仕様」に当たる基幹システムの責任は負えないケースがほとんど

などです。

　本システムでは、基本的にベンダの提供するその手のモジュールは一切使わず、デザインパターンを用いて、オリジナルを作成しました。

　MQはもともと、そのシンプルさが堅牢さに結び付いている部分があり、実装もシンプルにまとまるケースが多く、統合アプリケーションを利用しなくても意外と開発コストが掛かりません。もちろん、テストのコストはミッションクリティカルなシステムだけに十二分に掛かりますが、それはベンダの統合アプリケーションを入れても同じことでしょう。他社の基幹システムやオリジナルの環境での動作をベンダが手放しで保証するわけがなく、結局、製品を使っているいないにかかわらず、非常に入念なテストが必要になるでしょう。

「開発現場の天国と地獄」バックナンバー

• 設計の落としどころ （後編）〜J2EE金融基幹システムの構築現場から〜
• 設計の落としどころ （前編）〜J2EE金融基幹システムの構築現場から〜
• 第4回 そして、システムはお蔵入りとなった
• ベテランならホントに安心なのか？
• 真のボトルネックは“顧客”なのか？
• “完璧な設計”がプロジェクトを失敗に導く！？