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社との関係も継続するということになります。
非常に単純化すると、同じPCの中でMACのOSと、ウィンドウズOSを動かしている中で、大事な家計簿のある部分はMACのナンバーズで管理しており、ある部分はウィンドウズで走るエクセルで管理している、しかも全体を見るにはGoogleのスプレッドシートで管理している、そんな感じです。
いやこの比喩は違いますね。家計簿を管理するのに、MACマシンとウィンドウズマシンの2台を使っていて、全体を見る場合にはもう一つ別のLINUXマシンかなんかを使っている、そんな感じです。
家計簿なので、一本化すればいいのですが、パートナーのそれぞれが譲らないのでそうなったとか、そういうストーリーです。税理士がやってきて、この家の家計管理システムはどうなっているのかと疑問を発したら、3つのマシンは一応にLANでつながっていて相互にデータを更新するようになっているので、一応家計管理も税務計算もできる、つまり「統合されている」という説明でとにかく押し返したという感じです。
ところが、あるときにMACのアプリを更新したら全体的に不具合が起きてしまって、LINUXマシンで見られるはずの収入合計がエラーになってしまったとか、ある時に仮想通貨の売買をプログラム取引でやったら行数が膨大になって、最初のマシンのスプレッドシートには入力できたのが、転送する際に行数エラーになって合計額が出ないとか、そんな現象が起きている、話を何十万分の一、あるいは何億分の一のスケールにして「たとえて」みるとそうした話になります。
要するに、1つのマシン、1つのアプリに統合、つまり本当の意味での統合をすればいいのですが、「できない」ということでズルズル来たわけです。私の恐れているのは、2年前に完成したという「統合システムの更新」というのは、依然として本当の意味の統合ではなく、例えば、
「元のA行の支店からのMという取引の場合は特別に夜間処理でQデータベースを見に行くようにしていたのを、リアルタイムで見に行くようにして、そこで問題があればエラーではじくようにした」
といった対策を隅々までやったとか、そういう話ではないかという可能性です。そうなれば、確かにバグを潰してカットオーバすれば、当初は動くかもしれませんが、しょせん全体は過剰に複雑で不安定なままというわけです。
これでは駄目なのです。
「元がA銀行だろうがB銀行だろうが、Mという取引の場合は新銀行の統一されたDBでリアルタイムに処理する。例外はなし。DBには全てがコンバートされて格納済み」
こうしなくてはいけません。SMBCやMUFJだって、100％できているとは思えませんが、少なくともかなり「まし」なことが出来ているわけで、みずほの場合は非常に心配です。
しかし、今回の事件は日本経済の恥部を露呈したという意味で、本当に暗澹たる思いがします。
- 経営統合しても理想の運用や組織に移行できない。間接コストの圧縮でのスケールメリットも出ない
- 開発費はどんどん中抜きされて結局はベンダーがヘトヘトになっているに違いない
- 経営幹部はコンピューティングに関するマネジメント力はゼロ
- システム監査などの制度は機能せず
- そもそもカネを借りてくれた（出資の場合もありますが）ので、商品サービスを買ってやるという腐敗した互恵取引のワイロ構造が大元。クライアントとしてベストなベンダーを選択できないのは、株主への裏切り
- これでフィンテックとか笑止千万
もうこの辺りで止めますが、とにかく「障害の再発防止」に努めるのではなく、本当の「システム統合」をちゃんとやらないと、最後には銀行全体が吹っ飛ぶのではないかと心配になります。（メルマガ『冷泉彰彦のプリンストン通信』より一部抜粋）
image by: Ned Snowman / Shutterstock.com