2002年の統合以来、周期的に発生する「みずほ銀行」のシステム障害は、バブル期に積み上がった銀行の不良債権を、日本経済に与える影響を限りなく押さえて、銀行経営を再建させることを目的として、日本政府が採用した「低金利政策」と「都市銀行の合併・統合政策」がもたらした、「副作用」のひとつであった。銀行の統合によって、経営規模を拡大し、銀行の資産を増大させることはできた。しかし、1980年代以降、銀行はオンラインシステム化を進め、全ての銀行が、それぞれ独自の複雑なシステムを開発し、運用していた。それらの複雑なシステムを統合し、複数の銀行を統合させたため、システムの安定稼働は、容易ではなくなっていた。

そのような元々、異なる設計思想で開発された別々のシステムを統合できなければ、銀行の統合は不可能であった。特に、都市銀行のような巨大な組織を動かす銀行の統合には、コンピュータシステムの円滑な統合が、必要不可であった。多くの銀行統合では、最も大きな規模の銀行のシステムを選び、それを拡張して新しい銀行に導入する方法が採用されていたが、みずほ銀行では、そのような「片寄せ」と呼ばれるやり方は、採用できなかった。その理由は、巨大な銀行、3行をまとめ上げなければならず、そのための時間的な余裕がなかったからである。、

このシステム統合の問題と難しさに焦点を当てて、考察する。このような統合を成功に導くためには、高度な専門知識を持った経営者人材が必要不可欠であったが、当時の日本社会は、そのような人材を育成できていなかったのである。

1) 日本のメガバンク誕生

1992年の「バブル崩壊」の後、日本経済は後退期に入った。それまで、銀行からの融資によって、不動産投資を行い、活況を呈していた不動産業界も、株価と不動産価格の急落に始まったバブル崩壊により大打撃を受け、倒産が相次いだ。そのことが影響して、それまで「世界一」と言われた日本経済は、成長を止め、「失われた何十年」と言われる長期低迷期に移行した。特に、バブル崩壊によって、大量の不良資産を抱えた金融業界、特に都市銀行は、人口1億人の規模の市場に対して多すぎる傾向があったため、財政基盤の再構築に悩まされていた。そのような状況の中で、当時の大蔵省は、それまでの「護送船団方式」で全ての都市銀行に対して同じ規制をかけることで、個々の銀行の経営を守る方針の政策を放棄し、複数の巨大銀行(都市銀行)の経営統合によって、銀行の体質を強化する方針を打ち出し、旧三菱銀行を中心としたグループ、旧住友銀行を中心としたグループ、旧第一勧業銀行を中心としたグループなどの巨大銀行グループをまとめて、「メガバンク」として再生の道を辿らせる方針を打ち出した。

みずほ銀行は、そのような大蔵省の方針に従い、旧第一勧業銀行が中心となり、旧富士銀行と政府系の旧日本興業銀行が統合されたメガバンクの一つである。この経営統合では、いくつかの重要な目的があった。その一つは、多数の巨大銀行が乱立していた日本の金融市場では、世界の先進諸国とは違って、1つ1つの銀行の経営規模が小さく、世界規模の金融競争では、他国の大銀行と対等に戦えるほどの体力がなかったことから、複数の銀行を統合して銀行の数を減らし、1つ1つの銀行の資産を増大させようとした。次に、複数の銀行を統合することで、各銀行が所有していた支店の数を全体として減らし、経営統合による経営効率の改善を図ることであった。これによって、都市銀行と地方銀行との違いが明確になるため、地方銀行の生き残りも容易になると考えられた。支店で雇用されていた従業員を整理することで、労働生産性も向上すると考えられた。最後に、1990年代に入って、各銀行におけるIT投資が膨れ上がっていた。各銀行は、減り続ける資産の制約の下で、巨大なIT投資への資金をどう調達するかが問題になっていた。経営を統合すれば、そのIT投資も統合して、効果的な投資にまとめることで、全体としては過剰気味であった投資を抑えることが可能になると考えられた。

