起こるべくして起こっているトラブルです。この一連のトラブルもハードウェア障害なんて、？？？？？です。
どんなシステムでも１００％稼働するシステムは絶対ありません。しかし、１００％に近づくように、ハードウェアを選定し、さらに冗長化します。システムにもよりますが、２重、３重、４重といったように。
銀行のシステム、交通システム、航空システム、防衛省のシステム、インターネットのシステム、電気、水道、ガスなどのインフラシステム等々が止まったときのことを想像してみてください。残念ながら、現代人は生活できません。
だからこそ、ハードウェア障害でしたぁ。なんて、何度も悠長なことは言ってられません。この、ハードウェア障害。システム構築ベンダーにとって最も都合の良いいいわけなのです。プログラムの不具合なんていったら、不具合のプログラムを修正、テストするのはもちろんのこと、他すべてのプログラムをもう一度テストしろと言われます。ハードウェア障害であれば、稼働率の高いハードウェアにとっかえたり、冗長構成の見直しですみます。しかしながら、この障害には冗長化が有効に作用していないようです。とても、不思議です。
レガシーなプログラム言語で作成されたものを、換装以降も使っている。システムに詳しい人間が定年、昇進などでいない。ろくに引継ぎもせずに。。。。。
ただ、個人的にはハードウェア障害は怪しいと思っています。こんなに連発することはありません。しょぼいシステムであれば、ハードウェアの換装時期が重なるため、換装直前にハードウェア障害が多発するということがありますが、みずほ銀行のような大規模システムでそんなことがありえるのか。通常、システム停止に至らないよう時期を少しずつずらしながら、ハードウェアを交換していくはずです。
ということで、ソフトウェア。これだけ、多岐にわたりトラブルを連発しているため、共通な機能が怪しいと思います。いろいろありますが。。。。。。。。
認証機能のトラブルってのはどうでしょう。銀行の業務として、必ず本人かどうかの確認をします。これは、みずほ銀行のすべてのシステムを使用する際、避けては通れない機能です。みずほ銀行の各機能ごとに認証機能を持っているとは思えません。認証機能は共通機能としてもっており、まずはこの機能を突破してから各機能が実行されると思います。
この認証機能。いろんな認証方式があり、仕様どおり動いてもトラブルと判断されることがあります。たとえて言うなら、大阪から東京に行くとします。飛行機、新幹線、バスなどいろんな方法があります。飛行機にのって、関空からロサンゼルスに行きます。そして、ロサンゼルスから成田に行きます。結果的には、大阪から東京に行ったことになります。関空⇒ロス⇒成田でもきちんと飛行機は飛びます。飛行機が墜落しない限り、ルート（要は時間、お金がかかるなど）以外問題はありません。でも、こんな人はいませんよね。これをシステムに当てはめると、各々の動作は仕様通りですが、複雑な認証方式を選定した結果、レスポンスが遅いというトラブルとなるわけです。安全で簡単な認証方法があるにもかかわらず。。。。
