計測自動制御学会産業論文集
Vol.4, No.12, 81/90 (2005)

帳票のイメージデータ化と疎結合コンポーネント接続による銀行営業店後方事務処理システムの開発
染谷 治志＊，森 有一＊，阿部 正弘＊，町田 勇＊＊，長谷川 篤＊＊＊，吉江 修＊＊＊＊
Development of Centralized Processing System for Back-office Operations in Bank Branches using
Form Image Data and Loosely Coupled Component Connection Method
Harushi Someya＊, Yuichi Mori＊, Masahiro Abe＊, Isamu Machida＊＊, Atsushi Hasegawa＊＊＊, Osamu Yoshie＊＊＊＊Abstract：Due to the deregulation of financial industry, the branches in banking industry need to shift to the sales-oriented bases fromoperation-oriented bases by rationalization of back-office operations. It is subjects how the back-office operations systematizes and how thesystem development cost is reduced.
In this paper we propose a centralized processing method that directly inputs forms in a computer as image data by a non-contacting
image scanner, transmits to a centralized operation center and then processes back-office operations centrally by workflow. By this method,
rationalization of the back-office operations and reduction of the operational cost are able to be accomplished. Also we propose a client
application architecture that has a loosely coupled component connection method, and allows developing the application by only describing
the screen configuration and their transitions in XML documents. By proposed architecture, it raises the reusability of the components, canlocalize the customize range and allows users to easily develop applications.
By adopting proposed system measures, we developed the centralized processing system of the back-office operations in the banking
branches. We checked quantitatively the rationalization effect by this system. And we verified the software productivity of the proposedclient application architecture, our experiments demonstrate good performance.
Keywords：Back-office operations in the banking branch, Centralized processing, Image data,
Loosely coupled component connection method, XML
る．その結果，各種文書や帳票が電子化され，ペーパレス

1. はじめにが進んできている．ところが，銀行営業店においては，自情報通信技術の発達により，エレクトロニックコマース

行が店舗内に備え付けている定型帳票（制定帳票）のほかや企業におけるIT化が進展してきている．また，社会基盤にに，税金や公金帳票，一般振込み帳票などの諸帳票（非制

おいても，電子政府1)やe-Japan戦略Ⅱ2)にもとづくIT基盤を定帳票）が多く，紙ベースの現物処理（帳票事務）が依然活かした社会経済システムの積極的な変革が進められていとして残り，ペーパレスが進んでいない状況にある．
銀行営業店における帳票事務は，窓口で顧客と直接やり＊（株）日立製作所システム開発研究所〒244-0817 神奈川県横浜市戸塚区吉田町 292 番地
Hitachi, Ltd., Systems Development Laboratory
292 Yoshida, Totsuka, Yokohama, Kanagawa 244-0817＊＊
日立オムロンターミナルソリューションズ（株）〒141-0032 東京都品川区大崎 1-6-3
Hitachi-Omron Terminal Solutions Corporation
1-6-3 Osaki, Shinagawa, Tokyo 141-0032＊＊＊（株）日立製作所金融システム事業部〒212-8567 神奈川県川崎市幸区鹿島田 890 番地
Hitachi, Ltd., Financial Systems Division
890 Kashimada, Saiwai, Kawasaki, Kanagawa 212-8567＊＊＊＊
早稲田大学大学院情報生産システム研究科〒808-0135 福岡県北九州市若松区ひびきの 2-7
Graduate school of Information, Production and Systems,
Waseda University
2-7 Hibikino, Wakamatsu, Kitakyushu, Fukuoka 808-0135(Received May 12, 2005)

取りをする窓口事務と，窓口の後方で顧客から受け取った帳票や書類の事務処理を行う後方事務に大別される．後方事務では，印鑑の確認や不正送金のチェックなど，正確な取引の実現と内部不正を防止する目的で，帳票およびその事務処理結果に対して二重三重のチェックが行われている．預金や為替の例では，業務プロセス全体の 70%〜80%が営業と直接関係がない事務処理で占められており，後方事務要員は営業店人員の約 20%〜30%を占めているという
報告(3)がある．このことが，営業店の取引コストを，インターネットバンキングの約 8 倍3)と，他のダイレクトチャネルに比べて非常に高くする原因となっている．その結果，営81計測自動制御学会産業論文集
Vol.4, No.12, 81/90 (2005)
業最前線のデリバリーチャネルである営業店は，「事務」主文書で記述することでアプリケーションを開発できる，帳体のオペレーション拠点となっている．

票処理クライアントアプリケーションアーキテクチャを提日本版金融ビッグバンに代表される規制緩和などによ案する．これらのシステム化方式により，各営業店で実施

り，金融機関を取り巻く環境が大きな変革期を迎え，銀行していた後方事務を集中事務処理センタに集約でき，事務業界では多様化する顧客ニーズや新業務・新サービスへのを合理化し事務コストを低減することができる．また，疎迅速な対応が求められている．このため，帳票事務の徹底

結合コンポーネント接続方式の導入により，コンポーネン

的な合理化により，営業店を「営業」主体のセールス拠点

トの再利用性が高まり，カスタマイズも容易でアプリケーへと変えていく必要がある．依然として残る現物処理（帳ションの開発コストを低減することができる．提案するシ

票事務）の合理化をどのようなシステム化方式で実現する

ステム化方式を採用して，銀行営業店の後方事務の集中事かが課題である．また，制定帳票や非制定帳票など多種多務処理システムを開発した．このシステムの導入による事

様な帳票の処理アプリケーションの開発コストをいかに低務合理化効果を定量的に確認するとともに，提案アーキテ

減していくかも，システム化する上での課題である．

クチャの生産性検証評価を通じてその有効性を確認した．

帳票処理の分野では，電子帳票アプリケーションパッケ

2. 銀行営業店における帳票事務合理化の課題

