◇銀行合併とシステム統合◇


 このレポートは、地域金融研究所発行の「NewFinance」2003年3月号への寄稿に加筆したものです。今後も銀行合併が続くであろうという認識のもとに、システムを一本化しないと合併効果が出ないという考えに疑問を呈しています。IT業界にとっては、事業機会の先送りとなるかもしれませんが、ITが銀行の合併戦略の足枷となることを避ける方法を論じています。


わが国の銀行にとって合併や持株会社の下での会社分割などが、例外的な戦略ではなくなってきた。業績悪化銀行の救済や自己資本増強策としても使われるが、本来は事業のコスト構造、収益構造を抜本的に再構築する手段として活用されるべき戦略手段である。

具体的には、顧客基盤・商品機能・チャネルの強化に加えて、従業員数・店舗数・IT費用の削減効果を期待することが多い。都市銀行の再編成によるメガバンク発足の際に、どの経営者も海外主要銀行との競合に必要なIT投資余力確保を合併目的にあげたことは、記憶に新しいところである。

1.合併時にシステム統合を行なう必然性はあるのか?

発表から新銀行発足までの時間制約があることから、通常、合併対応のシステム変更は二段階で実施される。

第一段階として、通帳・ATMカードの相互取扱いや銀行コードなどの変更に伴うシステム変更が必要となる。一般的にRC(リレーコンピュータ)と呼ばれる小型コンピュータに、コード変換やオンライン取引の仕訳け機能を持たせて、当該行のシステム同士を接続する。また、振込・口座振替処理に関しては、新しい銀行番号や調整した後の店舗番号にあわせたデータを顧客に作成してもらう必要がある。そのデータをバッチ処理する為に、両行分の仕訳け、処理、結果を受付銀行のシステムで確認するように修正する。いわゆるRC接続というシステム変更である。この方法だと、元々の取引銀行でのATMや窓口でしか通帳や証書の取引ができない。無帳引出は他行扱い手数料を徴収しないようにすれば問題ないが、どちらの銀行でも有帳取引を可能にする為には、ATMと窓口端末を相互に設置するクロス設置という方法を取ることになる。顧客の通帳が使えるATMや窓口を明確にするために、赤や青の掲示を行なうことが多い。インターネットバンキングも普及しているので、同様に二種類の受け口を用意することになる。

大手銀行の事例で言えば、これらのシステム変更に半年間500人月程度の作業が必要となる。クロス設置用のATMや端末機の費用も発生するが、技術的には難しいことではない。顧客を含めた事前準備と移行作業に注意を要するだけである。

第二段階として、システム統合(システムの一本化)が検討される。商品・サービスの統一、店舗統合などを行なうためにはシステムの一本化が前提とされている。また、複数のシステムを集約すればIT費用が節減できるという期待もある。システム統合の方法は三種類ある。

@ 片寄せ方式:一方のシステムを残して他方を廃棄する方法である。最も簡便であるが、廃棄するシステムにあって、残るシステムにはない機能や商品の扱いが課題となる。得てして後追い開発と言い、一部の機能を廃棄システムから存続システムに移植することになる。ところが、システム基盤が異なったり、他業務と密接に関連しあったりするので、この作業は極めて複雑で労力を要し、障害を発生させる元になる。ソフトウェアはハードウェアよりも、はるかに硬直的なのである。片寄せの場合は、極力、存続システムを変更しないことが重要である。一部の商品や機能を放棄する覚悟が必要であろう。

A 最善機能選択方式:両行の機能の良い所取りを目指す方法である。預金や為替、融資などの業務別に比較検討して優れた方を選択する。時には、更に細かく分類して商品やサービス別に選択する場合もある。両行のハードウェアや基盤ソフトなどが異なることが多いので、新しい基盤を構築してから、選択した機能を移植することがある。

作業期間も費用も膨大であり、開発リスクも大きい。ソフトウェアは30%以上を変更するのであれば、全く新規に開発する方が容易である。この方式は実務的・技術的には採用すべきものではないが、対等合併などで政治的配慮から採用されることがある。

B 新システム開発方式:全く新しいシステムを開発して、両行ともに移行させる方式である。容易に想像できるように、膨大な時間と費用を要する。地方銀行の第三次オンラインは、1万人月から3万人月をかけて数年がかりで開発された。十数年前に比べてハード機器は大幅に低価格化したが、開発費用は高騰している。パッケージを採用しても、この課題の解決になることは少ない。窓口端末機の更新も必要となる。合併が前向きな目的で、時間・予算に余裕がある場合を除き、採用できる方式ではない。

