金融系トータル情報システムの構築手法に関する研究

(1)

金融系トータル情報システムの構築手法に関する研究

A Study on Development of

Financial Total Information Systems

2005 年 12 月

早稲田大学大学院情報生産システム研究科

情報生産システム工学専攻知能化ネットワーク研究

染谷治志

(2)

第 1 章序論

本章では，企業情報システムの研究状況を概観し，本研究の主題である「一環情報流通」のための企業情報システム構築手法の研究の位置づけについて

(5)

1.1 まえがき

計算機システムのビジネスユースは，受発注伝票処理などの定型事務の置換からはじまり，業務や事務の合理化・効率化を目的にその適用範囲が広がってきた．計算機システムのビジネスユースは，さらにその活用目的を合理化目的から戦略目的へと広げ，情報システム構築の視点が抜本的に変わっていった．戦略情報システムは，企業戦略の実現手段としての情報システムである．たとえば，宅急便システムやセブンイレブンの情報システムは，新たなビジネスの創造という点で，我が国において大きな成果を上げた戦略情報システムの事例として有名である．

企業内には，その時代の経営環境における要求にその時代の最良の技術で応えるために構築され，依然として大きな価値を持っているさまざまな情報システムが存在する．企業は，動的な競争と絶えざる技術革新の中に存在し，

この過酷で変化が激しい環境のもとで，新たなビジネス開発と業務改善にチャレンジしている．そのため，戦略的な意思決定に関わる価値あるシステム資源を組織化していく必要がある．そのフレームワークの基本的な考え方に

「情報流通」があると考えている．「情報流通」とは，情報が留まりその利用が特定のところに限られるのではなく，必要とされる時に必要とされるところに提供され，またその活用先で新たな情報が生成され提供されていく考え方である．

本研究では，一般システム思考での「情報流通」の観点から，「一環情報流通」を実現するための企業情報システムの構成とその構築課題を整理し，

構築上の課題の中から 3つを取り上げ，具体例を挙げてそれらの課題に対する解決策の提案・評価を行う．まず，次節で企業情報システムに関する研究状況を概観し，本研究の位置づけについて述べる．第2章で，本研究の主眼となる「一環情報流通」について述べ，これを実現する企業情報システムの基本構成とその構築課題を述べる．第3 章では，一つ目の課題である基幹業務の合理化とそれを実現するアプリケーションソフトウェアの生産性について述べる．第 4次銀行営業店システムを具体例に取り上げ，帳票事務の効率化・合理化施策のシステム化方式として，帳票のイメージ化による事務集中処理方式とXMLを適用した新たなアプリケーションアーキテクチャを提案・評価する．第4 章では，二つ目の課題である試行錯誤となる意思決定プロセスの効率的運用環境について述べる．シナリオベースシミュレーション

(6)

システムを具体例に取り上げ，意思決定過程における試行錯誤のプロセスを効率的に運用できる環境として，シナリオ設定支援機能を提案・評価する．

第5 章では，三つ目の課題であるシステム運用方式の高信頼化設計について述べる．コンピュータで実行されるジョブの運用方式設計を具体例に取り上げ，その高信頼化設計方法として，拡張確率ペトリネットを用いたジョブ運用方式の評価方法を提案・評価する．最後に，第 6章で本研究のまとめを述べる．

1.2 企業情報システム研究における本研究の位置づけ

企業情報システムは，1960年代にEDPS(Electronic Data Processing System) による業務の効率的処理が行われるようになり，コンピュータの適用業務が急速に拡大した．このときの適用業務は，受発注伝票処理などの定型事務の置換が中心であった．ここでの企業情報システムの研究は，コンピュータありきであり，計算機システムの高性能化やコンピュータリソースの最適化など計算機システムそのものの研究⁽¹⁾⁽²⁾が中心であった．

情報通信技術の発達により，企業における計算機システムの活用目的は，

単純な事務処理を代表とする合理化目的から意思決定支援を代表とする戦略目的へと変化していった．Charles Wisemanはこの変化に気づき，戦略情報システム(Strategic Information System：SIS)という概念を提唱した⁽³⁾．その後，数多くの戦略情報システムに関する研究^(4)(5)(6)が行われている．三森⁽⁷⁾ は，企業活動を PLAN，DO，SEE の各活動とそれらを結ぶ情報フローでモデル化し，企業活動と各活動間の情報流通を実現する戦略情報システムの要件と，その構築に必要な情報処理技術を示している．また，三森⁽⁸⁾⁽⁹⁾は，戦略情報システムは新たな創造的業務を実現するシステムであり，そこで重要な役割を果たす情報の創造的生産性を支援する機能と，実現のための情報技術について見解を示している．そこでは，組織内の情報流通と情報共有は組織の創造活動に有効であることを主張している．その後，多くの研究者によって電子メールを中心とする企業内での情報流通(10)(11)(12)，文書管理(13)(14)(15)，

(7)

各情報システムは，時代の要請に従って生じる企業ニーズやその時代の情報技術の成熟度により，個別に構築されてきた．これらの個々の情報システムのデータを，戦略的な意思決定に関わる情報に組織化していく必要がある．

このため，個々の情報システムを戦略情報システムとして機能させる，情報流通のフレームワークが重要である．このフレームワーク技術として，システム連携技術⁽¹⁸⁾が注目されている．システム連携技術の中で比較的成熟しているものに，EAI(Enterprise Application Integration)^(19)(20)と ETL(Extract / Transform / Load)⁽²¹⁾がある．また，昨今のインターネット技術の発展により，

Webサービス(22)(23)(24)が注目されている．

EAIは，企業内で業務に使用される複数のコンピュータシステムを有機的に連携させ，データやプロセスの効率的な統合を図る技術である．すなわち，

