これから「みずほ銀行」に起こる、ヤバすぎる現実…システムの「爆弾」を誰も処理できない

スポンサーリンク
みずほ銀行 社会問題

これから「みずほ銀行」に起こる、ヤバすぎる現実…システムの「爆弾」を誰も処理できない

結局3行の上層部がコンピューターを知らなさ過ぎた結果

今年8月に発生したみずほ銀行のシステムトラブル。実は19年前にもこれに似たケースが起こっていたことを【前編】『「みずほ銀行」のシステム障害はなぜ防げなかったのか…エンジニアを見下す「悪しき体質」』で報じた。多発する「システム障害」の爆弾を抱えた同行は今後どうなっていくのか…?

隠れていた「古の言語」

全体像の見えない「バベルの塔」と化したみずほのシステム。その成り立ちとは、どのようなものなのか。

過去に2度、みずほは大きなシステム障害を起こしている。1度目は前編でも触れた、’02年の3行統合に伴う混乱だ。

統合時、みずほは旧3行が使っていた複数の異なるシステムを生き残らせたまま、「ゲートウェイ・システム」と呼ばれる中継プログラムでそれらを繋ぎ合わせるという方針を打ち出した。

だが、この建て付けそのものに難があった。当時の事情を知るみずほ行員が言う。

「勧銀は富士通製のメインフレーム(大型コンピュータ)の『STEPS』を’88年に導入していました。また興銀は日立製のシステム『C-base』を、富士銀行は日本IBM製の『TOP』をそれぞれ持っていた。

普通、銀行が合併してシステムを統合する時は、顧客や預金などの情報をどれか一つのシステムに全て移行する『片寄せ』という方法を取ります。

しかし、みずほは合併後も『同じ担当の役員が3人いる』と揶揄されるくらい、よく言えば旧3行が対等、悪く言えばバラバラだった。そのため、各行のシステム、ひいてはベンダーとの取引を温存しようとしたのです」

統合直前、旧勧銀のSTEPSと、富士銀のTOPを並立させ、別のコンピュータでつなぐことが決まったが、あえなく失敗。それが統合時に発生した障害の原因だった。

このとき、事後処理にあたった情報系子会社の元社員は驚いたという。

「勧銀のシステムの一部に、’71年に第一銀行と日本勧業銀行が合併した時に作られたとみられる部分が残っていたのです」

この部分は、’80年代まで盛んに使われていたプログラム言語「COBOL」で書かれていた。’00年代には使いこなすエンジニアが激減し、「化石」と呼ばれた言語である。

「当時ですら、わかるエンジニアが現場にいなかった。もちろん設計図や手引の類いも見当たりませんでした」

たとえるなら、古い時計を部品交換のため開けてみたら、交換したい部品が古すぎて替えが利かず、やむなく油を差して閉めた、というような話だ。だがこの時は、気に留める者もいなかった。

複雑怪奇な「キメラ」

2度目の大規模障害が起きたのは’11年3月15日、東日本大震災の直後だ。災害義捐金の振り込みがひとつの口座に殺到し、システムが一度に対応できるデータ量の上限を超えてしまった。

エラーに対応しているうちに、他の取引のデータも渋滞を起こし始め、遅れてゆく。際限なく積み上がる未送信データを処理するため、ATMの全面停止を繰り返し、行員たちは夜を徹して手作業で数字を入力した。未処理の金額は一時、8300億円分にも達した。

「当時のみずほのシステムは『バッチ処理』といって、夜間に取引データをまとめて自動処理し、朝に各支店へ送信する仕組みをとっていましたが、これが機能しなくなった。

バッチ処理自体、とっくの昔に時代遅れになった手法ですが、みずほは何らかの理由でこだわっていたのです」(ITジャーナリストの佃均氏)

データの手入力が終わったあとでシステムが予期せず再起動し、振り込みや引き落としが二重に発生するミスも多発。結局、沈静化するまでに1週間もかかった。

これら2度の致命的な障害に懲りて、みずほは前述した新システム「MINORI」の開発に着手したというわけだ。いや、金融庁の叱責と業務改善命令に押される形で、着手せざるを得なかったというほうが正しいだろう。’11年6月のことだ。

MINORIは約4000億円の費用をかけて8年後の’19年7月に完成した。業界では、「史上初めて、銀行が自社の勘定系システムを全面再構築した」と話題になった。

だが、どうやら実態は異なる。一から作り直した「新築」ではなく、既存の「塔」をさらに建て増しした「改築」だったと考えなければ、説明がつかない謎があるのだ。

