みずほ銀行システム統合、苦闘の19年史/日経コンピュータほか

■ビジネス・経済

photo

みずほ銀行システム統合、苦闘の19年史
日経コンピュータ、山端 宏実、岡部 一詩、中田 敦、大和田 尚孝、谷島 宣之
日経BP (2020/2/14)

みずほ銀行システム統合は「IT業界のサグラダ・ファミリア」なんて言われ、2度の大規模障害も、記憶に新しい。

みずほ銀行のシステム障害は、一つの企業だけにとどまらず日本全体に影響するほどの影響を及ぼした。

本書は、困難を極めたみずほ銀行システム統合を追った。

日経コンピュータに掲載された記事を加筆修正したものだそうだが、そのせいか、時間の流れがごちゃごちゃしている。

大きく分けて3部構成になっていて、まず第1部では、無事完成する話が描かれ、第1部の最後には、社長のインタビューまで載っている。

大規模障害の背景などにはさらっと触れる程度で、全体的には、創意工夫で困難を乗り切った話が続く。

まるで広報誌のようなテイスト。

実際の、大規模障害については、第2部と第3部で取り上げられているが、なぜか時間が前後していて、第2部が2011年の東日本大震災の募金集中がきっかけで起きた件、第3部が2002年の合併直後に起きた件となっている。

なので、読み応えがあるとすれば第2部以降…ということになるか。

東日本大震災発生した直後に殺到した、義援金の処理ができなくなったことが、大規模なシステム障害につながっていく。

まず、義援金の口座に取引明細の上限に制限があって、受付できなくなったことがきっかけだった

どれだけくるか分からない義援金の口座に上限?と思ったが、この上限というのは、法人などの取引では不要な「記帳」のための要件だった。

もともとは、法人用の口座として明細の上限がなかったが、2007年の時点で通帳で把握したいという要望を受けて、個人用になっていたことに誰も気づかなかったのだ。

この事象に気付き新たに口座を設けたものの、さらに振り込み依頼が継続してしまったようだが、最初はこの口座だけの問題にとどまっていたようだ。

しかし、その日の夜間に再び異常が起きる。問題のあった上限とは別の上限(一括処理ができる上限)があったことが判明する。

一括処理が滞ったことで後続処理ができなくなったため、翌日の開店に向けた準備が間に合わなくなってしまった。

障害対応のマニュアルが整備されていなかったために手動で対応したためミスも多発してしまう。

トラブル対応に追われている間に、さらに別の口座でも義援金の振り込みが集中し、ふたたび前述の上限値に達して一括処理の異常終了が発生し、事態は悪化の一途を辿ってしまう。

システムの全面停止などを経て、振り込み処理の積み残しを解消することができたのは、最初の障害発生から10日後のことだった。

当時のできごとは自分の記事でも取り上げているが、こうしたできごとがおきていたのだ。

第3部では、合併直後の大規模障害を取り上げている。

これは、まさに企業合併の難しさがそのまま大規模障害として現れたできごとだった。

合併は、業務フローはもちろん、各銀行で使われている用語もすべて統一するところから始まる。

しかし、できるだけ出身母体の業務やシステムを生かしたいに決まっている。

企業合併で最も面倒なのが情報システムの統合である。
業務の統合や一本化が終わって初めて、情報システムの統合ができるからだ。企業の情報システムは、その企業の業務のやり方と表裏一体の関係にあり、業務の一本化が終わらないと情報システムの統合はできない。(p.201)

第一勧銀からは、旧第一銀行と旧勧業銀行のそれぞれも担当者として出てきてしまい三行合併ではなく、四行合併じゃないかとすら言われていた…なんて話は、いかに合併が難しいかがよくわかるエピソードだ。

銀行それぞれの主導権争いに加えて、それぞれを支えるコンピュータメーカーも加勢してしまい、とにかくまとまらないのだ。

そうした状況のなかで合併を迎えてしまい、最初の大規模障害につながってしまった。

前述の通り、最終的に無事に成功したシステム統合の話を第1部に持ってきているために、話が前後してわかりづらい。

取材に協力したみずほ銀行におもねるため?…と勘ぐってしまう。

本書の切り口はとても興味深く面白かったが、ツッコミ不足を感じずにはいられなかった。

読み終えて感じたのは、企業合併というものは、いかにトップがリーダーシップを取るか…これに尽きるということだった。

Posted by ろん