みずほ銀行の経営統合がなされる前、それぞれの銀行では、それまで、長年にわたって開発・維持してきていたオンラインシステムが稼働していた。それらは、いわゆる第二世代オンラインシステムと呼ばれていたもので、銀行の各支店とセンターを通信回線で結び、預金の入金と出金、通帳への記帳、残高照会等の、最も一般的な処理を行っていた。処理の多くは、窓口で受け付けた処理を、行員が端末装置を操作する形式で行われていたが、1970年代の中頃から、ATMの導入が進み、支店の店舗外に設置されたATMからの処理要求も受け付けるようになっていた。また、提携する他行の口座に対する処理も、全銀ネットワークを経由することで、処理をできるようになっていた。このため、コンピュータシステムは、通信回線を経由して、他行のコンピュータシステムともデータ交換をしなければならない状況になっていた。1980年代の中頃になると、ほとんどの処理は、ATMからの入力で行われるようになっていた。このことは、センターのコンピュータと各地に分散して設置されているATMとの間は、それぞれ個別の通信回線で接続されるため、通信ネットワークの構造が複雑化するとともに、その通信制御のために、コンピュータに負荷がかかるようになっていた。その第二世代オンラインシステムの時代が終わり、各銀行は、 ATMの処理を強化した新しい第三世代のオンラインシステム開発に着手し、順次、その稼働を開始していた。また、日本社会も従来の現金社会から脱却しつつあり、個人口座から個人口座、個人口座から法人口座への振り込み処理が飛躍的に増加した。この口座間の振り込み処理、特に他行の口座との間で行なわれる振り込み処理は、コンピュータシステムへの負荷を増大させていた。

旧第一勧業銀行は、第一銀行と勧業銀行が合併した時、第一銀行で利用していた富士通を中心としたシステムと、勧業銀行のIBMを中心としたシステムが統合され、富士通のコンピュータを中心としたオンラインシステムに変わっていた。これに対して、富士銀行は、1970年代のはじめに、ユニバックを中心とした第一世代のシステムから、IBMを中心とした第二世代のシステムに移行し、それを基礎に第三世代のシステムを作り上げ、運用を初めていた。日本興業銀行は、日立のコンピュータを中心としたオンラインシステムを開発し、運用していた。コンピュータをあるメーカのものから、別のメーカのものに替える時、新しいシステムで稼働するプログラムは、従来のシステムで稼働していたプログラムの機能を踏襲する形で、新しく書き換えられる。この書き換えの過程で、誤りが混入する例は少なくない。しかし、その誤りが発見されずに新しいシステムのプログラムに残り続け、その次の世代のシステムに移行した時、問題が表面化する例もある。しかし、そのような場合、最初のプログラムを設計した技術者、次の世代のプログラムを設計した技術者が、開発の委託を受けた企業に残っている例は少なく、なぜ問題が起こるのかの原因を究明できない例もある。プログラムは、支店や銀行の業務に基づいて設計されるので、現場を詳細に調べれば、どのような仕組でできているかがわかるはずである。しかし、組織の中の仕事のやり方は、時間と共に少しずつ変化することがある。このことが、問題の究明を難しくするのである。特に、ソフトウェア開発を委託されたベンダーが変わっている場合には、問題の究明はさらに難しくなる。

2) みずほ銀行の誕生まで

