日経コンピュータによる「ポストモーテム みずほ銀行システム障害 事後検証報告」を読んだ。
メインフレームがどうのとか階層型データベースが云々とか、大規模金融システムで使われている技術を知らないのでわからない部分が多々あった。いろんなオペレーションが大変煩雑であったということはわかった。紙に印刷されたエラーメッセージのIDを電話で担当者に伝えるといったワークフローがあったらしい。
本の後半にあったイギリスのポストオフィスの事例とあとがきもとても面白かった。
指摘されている課題の多くは hindsight 20/20 な感じでふむふむ納得！と思った。ATMが利用者の通帳を取り込んでコールセンターがパンクして利用者は情報が無い状態で立ち往生したとか、システム監視担当者は電話でエラーを伝えていたとか、インシデントへのレスポンスが不十分だったのはそりゃそうだわって思う。一方で障害発生の予防の観点で、もし自分が設計や開発を担当していたとしたらその過程で気付けるものなのか、と思った。システムが大きくなればなるほど一人の人間が把握できる範囲は狭くなる。そうなったときに、部門間で知識が不連続になっていることに気づくことはできるのか。気づけないとしたらどう対策すべきなのだろうか。
言語の仕様や設計で予防できるところはある気がする。オブジェクト指向のカプセル化とかインターフェースはそういう課題を解決するためにある気がする。（前の仕事でCOBOLを書いていたとき、スコープが存在せず全ての変数がグローバルだったのを思い出した。）あとは DevOps のプラクティスとか便利なツールを導入するというのも一つの手だと思う。けどそれ以前にそもそもそういった情報を担当者が知らないという状況もありそう。
MINORIがメインフレームとCOBOL、階層型データベースという古い技術を採用した点が批判されることもある。確かに現在のシステム開発における主流はLinuxサーバーやJava、リレーショナルデータベースなどの技術であり、新規システム開発にメインフレームやCOBOLが選ばれることはまずない。しかしみずほ銀行が2004年から2010年にかけてMINORIのアーキテクチャーを検討していたことを考えると、メインフレームやCOBOLはやむを得ない選択肢でもあった。
（Kindle版 位置No.2310/3064 より）
その「やむを得ない」理由については、過去事例的になんだかんだうまくいかない事が多かったから、としか書かれていない。言語の仕様がネックになっているのか、人的リソースがネックになっているのかが知りたい。COBOLの利点として固定小数点数や二進化十進表現が使えるということを目にするけど、じゃあもっとモダンな電子マネーやビッグデータ分野ではその辺をどうクリアしているのか知りたい。個人的には言語の仕様がネックというよりもレガシーコードを理解できる人で他の言語が書ける人がいないということがマイグレーションのネックになりそうだなと思う。
開発で使う技術や手法の新陳代謝は大事だけど、集団全体の技術力を上げるということは難しいと思う。なので自分の身を守るためにも自己研鑽は続けたほうが良いのだろうなあという気がする。
関連リンク