みずほ銀行、技術力の限界

ん～。みずほ銀行、また障害か。(´・ω・`)

• みずほ、信頼回復険しく　再発防止中の失態　自浄作用に疑問符

これは難しいなぁ。
僕の理解を越えている感がある。(；´-ω-`)

と言うのも、一言で障害と言っても、障害の性質ってものがあるじゃんね？

一般的に言うクソシステムは、ソフトウェアの品質が悪いという意味で使われることが多い。

例えばＤＢ設計の割り振りが下手で、その結果としてソースが劣悪になり、結果として不正な挙動をしてしまう、みたいな。

だけど、「別の人間に振り込んじゃった」とか、「利息の計算が間違ってる」とか、「画面に全然違う金額が表示されちゃってる」とか、そういうロジック的バグに起因する問題は発生していない。

つまり、ソースがダメダメであることに起因する問題じゃないわけよ。

じゃあ何かと言うと、インフラ系かつイレギュラー系だな。

• 特定の機器が故障すると全システムが使用不能になる。
  
• 障害時にＡＴＭが通帳を飲み込んだままになってしまう。
• 負荷が高まるとＤＢに遅延が発生する。

などなど。

正常系が腐ってるわけじゃない。
システムがもの凄く膨大で、各種サブシステムを組み合わせていくパズルの中に見落としが多い、ということだ。

う～ん。(；´-ω-`)
これは正直、見直ししようにも難しいものがあってね。

システムが膨大だと組み合わせが無数にあるから、「同じトラブルでも通常は大丈夫なようになっているが毎月１５日の夜間に発生した時だけアウト」みたいに時間やタイミング次第でＯＫがＮＧに変わってしまうとか、「機器故障にしても機器が丸ごと止まった場合は待機系に切り替わるが、止まるんじゃなくて挙動がおかしくなった場合は切り替えが作動しないからＮＧ」みたいに、故障と一言で言ってもどういう風に故障するかでＯＫがＮＧに変わってしまう、とか。

と、「え、そんなパターン、気付くわけないじゃん！！」ってのが発生する。

みずほ銀行の場合は、そういうのが大量に潜在しているのだろう。

無論、初期開発の時に、システム全体のカラクリをシンプルな形に整理出来ていれば、そういうのが潜在するリスクを小さくすることは出来る。
だが、みずほ銀行の場合は初期開発に失敗があって、システム全体がピタゴラスイッチみたいになっちゃってるのだろう。

だから今更どんな優れた技術者が目を凝らしても見直しし切れない深淵が生じている。

と考えると、「再発防止策」と言っても、技術的に抜本的な改善することは不可能と言って良いだろう。

よく、「みずほ銀行は第一勧業銀行・富士銀行・日本興業銀行が統合された銀行だから、その組織の対立により合理的な対応が出来ない」という組織論について触れられることが多いが、もうそういう段階ではない。

もう物理的にどうにもならんシステムがそこに存在しちゃってるの。ここで心を入れ替えて一致団結して取り組もうとしたって、技術的に手の施しようが無いわけよ。

既に過去形、戦後なんだ。

じゃあどうするかと言うと、やれることがあるとすれば、継続的リファクタリングだろうな。

つまり、

• 偶々問題に気付いたら改善する。
• 障害が発生したらその部分を改善する。

これを繰り返す。

問題が多いと言っても無限ではないから、１０年２０年と続けていれば、いずれは安定する。
こういうやり方だ。

このやり方は、通常のプロジェクトでは不可能。予算計画が立たないからね。

１年とか、２年とか、定められた期間でキッチリ終えるから予算の範囲内で収まるのであって、
「完了まで５年か１０年か分かりません」では、お金が延々と垂れ流しになってしまうから、会社が潰れてしまう。

でも、みずほ銀行に限っては、例外的にその費用の捻出が可能な希有な組織だろう。

いくらか知らんが、本来のシステム保守費用が年間１００億円で計画されていたとしたら、そのコストが３倍に増えた状態を３０年続ける、という対応も不可能ではない。

この費用はエンジニアだけじゃなく、オペレータ部門とかも含む。
例えば、システムが止まった場合、エンジニアの力では早期復旧が難しくとも、電話での問い合わせが充実していれば被害が減らせるでしょ？
いつ発生するか分からん障害の為に、必要かどうか分からん人間をキープする。

こんなのは普通の企業では無理だが、みずほ銀行の資金力なら可能だろう。

みずほ銀行に出来る「再発防止策」とは、こういう「普通に考えたら拒絶反応を示すようなやり方に社内で承認を通すこと」ではなかろうか。

みずほ銀行は組織構造の問題についても、それが改善出来れば１０年で完了、改善出来なかったら３０年で完了、とか最早そういうスケールになっちゃってるだろうな。

いやぁ、しんどいなぁ。(；´・ω・`)