2000年9月、旧第一勧業銀行、旧富士銀行、旧日本興業銀行は、株式移転によって「みずほホールディングス(みずほFG)」を設立し、旧3行はその完全子会社となった。みずほホールディングスは、2002年4月のみずほ銀行設立を目標として、3行の業務を統合すべく準備を開始した。その結果として、個人向けの銀行業務を旧第一勧業銀行と旧富士銀行を統合した旧みずほ銀行が継承し、大手企業を主たる対象とした銀行業務を展開するホールセールバンキング事業を旧日本興業銀行が設立する「みずほコーポレート銀行」が継承することとした。それぞれの旧銀行は、当分の間(2010年以降に統合を計画していた)、従来から運用していた基幹システムを、そのままの形で運用する方針を決定した。これは、新銀行移行までの時間的余裕がなく、短時間で基幹システムを統合することが不可能と考えられたからであった。この旧みずほ銀行・旧みずほコーポレート銀行体制は、2011年の3月に発生した東日本大震災直後のシステム障害発生を機に、経営統合が必要不可欠とされたことから、2013年に旧みずほ銀行を旧みずほコーポレート銀行が吸収合併する形で、新しく現「みずほ銀行」が誕生した。

2002年4月のみずほ銀行設立を目指して準備を進めていた旧3行では、経営統合に際して「勘定系システムの統合をどうするか」が議論された。この問題は、旧3行のシステム開発を支援してきた、富士通、IBM、日立にとっても重大な問題であり、いくつかの統合案が検討された。1999年末の段階で、3行の責任者は、オンラインシステムを旧第一勧業銀行のシステムに統一する「片寄せ方式」を採用する事で合意した。しかし、2000年末の時点で、統一した一つのシステムを開発し、2002年の4月1日までの期間で、本格移行させることは、困難であると考え、本番稼働を2003年4月に延期する決定をした。この延期によって未解決になったシステム統合問題を解決するために、3行のシステム責任者と3社の主ベンダー企業の管理者達の間で合意された結論は、旧第一勧業銀行を除く2行は、旧第一勧業銀行のコンピュータから送られてきた処理依頼データを受けたとき、それを口座のある自行のシステムで処理するための、「リレーコンピュータ」を開発し、それを介して各銀行のシステムで業務処理を実行できるようにする案であった。

旧3行からの委託を受けて、ベンダー3社は、それぞれの環境で稼働するリレーコンピュータの設計と、ソフトウェアの開発に着手した。設計されたソフトウェアの機能仕様は、他のベンダーの技術者にも渡され、内容の検討が行われるはずであった。しかし、短期開発の圧力のため、技術者のレベルでは、そのような内容の検討に投入できる時間的な余裕は、なかったようである。その結果、設計時のレビューは形だけのものとなった。そのような、「ずさん」な設計に基き、急ぎプログラミングが作業が開始された。プログラミングにも、多数の技術者が投入されたため、その品質を確認するためのレビューは、形式的なものにならざるをえなかった。2002年に入って、作られたプログラムを実際に動かして試験をはじめると、どのベンターにおいても、様々な問題が発生した。実際に作業を担当していた現場からは、「3月末までに試験を終わらせることは困難である」との意見が上がっていたと報告されている。この段階においても、3行のシステム開発を担当する「みずほ銀行」の責任者達は、事態を楽観視していたと報じられていた。経営会議からの進捗照会に対して、それぞれの開発責任者は「おおむね、問題はない。」と報告したと記録されている。計画されていたテストの一部は、時間不足として、割愛された。

3) 勘定系システムの統合

1999年の統合準備の過程では、新銀行のオンララインシステムは、旧第一勧業銀行のシステムを基礎とした新システムへと移管することを決定していた。しかし、新システムの検討を続ける過程で、2002年4月の稼働開始を考えると、時間的な余裕がなく、それまでに開発を終了できないことが判明した。そこで、2000年12月、旧3行のシステム責任者は、それぞれのシステム開発を受託していたベンダーと協議し、1年間、開発スケジュールを延期して、2003年4月に新システムの稼動を開始する方針に切り替えることとした。このとき、新銀行の設立は、2002年4月が予定されており、旧3行のシステムをそのままの形で継続運行することには、問題があった。この問題を解決するため、3行のシステム開発責任者と各ベンダーからの代表者が協議し、各銀行で運用しているシステムをそのまま稼働させ、支店やATMから送信されてくるトランザクション情報は、旧第一勧業銀行のシステムで一旦受信し、旧第一勧業銀行の口座に対する要求の場合は、そのまま従来通りの処理を行い、そうでない口座の処理要求に対しては、宛先銀行のシステムへと、リレーコンピュータを経由して転送し、処理を実行する設計に変更することとした。