結論からすれば、現行の複数システム並存を続ける方が合理的である。合併という緊急時にシステム統合のような大規模投資は避けるべきであろう。システム統合完了までの数年間は、新しいIT機能を展開できないばかりか、業務の効率化施策も営業活動一本化も制約されることになる。何よりも一線行職員の効率とモラールを落とすことで、合併効果そのものを阻害しかねない。現行システムの維持費用は続くが、統合によるIT費用節減額は30%程度というのが地銀IT共同化事例などからの経験値である。収支均衡まで10年前後を要する投資を行なう時代ではない。

仮に統合する場合は、三井住友銀行のように全面的な片寄せ方式を採用すべきであろう。

2.合併効果を早期に実現するシステム施策は?

近年、ITの共同化やアウトソーシングが普及している。アウトソーシングの場合は、既存システムの運用を外部委託することが多いが、共同化の場合は新規にシステム開発をすることが多いようである。昨年来、数多くの開発プロジェクトが計画変更や稼動延期となり、多大な損失を発生させている。銀行とITベンダー双方の開発力低下も危惧されている。

また、大型汎用機による大規模開発が技術的に陳腐化しているとの判断から、オープン系といわれる技術で開発を始め、挫折する事例も出ている。

こうした状況下で、新システムを開発することを前提に合併計画を実施することには、極めて大きな危険を伴う。勘定系オンラインのような大規模投資は、まさに戦略案件である。新銀行の経営戦略に基づいた、商品戦略・顧客管理戦略・価格戦略・サービス戦略・チャネル戦略とそれを支援する財務戦略、人事戦略に合わせてIT戦略を構築することが重要である。これら事業戦略がなくて、新システムに必要な機能を定めることはできない。


現在の機器が処理能力の限界に達し、上位機種がないので新規開発するなどということは本末転倒であり、一線の行員にも顧客にも何の恩恵がなく、株主利益を失うだけである。

インターネットを利用した商品・サービスに対応することを理由とする事例もあるが、従来システムとインターネットバンキングを問題なく並存している銀行は数多い。

店舗統合を行なうためには、システム統合が絶対前提条件という考えがある。しかし、これは統合が完了するまで店舗統合に着手できないと言うに等しい。両行のシステムを並存したままで、統合効果を享受する方法はある。例えば、

第1段階 RC接続

RCで両行オンラインを連結してATM、窓口処理、総振・口振処理、為替電文対応などを実施する。ATMや窓口端末はクロス設置を行なう。

第2段階 ネットワークと端末機の更新

現在の低速・高コストの専用ネットワークをインターネット・プロトコルの高速回線網に切り替え、電話・FAXなど各種通信網と統合する。これにより、通信費用の大幅削減を実現する。窓口端末機が旧式で償却が完了しているのであれば、高額な銀行専用端末機からウェブ・ベースの端末機に更新する。現金や通帳処理機能を除けば、一般仕様のPCなので価格は大幅に低下しており、使いやすく、多目的である。

第3段階 後方事務の集中化

両行の後方事務をイメージ・スキャナーによって集中化する。20〜40%程度の合理化効果が期待できる。また、後述の支店内支店を採用するためのスペース確保にもなる。最近では、まさに製造業のリーン生産方式のように高度に自動化された集中処理の方法が開発されている。銀行にとって根源機能であるプロセシング能力をプロフイット化できる可能性が出てきた。

第4段階 統合CRMの構築

両行の顧客を名寄せし、一元管理できるようにする。但し、この段階では元帳は並存しているので、統合CRM(カストマー・リレーションシップ・マネジメント)を別途構築する。これを活用することで、営業活動の一元化と効率化を図る。当初は、重要顧客の基本情報や属性情報を一元化し、取引情報については、必要の都度、アグリゲートする方法で対応できるだろう。 

第5段階 支店内支店による店舗統合

両行の近隣支店は、一方に統合する。合併前に実施するには両行の看板が併設となり、合併後でもカウンターとATMに案内板を掲示せざるをえないが、顧客への実害はない筈である。

