みずほ銀行の「システム障害特別調査委員会」報告書

2012年4月20日金曜日 | ラベル: |

4月10日のブログで「わが国の決済システム、金融機関が、今回の大震災にあたり安定的に金融・決済機能を発揮し続け、国民生活や経済活動を下支えする役割をしっかりと果たしたことは高く評価されるべきことだと思います。ただその最中、東日本大震災直後の3月14日(月)夜から発生したみずほ銀行の大規模なシステム障害は誠に遺憾な出来事であったと痛感します。」 と書きました。今回はみずほ銀行の「システム障害特別調査委員会」報告書をご紹介申し上げます。

素敵な京都の櫻 その3です。

HP 「京都の四季」より  祇園 白川

 祇園・白川の畔に「かにかくに 祇園は恋し寝(ぬ)るときも 枕の下を水の流るる」の歌碑が建てられている吉井勇先生も60年前大学入学当時はまだご存命でした。

祇園 新橋 「かにかくに」の歌碑
ブログ 京都検定を目指す京都案内(2010.10.6)より

○みずほ銀行の「システム障害特別調査委員会」報告書
 日本銀行決済機構局の「東日本大震災におけるわが国決済システム・金融機関の対応」には、「3月14 日(月)夜、一部大手行でシステム障害が発生し、その後、日をおって決済不能件数・金額が拡大した。当該行が設置した第三者委員会の調査報告書によると、同行において、15 日(火)指定日分から23 日(水)の指定日分までの合計約120 万件の為替電文が未送信となった。また、16 日(水)指定日分から18 日(金)指定日分まで合計約101 万件の受信為替電文が未処理となった。当該障害は、今回の地震や津波に直接起因するものではないが、義援金が一部口座に大量に集中し、その後の対処ミスとあいまって障害を大規模にしたと報告されている。」と記述されています。今回はみずほ銀行のシステム障害を詳しくご報告致します。

 以下は、みずほ銀行の「システム障害特別調査委員会」報告書の抜粋です。
✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦
第1 調査の概要
1. 委員会設置の経緯
株式会社みずほ銀行(以下「MHBK」という。)は、2011年3月14日夜から24日にかけて大規模なシステム障害(以下「本障害」という。)を起こし、その間、給与振込等の為替送信が遅延し、ATMが利用停止になるなど、顧客らの経済活動に多大な影響を与えた。
 MHBKは、本障害に対し、原因究明と再発防止策の策定を実施することとしたが、本障害が顧客や社会に与えた影響の大きさに鑑み、外部の識者・専門家から構成される第三者委員会を設置し、中立・公正な立場から原因究明と再発防止策の妥当性評価及び提言を受け、システム障害の再発防止と信頼回復に努めることとした。その結果、MHBKと利害関係を有しない法律専門家及びシステム専門家に委員就任を依頼し、4月11日にシステム障害特別調査委員会(以下「本委員会」という。)を設置した。(後略)

第2 調査の方法・範囲   (略)

第3 本調査の結果判明した事実
1. 本障害の概要
(1) 本障害の概要について
 本件の調査対象である本障害は、2011年(以下、個別に明記しない限り、日時の表記については2011年を指す。)3月11日(金)に発生した東日本大震災に伴い、特定の義援金口座に対して振込入金処理が集中したことに起因して、14日(月)勘定系システムの夜間バッチの処理件数がリミット値を超えたため異常終了したことに端を発するものである。
 MHBKは、上記の夜間バッチの異常終了に対してシステム復旧処理を実施したものの、当該処理に多くの時間を要したため、実施されるべき一連の夜間バッチが15日(火)の営業店開始時刻までに終了しない状況が濃厚になった。そのため、MHBKは、夜間バッチを中断するとともに営業店端末の開局処理を実施し、一旦中断した夜間バッチの影響により業務提供が不能となる取引の抑止オペレーションを実行した。
 しかし、これらの作業には時間を要したため、15日(火)の営業店業務の取引開始は遅延した。更に、営業店端末の開局処理に必要なバッチの日替り処理(以下「DJS切替」という。)により、通常自動化されているシステム運行が手動に切り替わったために、当日中に中断した夜間バッチを終了できず、終了後に予定していた為替の送信ができなかった。
 また、16日(水)朝、14日(月)分の夜間バッチが終了し、15日(火)分の夜間バッチを開始したが、14日(月)の義援金口座とは別の口座において、14日(月)と同様の振込入金処理の集中が発生し、16日(水)早朝に再び夜間バッチが異常終了した。この後、前日同様に取引抑止オペレーションを実行する必要があったことに加え、ATMの障害への対応が生じたため、16日(水)の営業店業務の取引開始も遅延した。以後、夜間バッチの未処理が蓄積するとともに、手動によるシステム運用に起因する人為的ミスも多発し影響範囲が拡大していった。
 システムリソースの確保及び未送信為替の増加を防ぐために、三連休を含む18日(金)から22日(火)の期間、ATMやダイレクト・チャネルの利用制限を実施し、滞留している夜間バッチを実行した。しかし、その後も処理時間の不足による未処理や、人為的ミスによる未処理が続いた。更に、本障害を起因として一部取引明細の提供不可等、顧客に影響を与える事象が副次的に多数発生した。