過去の情報資産の有効活用や異機種間の有機的なデータ連携により，すばやい意思決定や効率的な企業経営を情報システム面から支援する．EAIを実現するソフトウェア(EAI ツール)は，ミドルウェアの一種で，各システムとのインタフェースを提供する「アダプタ」，システムごとのデータ形式やプロトコルの違いを吸収する「フォーマット変換」，あるシステムから受取ったデータを内容に応じて他のシステムに振分ける「ルーティング」，これらの機能を組み合わせ，実際の業務に合わせたビジネスプロセスを構築する「ワークフロー（プロセス制御）」などの機能から構成される．

ETLは，企業の基幹系システムなどに蓄積されたデータを抽出(Extract)し，

データウェアハウスなどで利用しやすい形に加工(Transform)し，対象となるデータベースに書き出す(Load)一連の処理を支援するソフトウェアである．

従来，この作業は専用のプログラムの開発をともない，ETL 作業が全体工数の半分以上を占めると言われていた．最近では，ETL ツールの登場により，短期間に容易に ETL システムを構築できるようになった．ETL ツールには，GUI(Graphical User Interface)を使ってデータの流れをビジュアルに構築する機能や，データ形式の変換機能，不正なデータを排除したり一定の形式にデータを修正したりするクレンジング機能などが搭載されている．

Webサービスは，WWW(World Wide Web)関連の技術を使い，ソフトウェアの機能をネットワークを通じて利用できるようにしたものである．機能の記述や呼び出し手順などの標準化が，進行中である．次世代のソフトウェア環境の主流は，コンポーネント化された複数の Web サービス同士をつなぎ合わせてアプリケーションを構築するというスタイルになると予測されて

(8)

いる．こうした環境が普及すると，従来のOS(Operating System)やミドルウェアはWebサービスを開発・実行する環境としての役割を担うようになり，

サービス（およびそれらを組み合わせたアプリケーション）を利用するエンドユーザは現在の Web ブラウザを拡張したようなクライアントソフトを通して，すべてのソフトウェアを操作するようになると考えられる．こうした環境の基盤となるようなソフトウェアやサービス，開発環境，仕様などが各社から提案されている^(25)(26)．現在のところ，XML(Extensible Markup Language)^(27)(28)をベースとした標準や標準案が多く，なかでも，ソフトウェア機能の呼び出しの手順を定めるプロトコルはXMLベースのSOAP(Simple Object Access Protocol)⁽²⁹⁾がデファクトスタンダードとなっている．また，

Web サービスの記述言語としては，WSDL(Web Services Description

Language)⁽³⁰⁾が標準として普及すると見込まれている．Web サービスは広い

概念で，適用範囲も広いが，現在の標準はどれも最も基礎的な基盤技術に関するものばかりで，具体的に高度なアプリケーションを構築しようとすると独自仕様に頼らざるを得ない．今後は，基盤技術をベースに各業界や分野に応じた数々の標準仕様が登場するものと思われる．

Web サービスの中心的役割を担う XML は，HTML(Hyper Text Markup

Language)のようなシンプルなフォーマットで文書構造を記述でき，タグを

独自に定義できることが特徴のマークアップ言語である．1998 年に W3C(World Wide Web Consortium)により標準化勧告され，現在は，電子機器業界（RosettaNet⁽³¹⁾など），金融貿易分野（Bolero⁽³²⁾など）や財務会計

（XBRL⁽³³⁾）など，さまざまな分野での応用が進められている．

このように，個々の情報システムの情報流通（さらには，サービス流通）

基盤を構築する，すなわち戦略情報システムとして各情報システムを融合するための技術が整ってきている．企業情報システムを戦略情報システムとして機能させていくには，企業経営や組織といかに合致した情報流通を実現するかにかかっている．

企業情報システムを取り巻く環境は，規制緩和，業界再編や低成長経済など厳しく変化が激しい時代を迎え，IT(Information Technology)投資における ROI(Return on Investment：投資対効果)がますます重要視されるようになっ

(9)

た組織的な取り組みである EA(Enterprise Architecture)^(34)(35)が注目を集めている．EAは，大企業や政府機関などといった巨大な組織の業務手順や情報システムの標準化，組織の最適化を進め，効率のよい組織の運営を図るための方法論，あるいはそのような組織構造を実現するための設計思想・基本理念のことである．EAでは，組織を構成する「人的資源」「業務内容」「組織」

「社内で有する技術」などの要素を整理し，階層構造化することで，組織全体に対する組織の一部分の構成要素の関係，組織の一部分同士の相互関係を明確化する．その上で，業務プロセスや取り扱うデータの標準化を行う．

EAを導入することで，巨大な組織内で複数の業務システムが別個に運用されていたものが標準化され，情報システムの導入・運用コストの削減，重複した業務内容の統合を通じて組織の運営コストの削減が可能となる．EAは，

1987年にJohn A. Zachmanが提唱した情報システムを設計するための枠組み

(36)が基礎となっており，1992 年に情報システムだけでなく組織全体を対象とするよう概念が拡張された⁽³⁷⁾．EAの導入事例としては，1999年に米国で策定された連邦政府の EA である FEAF(Federal Enterprise Architecture Framework)⁽³⁸⁾があげられる．日本政府も，2003 年 7 月に策定した「電子政府構築計画」⁽³⁹⁾の中で，2005 年度末までに「業務システムの最適化計画」

の名称で EA の概念を取り込んだ情報システムの構築を行うことを発表している．また，東京三菱銀行，セブンイレブンや三井住友銀行などでEAの導入をはじめている⁽⁴⁰⁾．

このように，組織を含めた企業全体の視点から情報流通を設計し，企業情報システムの再編に取り組む動きが主流となりつつある．

