前回、『みずほ銀行システム統合、苦闘の19年史』を記載したが、今年2月28日にシステム障害が発生し、メディアを騒がせた。
障害の理由は、[定期預金の積み立てなど通常の取引量が多い月末に、システムを増強せずに臨時のデータ移行作業を行った] とのことらしいが、これは前述した『みずほ銀行システム統合、苦闘の19年史』のデータ量の想定の甘さで障害が発生した事例と殆ど似た理由だ。苦闘の19年で身に染みるほど経験したはずなのに、似たような原因で障害が発生している。どうしたの？と思わず思ってしまった。
なぜ処理能力を増強出来なかったのだろう。勝手な判断だが、先に対応すべき優先順位がありすぎて手が回らなくなっている気がする。プログラムも問題を抱えているのが分かっていながら、完成版に持って行けない気がする。
さらに3月3日、システム障害が発生した関係で28拠点の29台のATMでキャッシュカードが戻らないトラブルがあったとか。これは2月28日発生した障害とは別の原因らしい。
さらに！さらに！3月7日、一部のATMやインターネットバンキングで定期預金の預け入れができなくなるトラブルがあった。カードローンのプログラム更新作業時に不具合が発生し、その影響で定期預金の預け入れが出来なくなったからだとか。これは小規模な障害で、利用者から数件の問い合わせがあっただけで済んだようだが、本当にシステム大丈夫？私がイメージしていたCOBOL個所でなく、LinuxのJavaチームの不具合のようだ。
前回の『みずほ銀行システム統合、苦闘の19年史』にも触れたが、大規模システムの開発経験があるだけに、大規模システム構築の大変さはかなり理解しているほうだと自負している。設計部隊はエリート精鋭でも開発は渡り鳥エンジニアも少なくない。みずほ銀行PRJではなかったが、製造部隊に仲間に加えたくないフリーエンジニアは当時何人も見ている。
複雑化したスパゲッティプログラムと、条件分岐の多いワークフローで分かっちゃいるけど解決困難な箇所が今でも多数あるんだろうなあ～と推測している。経験的に何となく分かる。