ージソフトウェアが種々実用化されている．銀行営業店窓口で扱う帳票をこのパッケージソフトウェアで実装するこ銀行業界では，これまで顧客サービスの向上や取引コスとが考えられるが，制定帳票は可能としても，非制定帳票ト削減に向けた事務の合理化を図ってきた．帳票事務に関すべてを実装することは非現実的であり実質上不可能であしても，銀行の公共性や社会的責任をまっとうする厳格性

る．なぜなら，非制定帳票の発行側にも同様のパッケージと正確性を保ちつつ，徹底的な事務オペレーションの合理

ソフトウェアを導入してもらわなければならないからであ化を進めてきた．しかし，規制緩和などによる経営環境のる．また，銀行によって使用するパッケージソフトウェア

変化から，さらなる合理化が求められている．帳票事務にが違えば，非制定帳票の発行側はすべてのパッケージソフおける合理化ポイントは，先に述べた通り，多くの人手とトウェアに対応することになるか，あるいは顧客に同じパ時間を要している後方事務にある．Fig.1 に為替業務におけッケージソフトウェアを使用している銀行での取引を強いる後方事務処理例を示す．銀行営業店窓口で顧客から受けることになる．すなわち，非制定帳票の発行側のコストに見合ったメリットが見出せず，あるいは顧客サービスの低Bank branch

下を招くことになるからである．制定帳票だけをパッケー
Back-office
operations

ジソフトウェアで実装した場合，制定帳票と非制定帳票とContents checkTransmitting check

Officer

で事務が異なり，かえって事務を複雑にすることになりかねない．

Formal check

一方，帳票アプリケーションの開発分野では，

Temporary input

XML(eXtensible Markup Language)とスクリプト言語を組み

Acceptance合 わ せ た 帳 票 ア プ リ ケ ー シ ョ ン 言 語 XFA(XML Form

Dealings execution

Clerk 2

Clerk 1

Clerk 3

Receipt issue
CounterArchitecture)4),5)が提案されている．また，多種多様な帳票でCustomerは類似項目が多いことから，GUI(Graphical User Interface)やFig.1 Example of back-office operations

業務ロジックをソフトウェア部品（コンポーネント）化して，これらを組み合わせてアプリケーションを開発していくコンポーネント指向の開発方法6)〜11)がある．しかし，ス取った帳票は，各事務の担当者に回付されて事務規定に則クリプト言語によるコーディングが必要であったり，コンり処理されていく．この後方事務を電子化して担当者の PC

ポーネント間が密結合となるためにカスタマイズ性が悪かでオペレーションできるようにすれば，紙ベースの帳票をったりと，開発コストを低減する開発環境としては不充分

担当者に回付する時間（立ち歩き時間）の削減が期待できである．

る．また，ある営業店で後方事務量が 0.5 人分あるとすると，

本稿では，銀行営業店と顧客や非制定帳票の発行者との1 人の担当者が必要になる．これと同じ事務量の営業店があインタフェースやプロセスを変更することなく帳票をコンれば同じく 1 人，合計 2 人の人員が必要になる．各営業店

ピュータ内に直接取り込み，ひとつの事務センタ（以下でで分散して事務処理をしているため，合計 1.0 人分の事務量

は，この事務センタを集中事務処理センタと記述する）にに対して 2 人の人員を配することになる．後方事務を電子集約して集中処理するシステム化方式を提案する．また，化できれば，その事務処理を集中化することが可能であり，集中事務処理センタには多種多様な帳票が集まり，これら

2 人要していた人員が 1 人で済むようになり，事務合理化とを処理するアプリケーションの開発コストを低減するた取引コストの削減が期待できる．

め，コンポーネント間を疎結合する接続方式を導入し，画これを実現するためには，現物の帳票をどのように電子面を構成するコンポーネントの接続関係と画面遷移を XML化するかが課題である．最近実用化されている電子帳票ア82

計測自動制御学会産業論文集
Vol.4, No.12, 81/90 (2005)
プリケーションパッケージソフトウェアの活用が考えられるが，先に述べたように実質上不可能である．また，帳票にバーコードを付けバーコードリーダによって電子化する案もあるが，パッケージソフトウェア活用案と同様，すべInput Field(Transfer Item)

Reference ofTransfer Item

Logic for Transfer Date
Division (Adjudication of Transfer Item)ての非制定帳票にある決められた仕様に従ったバーコード

Update Transfer Date Division

を付けることは実質上不可能である．したがって，外部（顧Reference ofTransfer Item

客や非制定帳票の発行者）とのインタフェースやプロセス

Reference ofTransfer Date
Division

Logic for Transfer Date
(Adjudication of Transfer Item)を変更することなく，帳票を電子化してコンピュータ内に取り込むシステム化方式を検討していかなければならな
い．

Input Field(Transfer Date Division)

UpdateTransfer Date

Input field(Transfer Date Item)

Fig.2 Example of dependency relations among components

ところで，銀行営業店で扱う帳票は多種多様であり，帳票を処理するアプリケーションの開発コストが問題となってくる．帳票は多種多様であるが，種別（たとえば，振込みに関わる帳票）によって，起票項目がほとんど同じ場合てのコンポーネントを変更する必要があるため，カスタマが多い．帳票内の各項目には，口座番号の桁数チェックやイズが容易であるとは言い難い．

支店コードの存在確認など各種業務ロジックが設定されて本稿では，営業店窓口と外部とのインタフェースやプロいる．しかし，同じ種別でも種目（たとえば，一般振込やセスを変更することなく，帳票をコンピュータ内に取り込

給与振込）によって項目に設定する業務ロジックが異なっむ手段としてイメージスキャナを用い，帳票のイメージデ

たり，項目間のチェック内容が異なったりするなど項目間ータをワークフローで集中事務処理センタに集約して後方の関連に相違がある．これらは銀行独自の事務規定に則っ事務を集中処理するシステム化方式を提案する．また，画ているもので，銀行によっても異なる．また，新たな帳票面を構成するコンポーネントの接続定義および画面遷移定の追加や帳票の項目追加・削除が頻繁に発生する．そのた義をXML文書で記述することでアプリケーションを開発すめ，帳票の項目追加・削除，帳票の文言の修正やシステムることができる，帳票処理クライアントアプリケーション