以上のように，企業情報システムは，企業の経営や組織と深く関わり，企業活動に不可欠なものである．「人」「物」「金」についで，「情報」は企業経営の第四の資源と言われている．「情報」が第四の資源として企業経営に資するためには，入力されたデータが情報，知識そして知恵へと変化し，それがフィードバックされて新たなデータ，情報，知識そして知恵を生んでいく循環サイクルをなすべきであると考える．この考え方を「一環情報流通」と呼ぶこととし，第 2章で詳しく述べる．本研究では，この「一環情報流通」

の観点からの企業情報システムの実現に向けた課題に取り組むものである．

(10)

第 2 章一環情報流通のための

企業情報システム構築の課題

本章では，企業情報システムを「情報流通」の観点から再考し，「一環情報流通」を実現する企業情報システムの構成，および，その構築上の課題について整理する．また，本研究で，具体事例を挙げてソリューション開発に

(11)

2.1 一環情報流通とその企業情報システムの構成

企業においては，時代の要請に従い生じる企業ニーズやその時代の情報技術の成熟度により，種々のアプリケーションシステムが構築されてきた．これらのアプリケーションシステムは，特定の適用先を想定しそれに適したシステム思考で構築されてきたので，システムごとに個別のシステムアーキテクチャをもつ．これらは一見異なるアプリケーションアーキテクチャであるが，企業活動プロセスとの融合や社会システムとの共生を求めるがゆえ，企業情報システム全体として見た場合，その根底には共通の基本的考え方「一環情報流通」があると考える．

コンピュータシステムの基本モデル⁽²⁾は，データ入力，データ処理及びデータ蓄積の３ステップである．「一環情報流通」はこれら３ステップが一方向で閉じるのではなく，蓄積されたデータあるいはデータ処理によって生成される情報や知識が知恵となって企業の第一線の場に還元され，また新たなデータ，情報，知識そして知恵が生成されていく循環サイクルをなす考え方である．

「一環情報流通」を実現するための企業情報システムの構成を，図 2.1に示す．企業情報システムは，「データ収集システム」，「情報加工システム」，

「知識加工システム」及び「知識編集システム」4つのサブシステムと，知恵が企業戦略や戦術になって各サブシステムに還元する「知恵のフィードバック」から構成される．「データ収集システム」は基幹業務処理システムに相当し，ATM(Automatic Teller’s Machine：現金自動預け払い機)やインターネットの企業ポータル Web ページなどからデータ入力を行う顧客，銀行窓

口端末やPOS(Point Of Sale：販売時点情報管理)端末などからデータ入力を

行う社員などがデータ発生源となり，基幹業務処理システムで業務処理され，

その処理結果が基幹データベースに蓄積される．「情報加工システム」は，

基幹データベースを入力源にデータを目的別に情報化するもので，基幹データベースから目的別に必要なデータを抽出，加工して目的別データベースに蓄積する．「知識加工システム」は，目的別データベースを入力源に経営戦略や顧客戦略の切り口から情報を知識化するもので，基幹業務処理システムを基幹系システムと呼ぶのに対していわゆる情報系システムと呼ばれるものに相当し，経営指標や組織などに対応した業務アプリケーション群から構成される．「知識編集システム」は，業務アプリケーションの出力である知

(12)

Customer Strategy Customer Management

Marketing Management Relationship Management

〜

Management Strategy Achievement

Control P rofit Management

Risk Management

〜

Subjective Database

〜

Business Database Data

Source

Customer, Counter,

etc.

Wisdom Source Wisdom-Feedback

図2.1 一環情報流通のための企業情報システムの構成

Data Information Knowledge Wisdom

Data-gathering System (Business-processing System)

Infor mation-processing System

Knowledge-processing System

Knowledge-compiling System Subjective

Database

Subjective Database Subjective

Database

Data Extract / Process / Accumulation

Mission-critical Business Processing Interface with Human

Interface with Data Source Decision Making

識を企業戦略実現に必要な知恵に編集し，それを具現化するものである．ここでいう知恵によって具現化されるものとは，企業活動における具体的アクションを指し，経営戦術や新たな分析アルゴリズム，それを支える情報加工の新たな切り口，新たな基幹業務・サービスや顧客に対するキャンペーンなどの営業戦術である．したがって，意思決定支援システム(DSS：Decision Support System)は典型的な「知識編集システム」である．「知恵のフィードバック」は，「知識編集システム」で出力された知恵を各サブシステムに反映させることである．経営戦術や新たな分析アルゴリズムは新たな業務アプリケーションの追加や既存業務アプリケーションのロジック変更，情報加工の新たな切り口は新たな目的別データベースの追加・変更，新たな基幹業務・サービスは基幹業務処理システムの変更や新規開発，キャンペーンなど

(13)

ータがデータから情報，知識そして知恵へと変化してフィードバックされ，

新たなデータが発生して情報，知識そして知恵となり流通していく．これにより，企業が経営環境に対応してそのビジネスモデル，戦略や組織を変えていくとき，企業情報システムもこれに追従していくことが可能となる．

2.2 企業情報システム構築上の課題

一環情報流通のための企業情報システムを構築していく上での主要課題を整理し，本研究での取り組みとの関係を示す．

「データ収集システム」では，情報，知識そして知恵へと変化するのに充分なポテンシャルをもつデータをタイムリーに収集できることが要件である．「データ収集システム」すなわち基幹業務処理システムは，処理及びデータが定型である特徴がある．したがって，この定型データ処理の効率化・

合理化が課題である．効率化・合理化するにあたって，データソースとのインタフェースはデータソース側からの使い勝手を低下させないことが重要である．また，フィードバックされる知恵に対して即応する，すなわち顧客や市場ニーズに即応して競争優位を築くために，こうした定型業務処理アプリケーションをより早く，低コストで開発していく，ソフトウェア生産性も重要な課題である．

「情報加工システム」では，「知識加工システム」へタイムリーに情報を目的データベースとして提供することが要件である．タイムリーに情報を提供できなければ，「知識加工システム」での知識化そして「知識編集システム」での知恵化，すなわちビジネス上の意思決定がタイムリーにできなくなり，機会ロスや廃棄ロスにつながり企業活動に支障をきたすことになる．「情報加工システム」は，数多くの情報系業務アプリケーションから構成される

