開発プロジェクトの3つのねらい
しかし、ユニケージ開発手法の処理速度がいくら速いといっても、いきなりCIS（営業料金システム）の中心部に導入することは容易ではない。このため、CISのWeb化開発プロジェクトで、いくつかのビッグデータの処理に適用し、試行してみることになった。
今回の試行プロジェクトは、現在メインフレームと専用端末で動作しているCISをWeb化することが目的である。
Web化によって、端末IDによる統計処理ができなくなるため、ユーザーID（利用者）による統計処理を実装することが必要となった。今回の試行的に適用する実証試験は、次のような「3つのねらい」をもって行われた。
- 【第1のねらい】 営業料金システム全店のオンライン実行ログを日次処理する必要があるため、
⇒ 高速なログ集計処理を実現すること。 - 【第2のねらい】 統計処理という業務特性から、今後も集計キーや集計項目が変更される可能性があるため、
⇒ 保守性や開発生産性を高める柔軟な対応を実現すること。 - 【第3のねらい】 近い将来の大規模バッチ処理の実装に備えたITスキルの向上を図りたいため、
⇒ バッチ処理の高速化技法を習得すること。
この3つのねらいは、従来のメインフレームの処理では処理コストが高いため、処理コストの安いサーバで短期間、かつ低コストで実現するというねらいもあり、ユニケージ開発手法を試行適用することになった。
Web化開発プロジェクトでの試行システム
図7に、Web化開発プロジェクトでの試行システムを示す。
諸データは、図7の上部左に示す業務サーバとその右に示すメインフレームから業務実行ログを取得し、下段に示す「稼働統計（ログ集計）バッチサーバ」で日次集計、月次集計処理を行いDB（データベース）へ蓄積する。ここに蓄積されたデータは、業務主管部がオンライン画面（Web）から参照・分析を行うという仕組みである。
図7の左上の業務サーバは18台設置されているが、この業務サーバには、システムの稼働ログが、UJ（ユーザージャーナル：履歴情報）として蓄えられる。その中から、必要な今日の処理分を抽出して、ファイル転送を行う。また、メインフレームは各支店別（東京、神奈川、千葉、埼玉、山梨、群馬……。合計10台）にあり、こちらにもUJがあるが、それは図7左下のように、一括でファイル転送をかけて稼働統計（ログ集計）バッチサーバ（バッチ処理専用のサーバ）に送られる。
図7 Web化開発プロジェクトでの試行システム概要
この稼働統計バッチサーバで、赤枠（ユニケージ開発手法の適用場所）で示すホスト集計、サーバ集計の処理（毎日1回夜間に集計）が行われる。
そのデータを組織のコード（符号）に置き換えて、組織単位で集計する。また、料金の補正がどこで何回行われたかというような集計も行われ、これがデータベースにインポート（入力）され日時累積データとして集積される。
最後に、月次（青い点線の枠）ということで月に1回行われているが、約30日分のデータをエクスポート（出力）して集計し、仕分け処理をし、月次累積データが作成されている。現在、稼働統計バッチサーバは、2コアのUNIXのサーバとなっている。
