― 銀行システムの障害対策とITガバナンス ―



当論考は、第二地方銀行協会の機関紙「リージョナルバンキング」平成16年6月号への寄稿に加筆したものです。

銀行界では、共同化やアウトソーシングという形態でシステム外部委託化が進んでいます。結果として、障害発生時における対応手順が複雑化し、修復が遅延するケースも出てきました。また、銀行の第一線における顧客への説明方法にもインソーシングとは異なる対応が必要となりつつあります。ITガバナンスが劣化することによって、銀行経営のガバナンスそのものが脅かされる可能性もあります。こうしたリスクを踏まえた障害対策の態勢整備やITリスク管理の仕組作りが重要だと考えます。


銀行が主催・関連する決済システムは20以上ある。昨年末以来、全銀システムや統合ATMネットワークなどで障害が発生した。最近のシステム障害は、数年前までとは原因や影響を異にしつつあるように見受けられる。ハード機器のトラブルに端を発し、操作ミスによって障害範囲を広げるというパターンではなく、ソフト設計上のミスや、設計する際の前提見誤りなどの原因が増えている。また、一部銀行の障害が、決済システム全体の通常運営を阻害するケースも増している。

1.システム障害はなくならない


IT部門やITベンダーの立場からは明言できないだろうが、システム障害を皆無にすることは不可能と前提をおくべきである。技術革新のお蔭でハードの故障率は下がり、バックアッブ機器を充分に装備できるようになった。しかし、ハードに搭載するソフトは余り進歩していない。ベンダーが提供する基幹ソフトは念入りなテストと多数のユーザーによる使い込みが行なわれているので大きな問題はないが、その上に搭載するアプリケーション・プログラムは、新規開発・機能変更の都度に何らかのバグ(欠陥)を内包する。銀行勘定系システムには、1万を越えるソフト部品が組み込まれている。それぞれが相互に関連しあって作動するのだから、全てを事前に検査することは不可能である。このように複雑なシステムが普段は問題なく作動するのは、前提とする処理条件やデータの様式に絞った精緻な設計と徹底した検査をしているからにすぎない。その前提が変わればソフト部品に支障がでる。仮に1万のうち、一つの部品でも不具合が出れば他の部品に影響を及ぼすことがある。それを防止する仕組みは用意するが、コストと開発時間の制約から限界はある。

情報システムに障害が出るのは、鉄道や飛行機が故障するのと同じというより、使い方が多様な分だけ、より発生確率が高いと言って過言でない。課題は障害発生の可能性を下げる一方で、発生した時の被害を最少化し、早期に復旧させ、再発を防止することにつきる。特に被害最少化については、営業店を始めとした全行職員の協力が必要である。


2.決済システムは益々複雑化する


決済システムはリアルタイム化、グロスネット化、DVP化、STP化していく。複数の当事者間でリアルタイムに連動処理する取引が増える。障害が発生すれば、一瞬にして波及拡大するので、人間の処理能力では対応できずにパニックに陥るのは容易に想像できる。現在は、前述のような決済手法高度化が機関投資家や法人取引に限定されているので大きな問題になっていないだけと言える。

しかしながら、個人向けサービスでも多くの変化が始まっている。例えば、コンビニATMの普及で銀行以外を含めたATM提携が普及しつつあり、そこでは利用時間、手数料、提供サービスなど千差万別である。しかも、それが頻繁に変更される。全国に17万台以上あるATMを付け焼刃で接続していけば運用管理が混乱するのは必至である。更に本人確認用の指紋認証など使用メディアが多様化すれば、プロトコル(データ様式・処理手順等の約束事)を変える必要も出るだろう。全てを一度に変えることはできないので、5年以上は新旧が並存することになる。その間の複雑さは級数的に増大する。

一方でインターネットを使った電子商取引の中には、決済のネッティングを自社システムで集中処理する事業者が出てきた。最終決済のためだけに銀行システムと連携処理することになる。そこで障害が発生した場合に何が起こり得るか、誰が問題個所を特定し、その修復手順はどうするのか。決済システムへの参加者が多様化することでネットワーク運営も急速に複雑化している。クロスボーダー取引となれば、手におえない状況が発生しても不思議でない。

将来を見据えた上で決済システム全体を見直し、再体系化することが不可避となろう。


3.国の重要インフラの一つだが、銀行の負担は大きくなる


政府はeジャパン構想推進とテロ対策の一環として重要インフラ(防衛・治安・通信など)におけるリスク管理の調査研究を進めているが、金融関連システムも重要インフラの一つとされている。銀行業界も利用者も、重要インフラに指定されることに異存はなかろうが、銀行にとっては何かと制約とコストの増えることが問題である。また、決済システムなど多数の当事者に跨るデータ処理の場合は、最も脆弱な個所から不具合が連鎖拡大するので、その手当に対する増加コストの負担配分も問題となる。