「知識加工システム」からさまざまな切り口，集約度や鮮度の情報を要求される．また，ATMサービスの 24時間化など基幹業務処理システムのサービス時間延長などにより，オンライン中（データが静止状態になく適宜更新される状態）の基幹データベースからある時間で静止したスナップショットを抽出して目的別データベースを作成する必要が生じている．したがって，「情報加工システム」では高度で複雑なシステム運用を強いられることになり，

システム運用方式を高信頼に設計していくことが重要な課題である．

(14)

「知識加工システム」では，経営戦略や顧客戦略の実現に必要な知識を「知識編集システム」に提供することが要件である．従来，業務アプリケーションは，基本的に自前開発してきた．経営環境が比較的安定している時代は，

これでよかった．しかし，今日のように経営環境の変化が激しい時代になると，業務アプリケーションの追随スピードが要求されるようになり，自前で開発するのではなく業務アプリケーションソフトウェアパッケージを導入して早期対応を図るようになってきている．このため，業務アプリケーションソフトウェアパッケージとのシームレスなシステム連携が課題である．

「知識編集システム」では，「知識加工システム」から提供される知識を人間とのインタフェースを介して知恵化し，それを具現化する過程を支援することが要件である．知恵化する過程は，通常，試行錯誤のプロセスを踏むことになる．「知識編集システム」を，実務上有効なシステムにするには，

この試行錯誤のプロセスを効率的に運用できる環境の整備が課題である．また，経験やノウハウが豊富な限られた人間にしか使えないシステムではなく，

経験が浅い意思決定者にでも使える，すなわちユーザに依らず結果として意思決定される知恵の質が均一となる環境の整備も課題である．

本研究では，上記課題のうち 3つの課題に取り組んでいる．一つ目は，基幹業務の合理化とそれを実現するアプリケーションソフトウェアの生産性の課題である．具体例として，第 4次銀行営業店システムを「データ収集システム」に取り上げる．ここでは，帳票事務の効率化・合理化施策を実現する事務処理方式と帳票処理アプリケーションの開発コスト低減に取り組み，

帳票のイメージ化による事務集中処理方式とXMLを適用した新たなアプリケーションアーキテクチャを提案・評価する．本研究内容は，第3章で述べる．二つ目は，試行錯誤となる知恵化プロセスの効率的な運用課題である．

具体例として，シナリオベースシミュレーションシステムを「知識編集システム」に取り上げる．知恵化する過程における試行錯誤のプロセスを効率的に運用できる環境としてシナリオの設定支援機能を提案し，適用事例を通してその有効性を評価する．本研究内容は，第4 章で述べる．三つ目は，高度化・複雑化するシステム運用方式の高信頼化設計課題である．具体例として，

(15)

評価する．本研究内容は，第 5章で述べる．

(16)

第 3 章銀行営業店事務の

集中処理システムの開発

本章では，図 2.1に示した「一環情報流通のための企業情報システム」の構築課題の一つ目である，基幹業務の合理化とそれを実現するアプリケーションソフトウェアの生産性の課題について述べる．具体例として，第4次銀行営業店システムを「データ収集システム」に取り上げる．ここでは，営業店における後方事務の効率化・合理化施策を実現する事務集中処理方式と，

帳票処理アプリケーションの開発コストを低減する新たなアプリケーショ

(17)

3.1 緒言

情報通信技術の発達により，エレクトロニックコマースや企業における IT化が進展してきている．また，社会基盤においても，電子政府⁽⁸⁴⁾や e-Japan 戦略Ⅱ⁽⁸⁵⁾にもとづくIT基盤を活かした社会経済システムの積極的な変革が進められている．その結果，各種文書や帳票が電子化され，ペーパレスが進んできている．ところが，銀行営業店においては，自行が店舗内に備え付けている定型帳票（制定帳票）のほかに，税金や公金帳票，一般振込み帳票などの諸帳票（非制定帳票）が多く，紙ベースの現物処理（帳票事務）が依然として残り，ペーパレスが進んでいない状況にある．

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

日本版金融ビッグバンに代表される規制緩和などにより，金融機関を取り巻く環境が大きな変革期を迎え，銀行業界では多様化する顧客ニーズや新業務・新サービスへの迅速な対応が求められている．このため，帳票事務の徹底的な合理化により，営業店を「営業」主体のセールス拠点へと変えていく必要がある．依然として残る現物処理（帳票事務）の合理化をどのようなシステム化方式で実現するかが課題である．また，制定帳票や非制定帳票など多種多様な帳票の処理アプリケーションの開発コストをいかに低減していくかも，システム化する上での課題である．

帳票処理の分野では，電子帳票アプリケーションパッケージソフトウェアが種々実用化されている．銀行営業店窓口で扱う帳票をこのパッケージソフトウェアで実装することが考えられるが，制定帳票は可能であるとしても，

非制定帳票すべてを実装することは非現実的であり実質上不可能である．な

(18)

ぜなら，非制定帳票の発行側にも同様のパッケージソフトウェアを導入してもらわなければならないからである．また，銀行によって使用するパッケージソフトウェアが違えば，非制定帳票の発行側はすべてのパッケージソフトウェアに対応することになるか，あるいは顧客に同じパッケージソフトウェアを使用している銀行での取引を強いることになる．すなわち，非制定帳票の発行側のコストに見合ったメリットが見出せず，あるいは顧客サービスの低下を招くことになるからである．制定帳票だけをパッケージソフトウェアで実装した場合，制定帳票と非制定帳票とで事務が異なり，かえって事務を複雑にすることになりかねない．

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

Language)⁽²⁷⁾とスクリプト言語を組み合わせた帳票アプリケーション言語

