障害本体の話は原因とかわかったらなにか書くかも（まだ終わってないしな）
にしても、50年（表向きに影響ある）障害無しで稼働していたのはやっぱり凄いことではあるんだけど、一方でそれ相応のコストを掛けて対応していた（＝手数料を下げるとかそういう発想についていけない）システムでもあるわけで、すげーすげーと褒めそやすばかりではいけないわけですよ。直感的にはそういう情勢下の中でやらかしたんじゃないかというのを感じており、もしそれが正しかったとしたら、50年間なにやってたんだろうね、と逆に批判されてもおかしくないと思っています。まあその辺は事実関係わかってからで。
ともあれ、COBOL/Javaだからとかホストだからとかとかそういう話ではないんですよ。電文だってXMLにシフトするわけだし。そうじゃなくて、大量トランザクション大量データ無停止サービスの話なので、物事の本質はそこです。そういうサービスを作る技量とか運用の大変さとか、そういうのを有象無象のサービスと同列に語るなよ、ってのはもちろんそう。何を重要視してシステムを作るかの概念のところから違うので、同じ物差しで計ってはいけないよね。だからといって、巨大なシステムが無条件で優れている、というわけでもない。どちらが偉いとかそういう話ではないんだよね。
僕がしばしば金融系のエンジニアとして、新興システムの批判をするのは、この「何を重要視して作るか」の観点において到底要件を満たしていないのではないか、という疑念がある部分が中心なんですよ。まあ僕がする批判は「わかってないのに既存システムを（主に工数かかり過ぎという点で）バカにする」「処理の速さを誇るのは良いけど耐障害性が弱々にしかみえない」「ドキュメントの文化をバカにするけどコードから仕様が読み取れるレベルのコード書けてない」というような部分に対して行うことが多いですけど、まあそういうことなんですよ。エンジニアの実装スキル以前のところで問題がある。
でも、それはエンジニアリングのスキルが低いせいではないことも多いよね。要件決める人がポンコツなだけでさ。まあ、何が大事なのかをわからないで実装を進めるエンジニアから、真に大事なことを常に模索して正解を考えていくエンジニアになっていってほしいな、とは思うんですが。
ともあれ、大規模がわからない人は大規模がわからないだけであって、大規模が分かる人よりエンジニアとしてのスキルが低い、というわけでは全然ないんですよ。世の中に金融系出身のエンジニアって溢れてると思いますけど、「この人たち優先順位分からなくて作業の工数かけすぎ。そもそも手でやるな」って思うことも多々あります。顧客の要求レベルに合わせてものを作っていくという点で不合格な「できるエンジニア」もたくさんいるのを見てきています。適材適所と言いたいけど、適所のほうが変わっていくのに適材のほうが変われないんじゃマッチしない現場が増えるだけですよね。
ということで、無意味なマウント取り合戦はやめようぜ（それぞれの低レベルなところを許容するというわけではないよ）