2001年5月10日、みずほホールディングス取締役会で、システム移行の実施計画を正式に承認した。この間、2001年の3月から6月にかけて、大蔵省の金融庁は、みずほグループの検査を実施して、スケジュールの遅れなど、システム統合の問題点を指摘した。しかし、計画は、取締役会の決定通りに実施され、作業は進められていった。2001年12月、月当たり5万件を超える大手取引先の口座振替データの処理を、当初の計画通りに旧日本興業銀行のシステムで処理するためには、負荷が大きくなり過ぎるとの見通しから、急遽、旧第一勧業銀行のシステムで処理を実行するように変更することとした。また、口座振替を委託する企業に対して、2002年4月1日からは、全国銀行協会が指定した形式で口座振替データを持ち込む場合は、旧富士銀行、旧日本興業銀行の「金融機関コード」を、旧第一勧業銀行の金融機関コードにして、支店の「店番号」を新しいみずほ銀行のものにするように、変更を依頼した。2002年3月上旬に入り、プロジェクトでは、口座振替の過負荷テストを開始した。3月22日、みずほホールディングスの経営会議が開催され、システム担当部署に対して進捗の確認がなされた。担当部署からは、「大きな問題はない」との回答があり、経営会議は、予定に従ってシステム移行を行うことを決めた。しかし、誤った口座振替データを入力してシステムに負荷をかける異常処理テストの実施は、時間的な余裕がないとの理由で、実施が見送られていた。

2002年3月30日、口座振替データの入力時に、旧3行のシステムにデータを振り分ける一括処理のプログラムで、新旧の「金融機関コード」と「店番号」が入り混じる例があり、エラーが多数発生した。また、指定された形式ではないデータ形式で作成された口座振替データが持ち込まれ、一括処理のプログラムに潜在していたプログラムの誤りも関係して、大量のエラーが発生した。これらの問題を、手作業でデータを修正し、解決しようと試みたが、量が多かったため、作業に遅れが生じ、仕掛かりのデータが5万件に達していた。この段階でも、みずほ銀行は、「決済システム全体に影響を与えるほどの問題ではない」と判断し、「4月1日中に処理を終わらせることが可能であれば、システムの移行は計画通りにできる」と判断した。

4) システム統合の失敗

2002年4月1日、みずほ銀行、みずほコーポレート銀行が発足した。両行の統合システムも、本稼働を開始した。稼働が始まって直ぐに、旧富士銀行のキャッシュカードが旧富士銀行の支店に設置されたATMでしか利用できず、旧富士銀行の支店では、旧富士銀行以外のキャッシュカードは利用できないと言う問題が発生した。さらに、旧富士銀行の支店以外に設置されたATMでは、旧富士銀行のキャッシュカードを使うと、現金が出されていないのに、通帳には引出し記録が記載されると言う問題も発生した。この現象に対して、みずほ銀行は、銀行外部とのデータ交換を行う対外接続系のシステムとリレーコンピュータとの接続を一旦切断し、原因究明を行った。13時ごろになって、この問題の原因は明らかになったと報告されている。この時点で、口座振替の仕掛かりデータは、手作業で修正が続けられていたが、約10万件が未処理のままであった。このようなシステム稼働中の修正作業は、障害復旧の場合、実施すべきではないとされているが、それを行ったため、後に顧客の口座データが消失した2次被害も引き起こした。緊急時の対応を誤ったと言える。