第6段階 ATMや窓口端末を更改、或いは改造することで、両行共通の新通帳・カードに順次更新する。また、商品に相違がある場合は、廃止するか統一対応する。

第7段階 新商品や新機能が必要な場合は、どちらか一方のシステムに追加開発するか、別途、独立した第二勘定系システムを構築する。ペイオフ解禁時には、決済預金の創設が予定されている。

これを全商品のハブ・アプリケーションとして設計できれば、現在の複雑に関係づけられたアプリケーション構造を整理し易くなるだろう。

これらの施策を、経営戦略の優先順位や両行システムの状況から判断して、組替えるのである。合併前に統合効果を享受できる可能性が高い。新システム導入は、経営環境と技術革新の状況を見計らって、最適な時期を決定すれば良い。

この方式の課題としては大きく三点ある。

@ 通帳・カードが二重のままの期間が長く、顧客を混乱させたり、クレームの対象になることである。懇切な説明と時間外手数料の無料化などが必要となろう。

A 半年間の例外処理期間内に、銀行コードを一本化しなくてはならないことである。全銀協が無期限に複数銀行コード対応を継続すれば問題は解決する。

または、一方のシステムを修正するか、FEP(フロントエンドプロセサー)を設置して、銀行コードの変換を行なう方法もある。

B 勘定精査の重複が発生する。銀行システムによって精査手順は異なる。特に支店内支店を導入した場合は、同一店内に二重勘定が発生する。現金勘定だけでも一本化するように、店頭処理体制と手順の工夫が必要となろう。

3.システム対応は経営トップの参画とシステム監査で成功できるか?

前述したように、昨今の銀行およびITベンダーのシステム構築力劣化は進んでいるようである。銀行経営者のITに対する不信と不満は高まっている。一方で、金融庁はシステム統合に関する金融検査マニュアルで、経営者の積極的参画と結果責任を要求している。このこと自体は正しい方向であるが、IT経験の少ない銀行経営者にとっては具体的対応の方法がないだろう。外部の専門家を頼ろうにも、銀行システムに精通したITコンサルタントは稀少である。多くは問題点列挙と実行不能な案を提示するだけである。

また、プロジェクトの監査を強化すべしとの考えもあるが、現実的にはプロジェクトの阻害要因になることが多いだろう。システム監査は平常時に規則通りの運用がなされることを担保するには有効であるが、大規模プロジェクトのような変動要素の多いケースにおいては、別の体制が必要である。

例えば、統合プロジェクト・オフイスを頭取直属で設置することである。頭取室に設置するくらいが望ましい。メンバーは、事務・営業・財務の専門家と現行システムの運用責任者、ITプロジェクト管理の熟練者などである。

当オフイスの役割は二段階に分かれるだろう。

@ 統合化計画作成段階:両行各部門の利害が錯綜する段階である。統合化投資を目指した外部からの接触も多い。とにかく、早い段階で変数を減らすことが重要である。判断基準を定めておいて即決することが求められる。大規模プロジェクト失敗の原因の多くは、経営トップが変数を減らすどころか、判断を遅らせたり、計画変更を頻繁に行なうことである。

A 統合化実施段階:システム対応とそれに伴う事務指導・研修、顧客への通知作業などを統括する。統合プロジェクトでは、品質管理と移行計画がポイントである。そして万一に備えたリスク管理をも担当することになる。

多くの銀行では、必要な人材を行内だけでは集められないことがあろう。その場合は外部の顧問グループを組織することになる。顧問に期待するものは経験と知識であって、ITベンダーの知名度や事業規模などで判断するのは危険である。まさに個人の能力が必要である。頭取自らが面談の上で、銀行業務とITプロジェクトに精通した人材を少数でも集めることである。最近は、大手銀行やITベンダーから二次オンライン、三次オンラインを経験した多くのベテランが転退職しつつある。こうしたベテランの活用も有効だろう。

4.メガバンクは合併によってIT投資余力を増すことができたのか?

あるメガバンクのIT支出は、平成12年度が1600億円、平成13年度が2400億円、平成14年度が2300億円と新聞報道されている。合併前の各行のIT支出を合計すると、およそ1000億円である。確かに支出額は急増したが、大半が合併対応と現行システム維持費である。その間に他行が進めたネットワーク更新や営業推進システムなどには手が回っていない。インターネットバンキングも大きく遅れをとっている。