先に触れたCOBOLがいまだに使われているのである。

「ITベンダーの間では、かねて『なぜみずほは、わざわざ高齢のエンジニアを雇ってまでCOBOLを使い続けるのか』が疑問視されていました。MINORI導入時にCOBOLを使った部分をなくして、別のプログラム言語で書き換えてもよかったはずなのに、それもしなかった。

それはつまり、なくさなかったのではなく『なくせなかった』のではないか。勧銀時代から抱える古い重要プログラムやデータが、いまだにMINORIの内部で生きているからではないか—そうとしか考えられないのです」(前出・佃氏)

事実、全面改修を経たはずのMINORIのシステム構成は、不自然なほど複雑怪奇だ。普通預金を司る機器は日本IBMが作るが、その上で走るソフトは富士通が作る。他行との接続を司るシステムは、機器を日立と富士通が作ってソフトをNTTデータが作る。各業務のシステムをベンダーが分割して作り、さながら怪物「キメラ」のようになっている。

これが意味するのは、おそらく’11年に金融庁から業務改善命令を受けた時点で、みずほのシステムは根本的な再構築がもはやできない状態だった可能性だ。

古い部分と新しい部分が幾重にも折り重なり、さらに開発元も複数のベンダーにまたがっていた。しかも、この時すでにみずほは延べ3000億円近くをシステム改修に投入していた。20年以上も二人三脚を続けてきたベンダーを切り捨て、一から作り直すわけにはいかなかったのだ。

いまや、システムの全容を知る者はみずほにも、ベンダーにもいない。

もう、誰にもわからない

前出と別のみずほ行員が言う。

「最初に勧銀にSTEPSを売り込んだのは、ソフトウェアエンジニア出身で’90年代に社長を務め、辣腕で鳴らした秋草直之氏でした。

彼は勘定系システムの開発とメンテナンスを請け負うことで、勧銀・みずほから安定的に巨額のカネを引き出す仕組みを作った。一方のみずほは、時が経つにつれて膨らむコストを損切りできず、両者は共依存関係になっていった。富士通に経産省の後押しがあったことも、みずほの意思決定を鈍らせました」

秋草氏をはじめ、’80年代に銀行のシステム開発に携わった技術者たちは、いわば日本のシステムエンジニアの「第一世代」の人々だ。だが、この5年ほどで、彼らは次々と鬼籍に入っている。

今回、勧銀・みずほのシステム開発に携わったと思しき複数の元エンジニアにコンタクトを試みたが、いずれも故人となっていた。判明した中で唯一健在の人物は、6月に脳梗塞を発症し、取材が難しい状態だった。

「2025年の崖」という言葉をご存知だろうか。この年までに、’80年代に開発された企業の古いシステムの根幹を知る人が業界を離れ、あるいは亡くなり、ブラックボックス化する。みずほのシステムは、その最大にして最悪の事例と言える。

【前編】『「みずほ銀行」のシステム障害はなぜ防げなかったのか…エンジニアを見下す「悪しき体質」』の冒頭で罵られていた富士通のエンジニアも、5年ほど前に業界を去った。彼はこう話す。

「みずほは障害が起こるたびに、人為的なミスが原因の『人災』だと言いますが、的外れもいいところです。もう何十年も前から、爆弾は作動していた。人災などではなくて構造的な問題だと気づいていないのは、みずほの人たちだけですよ」

バベルの塔の基礎がどうなっているのか、そしてどこがグラつきの原因なのかを知る人は、もはや語る術を持たない。みずほは手探りで、いつ終わるとも知れぬ修繕を繰り返すほかない。崩壊の日に怯えながら。

『週刊現代』2021年9月11・18日号より

マイコメント

どうして3行のシステムをひとつに統合し移行させなかったのだろうと思う。

当時も言われていたことだが、第一勧銀、日本興業銀行、富士銀行の合併が済んだのは
良かったのだが、どの銀行幹部も自主権を握ろうとしたのを3行仲良くということに
させたようだった。

そのため銀行システムも3行仲良く併存させる方法を取ったものだろう。
しかし、時代の進歩は早く今どきCOBOLなんか使っているところなんてありません。
マシン語に近い言語でそれを今の言語に翻訳することは無理なものです。

結局合併時の上層部の覇権争いが原因だったということです。
完全に顧客無視の話です。今になっていったい当時の誰が責任を取れるというのか?

もはや、みずほは利用しない方が賢明です。
復帰不可能なシステム障害で預貯金丸ごと取られます。

コメント

タイトルとURLをコピーしました