https://gendai.ismedia.jp/articles/-/87384?imp=0
https://gendai.ismedia.jp/articles/-/87384?page=2

週刊現代講談社
毎週月曜日発売

今年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週間もかかった。


→説明がつかない謎
https://gendai.ismedia.jp/articles/-/87384?page=3