(2) 本障害の発生事象による分類
 本障害を発生事象ごとに分類すれば、①為替処理の遅延、②営業店業務の取引開始遅延及び取引停止、③ATMの利用停止及び利用制限、④ダイレクト・チャネルの利用制限及び⑤その他顧客に影響を与えた事象に分類される。

2. システムの概況   
 現行の勘定系システムは、旧株式会社第一勧業銀行(以下「DKB」という。)において1988年に稼動開始したシステムをベースとし、2002年の経営統合時に旧株式会社富士銀行(以下「FBK」という。)のシステムと併せて稼動させ、それらをリレーコンピュータによる暫定的なシステムで繋いだ上、2004年7月から12月にかけて、旧FBKシステムのデータを旧DKBシステムに移行し、一本化されたものである。(後略)
(1) 現行MHBKシステムの概要 ― (5) 本障害に関連する各種規程(略)
(6) 緊急時の体制
 MHBKの緊急時体制は、取締役会が定めた「事業継続管理の基本方針」(以下「基本方針」という。)に基づき、頭取が事業継続管理を統括し、「緊急事態が発生した場合には、各担当役員からの報告に基づき、頭取の判断により、頭取自身を本部長とする「緊急対策本部」または、頭取が指名する者を長とする「非常対策PT」を設置し、情報収集や対応方針の決定、対策の指示等を行うこととされている。(後略)

3. 本障害発生以前のシステム障害及び対応状況 (略)

4. 本障害の発生事実
(1) 発生事象と復旧措置
ア 為替処理の遅延
3月15日(火)から24日(木)にかけて、大規模な為替処理の遅延が発生した。(後略)
(2) 発生事象への事後措置 (略)
(3) 本障害に対する経営の関わり(略)

第4 発生原因の分析
1. 原因分析の概要
 本調査の結果判明した事実により、各種障害を引起こした原因を検討すると、システム障害発生前及び発生後間もない時期の担当者による基本的な過誤(例えば、リミット値の認識不十分、システム全体の理解不足、これらによる回復作業時間見積りの誤りやDJS切替等の判断の誤り等)によるところが大きいものと認められる。しかしながら、更に、このような基本的過誤をもたらし障害の影響を拡大させた原因を検討すると、システム機能上の不備、未然防止に至らなかったシステムリスク管理態勢上の不備、復旧対応における緊急時態勢の不備、人材の育成・配置の遺漏並びに経営管理及び監査の不備等が指摘され、再発防止策を検討する上では、このような基本的過誤をもたらした原因を明らかにすることが必要である。(後略)

2. システム機能
 MHBKの勘定系システムは1988年に稼動を開始したものであるが、その後、情報環境は大きく変化し、例えば、ATMは、当時においては稼動時間が限定されていたものの、現在では24時間の利用が可能となり、インターネット・モバイルを始めとした取引チャネルが多様化し、情報量が増大したばかりか短期集中的な処理を求められるようになっており、そのためにシステム復旧に充てられる時間的な余裕は減少しつつある。したがって、このような状況の変化に応じシステムにおいても柔軟に対応すべきであったといえ、これをまとめると以下のようなことがいえる。