その後、4月2日にオンラインシステムは、復旧し、ATMの処理も復旧した。しかし、4月4日になって、みずほ銀行は口座振替処理の遅延を公表するに至った。4月5日の時点で、口座振替処理の遅延件数は、約250万件に達していた。また、3万件にのぼる二重引き落としがあったことも判明した。4月8日には、さらに3万件の二重引き落としがあったことが判明した。これらの二重引き落とし問題は、4月9日までに修正が完了した。4月9日の時点で、口座振替の未処理件数は約15万件にまで減少した。この段階で、前田みずほホールディングス社長は、衆議院財務金融委員会に参考人招致され、その後、記者会見で事態について説明を求められた。4月11日、新たな口座引き落とし漏れが判明し、仕掛かりデータの件数は、40万件になった。4月18日、口座引き落としの後れは、解消されたと報告された。しかし、入金結果通知の処理については、大幅な遅れが続いていた。4月30日、口座引き落とし処理のピーク日で、約1,200万件の処理が必要であったが、これについては障害発生はなかった。5月8日、金融庁と日本銀行は、みずほ銀行に対して立入検査・考査を開始した。5月21日、東京都も、臨時の立ち入り調査を開始した。5月24日、前田社長は、決算発表の記者会見で、システム障害に伴う損害は、約18億円にのぼるとの見通しを公表した。

この2002年4月のシステム障害が起きた背景には、「みずほ」の合併が、他のメガバンクの例とは異なり、「対等合併」したことにあるとする見方がある。旧3行の基幹システムが温存され、それぞれのシステム開発を担当したベンダー3社は、合併前と同じ体制を維持した。結果として、開発プロジェクトの規模と複雑性は、著しく増大した。そのような企業文化も技術力も異なるベンダー3社を統合するプロジェクトマネジメントの能力を持った人材は、日本のIT産業界にはいなかったと考えられる。そして、そのような統合プロジェクトを遂行する「みずほ銀行」には、プロジェクトの実施組織をまとめる能力を持った人材がなかったため、ベンダーからの報告をそのまま、経営層に報告する「電報ゲーム」のような管理に陥り、「みずほ銀行」は、リスクを認識する力も失っていたのである。この巨大3ベンダーを管理・監督するためには、1民間銀行の力では、能力不足だったと言わざるを得ない。旧3行のチームワークを重視した「対等合併」は、和を尊重する日本的文化の影響と言えるが、それは西洋文化を基礎として動くことを前提とするビジネスの世界では、弊害が多かった。

5) 度重なるシステム障害

2002年4月のシステム障害の後、みずほ銀行は、旧第一勧業銀行の基幹システムを基礎としたオンラインシステムの開発を完了し、2003年から稼動した。その8年後、東関東大地震が発生し、その直後に再び大規模なシステム障害を引き起こした。これは、震災後に受付を開始した義援金受付口座に1万件を超える大量の振り込み依頼が一度に殺到し、その処理を行う一括処理(オンライン処理ではない)を実行していたコンピュータの負荷が、処理能力を超えたためにシステムが停止したためであった。みずほ銀行は、この2011年のシステム障害の経験に基づき、2019年までに、開発費4,500億円、推定工数約35万人月を投入し、大規模なシステム移行を実施した。新しい基幹システムは、MINORIと名付けられた。この開発には、従来からシステム開発に参画していた富士通、IBM、日立の3社に加えて、日本最大のソフトウェア会社と呼ばれているNTTデータも加わった。これは、開発に必要な工数を考えると、当然のように見えるが、ソフトウェア開発の常識から見ると、「危険極まりない」やり方であった。工数の増大を、投入する人員数で吸収し、工期を遅らせないようにする考え方は、知的な作業を中心としたソフトウェア開発では、通用しない。関わる技術者が増えると、その人の管理とソフトウェアの品質の管理が極端に複雑化し、人間の管理能力を超えるからである。2019年に稼働を開始したMINORIシステムも、2021年、再び、ATMを利用していた顧客のキャッシュカードや通帳を取り込み、顧客に返却できなくなる問題を起こした。

(つづく)