まだバグがあったのかというのが第一印象
みずほ銀行はD1KG、FJG、NKGGが合併した銀行なんやけど、システム統合にあたり一番先進的なFJGのシステムに集約するという当たり前の手段を取らず、存続行のD1KGのシステムを使うという、力関係によるありえない判断がなされたと記憶しています、
それだけに留まらず、D1KGのシステムを使っている支店と、FJGのシステムを使っている支店が混在するという状態も発生し、こういう環境でまともにシステムを動くようにしろと言われた当時のシステム担当の苦労を思うと思わず涙が滲む思いです。
もともと勘定系システム（銀行系のシステム）は汎用機時代の遺物が多く、COBOLと言う言語ができるエンジニアしかメンテナンスできない上に、長年に渡って改良を重ねてきたシステムなので、誰も仕様の全てを把握していないという問題がありました。
どうすれば良かったのかという理想論
本来なら、３行統合の最大のチャンスを逃さず「勘定系システムはかくあるべし」という仕様を策定し、最新の技術でその仕様通りに動くシステムを、少なくとも３年のスパンで開発・構築していれば、きっと世界から賞賛されるシステムができたと思われるのに、前述の力関係からかシステムエンジニアからしたら地獄の統合案が採用されてしまいました。
それでもシステムエンジニアの想像を絶する努力の末、約20年間に渡るシステム障害を乗り越え、安定稼働していたと思っていたのに、忘れた頃にATMからキャッシュカードや通帳が出てこないという今日のシステム障害が発生してしまいました。
今のところ、ATM5000台程度のトラブルだそうですが、限定的障害と言う事実自体が限定的システムテストをしてなかったんかな？テストケースが漏れるのはテスト仕様書のレビューが不十分だったというだけなんだけど、あぁ漏れちゃったかと、いやテストしたんだろうけど・・・特異日のテストが抜けたんだろうか・・・
今日は特殊な２月の月末日という特異日です。
2000年じゃあるまいし、うるう年の計算ロジックが間違っていたということはないだろうけど、２月の月末日で銀行の休業日という条件のテストまで網羅しきれなかった可能性は容易に想像できてしまいます。
- 西暦年が4で割り切れる年はうるう年
- ただし、西暦年が100で割り切れる年は平年
- ただし、西暦年が400で割り切れる年はうるう年
例えば、
・2020年は4で割り切れるのでうるう年です。
・でも2100年は100で割り切れるので平年です。
ここまでのロジックはほとんどのシステムで実装されていましたが、
・2000年は400で割り切れるのでうるう年である。
というロジックが抜けていたシステムが多く、2000年問題と相まって、2000年2月の月末日はシステムエンジニアの厄日となりました。
※2000年問題：
西暦年を下2桁で管理していたので、00年は1900年だと誤認したという問題。
※2000年2月の月末日：
1900年ではなく2000年だという2000年問題の修正がやっと完了した頃に、うるう年の問題が顕在化した厄日。
お疲れさまですとしか・・・
そんなこと当たり前のように網羅試験もしてる筈やし、普通に月末処理の高負荷にたまたま通信回線のハード障害かなにかでATMが誤作動したのだろうとは思うけど、真相はどの辺にあるのかとても興味のあるところです。
ATMがキャッシュカードも通帳も取り込んで吐き出さないという現象から見て、（通信異常による？）ATMの誤作動とは思いますが・・・
日曜日なのに電話がかかってきて現場急行したシステムエンジニアの方、頑張ってくださいとしか言えませんが、同業エンジニアとして、心中察するに余りありますと、役に立たない言葉を残しておきます。
ポチップ
追記
定期預金のデータ更新作業中に不具合が生じたことが原因との報道がありましたがホントかなぁ。月末処理で高負荷でしかも日曜日で２月の特異日にそんな作業計画するかなぁ。本当にデータ更新作業をしたならその計画そのものがおかしいですね。計画立案する人もそれを承認する人も。（SEがこの日はダメと言ったのにどうしてもやれという人がいたのかなぁ）
データ更新作業とATMが通帳を返却しないという現象との関連性もよくわからない。
まぁシステム障害なんてどんな現象が発生したとしても不思議ではないし、ATMにも通帳を返却しない条件とかあるだろうけども。