(1) 大量取引が集中した場合のシステム処理単位
 A社の義援金口座aに係る夜間バッチの異常終了は、当該口座の明細を退避する処理によって発生したものであるが、この処理は、本来リミット値の範囲内で明細を区切って実施すべきであるにもかかわらず、当該口座の全明細を一括で実施しているために、大量データを処理しようとした際にリミット値を超過し異常終了した
 また、B社の義援金口座bに係る夜間バッチの異常終了は、大量明細がある場合に後続の夜間バッチにデータを振り分ける処理において発生したものであるが、データの振り分け処理についても、本来リミット値の範囲内で実施すべきであるのに、当該口座の全明細を一括で実施しているため、上記と同様に、リミット値を超過し異常終了した
 取扱うデータ量が著しく増加した現時点では、大量取引の集中に対して柔軟に対応できるように、システム機能においてリミット値を踏まえた処理の分割を図るべきところ、あらかじめそのような措置を講じなかった
(2) 夜間バッチが長期化した際のシステム運用機能
 STEPSは、日中のオンラインと夜間のバッチとが交互に行われることが予定され、夜間バッチにおいては、TARGETで自動運行されているが、夜間バッチの突き抜けの場合には、営業店端末の開局時間を延期しない限り、夜間バッチを中断してDJS切替を実施する手順となっていた。しかし、DJS切替を行うと、残りの夜間バッチが手動となり、その処理に膨大な手数を要することとなるばかりか、為替データの作成・送信が夜間バッチの後に一括して行われることにより為替送信も遅延する仕組みとなっていた。
したがって、担当者がこのようなSTEPS、TARGETの基本的な仕組みを理解し、夜間バッチ突き抜けの場合のリスクが大きいことを認識していれば、あらかじめ、DJS切替を実施した場合においても、処理未了分の夜間バッチを自動運行できる機能を備えるといった対策を講ずることが可能であった
 上記の対策も、復旧処理の過程で初めて検討し3月19日から順次実施されているが、当初から実施されていれば、システム障害は短期間に収束することができたといえよう
3. 未然防止に向けたシステムリスク管理
 システム障害は、夜間バッチで実行された1処理においてリミット値を超過したことを起因として発生したものである。当該リミット値はシステム稼動時から設定の見直しはなされておらず、定期的な点検項目にも入っていなかったため、担当者において、夜間バッチにおける当該リミット値が存在することの認識すら不十分であった。このようなことを防止するためにシステムリスク評価が行われ、また、ビジネスの環境変化に応じた点検項目の見直しが必要であったが、定期的システムリスク評価及び新商品・サービス導入時のシステムリスク評価の点検項目の見直しが不十分であったために、システム障害の発生を未然に防ぐことができなかった。(後略)
4. 復旧対応における緊急時態勢
 障害が発生した場合、早期に復旧するためには適切な緊急時態勢が整備されなければならない。緊急時態勢については、事業継続管理関連規程として事前に準備されていたにもかかわらず、本障害を早期に復旧することができなかった原因は、緊急時における態勢が実効性を伴っていなかったこと、システムコンティンジェンシープランとして想定すべき事象が不足していたこと、復旧対応の手順書が実効性を伴っていないことが指摘される。また、それらの不備を検知できなかった原因としては、チェックプロセス及び訓練が、実効性を検証する役割を果たせなかったことが挙げられる。(中略)
 このように復旧対応への取組みが形骸化することとなった背景には、2002年の大規模障害の再発防止策において、新規開発システムに対する品質向上策や、障害の未然防止策に重点が置かれていた事情や、STEPSは長年安定稼動していたという事実、更に再発防止策により障害発生件数が減少傾向にあったという事実による油断から、復旧対応に取り組む意識が希薄になっていたものと思われる。(後略)
