みずほ銀行システム統合、苦闘の19年史

　　現在も続いている、みずほフィナンシャルグループのシステム障害。普段システム系に疎い私ですが、やはり、日本を代表するメガバンクの一つで起きているシステム問題は尋常ではないと思います。この銀行システム障害については何か学べる点もあるかと思い、今回本書を手に取ってみました。この「みずほ銀行システム統合、苦闘の１９年史」、著者は、雑誌「日経コンピュータ」の記者や編集に携わった、山端宏実、岡部一詩、中田敦、大和田尚孝、谷島宜之の皆さんで、本書では、２００２年4月と２０１１年３月に発生した２つの大規模システム障害とそれをいかに克服したかが詳述されています。

　　まず、最初の２００２年に起こった大規模システム障害ですが、このシステム障害は第一勧業銀行、富士銀行、日本興業銀行の３行の全面合併がもとになりました。３行が全面的統合を発表した１９９９年は、経済のグローバル化や金融ビックバンといった世界規模の金融業界の競争が激化した頃で、国内外で金融再編が叫ばれていました。第一勧業銀行、富士銀行、日本興業銀行はそのような時代の潮流の中で、国際的な競争力をつけ日本をリードする金融機関を目指し統合を決めます。そして、１９９８年８月、三行の頭取は全面合併の発表の席で「統合により徹底した合理化を図る一方、戦略的な情報技術投資を実施して米国銀行に対抗していく。」と決意を述べました。

　　通常、経営統合で一番の難関と言われるのは「情報システムの統合」ですが、その前に業務の一本化を行う必要があります。この業務の一本化がまず大変です。人事・組織の再編から始まって、工場・営業所の統廃合、商品・製品の統廃合、事務処理の統一化、社員給与の一本化などなど、そいうったもろもろの組織の統一化を完了した上でシステムの統合ができるのです。例えば、商品の受発注、各工場や倉庫との在庫確認、出荷という手順だけを考慮しても、商品名、コード、在庫情報の一本化が必須になります。そして、銀行の情報システムの統合の場合には、「勘定系」と呼ばれる大型コンピュータを使うシステム中核の統合が最難関のタスクになります。「勘定系」というのは、銀行における預金、融資、さらには国内為替や外国為替などの業務を処理するシステムのことで、この勘定系システムが停止すると、我々預金者にとってはおなじみの、銀行支店窓口業務、ATM機の使用、さらにはインターネットバンキングの入金・支払サービスも利用できなくなってしまいます。みずほフィナンシャルグループのケースでは、三行の企業規模や実力が拮抗していたこともあり、三つの銀行システムを二つの銀行システムに再編するという過去に前例のないやり方を選択。この選択により情報システムの統合作業は他に類をみない難しいものになったのです。

　　通常、勘定系システムの統合には二つの選択肢があります。一つは全く新しい情報システムを構築し、各行の既存システムから新システムへ情報を移行するやり方。二つ目は、統合する銀行のどれか一行の既存システムを活かし、他行がそのシステムへ情報を移行するというやり方です。後者の場合、勘定系システムを残す方の銀行がもう一方の銀行を吸収合併するという印象を与えてしまうので、対等合併の場合情報を移行する側の銀行の印象が悪くなることがあります。どちらの情報移行の方法をとるにせよ、移行する銀行の預金・融資の情報データは、一つのミスなく移し替えることが必要になります。このどの勘定系システムへ銀行の情報を移行するか、という判断は、（本書によると）経営統合を発表した段階で、３行の力関係から第一勧銀の勘定系システムに一本化することを三頭取が即決し、発表して既成事実にしてしまえばよかったのですが、しかし、三頭取はその判断を小委員会の検討に委ねてしまったのです。「それぞれのコンピュータで動いているプログラムは、各行の時業務を反映したものになっているので、各行で全くと言って良いほど違う。仮に三行が同じメーカーのものを使っていたとしてもその統合の難しさには変わりがない。」　

       ここから各現場部門は自分達のシステムに執着し始め、特に富士銀行のシステムと第一勧業銀行のシステムのどちらかを採用するという検討は、泥仕合の様相を呈してきたようです。（本書ではここからの統合の経過を詳述していますが、ここでは割愛します。）結局、このシステム統合の争いは第一勧業のシステムを存続させることで落ち着き２００４年に終了。１９９９年８月の経営統合発表から実に５年４か月の歳月を要し、この統合にかかった総費用は最終的に４千億円にも上りました。この問題が長引いた原因は、三行それぞれが抱えてた情報システム会社を一本化できず、おのおのがシステム統合の作業に力と時間をとられそれそれの思惑で統合を進めてしまったこと、また、このシステム統合が終了した２００４年までに三行のCIO（最高情報システム責任者）が途中で人事異動してしまい、システム統合を全体に指揮する責任者が不在であったことです。

       次の大規模障害は、２０１１年3月１１日に起こった東日本大震災の三日後の１４日に起こります。原因は、テレビ局や携帯電話会社が一般市民へ呼びかけた義援金の振込みが、みずほ銀行の特定口座に集中し過ぎたことによるものです。義援金の振込みが殺到し、みずほ銀行の勘定系システムが１日に格納できる取引件数の上限値を超えてしまい、システム処理の異常終了が発生。欠落したデータの復旧などで時間がかかり、その間にも義援金振込希望者の振込件数が膨れ上がって行く、それを処理しきれない、というようなことが雪だるま式に重なっていったのです。