XFA(XML Form Architecture)^(42)(43)が提案されている．また，多種多様な帳票では類似項目が多いことから，GUI(Graphical User Interface)や業務ロジックをソフトウェア部品（コンポーネント）化して，これらを組み合わせてアプリケーションを開発していくコンポーネント指向の開発方法

(44)(45)(46)(47)(48)(49)(50)(51)がある．しかし，スクリプト言語によるコーディング

が必要であったり，コンポーネント間が密結合となるためにカスタマイズ性が悪かったりと，開発コストを低減する開発環境としては不充分である．

本章では，銀行営業店と顧客や非制定帳票の発行者とのインタフェースやプロセスを変更することなく帳票をコンピュータ内に直接取り込み，ひとつの事務センタ（以下では，この事務センタを集中事務処理センタと記述する）

に集約して集中処理するシステム化方式⁽⁵⁶⁾を提案する．また，集中事務処理センタには多種多様な帳票が集まり，これらを処理するアプリケーションの開発コストを低減するため，コンポーネント間を疎結合する接続方式を導入し，画面を構成するコンポーネントの接続関係と画面遷移を XML文書で記述することでアプリケーションを開発できる，帳票処理クライアントアプリケーションアーキテクチャ XAP(XML Applications)^(56)(57)を提案する．これらのシステム化方式により，各営業店で実施していた後方事務を集中事務処理センタに集約でき，事務を合理化し事務コストを低減することができる．

また，疎結合コンポーネント接続方式の導入により，コンポーネントの再利

(19)

理化効果を定量的に確認するとともに，提案アーキテクチャ XAPの生産性検証評価を通じてその有効性を確認した．

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

銀行業界では，これまで顧客サービスの向上や取引コスト削減に向けた事務の合理化を図ってきた．帳票事務に関しても，銀行の公共性や社会的責任をまっとうする厳格性と正確性を保ちつつ，徹底的な事務オペレーションの合理化を進めてきた．しかし，規制緩和などによる経営環境の変化から，さらなる合理化が求められている．帳票事務における合理化ポイントは，先に述べた通り，多くの人手と時間を要している後方事務にある．図 3.1に為替業務における後方事務処理例を示す．銀行営業店窓口で顧客から受け取った帳票は，各事務の担当者に回付されて事務規定に則り処理されていく．この後方事務を電子化して担当者の PC でオペレーションできるようにすれば，

紙ベースの帳票を担当者に回付する時間（立ち歩き時間）の削減が期待でき

Clerk 2 Officer

Customer

Clerk 1 Clerk 3

Acceptance Receipt issue Formal check Te mporary input Dealings execution

Trans mitting check Contents check

図3.1 後方事務例

Counter

Bank branch

Back-office operations

(20)

る．また，ある営業店で後方事務量が0.5 人分あるとすると，1人の担当者が必要になる．これと同じ事務量の営業店があれば同じく 1人，合計 2人の人員が必要になる．各営業店で分散して事務処理をしているため，合計1.0 人分の事務量に対して 2人の人員を配することになる．後方事務を電子化できれば，その事務処理を集中化することが可能であり，2人要していた人員が1 人で済むようになり，事務合理化と取引コストの削減が期待できる．

これを実現するためには，現物の帳票をどのように電子化するかが課題である．最近実用化されている電子帳票アプリケーションパッケージソフトウェアの活用が考えられるが，先に述べたように実質上不可能である．また，

帳票にバーコードを付けバーコードリーダによって電子化する案もあるが，

パッケージソフトウェア活用案と同様，すべての非制定帳票にある決められた仕様に従ったバーコードを付けることは実質上不可能である．したがって，

外部（顧客や非制定帳票の発行者）とのインタフェースやプロセスを変更することなく，帳票を電子化してコンピュータ内に取り込むシステム化方式を検討していかなければならない．

ところで，銀行営業店で扱う帳票は多種多様であり，帳票を処理するアプリケーションの開発コストが問題となってくる．帳票は多種多様であるが，

種別（たとえば，振込みに関わる帳票）によって，起票項目がほとんど同じ場合が多い．帳票内の各項目には，口座番号の桁数チェックや支店コードの存在確認など各種業務ロジックが設定されている．しかし，同じ種別でも種目（たとえば，一般振込や給与振込）によって項目に設定する業務ロジックが異なったり，項目間のチェック内容が異なったりするなど項目間の関連に相違がある．これらは銀行独自の事務規定に則っているもので，銀行によっても異なる．また，新たな帳票の追加や帳票の項目追加・削除が頻繁に発生する．そのため，帳票の項目追加・削除，帳票の文言の修正やシステムメッセージの表現修正など，些細な変更はユーザ自ら行うことでコストダウンを図り，変更に早期対応したいというユーザニーズもある．したがって，集中事務処理センタの帳票処理クライアントアプリケーションの開発においては，再利用性が高く，かつカスタマイズが容易で，ユーザ自身による開発を可能とする開発環境の整備が必要である．

(21)

ジックの分離設計が図られておりそれぞれの再利用性は高いものの，業務ロジックのカスタマイズ性とユーザ開発性の観点から上記課題に対して充分に応えられるものではない．多種多様な帳票の中で類似項目が多いことから，

GUI や業務ロジックをコンポーネント化して，これらを組み合わせてアプリケーションを開発していく BML(Bean Markup Language)(46)(47)(48)や

Curl(49)(50)(51)などのコンポーネント指向の開発方法がある．BMLは，コンポ

ーネントである JavaBeans の接続関係を XML で記述して，アプリケーションを開発するものである．一般に帳票処理では，先に述べたように項目間に複雑な依存関係があるため，上記コンポーネント間にも依存関係が発生し，

コンポーネントの再利用が困難な場合が多い．たとえば，一般的な銀行の為替振発業務において以下のような仕様がある．為替振発業務とは，振込み帳票で指図された銀行口座に送金して債権債務の決済を行う業務であり，送金種目（給与振込みや一般振込みなど）によって送金口座への入金日が異なる．