5. 経営管理及び組織管理の問題
(1) 人材の計画育成及び適所配置
 本障害の原因として、ある事象の勘定系システム全体への影響を分析する能力を有し、あるいは多重障害の復旧見通しが立てられる実務人材が不足していたことが指摘される。たとえば、IT・システム統括部において、夜間バッチや為替について、MHIRから提示される対応策を十分に理解できず、更に、MHIRからなされる報告も、発生した事象に関する断片的な情報にとどまり適切な障害対応の判断には不足していたにもかかわらず、そのまま受け入れる判断しかできなかったのである。また、一連の障害を通じて、システム全体を俯瞰でき、かつ、多重障害の陣頭指揮を執り得るマネジメントの人材も不足していたといえよう
 その上、MHBK、MHIR、MHOS合同でのシステム障害を想定した実地訓練がこれまで実施されていなかったことからも明らかなとおり、訓練を通じて人材を育成する視点が希薄だったと考えられる。(中略)
 人材の不足の背景には、2002年に大規模障害が発生して以降の品質向上への取組みの結果、勘定系システムにおいて障害件数が減少し、本障害の引金となった夜間バッチで開局が遅延するような多重障害が過去に発生していなかったために、MHBKのIT・システム統括部、MHIRにおいて現実の障害に対応する経験を積む機会が減少したこと、また、既存の勘定系システムの設計全体を見直す取組みを次期システム構築時に実施する方針であることMHIRにおけるシステム開発がグループ外部へ再委託されることが主流となっていること、更に、開発及び運用の自動化の推進が進められたために、システム部門の人材が自らシステム開発やシステム運用の実務を学習する機会を減少させたこと等が挙げられる。加えて、経験豊富な職員の退職が進んでいく一方で、勘定系システムのシステム要件と業務要件に精通した人材が重点的に大規模プロジェクトに投入された事情もあずかっていたといえよう。 (中略)
(2) 監査の実効性
監査部門においては、STEPSに対するシステム監査の不十分さ、グループとしての監査体制の不備、外部監査の活用の遺漏が指摘される。 (後略)
(3) その他
 MHBKにおいては、システム機能の整備、復旧対応の管理態勢、人材育成及び監査の各分野で、前記のとおりの不備が認められるが、その背景には、ビジネス環境の変化やシステム利用の多様化等に対応しきれていない事情があることがうかがわれる。このように、ビジネス環境の変化が現行システムに及ぼす影響を組織として常に掌握し、システムの改善、監査の充実等において時宜に応じた対策を講じ、人材の育成や確保の点でも十分な措置を施すべきであったといえよう
 振りかえって、2002年4月の大規模障害における再発防止策についてみると、本障害の発生原因とは直接の関連はないが、このような大規模障害を教訓として、コンピュータシステムの安定した稼動に組織として留意すれば、今回のシステム障害は防止することが出来たはずであることも指摘しておかなければならない

第5 再発防止策の提言
1. MHBKの再発防止策
 MHBKは、今回のシステム障害を踏まえ、4月28日に「システム障害等に関する発生原因分析、改善・対応策」を策定した(以下「再発防止策」という。)。
 MHBKは、その中で今回のシステム障害の原因について、①今回の障害は、「特定口座への取引集中がセンター集中記帳途上での異常終了を招くこと」及び「その結果として様々な業務に影響を及ぼすリスクがあること」について、認識が十分ではなかったことが背景にあるとした上で、②今回の障害を発生・拡大させた原因は、上記認識の不十分さに起因して、「特定口座に取引が集中した場合に発生するセンター集中記帳の異常終了を未然防止する取組が不十分であったこと」及び「センター集中記帳の途上で異常終了した後の事後対応が不適切であったこと」に大別されるとしている。(後略)

2. 再発防止策に対する評価
MHBKの再発防止策は、今回のシステム障害の原因についてシステムリスクについての認識が不十分であったことを率直に認めた上で、今回と同様のシステム障害の再発防止策のみならず、システムリスク一般についての管理態勢等についても考慮した内容となっており、基本的に妥当なものとして評価できる

3. 再発防止策に対する提言
(1) システム機能
 システムコンティンジェンシープランやビジネスコンティンジェンシープランの再点検においては、認識したリスクで十分であるか否かについて検討する必要があるが、その際には今回のシステム障害で明らかになったもの以外にも、システム設計上・システム運用設計上のリスクが現状のシステムに存在しないか、改めて確認・分析し、コンティンジェンシープランのリスクシナリオとして盛り込む必要がある。
(2) 未然防止に向けた管理態勢
ア システムリスクCSAの実効性の向上
システムリスクCSAとしてシステムごとにチェックリストによる年1回のリスク評価が行われているが、リスク評価の実効性を高めるためには、チェック項目のレベルアップを図ることのほかに、チェック作業自体の精度向上も必要と考える。
チェック項目のレベルアップには、金融機関で参照されている一般的な基準を参照するだけではなく、内外の環境変化を踏まえた多面的なリスク評価を継続的に行う必要があり、それには商品所管部・事務部門・システム部門といった銀行内部の視点だけではなく、銀行外部の視点も積極的に活用することを推奨したい。
 更に、チェック作業の精度向上についてはシステム所管部の責任の下行われているチェックで満足せず、複数の視点で網羅的な確認を図るために、確認結果の妥当性を複数部署間でクロスチェックしたり、ベンダーや有識者も含めたレビューを実施することとし、システムリスク管理部署においてはチェックの形式的な確認にとどまらず、実地の検証も検討することが必要である。