いずれの時にか、システム統合は完成し、システムの維持費用は削減できることは確かである。しかし、その削減率は前述したように30%程度と想定される。上の例だと年間300億円である。その為に10倍以上の投資を行う合理性には疑問がある。更に、タイミングの問題も大きい。不良債権処理を始めとして大きな経営課題を抱えている時期であり、業界構造も垂直型から水平型に大きく変わりつつある。その間、先進的なIT対応は殆どできないことになる。

大手米銀のIT投資額とIT要員数は、邦銀大手の数倍であることは事実である。新しいシステムも積極的に構築している。それが可能なのは、業務に精通したIT人材を容易に入手できる労働市場があること。そして、邦銀オンラインのように顧客勘定元帳が一本でないため、システム増築にあたって既存システムとの連携負担が少ないこと。膨大な小切手処理を始めとした単純事務要員を大量に抱えているため、合理化によるコスト代替効果をえやすいことなどが考えられる。

日米の銀行IT化進展度を、予算規模だけで比較することは極めて危険である。日本の銀行が、世界最高水準の事務処理効率を持っていることを無視してはならない。

5.合併時のIT戦略で経営トップのなすべきことは?

今後も銀行合併は発生するであろう。その際に、ITが大きな課題であることは、既に共通認識となった。懸念すべきは、合併時のシステム変更によるシステム障害ばかりに目が向けられていることである。

現実として認識しておくべきことが三点ある。

@ システムは人間が手作りするプログラムの集積であり、欠陥をなくすことは不可能である。つまり、障害は発生するという前提で業務手順・体制を構成し、システムと連携させなくてはならない。

A 合併時のRC接続は、これまでに何度も実施されてきており、技術的には決して難しいプロジェクトではない。最近のプロジェクト失敗の大半は、ITガバナンスとシステム化計画、そしてプロジェクト管理の欠陥に起因している。基本に忠実であれば、恐れる必要はない。

B システムは各銀行の業務手順そのものであり、組織文化を反映している。決して、テレビや冷蔵庫のような箱物ではない。製造ベンダーの知名度や機器の古さなどでシステム対応策を決定してはならない。


では、合併を考える経営陣はシステム対応に関して、何を考え、なすべきであろうか。

@ 合併による新しい銀行象を具体的に語り続け、全行員・顧客・株主と共有する。

A 具体的な戦略を立案して、それに必要なシステム機能を整理する。

B 必要なシステム機能と、現行システムとのギャップ分析を行ない、システム変更や統合計画を策定する。その際には、余りに多くのことを一度で変革しないようにすべきである。

ここまでの作業は、合併発表後3ヶ月以内に終えることが望ましい。遅れるほど、行内での不安や混乱が高まり、協業が難しくなる。また、優秀な人材が流出する危険も高まる。

C 必要な体制を整備する。特に人材の手当てが重要である。トップ自らが、プロジェクトを任せるリーダーと複数のサブリーダーを選任し、必要な権限を与える。それまでの行内序列や両行バランスなどで判断してはならない。

D システム対応の作業中には、多種多様な問題が発生する。事前に準備した判断基準に基づいて、迅速に判断し、必要な資源を提供する。この際に、前述のプロジェクト・オフィスのような組織が必要である。また、先進のプロジェクト管理技法とツールを使って、進捗を常時モニタリングする。進捗の概要については、できるだけ社内にディスクローズする。

E 合併には相当規模の費用負担が発生する。技術的要素のみでなく、政治的要素も複雑化する。専門家による技術的裏付けをとりながら、早急に変数を減らす必要がある。その根拠をプロジェクト・メンバーに開示することで、透明性と納得性を確保する。また、決めたことは変更しないようにする。

F 作業完了基準コンティンジェンシープランを作成しておく。品質管理と完了基準は数値化し、その正確性を担保するチェックを行なう。常に、プロジェクト・リスクを測定しつつ、最悪の場合に備えた対策を準備しておく。

G 大きなITプロジェクトは、メンバーの健康と生命を左右するほどの危険を伴う。経営者としては、メンバーの健康とモラールに注意しすぎるということはない。


以上のことは、これまでにも大規模開発で各銀行が経験してきたことと同様である。ただ、合併という最高レベルの経営課題であり、全組織の協業とスピードを必要とするために、経営トップ自らがリーダーを務める必要があるということである。


→ 調査レポート Backnumber