仕様1：振込指定区分は，振込種目が「振込」の場合，

「当日扱」ないしは「翌日扱」のいずれかを表示．振込種目が「先振」「給与」の場合，空白を表示．

仕様2：振込指定日付は，振込種目が「振込」の場合，

振込指定日区分に対応した日付を計算して表示．振込種目が「先振」「給与」の場合，窓口で銀行員によって入力された値を表示．

上記仕様を有する画面を，BML のようにコンポーネントを組合せてアプリケーションを開発した場合の，一般的なコンポーネントの接続関係を図3.2 に示す．まず仕様 1を満足するため，振込指定日区分判定ロジックコンポーネントは振込種目フィールドの振込種目を参照し，判定結果に基づき振込指定日区分フィールドの表示内容を更新する．また仕様2 を満足するため，振込指定日判定ロジックコンポーネントは，振込種目フィールドコンポーネントの振込種目と振込指定日区分フィールドコンポーネントの振込指定日区分を参照し，振込指定日フィールドの表示を更新する．これら 5つのコンポーネント間には図 3.2に示すような依存関係が存在し，個々のコンポーネントを切り出して再利用することは困難である．また，コンポーネントが密結合しているため，カスタマイズが発生すると，変更箇所に依存するすべてのコンポーネントを変更する必要があるため，カスタマイズが容易であるとは

(22)

図3.2 コンポーネントの依存関係例

Input Field (Transfer Ite m)

Input Field (Transfer Date Division)

Input field (Transfer Date Ite m) Logic for Trans fer Date

(Adjudication of Trans fer Ite m) Re ference o f

Transfer Ite m

Re ference o f Transfer Ite m

Update Transfer Date Division Re ference o f

Transfer Date Division

Update Transfer Date

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

言い難い．

本章では，営業店窓口と外部とのインタフェースやプロセスを変更することなく，帳票をコンピュータ内に取り込む手段としてイメージスキャナを用い，帳票のイメージデータをワークフローで集中事務処理センタに集約して後方事務を集中処理するシステム化方式⁽⁵⁶⁾を提案する．また，画面を構成するコンポーネントの接続定義および画面遷移定義をXML文書で記述することでアプリケーションを開発することができる，帳票処理クライアントアプリケーションアーキテクチャ XAP^(56)(57)を提案する．本アーキテクチャでは，イベントアダプタ^(52)(53)にデータオブジェクトを内包させた拡張イベントアダプタを用いることにより，コンポーネント間の依存関係を緩やかにしてコンポーネントの独立性を高めた接続方式を導入している．これらのシステム化方式により，営業店の後方事務の合理化と事務コストの低減を図るこ

(23)

現しているので，ユーザでも容易にアプリケーションを開発することができる．

3.3 システム化方式

3.3.1 事務集中処理方式

事務集中処理方式の基本方針は，(1)銀行の営業店窓口と外部とのインタフェースやプロセスが変わらないこと，(2)また窓口行員に新たな手間と時間がかかるオペレーションを発生させないこと，(3)さらに帳票事務オペレーションに際して現物帳票の look and feelを大きく変えないことと，(4)立ち歩き時間を排除することである．これらの基本方針に従い，帳票は人間の業務を集約したエッセンスであることから，帳票をコンピュータに直接取り込み，その帳票を自動回付して事務オペレーションを実施する考え方に基づきシステム化する．

具体的なシステム実現方式は，(1)帳票のコンピュータへの取り込み手段として，図 3.3に示す非接触イメージスキャナで帳票をイメージデータとしてコンピュータ内に直接取り込む，(2)読み込んだ帳票イメージデータの集中事務センタへの伝送と事務規定に則り帳票を回付する手段として，ワークフローで実装する，(3)事務処理は，帳票イメージデータをもとに事務オペレーションできるよう帳票処理クライアントアプリケーション（Web クライアントアプリケーション）で実装する．

図3.3 に示す非接触イメージスキャナは，帳票を所定の位置に置くだけで自動的に読み込む仕組みであり，帳票の大きさ，厚み，皺，折り目や紙質にも対応する自由度の高い手段である．また，読み込み対象である帳票の位置や方向合わせが不要であり，帳票種別の自動認識による業務画面の自動索引も可能であるので，窓口受付事務におけるクイックオペレーションを実現することができる．

帳票イメージデータのコード化の考え方を示しておく．従来は一人目の行員が帳票内容をキーボード入力（一次入力）していたオペレーションを自動認識ソフトウェア⁽⁸⁶⁾で代替し，二人目の行員が帳票のイメージデータを見てその内容をキーボード入力（二次入力）する．両者の入力内容を突合し，

一致すればそれを正しいコードデータとして扱う．違っていた場合，例外処

(24)

図3.3 非接触イメージスキャナーの概観

理として，第三者（役席行員など）が両者の入力内容と帳票のイメージデータをもとに正しいコードデータを入力する．使用する認識ソフトウェアは，

その認識アルゴリズムに方向性特徴を用いた統計的識別方式⁽⁸⁷⁾を採用している．認識率は，活字で99%，JIS規格に準拠した手書き文字で 97%である．

図3.4に，集中事務処理システムの概要を示す．本システムは，営業店の非接触イメージスキャナを設置した窓口端末，集中事務処理センタのワークフローサーバと事務オペレーションを行うクライアントPCから構成される．

窓口端末の非接触イメージスキャナで，顧客から受け取った帳票をイメージデータとして読み込む．このとき，同時に文字認識を自動実行して，従来は人手で行っていた帳票の形式点検（記入漏れチェックで図 3.1 の Formal check）や一次入力（記入内容のコードデータ化で図3.1の Temporary input）

を自動化する．読み込んだ帳票イメージデータと自動認識した記入内容のコードデータを，集中事務処理センタのワークフローサーバに伝送する．ワー