(3) 早期復旧に向けた管理態勢
ア 緊急時態勢の見直しに向けた提言
緊急時態勢の見直しにおいては、各組織の役割を再整理すること、各組織の責任の所在や範囲を明確にすること、現場レベルの指揮命令系統を確立することに加え、MHBK、MHIR、MHOSそれぞれの経営陣を含めた統合的な指揮命令系統を確立することが重要である。(後略)
(4) 経営管理及び組織管理
ア 人材の育成
MHBK及びMHIRにおいて、計画的な人材育成を図り、双方で定期的に訓練を実施し、疑似体験により多重障害に対応するスキルを養成し、また、グループ全体で長期にわたって維持及び安定運用が求められる既存システムに対するノウハウを計画的に承継する取組みを深めるべきである。(後略)
4. 将来への提言
 今回のシステム障害によりMHBKのシステムに対する顧客の信頼は損なわれた。メガバンクのコンピュータシステムは、経済的インフラであり、これが損なわれることによる顧客等ステークホルダーへの影響は大きい。MHBKはもとよりみずほグループ全体が、全力を挙げてその維持と信頼回復に努めるべきである。幸いにして今回の調査を通じて、MHBK関係者の信頼回復にかける決意を感ずることができた。しかし、一度損なわれた信頼を回復することは容易なことではない。本委員会は、このような観点から最後に次の2点を指摘し、将来への提言としたい。
第一は、再発防止策の継続的な実行である。
2002年の大規模障害において、みずほグループは再発防止策を策定し2004年には一応所期の目的を達したと評価されている。しかし今回再びシステム障害を起こすに至った。今回のシステム障害は、2002年の障害とは場面が異なるものではあるが、当時のシステム障害を教訓としシステムの安定した稼動に組織として留意すれば、今回のシステム障害は防止することができたはずである。改善策は、実行して初めて意味があり、かつ長期にわたり実行が継続されねばならない。信頼回復の決意を失うことなく、改善策の長期にわたる継続的な実行こそが強く望まれる。
第二は、システム統合の早期実現である。
現在MHBKとMHCBとは同一グループであるが、統合以前からの別々のシステムを運用している。しかし、このことによるデメリットは明らかで、長期的な経費削減の点からもシステムのレベルアップの点からもグループ全体のシステムの統一が望まれる。現に、2010年5月に公表された「みずほの変革プログラム」によれば、IT・システムのグループ一元化の推進を明らかにしているのであるから、今回のシステムトラブルを機会として、十分な準備の上で文字通りの早期実現に努めるべきであり、このことが顧客の信頼回復の早道であろう。
✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦

【 所 感 】
 みずほ銀行の「システム障害特別調査委員会」報告書は余り世間で話題になっていません。今回本報告書を読んで痛感することは、「東京電力福島第1原発事故調査・検証委員会・中間報告書」や「福島原発事故独立検証委員会(民間事故調)」の報告書で指摘されている問題点との類似です。即ち、事故の発生が「想定外」あったということ、更に事故発生後の対応にミスがあり、事故の規模が拡大したと言う点です
 「想定外」に関しては電力・金融など国民生活や経済活動を支える重要なインフラを支える企業が、予め想定していなかったリスクの発生に対して如何に対応するかがシビアに問われています。
 事故発生後の対応については、経営者および社員のリスクマネジメントやBCP危機管理に関する教育や訓練の不足、人材の育成の不十分がどの報告書でも指摘されています。わが国企業の組織・人事政策のありかたがこの原因の一つだと思います。
 東日本大震災では、広域の壊滅的災害および複合災害における国や大企業の危機管理のあり方が問われている訳です。
 私は約25年間リスクマネジメントに関って来て痛感することは、中小企業のみならず、大企業でも(なおさら)リスクマネジメントの実行に当たり、技術論が先行し、経営的視点が不足していることです。これは現在多くの経営者にリスクマネジメントの本質に対する理解が不足している結果だと思います。