メッセージの表現修正など，些細な変更はユーザ自ら行う

アーキテクチャ14),15)を提案する．本アーキテクチャでは，イことでコストダウンを図り，変更に早期対応したいという

ベントアダプタ12),13)にデータオブジェクトを内包させた拡

ユーザニーズもある．したがって，集中事務処理センタの張イベントアダプタを用いることにより，コンポーネント

帳票処理クライアントアプリケーションの開発において間の依存関係を緩やかにしてコンポーネントの独立性を高は，再利用性が高く，かつカスタマイズが容易で，ユーザめた接続方式を導入している．これらのシステム化方式に自身による開発を可能とする開発環境の整備が必要であ

より，営業店の後方事務の合理化と事務コストの低減を図る．

ることができる．また，コンポーネントの高い再利用性が帳票アプリケーションの記述言語として知られているも得られるので，カスタマイズ範囲の局所化を図ることがで

4),5)

のに，XFA(XML Form Architecture)がある．XFAでは，GUIき，アプリケーションの開発コストを削減することができと業務ロジックはスクリプト言語でプログラミングする仕る．さらに，XML文書記述によりアプリケーションを実現様となっている．このため，GUIと業務ロジックの分離設計しているので，ユーザでも容易にアプリケーションを開発が図られておりそれぞれの再利用性は高いものの，業務ロすることができる．

ジックのカスタマイズ性とユーザ開発性の観点から上記課

3.

題に対して充分に応えられるものではない．多種多様な帳票の中で類似項目が多いことから，GUIや業務ロジックをコ

3.1 事務集中処理方式

ンポーネント化して，これらを組み合わせてアプリケーシ6) 〜 8)

ョ ン を 開 発 し て い く BML(Bean Markup Language)

システム化方式

事務集中処理方式の基本方針は，(1)銀行の営業店窓口とや外部とのインタフェースやプロセスが変わらないこと，(2)Curl9)〜11)などのコンポーネント指向の開発方法がある．Fig.2

また窓口行員に新たな手間と時間がかかるオペレーションに，銀行の為替振発業務をコンポーネント指向で開発したを発生させないこと，(3)さらに帳票事務オペレーションに場合の一般的なコンポーネントの接続関係を示す．為替振際して現物帳票の look and feel を大きく変えないことと，(4)発業務は，振込み帳票で指図された銀行口座に送金して債

立ち歩き時間を排除することである．これらの基本方針に権債務の決済を行う業務であり，送金種目（給与振込や一従い，帳票は人間の業務を集約したエッセンスであること

般振込など）によって送金先口座への入金日が異なる．前から，帳票をコンピュータに直接取り込み，その帳票を自述のように，帳票処理では項目間に複雑な依存関係がある

動回付して事務オペレーションを実施する考え方に基づきためコンポーネント間にも依存関係が発生し，コンポーネシステム化する．

ント間の接続は密結合となる．このため，カスタマイズが具体的なシステム実現方式は，(1)帳票のコンピュータへ

発 生 す る と 変 更 箇 所 に 依 存 す る す べの取り込み手段として，Fig.3 に示す非接触イメージスキャ
83計測自動制御学会産業論文集
Vol.4, No.12, 81/90 (2005)

Image
Input

Branch

Form
ATM
PC

Verification

TellerTerminal

Workflow
Form
Image

Seal
check

Fig.3 A non-contacting image scanner

Execution check

Workflow S erver

Centralized Operation Center
Fig.4 Overview of the centralized processing system
for the back-office operations

ナで帳票をイメージデータとしてコンピュータ内に直接取け取ったデータを案件として管理し，ワークフロー定義にり込む，(2)読み込んだ帳票イメージデータの集中事務セン

従ってクライアント PC に事務オペレーションの実行を指タへの伝送と事務規定に則り帳票を回付する手段として，示し，案件の進捗を制御する．クライアント PC では，事務ワークフローで実装する，(3)事務処理は，帳票イメージデ内容に応じた帳票処理クライアントアプリケーションが動ータをもとに事務オペレーションできるよう帳票処理クラ

作し，帳票精査（帳票内容の二次入力を行い，一次入力内

イアントアプリケーション（Webクライアントアプリケーシ

容との突合せを行うコードデータのチェックで Fig.4 のョン）で実装する．Fig.3 に示す非接触イメージスキャナは，

Verification），印鑑照合（Fig.4 の Seal check）や検印（取引帳票を所定の位置に置くだけで自動的に読み込む仕組みで実行可否の判定で Fig.4 の Execution check）などの後方事務あり，帳票の大きさ，厚み，皺，折り目や紙質にも対応す処理を行う．このように，営業店後方事務を事務集中処理

る自由度の高い手段である．また，読み込み対象である帳

センタに集約することで，事務の合理化・効率化を図って票の位置や方向合わせが不要であり，帳票種別の自動認識

いる．

による業務画面の自動索引も可能であるので，窓口受付事

事務集中処理センタのクライアント PC の操作者は事務

務におけるクイックオペレーションを実現することができ

行員や役席行員で，クライアント PC に対するオペレーショ

る．帳票イメージデータのコード化の考え方を示しておく．

ンをできる限り簡略化するために，前章で述べた帳票内の従来は一人目の行員が帳票内容をキーボード入力（一次入各項目に設定されている業務ロジックや項目間の関連チェ力）していたオペレーションを自動認識ソフトウェア18)で代ックなどは，帳票処理クライアントアプリケーションに実替し，二人目の行員が帳票のイメージデータを見てその内装する．このとき，帳票ごと個別にアプリケーションを開容をキーボード入力（二次入力）する．両者の入力内容を発していくと，似て非なるものを多数開発することになり，突合し，同じであればそれを正しいコードデータとして扱

開発コストが大きくなってしまう．そこで，次節で提案すう．違っていた場合，例外処理として，第三者（役席行員るアプリケーションアーキテクチャで，開発生産性を向上など）が両者の入力内容と帳票のイメージデータをもとにさせている．