　　このシステム障害にはいくつかの不手際があります。　その一つが義援金口座の振込件数の上限値をシステム担当者が知らなかったということです。当初のシステム担当者は、一定の取引件数を超えたらシステムが作動しなくなる、という上限値の設定を知っていたはずですが、相次ぐシステムの機能変更と担当者の入替えで、システムの引継ぎが適切になさてれいなかったわけです。（このように組織内のシステムの中身が、相次ぐ編成・合併などで複雑化して行き、その内容を引き継いだシステム担当者が把握しきれなくなる状態を「ブラックボックス化」と呼びます。）　二つ目の不手際はシステム運用に関するもので、「必要なデータを誤って処理した、重要な運用操作を失念した、自動運用の仕組みを用意していなかった、」というようなものです。今回のように振込処理が集中的に重なり、昼夜の作業を行い続けるシステム担当者のプレッシャーは相当なものだったことは想像に難くありません。そのために人為的ミスが重なって発生したのです。本書で指摘する三つ目の不手際は、普段からのシステムリスクの点検の不備や、新しいサービスを導入する際のリスク評価の不備です。これは、このシステム障害が発生してからわかったことですが、システム監査を行っていなかったり、テストのチェックを怠っていたり、そのチェックのプロセスが抜け落ちていたり、また外部監査もうまく機能していなかったのです。四つ目の不手際は「危機対応能力の欠如」です。（当初、この障害が大規模なものになるとは予想できなかったのでしょうが、）システム障害が発生してからシステム担当役員がそれを知るまで１７時間、頭取がそれを知るまで２１時間を要したのです。この報告の遅れが初動の遅れにつながり、システム障害の大規模化につながったのです。

       メガバンクの勘定系システムは５千万のステップを超えるプログラムや、数十のサブシステムが複雑に絡み合う超巨大システムです。みずほ銀行はサブシステム単位で担当者を置き、システムの開発・運用にあたり、情報システム部門は要件定義、システム子会社はシステム設計、ＩＴベンダーはプログラム開発と実務作業を分担化していましたが、その分担化を進めるにつれ、このシステム全体を把握・統括できる人がいなくなり、結果としてこの２回目の大規模障害が発生。ＩＴガバナンス立て直しのため、みずほは、「データフロー図の作成」（いろいろな決済業務の可視化）、システムのどこに超えてはならない「上限値」が存在するのかの洗い出し、エラー処理の強化、情報伝達体制の見直し、緊急対応の有効性の検証、ＩＴ人材育成の仕組みを刷新するなど様々な改善を行ったのです。

　　この２度の大規模システム障害を重く受け止めたみずほＦＧは、２０１１年６月から勘定系システムの刷新を大規模に進めます。これまでのシステムを単に新しくするだけではなく、それまでみずほ銀行とみずほコーポレート銀行、みずほ信託銀行、それぞれのグループ三行が個別に運用していた勘定系システムも一つに統合することを同時に目指したのです。このプロジェクト開発には、富士通、日立製作所、日本ＩＢＭ、ＮＴＴデータという日本を代表するシステム開発会社（システムインテグレーター）四社を中心に、合計で千社が関わり、２度のシステム開発完了の延期を経て、２０１７年７月に新勘定系システム「ＭＩＮＯＲＩ」の開発完了し、その後２年をかけて古い勘定系システムからデータの移し替えを行いました（そのため９回にわたり、週末の勘定系システムの運用を停止）。すべての移行作業完了は２０１９年７月でした。この遅延に遅延を重ねたプロジェクトは、なかなか完成しないスペイン・バルセロナの教会にちなんで 「IT業界のサグラダファミリア」（＊）とまで呼ばれたのです。

      皆さんご存知のように、このブログを書いている２０２１年秋現在でも、同行のシステム障害がニュースなどで取り上げられています。日本を代表するメガバンクのシステム障害における混迷は、今の日本の経済状態をそのまま反映しているようにも受け取ることが出来ますが、これは同時に日本でなかなか進まないＤＸ（デジタル・トランスメーション）化の象徴でもあるように思えます。本書の中にも指摘があるように、システム設計時における、どのようなシステムを構築したいのか、という設計思想が当初から一貫せず曖昧だったようにも思えます。これは、丹羽  宇一郎さんが新刊「会社がなくなる！」の中で政府が推進しているＤＸ化に対し疑問を呈している問題、つまり、日本の企業における独特のタテ型組織の問題や、物事をうやむやにしてしまう権限と責任の不明確さ（曖昧さ）の問題と根っこは同じように思えます。換言すると、権限と責任の所在が不明確な日本のタテ型組織とＩＴというのは相性があまり良くないように思えるのです。このシステム障害というのは、ある意味、日本のＤＸ化の難しさを象徴しているように思いました。　

(＊）スペインのバルセロナにある現在も建設中の教会。聖家族にささげる“贖罪(しょくざい)教会”とし1882年に着工。着工から完成までの期間の長さからこの教会の建設に例えられた。