2月28日に全国で発生したみずほ銀行の大規模なシステムトラブルですが、そこに至るまでの背景には極めて深刻なものがあるようです。今回のメルマガ『冷泉彰彦のプリンストン通信』では米国在住作家の冷泉彰彦さんが、当トラブルの原因を分かりやすく解説。さらにこの事件は日本経済の恥部を露呈したものであると断罪した上で、根本的な解決策を取らなければ銀行全体が吹っ飛ぶと強い言葉で警告しています。
みずほのシステムトラブルに見る「終った感」
ATMが止まって吸い込んだ通帳が出てこないとか、これは本当かどうか知りませんが、ATMコーナーの自動扉が動かなくなって閉じこめられた人が出たという報道があります。こうなると、ベンダーの中で悪意をもったエンジニアが、クライアントに仕掛けた時限爆弾のようなものと思えます。
勿論、これは完全に冗談ですが、仮に意図的に妨害した人がいたとしたら、事態としては「まだまし」とも言えます。妨害しようという要件定義をして、それをシステム設計に落として適切なプログラムを書いて、それをハックした基幹システムに乗っけたのであれば、「問題の所在はつかめる」し「回復は可能」だからです。
ですが、実際はどうなのでしょうか。私は密かに一つのことを恐れているのです。それは、この銀行の基幹システムは「まだ統合されていない」という可能性です。
複数の銀行が経営統合した場合には、基幹システムの統合が必要となります。例えば、銀行の場合は一番の根幹にあるのは勘定系のシステムです。更にその中の一番の根本は勘定元帳です。非常に単純化すると、勘定元帳というのは
A）支店名＋預金種別＋口座番号による口座の特定
B）入出金など起きたアクションの種別（勘定科目）
C）金額
D）日付と時間
E）取引の相手（勘定科目）
などを含むデータのことです。B）やE）については、勘定元帳では簡単な符号にしておいて、預金系のDBや為替系のDBとリンクすることもあります。いずれにしても、銀行でカネが動いた場合の大元のオリジナルデータということになります。
問題は、この勘定元帳のファイルレイアウトが、古い銀行の場合はそれぞれに異なるということです。例えば金額を記載したカラムが、Aという銀行では14桁目からなのが、Bという銀行では18桁目からだとか、マックスの桁数が違うというような問題です。
本当は、AとBが合併した場合には、新しい勘定元帳のデータベースを作って、そこで、金額を記載したカラムが21桁目から、桁数がこれこれということになったら、AとBの元帳データは1対1でコンバートしてコピーし、新銀行のシステムに引き継がねばなりません。
また、勘定元帳にリンクしている例えば預金系のシステムがあるとして、その運用基準がこれこれで、ファイルレイアウトがこうだとすると、新銀行の場合はこれも1本化して旧データはA銀行のものもB銀行のものもコンバートして新システムに格納するし、システム統合以降の運用は全て新しいDBで運用すればクリーンになります。
ところが、日本の場合はこうした統合を完全にはやりません。何故かというと、A銀行の場合はベンダーX社のメインフレームでやってきたのでDB更新作業に癖があり、なおかつ合併後もXとの取引や資本関係は継続するのでXは切れない、またXに馴染んだA銀行系の人材も終身雇用なので維持するからです。
一緒の銀行になったはずの元のB銀行でも同様です。ですから、旧B銀行系の支店のシステムはY社のままで、結局は経営統合といってもABの両銀行のシステムが維持されて、X社とY社との関係も継続するということになります。