正しいコードデータを入力する．使用する認識ソフトウェ
3.2 帳票処理クライアントアプリケーション

アは，その認識アルゴリズムに方向性特徴を用いた統計的識別方式19)を採用している．認識率は，活字で 99%，JIS規アーキテクチャ3.2.1 コンポーネント接続方式

格に準拠した手書き文字で 97%である．
Fig.4 に，集中事務処理システムの概要を示す．本システ

提案するコンポーネント接続方式は，①従来のようにコ

ムは，営業店の非接触イメージスキャナを設置した窓口端

ンポーネント間を直接接続する（コンポーネントから別の末，集中事務処理センタのワークフローサーバと事務オペ

コンポーネントを呼び出す）のではなく，仲介者（データレーションを行うクライアント PC から構成される．窓口端オブジェクトを持ち込んだイベントアダプタ）を介して間末の非接触イメージスキャナで，顧客から受け取った帳票

接的に接続する，②コンポーネントと仲介者とのインタフをイメージデータとして読み込む．このとき，同時に文字ェース仕様を共通化することにより仲介者の汎用性を持た認識を自動実行して，従来は人手で行っていた帳票の形式

せる，という考え方に基づいている．従来のような直接接点検（記入漏れチェックで Fig.1 の Formal check）や一次入

続では，接続元コンポーネントは接続先コンポーネントの力（記入内容のコードデータ化で Fig.1 の Temporary input）

インタフェース仕様が分っていなければならず，それが自を自動化する．読み込んだ帳票イメージデータと自動認識分の仕様を決定づけている．すなわち，依存関係を持ってした記入内容のコードデータを，集中事務処理センタのワいる．これに対して提案方式では，各コンポーネントは汎ークフローサーバに伝送する．ワークフローサーバは，受84

計測自動制御学会産業論文集
Vol.4, No.12, 81/90 (2005)

GUI
Component

XAP Component

GUI
Component

Individual Adapter

XAP Component

XAP Component

GUI / Business Logic
Component

GUI / Business Logic
Component

Individual Adapter

Individual Adapter

Individual Adapter

Re ference ValueXAP Component

Update Value

Common Interface
Extended Event Adapter

Extended Event Adapter①②

GUI / Business Logic
Component

GUI / Business Logic
Component

Individual Adapter

Individual Adapter

Extended Event Adapter
Data Object

Common Interface

XAP Component

Individual Adapter

Individual Adapter

Business Logic
Component

Business Logic
Component

XAP Component

XAP Component

XAP Component

Notification of
Value Update

Registry
Extended Event Adapter

Extended Event Adapter③④

Fig.5 A proposed method of component connection

Fig.6 Interfaces between XAP component andExtended Event Adapter

用的な仲介者とのインタフェース仕様だけで自分の仕様をが，提案方式では XAP コンポーネント間で直接の依存関係決定づけることができ，接続先コンポーネントの仕様とはを持たないため，データオブジェクトを介しての通知メカ

直接的な関係がない緩やかなコンポーネント間接続を実現

ニズムとなる．Fig.2 に示した銀行の為替振発業務は，提案している．これにより，コンポーネントの独立性と再利用接続方式によれば Fig.7 のようになる．

性を高めている．

提案接続方式により，コンポーネント間の依存関係を緩提案するコンポーネント接続方式を，Fig.5 に示す．本方

やかにでき，コンポーネントの高い再利用性が得られる．

式では，コンポーネント間を直接接続するのではなく，イまた，カスタマイズ発生時は，カスタマイズ対象 XAP コン

ベントアダプタにデータオブジェクトを内包した拡張イベ

ポーネントとデータオブジェクトとの接続関係を変更する

ントアダプタを導入し，コンポーネントと拡張イベントアだけでよく，カスタマイズ範囲の局所化を図ることができダプタに内包されたデータオブジェクト（以下では，単にる．アプリケーション開発者は，画面を構成する XAP コン

データオブジェクトを記述する）との接続関係で間接的にポーネントのデータオブジェクトを介した間接的接続関係

コンポーネント間を接続する．各コンポーネント，すなわと画面遷移フローだけを定義すればよい．この定義言語に

ち GUI コンポーネントや業務コンポーネントの実装方法は

Web 環境との親和性を考慮し，XML を適用することで提案規定しないが，各コンポーネントが有する個々のインタフ

方式のオープン性とユーザによる記述容易性を持たせていェースを Fig.6 に示す共通インタフェースに変換する機能をる．

持つ個別アダプタを用意する．この個別アダプタを有する
コンポーネントを XAP(XML Applications)コンポーネントと呼ぶことにする．

Input field(Transfer Ite m)

Fig.6 に示すデータオブジェクトと XAP コンポーネント間の 4 つの共通インタフェースは，

Extended Event Adapter( Trans fer Ite m)①XAP コンポーネントからデータオブジェクトの値を参照するメソッド②拡張イベントアダプタに登録された XAP コンポーネン

Logic for Trans fer Date Division(Adjudication of Trans fer Ite m)

Extended Event Adapter(Transfer Division Item)

Input Field(Transfer Date Division)

Logic for Trans fer Date
(Adjudication of Trans fer Ite m)

Input Field(Transfer Date Ite m)
Extended Event Adapter(Transfer Date)

トから当該データオブジェクトに設定されたデータ値を更新するメソッド

Fig.7 Example of relations among XAP components andExtended Event Adapters③拡張イベントアダプタに XAP コンポーネントを登録するメソッド④データオブジェクトのデータ値が更新された場合，当該拡張イベントアダプタに登録された XAP コンポーネントにデータ値の更新通知を行うメソッド

3.2.2 XAP アプリケーション構成

である．①は，XAP コンポーネント動作時に他の XAP コン

XAP コンポーネントの組み合わせでできあがるアプリケ

ポーネントにより更新されたデータオブジェクトのデーターションを XAP アプリケーションと呼ぶことにする．XAP

値を参照する場合に用いられるメソッドである．②〜④は，