(25)

Branch Branch

ATM

Teller Terminal

Seal check Verification

Centralized Operation Center Centralized Operation Center

PC

Workflow

Form

Execution check

図3.4 後方事務集中処理システム概要 Form Image

Image Input

Workflow S erver

アントアプリケーションが動作し，帳票精査（帳票内容の二次入力を行い，

一次入力内容との突合せを行うコードデータのチェックで図 3.4 の Verification），印鑑照合（図 3.4の Seal check）や検印（取引実行可否の判定で図3.4の Execution check）などの後方事務処理を行う．このように，営業店後方事務を事務集中処理センタに集約することで，事務の合理化・効率化を図っている．

事務集中処理センタのクライアントPCの操作者は事務行員や役席行員で，

クライアント PC に対するオペレーションをできる限り簡略化するために，

前章で述べた帳票内の各項目に設定されている業務ロジックや項目間の関連チェックなどは，帳票処理クライアントアプリケーションに実装する．このとき，帳票ごとひとつひとつ個別にアプリケーションを開発していくと，

似て非なるものを多数開発することになり，開発コストが大きくなってしまう．そこで，次節で提案するアプリケーションアーキテクチャで，開発生産性を向上させている．

(26)

3.3.2 帳票処理クライアントアプリケーションアーキテクチャ

(1) コンポーネント接続方式

集中事務処理センタにおける帳票処理クライアントアプリケーションアーキテクチャ XAP でのコンポーネント接続方式は，①従来のようにコンポーネント間を直接接続する（コンポーネントから別のコンポーネントを呼び出す）のではなく，仲介者（データオブジェクトを持ち込んだイベントアダプタ）を介して間接的に接続する，②コンポーネントと仲介者とのインタフェース仕様を共通化することにより仲介者の汎用性を持たせる，という考え方に基づいている．従来のような直接接続では，接続元コンポーネントは接続先コンポーネントのインタフェース仕様が分かっていなければならず，それが自分の仕様を決定づけている．すなわち，依存関係を持っている．これに対して，提案方式では各コンポーネントは汎用的な仲介者とのインタフェース仕様だけで自分の仕様を決定づけることができ，接続先コンポーネントの仕様とは直接的な依存関係がない緩やかなコンポーネント間接続を実現している．これにより，コンポーネントの独立性，再利用性を高めている．

図3.5 コンポーネント接続方式

Individual Adapter GUI Component

Business Logic Component Common Inter face

Common Inter face Extended Event Adapter

Individual Adapter GUI Component

Data Object

Individual Adapter Business Logic

Component Individual Adapter

(27)

XAPにおけるコンポーネント接続方式を，図3.5 に示す．本方式では，コンポーネント間を直接接続するのではなく，イベントアダプタにデータオブジェクトを内包した拡張イベントアダプタを導入し，コンポーネントと拡張イベントアダプタに内包されたデータオブジェクト（以下では，単にデータオブジェクトを記述する）との接続関係で間接的にコンポーネント間を接続する．各コンポーネント，すなわち GUI コンポーネントや業務コンポーネントの実装方法は規定しないが，各コンポーネントが有する個々のインタフェースを図 3.6 に示す共通インタフェースに変換する機能を持つ個別アダプタを用意する．この個別アダプタを有するコンポーネントを XAPコンポーネントと呼ぶことにする．

図3.6 XAPコンポーネントと拡張イベントアダプタのインタフェース概要

Re ference Value Update Value

Notification of Value Update Individual Adapter

GUI / Business Logic Component

Extended Event Adapter

Registry

①

Individual Adapter

②

Individual Adapter

③

Individual Adapter

④ GUI / Business Logic

Component

GUI / Business Logic Component

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

①XAP コンポーネントからデータオブジェクトの値を参照するメソッド

②拡張イベントアダプタに登録されたXAP コンポーネントから当該デ

(28)

ータオブジェクトに設定されたデータ値を更新するメソッド ③拡張イベントアダプタに XAPコンポーネントを登録するメソッド ④データオブジェクトのデータ値が更新された場合，当該拡張イベント

アダプタに登録された XAP コンポーネントにデータ値の更新通知を行うメソッド

である．①は，XAP コンポーネント動作時に他の XAPコンポーネントにより更新されたデータオブジェクトのデータ値を参照する場合に用いられるメソッドである．②〜④は，XAP コンポーネントの動作を契機に他の XAP コンポーネントを動作させたい場合に用いられるメソッド群である．従来では，このような場合，コンポーネント中に他のコンポーネントを動作させるためのイベントハンドラを記述するが，提案方式では XAPコンポーネント間で直接の依存関係を持たないため，データオブジェクトを介しての通知メカニズムとなる．

図3.2 に示した一般的な銀行の為替振発業務画面は，提案接続方式によれば図3.7のようになる．

図3.7 XAPコンポーネントと拡張イベントアダプタの接続関係例

Input field (Transfer Ite m)

Input Field (Transfer Date Division) Extended Event Adapter

(Transfer Division Item)

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

Input Field (Transfer Date Ite m) Logic for Trans fer Date

(Adjudication of Trans fer Ite m)

Extended Event Adapter (Transfer Date) Extended Event Adapter

( Trans fer Ite m)

(29)

たとえば，図 3.2 の振込指定日判定ロジック XAP コンポーネントが参照している振込種目データおよび振込指定日区分データを各々の XAPコンポーネントから分離し，各拡張イベントアダプタのデータオブジェクトに格納している．振込指定日判定ロジックは，他の XAPコンポーネントではなく，

これらの汎用的な拡張イベントアダプタのみを参照しており，他の XAPコンポーネントとの依存関係はない．そのため振込指定日判定ロジックを再利用することができる．