昨今のように新規参入の銀行だけでなく、銀行免許事業者以外がATMネットワークの運営管理を行なうようになると、障害等の緊急時に関係者間の責任分界が不明確になり、障害原因の特定や復旧作業が錯綜するリスクも高まる。営業拠点において顧客への説明が不可能な事態が起これば、顧客の信頼を失うばかりか、賠償問題等にも発展しかねない。顧客としては、システム障害の責任が誰にあろうが正常サービスを提供出来ない取引銀行を責めることになる。更に問題を複雑にするのは、障害時の連絡体制が複雑になることだ。障害発生時の店頭での対応方法も各銀行の判断(事務規定)に委ねざるをえないことも緊急時の対応を複雑にする。

銀行としては、サービス提供手段を多重化するだけでなく、顧客との間でサービス・レベル・アグリーメントを結んでおき、高レベル・サービス(例えば、払い戻しや送金取引を100%保証するなど)は有料化するなどの仕組みが必要になるかもしれない。その為の保険も必要となろう。


4.システム障害はITリスクの一部


システムに係わるリスクとしては障害が最も意識されるが、実はIT全体のリスクを把握しておく必要がある。(図1


特に経営戦略とITのミスマッチや開発プロジェクトの失敗などは、経営に大きな影響を与える。システム障害や情報漏洩を含めたデータ・セキュリティなどのリスクも技術的対応だけでは実効性を確保できない。

一般的に認識されるシステム障害は、ソフトウェア品質リスクに起因する。バグといわれるプログラムの不具合は、開発の前工程である業務分析の段階、システム設計の段階、プログラム開発の段階で各々三分の一ずつ組み込まれると経験的に言われている。どんなにテストを繰り返しても、検出できるバグはプログラム開発のミスだけである。使い込むことで不具合を発見し、都度修正することにより表面化するバグを時間とともに減らすことはできる。決済システムのように、業務手順として単純な業務であれば、表面化するバグを殆どなくすことは可能である。


しかし、前述したように決済システム設計の前提条件が急速に変化している。顧客が24時間365日好きな時に好きな場所から使えるようになると、何らかの契機で取引件数が激変する。昔であれば、稼動する行内ATMの台数を制限するなどして取引量を制御することができたが、今日では全く不可能である。取引量の繁閑差は広がる一方であろう。前提とした許容量を越える取引が発生すれば、システムは停止することになる。ネット証券システムでは、最大取引件数(実績)の3倍の取引量に対応できるように、常に処理能力を増強しているほどである。システムの処理能力は、ソフトウェア品質リスクではなくシステムインフラ・リスクの問題である。インフラを取り替えるとなると、その時間・費用・再開発リスクは極めて大きくなる。システムインフラを読み間違えるのはIT専門家の責任と考えるかもしれないが、実は、業務設計の根幹をなすビジネス戦略やビジネスインフラの曖昧さや過誤が原因の大半である。

銀行におけるITリスクは経営リスクの主要部分をなしている。経営トップが技術的な細かいことに参画する必要は毛頭ないが、経営リスク管理の視点で、ITリスク管理への期待レベルの提示と必要資源の配分を行なう必要がある。


5.ITガバナンスとITケイパビリティの関係


ITガバナンスを端的に定義付けすれば、「何を、どんなサービスレベルで、何時までに、投資を幾らまでと決定して、実行を命令し、その進捗と成果を評価し、実行者を報奨或いは懲戒する」ことである。ITはビジネス戦略を具体的施策として遂行する際のツールであるから、ITガバナンスを失うことで、ビジネス戦略の遂行が不可能になる場合すらある。

ITケイパビリティとは、「要請される機能を所定のコスト、時間、サービス品質で開発・運営する能力」である。主としてIT要員の人数と必要な技術力(当該業務に関する知識経験と関連ITスキル)と投資力から構成される。プロセスとしては、ビジネス戦略を前提にIT戦略を策定し、対象分野における必要資源を定義・調達し、それを管理運営する仕組みを設計・実行することである。


第三次オンラインが構築された1980年代後半以降、CRM、収益管理、リスク管理、自己査定、インターネットバンキング等の開発はあったが、大規模なプロジェクトは銀行業界になかった。その間にIT担当者の世代交代が進み、若手に実践の場が少なく、銀行IT部門のスキルは徐々に劣化した。同時にITコストも一律的経費削減の対象となった。低コスト化と脱特定ベンダー依存の方策としてオープン系技術を導入しようとしても、行内IT部門には関連スキル・経験が不足していた。ITケイパビリティが劣化していたのである。

こうした状況下、経営としてはコスト削減とスキル補完を名目として、共同化或いはアウトソーシング化を進めつつある。しかし、このことは、オープン系技術を使いながら、むしろ特定ベンダーへの依存を高めるという皮肉な結果をもたらしている。また、自社のITケイパビリティを喪失させる可能性を持っている。一度、喪失すれば単独自力での回復は至難である。そこからITケイパビリティのない組織にITガバナンスが存続できるかという問題が出てくる。ベンダー等との契約により保持しうるとの考えもあるが、保証の限りではない。外部委託を行なう銀行からは、IT企画機能を社内に温存すると発表されることが多いが、実効性を確保できるか疑問である。実戦を知らない人達に企画機能を期待できるのか?ということである。[運用を知らない者が作ったシステムは動かせない。開発を知らない者が計画したシステムは作れない。]は多くの場合で真理である。

システム障害に関連して考えれば、行内にITケイパビリティがない状態で、顧客サービスの維持・向上をいかに具現化するかが課題である。システムが複雑化、多層化するに従い、複数のベンダー管理も複雑になる。契約で各社間の責任分界と義務事項は明確に定義されてはいるだろう。しかしながら、ベンダーによって作業手法は異なり、複数企業間の指揮命令系統の問題もある。一社にすべてを集中する考えもあるが、その場合にはITガバナンスを喪失する可能性が高まる。

ハードウェアなどの製品は対価を払えば誰でも短時間で入手できるが、ITケイパビリティは個人の持つ技術・経験の集積である。時間と経験が不可欠である。いわゆる2007年問題は、銀行だけでなく大手IT企業でも顕著に進んでしまっていることに注意すべきである。ある業界共同のシステムは、かって数十人いたプロパー技術者をリストラし、現在では数名に減らしている。それも全員同世代である。このリスクは極めて大きく、10年もすれば現実となることは間違いない。しかし、ITガバナンスがない為、放置されたままでいる。こうしたリスクは金融関連システムに多く見られる。

ITガバナンスはCEOとCIOが保有すべきであるが、詳細なITノウハウは不要である。シビリアン・コントロールできるだけのIT基礎知識とゼネラルマネジメント能力が必要なだけである。また、IT専門家は、三文字英語でCEOやCIOを当惑させずに、平易に説明できるだけの勉強が望まれよう。


6.事前対応として不可欠な施策


障害対策の基本は、発生させないこと、発生した場合に被害を最少化すること、復旧を早めること、再発させないことの4点に尽きる。障害の原因が分かっていれば即座に対応できるが、前述したように銀行システムは余りに巨大で複雑である。加えて近年では、開発も運用も担当者が銀行内外に分散多様化している。技術だけでなく銀行業務そのものも複雑化しつつある。障害発生時に顧客や営業店担当者に技術的な説明をしても意味がないが、業務に与える影響と代替策・回復策を説明する為には技術と業務双方に精通した人材が不可欠である。残念ながらこうした人材が払底しつつあり、ITベンダーに期待することにも無理がある。ベンダーは情報技術が専門で銀行業務は本業ではない。余りに分業化しすぎたようだ。

具体的な対策につき、技術的対策以外の項目を列挙する。技術的対策については、長年の経験に基づいた資料やツールがベンダーにもユーザー企業にも数多く蓄積されている筈である。

@  ITプロセス管理 ITに関わるプロセスを整理・体系化して、必要な資源を配分し、実行する手順を制度化することである。必要なITプロセスは図2のようなものである。分業化された機能の関係を管理できる。その責任者はCIOである。



AITリスク管理体制に専門監査を加える 共同化・アウトソーシング等を実施している場合でも、行内専門家か外部専門家を使って、システムの現況と障害対策計画を充分に把握・監査しながら、障害発生時における自行の対策・体制を準備しておく。この専門家は営業店等関連部門や顧客・マスコミ等外部への説明・報告内容作成責任を持つことが望ましい。

BBCPの策定と継続的更新 システムの適正作動が長時間に渡って不可能な場合のBCP(ビジネス・コンティンジェンシー・プラン)を策定しておく。障害の現象、波及する影響などを考慮して幾つかのシナリオを作成して、影響を最少化しつつ事業継続を可能とする態勢を設計・準備しておくことである。限界費用は、障害パターン毎の予想被害額と発生確率を計算することで投資上限額として算出できる。事前対策の成熟度と実効性が株価、格付け、オペ・リスクなどに反映されることも考慮すべきである。また、定期的継続的な実地訓練も不可欠である。いざとなれば様々な想定外の欠落があるものである。

Cモニタリング体制の充実 特にATMネットワークや決済システムについては、トランザクションの滞留や応答時間の異常などを早期に検知するためにも、ネットワークとアプリケーションの状況をリアルタイムでモニタリングすることが必要である。システムが外部委託の場合でも、その重要性に変わりない。

Dディスクロージャの充実 これまで銀行はシステム障害を発生させないという前提でいた。発生した場合には、極めて例外的な事象であると説明してきた。その結果、顧客も営業店も障害は許せないという極めて高い期待レベルになってしまった。この期待レベルの修正が必要であろう。例えば「障害は発生する可能性があります。その際には他行で取引をお願いします。その手数料は当行が負担します。」としてしまえば障害対策に関わる費用を激減できるかもしれない。民間の営利企業である銀行が鉄道以上のサービス継続性を維持する費用は誰が負担すべきかという問題もある。マスコミも銀行オンライン障害には敏感であるが、彼らには銀行事務や銀行システムに関する知識はない。銀行も正確な情報を提供する努力を尽くしてきたとは言い難い。行内、マスコミ、顧客に対して正確な実状を説明して、全者が納得できるサービスレベルを設定すべきであろう。


7.障害発生以後の対応策


オンライン障害の場に立ち会って何時も痛感するのは、営業店からの悲鳴にも似た問い合わせの多さと頭取や上級役員からの叱責・詰問の電話である。何が起きているか全体を把握できるのはチーフ・オペレーターだけだが質問に応対している余裕はない。原因が判っていれば対処策と所要時間は予想できるが、多くの場合は障害原因が複合的に絡んでいる。運用チームは原因と対応策の解きほぐし作業で緊張の極限状態にある。運用チームには回復作業に専念させるべきであろう。外部からの圧力はマイナス効果しかない。

@    営業店の対応 

障害の状況によって、発動する体制は通常四つである。待機、部分稼動、手作業での対応、バックアップへの切り替えである。銀行オンラインは、パソコンのように電源を入れ直すだけという訳にはいかない。滞留していた取引の扱いを含めて、障害の後処理には膨大な作業が必要となる。最終的にはCIOの決断であるが、営業店においては常に悪い方の事態を想定して準備しておくことが無難だろう。

A    連絡体制 

特に決済システムやATMネットワークのように複数の当事者が関係する場合は、障害原因特定が難しくなる。加えてコミュニケーション上の問題も発生する。関連各社のシステム担当者を含めた指揮命令系統の整備・訓練が必要である。特に運用を外部委託している場合は、ベンダー間で用語が違うことや業務に不慣れなことが多い。緊急時の連絡方法と内容に関する事前の刷り合わせが不可欠である。

B    初動対応 

こうした基本的準備を前提として、障害の早期発見昨、被害拡大防止策、早期復旧策を事前に準備・訓練しておくことで障害発生時に整然とした対応が可能となる。前述したように、障害は単発的な原因で発生し、順次波及していく。初動対応が重要な理由である。技術的にはPD(プロブレム・ディターミネーション)といって障害の因果関係を整理したマニュアルが準備されている筈で、運用チームはそれに従って問題発生箇所や原因を推測し確認する。特定できた段階で応急処置を施すことになる。適確な情報と正確な判断ができる環境が必須である。

C    顧客への説明 

顧客は第一に回復時間を知りたい。各行ともに店頭での顧客説明の手順・内容についてマニュアル化されているだろう。問題は、当初の説明と異なる事態に発展する場合である。インターネットや電話センターか携帯メールで復旧状況を報告することも有効だろう。

D    マスコミへの協力依頼 

大規模な障害の場合はマスコミからサポートを受ける必要も考えられる。テレビ、ラジオ等で障害の状況と銀行としての緊急対応策を報道してもらうのである。その為にも事前対応で述べたマスコミ啓蒙活動が重要である。また、マスコミ等外部に対する説明の方法も課題である。簡潔かつ正確に判りやすく説明するには相当の知識と説明技術を必要とする。システムと障害対策を熟知したスポークスマンを配置育成しておくことが望まれる。

E    再発防止策 

想定外の取引件数が発生して障害となる場合がある。予算の関係もあって、機器増強や記憶域拡大を小出しにして障害を繰り返す例が散見される。経営の理解を得て、早い段階で抜本的な対策を取ることが無難であろう。

最後に、ITの経験のない方々には、銀行の情報システムは単なるハードウェアの集合体でないことを再確認頂きたい。まだまだ、情報システムを車や家電製品のようなハード商品と同じに考える経営者が多い。情報システムは、組織文化、事務処理手順、顧客サービスをプログラム化してハードに搭載している。経営陣を始めとした全行職員の参画と協力があって、適正な運用と戦略的な活用が可能となる。障害のような緊急時には、その銀行の組織力や文化が現れるものである。