アプリケーションは，Fig.8 に示すように，アプリケーショ

XAP コンポーネントの動作を契機に他の XAP コンポーネン

ンフレームワークとして提供される XAP コア，XAP コンポ

トを動作させたい場合に用いられるメソッド群である．従ーネント群（GUI コンポーネントと業務ロジックコンポー

来では，このような場合，コンポーネント中に他のコンポネント），画面定義，フロー定義及び Web ブラウザから構成

ーネントを動作させるためのイベントハンドラを記述する
85

計測自動制御学会産業論文集
Vol.4, No.12, 81/90 (2005)
フロー定義は，XAPアプリケーションの画面遷移フロー
をXML文書で記述したものである．フロー定義の各タグには，画面遷移フローに関する制御コマンドが定義されていScreenScreen Layout

る．XAPコアが，SAX(Simple API for XML)16)パーサの作法

Web Browser

GUI Logic

GUI
Component

に従い，フロー定義のXML文書の木構造を解析しながらタグの制御コマンドを実行していく．Fig.10 に示す画面遷移フXAP Components

Business Logic
Component

Business Logic

Flow Definition(XML Document)

GUI
Component

ロー例に対するフロー定義をFig.11 に示す．FLOWDEFタグ

XAP core¾Interpret screen configuration
definitions¾Generate and manage
extended event adapters¾Interpret screen transitions

は，フロー定義全体を意味する．XAPコアは，このルート

Screenconfiguration
configuration
ScreenScreenConfiguration
definition
definition
Definition(XML
document)(XML
document)(XML Document)タグであるFLOWDEFから処理を開始し，最初の子ノードであるTransactionタグを実行する．Transactionタグは画面表示の 制 御 コ マ ン ド で ， こ の 例 で は ， XAP コ ア

Fig.8 Configuration of XAP application

は”MainMenueForm”という名称を持つ画面定義によって定義される画面を表示する．フロー定義のために用意されたタグ一覧を，Table 2 に示す．

される．XAP アプリケーション開発では，GUI コンポーネントと業務ロジックコンポーネントの接続情報によって作

XAPコアは，XML文書で定義された画面定義の解釈，拡られる画面を記述する画面定義と，画面遷移を記述するフ張イベントアダプタのインスタンス生成と管理やフロー定

ロー定義を XML 文書でそれぞれ作成することになる．

義に従い画面遷移を実行するアプリケーションフレームワ

画面定義は，XAP コンポーネントとデータオブジェクトークである．Fig.12 にXAPコアの機能構成を示す．フロー定の接続関係を XML 文書で記述したものである．例として，

義を読み込み解釈するのが「フロー定義パーサ」で，フロFig.7 の接続関係を記述した画面定義を Fig.9 に示す．画面定ー定義XML文書をDOM(Document Object Model)17)の木構造

義のために用意された XML タグを，Table 1 にまとめる．

としてメモリ上に展開する．展開された木構造の各ノードを実行管理するのが「フロー制御エンジン」である．ノードが画面定義（Transactionタグ）の場合は「画面定義パーサ」に読み込むべき画面定義を指示し，ブラウザから画<?xml version="1.0" encoding="Shift_JIS" ?><XScript><XApplet name="振込種目フィールド"><XComponent name="入力フィールド" /><Parameter name="Text" value="EventAdapter;振込種目" /></XApplet><XApplet name="振込指定日区分フィールド"><XComponent name="入力フィールド" /><Parameter name="Text" value="EventAdapter;振込指定日区分" /></XApplet><XApplet name=“振込指定日区分判定"><XComponent name=“振込指定日区分判定ロジック" /><Parameter name="振込種目" value="EventAdapter;振込種目" /><Parameter name="振込指定日区分" value="EventAdapter;振込指定日区分" /></XApplet><XApplet name="振込指定日フィールド"><XComponent name="入力フィールド" /><Parameter name="Text" value="EventAdapter;振込指定日" /></XApplet><XApplet name="振込指定日判定"><XComponent name="振込指定日判定ロジック" /><Parameter name="振込種目" value="EventAdapter;振込種目" /><Parameter name="振込指定日区分" value="EventAdapter;振込指定日区分" /><Parameter name="振込指定日" value="EventAdapter;振込指定日" /></XApplet></XScript>

Display“FORM ”
MenuID=01

M enu
Selection

MenuID=99
End

Fig.9 Example of a screen configuration definition

Fig.10 Example of a screen transition flow

Table 1 XML tags used in the screen
configuration definition
Tag name

Attribute

XScript<?xml version="1.0" encoding="Shift_JIS"?><FLOWDEF><Transaction layout="M ainM enuFrom"/><SWITCH DID="M enuID"><CASE VALUE="01"><GOSUB NAM E="M enu01"/></CASE><CASE VALUE="99"><End/></CASE></SWITCH></FLOWDEF>

Description
Entire screen configuration definition

XAppletDefinition of each XAP component
name

XComponent

Name of XAP component instanceDefinition of component program

name
Parameter

Name of component program
Parameter of XAP component

nameParameter namevalue

Parameter value

Display“M enu01”

Fig.11 Flow definition corresponding to
the screen transition shown in Fig.10

86計測自動制御学会産業論文集
Vol.4, No.12, 81/90 (2005)
れたパラメータ値のセット）を抽出し，「XAP部品ローダ」へ通知する．「XAP部品ローダ」は，上記パラメータに基づ
Table 2(a) XMＬ Tags used in flow definition(flow control)
Tag name

Attribute

FLOWDEFきXAPコンポーネントを呼び出す．
以上のように，XAP コンポーネントはユーザの GUI 操作

Descriptionなどを契機として動作する．また，XAP コンポーネントは，

Root

SUB

Declaration of subroutine
NAME

EXITSUB

データオブジェクトのデータを更新する．データオブジェ

Name of subroutine
Termination of subroutine

GOSUB

クトのデータに更新があった場合，「XAP 部品ローダ」はそSubroutine call
NAME