上記のような XAP におけるコンポーネント接続方式により，コンポーネント間の依存関係を緩やかにでき，コンポーネントの高い再利用性が得られる．また，カスタマイズ発生時は，カスタマイズ対象の XAPコンポーネントとデータオブジェクトとの接続関係を変更するだけでよく，カスタマイズ範囲の局所化を図ることができる．帳票処理クライアントアプリケーション開発者は，画面を構成する XAP コンポーネントのデータオブジェクトを介した間接的接続関係と画面遷移フローだけを定義すればよい．この定義言語

にWeb/CORBA/Java 環境との親和性を考慮し，XML を適用することで XAP

アーキテクチャのオープン性とユーザによる記述容易性を持たせている．

(2) XAP アプリケーション構成

XAP コンポーネントの組み合わせでできあがるアプリケーションを XAP アプリケーションと呼ぶことにする．XAPアプリケーションは，図3.8 に示すように，アプリケーションフレームワークとして提供される XAPコア，

XAP コンポーネント群（GUI コンポーネントと業務ロジックコンポーネント），画面定義，フロー定義及び Web ブラウザから構成される．XAP アプリケーション開発では，GUI コンポーネントと業務ロジックコンポーネントの接続情報によって作られる画面を記述する画面定義と，画面遷移を記述するフロー定義を XML文書でそれぞれ作成することになる．

(a) 画面定義

XAP の画面定義は，XAP コンポーネントとデータオブジェクトの接続関係をXML 文書で記述したものである．例として，図3.7 の XAPコンポーネントとデータオブジェクトの接続関係を記述した画面定義を図 3.9に示す．

画面定義のために用意された XML タグを，表 3.1 にまとめる． XScript タグは，画面定義全体を意味する．XApplet タグは個々の XAP コンポーネ

(30)

Screen conf iguration def inition (XML docume nt) Screen conf iguration

def inition (XML docume nt) Web Browser

Screen

XAP core ComponentGUI G UI Logic

Screen Layout

B usiness Logic

¾Interpret screen configuration de finitions

¾Generate and manage e xtended event adapters

¾Interpret screen transitions Flow Definition

(XML Docu ment)

図3.8 XAPアプリケーション構成

ComponentGUI

Business Logic Component

XAP Components

Screen Configuration Definition (XML Docu ment)

ントに対する定義内容を表し，XAppletタグの name 属性は XAPコンポーネントのインスタンス名を意味する．XComponentタグは XAppletで定義された XAP コンポーネントの実体として，XAP コアにより起動される XAP コンポーネントプログラムの指定を表し，XComponentタグのname属性はXAP コンポーネントプログラムを呼び出し可能な名称を表している．Parameter タグは XAPコンポーネントの呼び出し時に指定するパラメータ名とパラメータ値の対応関係を表し，Parameterタグの name 属性がパラメータ名を示し，

value 属性がパラメータ値を示している．たとえば，図 3.9 の第一番目の

XApplet タグの意味は，「“振込種目フィールド“というインスタンス名で

XAPコアが起動するXAPコンポーネントプログラムは”入力フィールド“という名称であり，プログラム起動時，”Text“というパラメータに対して”

EventAdapter;振込種目”という値が代入されている」ことを意味する．

(31)

<? xml version="1.0" encoding="Shift_JIS " ? >

< XCo mponent name= "入力フィールド" />

</XApplet>

</XApplet>

< XCo mponent name=“振込指定日区分判定ロジック" />

</XApplet>

</XApplet>

< XCo mponent name= "振込指定日判定ロジック" />

</XApplet>

</XScript>

図3.9 画面定義例

表3.1 画面定義におけるXM Lタグ一覧

Parameter value value

Parameter name name

Parameter of XAP component Parameter

Name of component program name

Definition of component program XComponent

Name of XAP component instance name

Definition of each XAP component XApplet

Entire screen configuration definition XScript

Description Attribute

Tag name

(32)

(b) フロー定義

フロー定義は，XAP アーキテクチャにより開発するアプリケーションの画面遷移フローを XML文書で記述したものである．フロー定義の各タグには，アプリケーションの画面遷移フローに関する制御コマンドが定義されている．XAPコアが，XML パーサを用いてフロー定義を解析しながら，タグに指定されている制御コマンドを逐次実行することにより，アプリケーションの画面遷移フローを制御する．

図 3.10に示す画面遷移フロー例に対するフロー定義を，図 3.11に示す．

図中のFLOWDEF タグは，フロー定義全体を意味する．XAPコアは，XML

文書のルートタグである FLOWDEF から処理を開始し，最初の子ノードである Transaction タグを実行する．Transaction タグは画面表示の制御コマンドで，この例では，XAP コアは”MainMenuForm”という名称を持つ画面定義によって定義される画面を表示する．XAP コアは，SAX(Simple API for XML)⁽⁵⁴⁾パーサの作法に従い，フロー定義 XML 文書の木構造をトラバースしながらタグの制御コマンドを実行していく．フロー定義のために用意されたタグ一覧を，表 3.2に示す．

図3.10 画面遷移フロー例 Display

“FORM ”

M enu Selection

MenuID=01

MenuID=99 Display

“M enu01”

End

(33)

<?xml version="1.0" encoding="Shift_JIS"?>

</CASE>

<End/>

</CASE>

</SWITCH>

</FLOWDEF>

図3.11 フロー定義例

表3.2(a) フロー定義におけるXM Lタグ一覧（フロー制御系）

Process in case of no data TRANSACTION_NODATA

Termination of loop process EXITLOOP

Loop process LOOP

Branch process DEFAULT

Data constant for condition VALUE

Branch process CASE

Conditional name of event adapter DID

Conditional branch SWITCH

Name of called subroutine NAM E

Subroutine call GOSUB

Termination of subroutine EXITSUB

Name of subroutine NAM E

Declaration of subroutine SUB

Root FLOWDEF

Description Attribute

Tag name

金融系トータル情報システムの 構築手法に関する研究