SWITCHの拡張イベントアダプタに登録されている XAP コンポーネ

Name of called subroutine
Conditional branch

DID
CASE

ントすべてに対して，データオブジェクトの更新イベント

Conditional name of event adapter
Branch process

VALUEを通知する．更新イベントを受け取った XAP コンポーネン

Data constant for condition

DEFAULTBranch process

LOOP

Loop process

EXITLOOP

Termination of loop process

TRANSACTION_NODATA

Process in case of no data

トは，その仕様に基づき動作する．このようにして，たとえば GUI 操作→GUI コンポーネント→業務ロジックコンポ
ーネント→他の GUI コンポーネント→…，のような状態変化により，XAP アプリケーションの動作を実現している．
Fig.13 に，XAP アプリケーションの実装概要を示す．本図

Table 2(b) XML Tags used in flow definition(communication control)
Tag na me

Attribute

Upload拡張イベントアダプタのデータオブジェクトに文字列が設

Description
Trans mission to server

messageTransaction

定されていない場合，”Message ID”拡張イベントアダプタのName of telegram

データオブジェクトに設定されているエラーガイダンス ID

Communication with server
message

Name of telegram

layoutName of screen con figuration definition

fre eData clear

Queueを，”Guidance”拡張イベントアダプタのデータオブジェクトに設定する機能を示したものである．

Store in queue
message

Name of telegram

layoutName of screen con figuration definition

size

Look-ahead number

DequeueSequencer Trigger

Take o ff fro m queue
message

Name of telegram

layoutName of screen con figuration definition

Free

Error
Sequencer

Argument Switcher

Release data
message

Error

Name of telegram

Checker Trigger

System error
messageEndは，入力必須チェックロジックの実装例であり，”Input Data”

Guidance Trigger

Error message
End of system

Input Data

MessageID
Input Checker：XAP Component：Extended Event Adopter

Parameter Setter

Guidance：Write/Read Data Object in Extended Event Adopter：Receive Event from Extended Event Adopter：Send Event to Extended Event Adopter

Adapter Manager

Fig.13 Example of implementation overview
based on the proposed architecture

XAP Component Loader
Screen De finition
P arser

Screen Configuration
Definition

Flow Control Engine
Flow
Definition

Flow Definition P arser

4.

適用評価

提案したシステム化方式を採用して，営業店の後方事務
Fig.12 Configuration of the XAP-coreの集中事務処理システムを開発した．Fig.14 は，集中事務処理システムを含む銀行営業店システム全体の概要を示したものである．3.2 節で提案したクライアントアプリケーショ
ンアーキテクチャは，集中事務センタ内の為替業務クライ

面終了が通知されると次のノードを実行する．「画面定義

アントアプリケーションで採用している．その開発内容をパーサ」は指示された画面定義を解釈し，画面定義内のTable 3 に示す．アプリケーションのステップ数は，XML 文

XAppletタグ（個々のXAPコンポーネントに対する定義内容

書タグを 1 ステップとしている．Fig.15 は，為替振発業務のを表す）ごとにXComponentタグ（XAppletタグで定義された

一次入力オペレーション画面例である．

XAPコンポーネントの実体としてXAPコアにより起動され提案システム化方式により開発したシステムの導入によるXAPコンポーネント名を表す）で指定されたXAPコンポ

る営業店後方事務の集約効果として，営業店における事務ーネントのインスタンスの設定パラメータ（Parameterタグ

量を 75%〜55%に削減することができている評価結果を得のname属性で指定されたパラメータ名とvalue属性で指定さた．また，事務要員も 20%程度の削減を達成している．こ87

計測自動制御学会産業論文集
Vol.4, No.12, 81/90 (2005)

はソースコードのステップ数による比較が一般的である

Java
Applet
ATM

PC

Java
Applet

Image
Input
Form

Server AP

テップ数による直接比較が困難である．このためカスタマ

BranchApplication
ServerTellerTerminal

イズ比率を評価基準として用いることにした．カスタマイ
ズ比率とは，アプリケーションのカスタマイズに要したス
テップ数とその母体アプリケーションのステップ数との比

HubServers率である．したがって，尺度の異なる開発言語の開発生産

LegacyHostComputer

Form
Image
Execution checkードではなく XML 文書で記述するため，ソースコードのス( CORBA
Object )Workflow

Verification
Seal
check

が，提案アーキテクチャではアプリケーションをソースコ

Data Center

BranchWorkflow Server

性比較に用いることができる．比較実験は，銀行営業店シ
ステムの標準仕様版と，ある銀行向けにカスタマイズを行

CRM

Centralized Operation Center

った仕様版を対象に，Fig.15 に示した業務画面を取り上げて実施した．ある銀行向けに行ったカスタマイズの内容は，Fig.14 Overview of the banking branch system

手数料区分や手数料現金振替など 6 つの項目追加と，手数
料区分と種目（電信扱い／文書扱いなど）で整合性がとれているかなどの各項目に対するチェックロジックの追加である．

Table 3 Contents of development
XAP Component
Category
Business
Operation

Num ber
Steps

GUI
Parts

10

Cursor-control Strings Editing Date Processing
Parts
Parts
Parts

1

評価結果を Table 4 に示す．ここでは 4GL ビジュアル開発
Logic Control
Parts

Logic OperationParts

ツールのステップ数はソースコードの 1 行を 1 ステップと

12

4

22

4

換算し，提案アーキテクチャでは XML 文書タグを 1 ステッSingle Money Transfer
Multiple Money Transfers

Temporary Input of
Money Transfer

14516

used

used

used

used

used

プと換算した．Table 4 によれば，アプリケーション全体のVerification of
Temporary Input Data

12789

used

used

used

used

used

ステップ数は，提案アーキテクチャの方が一桁大きくなっ

Money Transfer Holding

9585

used

used

used

used

used

ている．提案アーキテクチャでは，たとえば，4GL ビジュ

Verification of Money
Transfer

6529

used

used

used

used

used

アル開発ツールでは 1 ステップで記述できる複数演算子含Temporary Input of
Money Transfer

18405

used

used

used

used

used

used

む計算式などは各演算子とデータ（拡張イベントアダプタ）

15908

used

used

used

used

used

used

との接続関係をすべて XML 文書で記述する必要がある．こMoney Transfer Holding 12855

used

used

used

used

used

used

のため，1 ステップの記述能力の違いにより，アプリケーシ

Verification of Money
Transfer

used

used

used

used

used

used

ョン全体のステップ数（XML 文書量）が多くなっている．

Verification of
Temporary Input Data7914

これは，提案アーキテクチャによる初期開発コストは 4GL
ビジュアル開発ツールに比べ大きくなることを表している．
カスタマイズにおける提案アーキテクチャの効果を考察する．まず，アプリケーション全体ステップ数に対する，
カスタマイズにより生じたコンポーネントの修正／追加／
削除に要したステップ数（カスタマイズステップ数）の割合である，カスタマイズ比率を評価する．4GL ビジュアル
開発ツールのカスタマイズ比率が 0.584 であるのに対して，Table 4 Evaluation results
Fig.15 Example of a screen developedby using our architecture

4GL visual tool

Total number of steps

れにより，提案システム化方式による事務の合理化効果を定量的に確認した．本システムは 7 行の銀行に導入済みであり，いずれの銀行においても同等の定量的合理化効果を得ている．
つぎに，提案した帳票処理クライアントアプリケーショ
ンアーキテクチャの有効性を検証する．
(1) まず，4GL ビジュアル開発ツール(Visual Basic)と開発
生産性に関して比較実験を行なった．開発生産性の比較で88

Proposed architectureStandard
specification

Customspecification

Standard
specification

Customspecification

1125

1429

11369

14516

Increase in steps due tocustomization

1.27

1.23

Number of customized
steps

657

4242

Number of component
deletion steps

54

69

Number of component
modification steps

94

391

Number of component
addition steps

509

3782

Customization ratio

0.584

0.373

計測自動制御学会産業論文集
Vol.4, No.12, 81/90 (2005)
提案アーキテクチャではその約 64%にあたる 0.373 となっ為替の件数や金額を集計する集計照会業務がある．この業ている．これは，提案アーキテクチャでは，カスタマイズ

務例では，ある項目値が更新されると合計値を更新するロに直接関連するコンポーネントと拡張イベントアダプタとジックが起動されて合計値が更新される仕様を持つ．このの接続関係だけを変更（削除／修正／追加）すればよいの

業務アプリケーションでのこれまでと同じ銀行向けに行っに対して，4GL ビジュアル開発ツールでは GUI と業務ロジ

たカスタマイズ（合計ロジックの仕様が変更）では，提案

ックの分離ができていないのでカスタマイズに関わる変更

アーキテクチャは BML に比べて約 46%のカスタマイズステ

部分が複雑であるためと考察できる．一方，カスタマイズ

ップ数ですんでいる．提案アーキテクチャでは合計ロジッ

コストに関してカスタマイズステップ数で評価すると，提クコンポーネントの接続関係だけを変更すればよいのに対案アーキテクチャでは，全体ステップ数が大きいのでカスして，BML では合計ロジックコンポーネントのほかに関連

タマイズステップ数も 4GL ビジュアル開発ツールに比べてする各項目のコンポーネントについても変更の必要がある

大きく，カスタマイズ時のコスト削減効果は得られていなため，提案アーキテクチャの方がカスタマイズ量は少なくい．しかし，銀行営業店システムの帳票処理アプリケーシなっている．

ョンを開発していく過程で，業務数（アプリケーション数）

以上の生産性検証評価の結果，本稿で提案したアプリケが増えていくほど，新規に開発しなければならない XAP コーションアーキテクチャの有効性を確認できたと考える．

ンポーネントの数が減少する傾向が見られた．これは，XAP

5.

コンポーネントの独立性から，XAP コンポーネントの再利おわりに用性が高いことを示していると考えられる．この結果，カ

本稿では，銀行営業店における事務合理化の背景と課題

スタマイズステップ数の多くを占めている表 4 の追加コンについて述べ，2 つのシステム化方式を提案した．まず，多ポーネントステップ数が減少するとともに，カスタマイズ

くの人手と時間を要している営業店の後方事務の合理化を

比率も小さくなる結果を得ている．提案アーキテクチャを図る目的で，非接触イメージスキャナで帳票をイメージデ採用して開発した為替業務機能全体で見ると，試算ベース

ータとして直接コンピュータ内に取り込み，ワークフロー

で，4GL ビジュアル開発ツールに比べ約 60%にカスタマイによって集中事務処理センタに伝送して後方事務を集中処

ズステップ数，すなわちカスタマイズコストを抑えられる

理するシステム化方式を提案した．これにより，営業店のと推定できる．本システムの適用銀行が増えれば，さらに後方事務の合理化と事務コストの低減を図ることができカスタマイズコストを抑えられると考える．

る．次に，集中事務処理センタにおける多種多様な帳票を(2) つぎに，同じコンポーネント指向の開発言語である

処理するアプリケーションの開発コストの低減を目的に，BML と開発生産性の比較実験を行なった．実験内容は，4GL

疎結合コンポーネント接続方式を導入し，画面および画面ビジュアル開発ツールと比較した場合と同じ，為替振発業

遷移を XML 文書で記述するだけでアプリケーションを開務のアプリケーションのカスタマイズを対象にした．結果

発できる帳票処理クライアントアプリケーションアーキテ

は，BML の方が，Table 4 に示す提案アーキテクチャの数値

クチャを提案した．提案アーキテクチャにより，コンポーより約 10%小さい数値が得られた．これは，ある銀行向け

ネントの再利用性が高まり，カスタマイズ範囲を局所化でに行ったカスタマイズは，プログラム上，他のコンポーネき，ユーザでも容易にアプリケーションを開発することがントとの依存関係がほとんどないコンポーネントの新規追できる．

加であったためと判明した．あるコンポーネントが独立で提案システム化方式により，銀行営業店の後方事務の集

他のコンポーネントと依存関係がないものと仮定し，その中事務処理システムを開発した．本システムの導入によるコンポーネントを別のコンポーネントと接続することを考

事務の合理化効果を定量的に確認した．また，提案アプリ

える．提案アーキテクチャでは，拡張イベントアダプタをケーションアーキテクチャの生産性検証評価を実施し，そ介して間接的にコンポーネントを接続するので，双方のコの有効性を確認した．開発したシステムは，現在，性能面

ンポーネントに関しての接続記述が必要である．これに対でも問題なく安定稼動している．

して，BML ではその接続に関する記述のみとなるため，接続情報に関しては，BML は提案アーキテクチャの 1/2 にな

参る．XML 定義文書の中でコンポーネントの接続情報が占め考

文 献る割合は 20〜30%なので，接続情報の記述量は約 10〜15%

1)金融財政事情，1997.7.7 号 (1997-7)

ほど BML の方が提案アーキテクチャより少なくなると分析

2)http://xml.coverpages.org/xfa.html

できる．したがって，この実験で約 10%小さい結果を BML3)http://www.w3.org/1999/05/XFA/xfa-template.html

が示したことになる．

4)青山，中所，向山編：コンポーネントソフトウェア，ソフ

帳票業務アプリケーションのカスタマイズでは，前述のトバンク (1998)

ように単純に項目や業務ロジックの追加ですむ場合は少な5)http://e-wop.jp/w/4GL.html

い．多くの場合は，2 章で述べたように各項目間に複雑な関6)http://www.alphaworks.ibm.com/tech/bml

連があるものをカスタマイズすることになる．その一例に，

7)http://www.javaworld.com/javaworld/jw-08-1999/iw-08-beans.
89計測自動制御学会産業論文集
Vol.4, No.12, 81/90 (2005)
森

html

有

一

1991 年大阪大学大学院工学研究科通信工学専
攻修士課程終了。同年，（株）日立製作所に入社。

8)http://www.javaworld.com/javaworld/jw-10-1999/iw-10-beans.

同社システム開発研究所にて，DB検索インタフ

htmlェースワークフローシステム，金融情報システ

9)http://www/cag.lcs.mit.edu/curl/

ムの研究開発に従事。情報処理学会会員。

10)M.Hostetter, D.Kranz, C.Seed, C.Terman and S.Ward: “Curl:
Gentle Slope Language for the web”, World Wide Web Journal,
Vol. II, Issue 2, Spring (1997)( http://www/w3j.com/6/s3.kranz.html )11)N.Damle, G.Gray, B.Mount: Curl Programming Bible, Hungry

阿

部

正 弘

1993 年大阪大学大学院基礎工学研究科情報工学専攻修士課程終了。同年，（株）日立製作所に

Minds Inc. (2002)

入社。同社システム開発研究所にて，金融情報

12)James Gosling, Bill Joy and Guy Steele: The Java Language
Specification, Sun Microsystems

システムの研究開発に従事。

(1997)

13)Erich Gamma, Richard Helm, Ralph Johnson and John
Vlissides:

DesignPatterns,

ElementsofReusable

Object-Oriented Software, pp.173-182, Addison Wesley (1995)
14)http://java.sun.com/webservices/docs/1.0/tutorial/doc/JAXPS
A.html15)http://www.w3c.org/DOM/
16)染谷，森，阿部，町田，長谷川：「第 4 次銀行営業店シス

町

田

勇

1981 年日本大学理工学部電気工学科卒業。同年，（株）日立製作所に入社。現在，日立オムロ

テムにおける XML を適用した帳票処理アプリケーショ

ンターミナルソリューションズ（株）にて，端末

ンアーキテクチャの開発」，電気学会情報システム研究

ソフトウェアの設計開発に従事。

会，IS-03-26，49/52 (2003-9)
17)Harushi Someya, Yuichi Mori, Masahiro Abe, Isamu Machida,
Atsushi Hasegawa and Osamu Yoshie: Development of a
Client Application Architecture Using XML in a Bank Branch
System, IEEE International Symposium on Communications
andInformation

Technologies(ISCIT

2004),

204/209
長(2004-10)

谷

川 篤

1979 年（株）日立製作所に入社。情報通信グル
ープ金融システム事業部チャネルソリューショ18)http://www.hitachi-omron-ts.co.jp/products/gazou/003.html

ンセンタにて，金融機関の営業店自動機ソリュ

19)Cheng-Lin Liu, Hiroshi Sako and Hiromichi Fujisawa: Effects

ーションの取り纏め業務に従事。技術士（情報of Classifier Structures and Training Regimes on Integrated

工学部門）
。

Segmentation and Recognition of Handwritten Numeral
Strings, IEEE Trans. Pattern Analysis
Intelligence, 26-11, 1395/1407 (2004-11)

andMachine

吉

[ 著

者 紹

介

江

修

1987 年早稲田大学大学院理工学研究科博士課程退学。早稲田大学理工学部助手，東京理科大]学理学部助手・講師を経て，現在早稲田大学大学院情報生産システム研究科助教授。専門は生

染

谷

治 志

産情報システム，コミュニティコンピューティ（正会員）1962 年 3 月 1 日生。1986 年早稲田大学大学院理工学研究科電気工学専攻修士課

ング。1985 年計測自動制御学会学術奨励賞受

程終了。同年，（株）日立製作所に入社。シス

賞，1990 年電気学会学術振興論文賞受賞（小テム開発研究所にて，事象駆動型システムのモ

平記念賞受賞），1996 年日本設備管理学会学会

デリング，ストレージ応用ソリューション，金賞論文賞受賞，2002 年電気学会電子・情報・システム部門特別貢融情報システムの研究開発およびソフトウェ

献賞，同大会企画賞受賞。工学博士。

ア生産技術の研究開発に従事。現在，早稲田大学大学院情報生産システム研究科博士後期課
程に在学中。電気学会，情報処理学会，電子情報通信学会の各会員。

90