完結したはずの前作(みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」)のまさかの続編。前途多難で非常に苦労し全面刷新して構築したシステム「MINORI」が稼働したものの、その後も断続的にシステム障害を起こしているみずほ銀行のシステム障害の詳細を掘り下げようという趣旨の本。
立て続けに障害が起こったものの、それらをわかっている範囲で個別に原因を項目化するだけでなく、なぜそのような事象に至ってしまったのかについてもできるだけ掘り下げようとしている。他の例と比較しながら、銀行システムならではの事情や、海外での似たような障害の例も紹介しつつ、1つ1つは他のシステムでも起こっている問題でありつつ、みずほの場合はそれが波及的に連鎖して大規模システム障害に至ってしまっている点を指摘している。
これまでの本は、経営者層がシステム開発と運用を軽視しているという論調が多かったけど、今回の本はその色は弱めた内容だった。とはいえ、テストや運用にさく工数をケチってるんじゃないかの指摘はしており、特に小さなシステム障害が起こった場合の対処マニュアルや実施訓練がほかと比べて不十分というのを具体例を出して述べている。
なんというか、批判するのは簡単なんだけど、じゃどうすればよいのかを大規模開発を対象に語る難しさというのを感じる。規模の差はあれ、私自身も似たように多人数の関わる大規模プロジェクトが迷走する実例をよく見るだけに、この本から何を教訓にすべきかを意識して読まざるを得なかった。プロジェクトなんて成功するか失敗するかは水ものだから、どれだけ小さく早く開発を回せるようにするかがキーなのかなぁ。もしくは、ある程度見識を持った少人数の集団で集中的に開発しコア部分を作り上げてしまうべきなのかなぁ。OSS類をモジュールとしてたくさん利用するのが当たり前な昨今、いくらモジュール志向をもって開発したとしても特定プロジェクトでしか使われないのならば汎用性が低いものしかできあがらない、それを洗練させるには複数のプロジェクトの採用例を増やしてアダプトさせるしかないのかなぁ。などなど。
以下はこれまでと同様に読んでて気になった項目をずらずらと。
第3章p133「二重エラーが発生している旨を伝えた」「二重エラーの報告は受けていない」、障害発生時の情報共有を口頭でのみ行っているという決定的な例かな。エラーメッセージなんて1字1句間違わないようにコピペしてテキストで共有するのが当たり前ですね。
第3章p167「オールフラッシュのストレージ装置に移行していれば、ハードディスクの故障という前時代的なトラブルに遭遇しなかった可能性」、いやそれはさすがに主張がおかしいだろと。SSDも壊れる。HDDより壊れにくいなんてことはない。ただ、頻繁な読み書きをするストレージ部位をSSDにすれば圧倒的な性能でシステムのボトルネックを取り除けるのは確か。
第4章p178「自らの持ち場でやれることはやっていたといえる」、部分最適の極みは実は相当難しい。というのも、システムの開発や運用をやっている末端は、子会社や孫会社どころかそこの孫請けやひ孫請けで、彼らは仕事を受けた単位が自分の持ち場だけなので持ち場を離れて横断的に作業をする義理もないしお金ももらっていない、むしろ契約書に書かれた担当をおろそかにしたと責められる。かといって全体責任を持つ上位の人は指示を出す仕事だけでいっぱいいっぱいになりとても現場の実情をチェックすることもできない。組織の壁でさえよく批判を受ける話なのにそれが会社や契約をまたぐととてもじゃないけどそうはいかない。権限を持った人も現場に入っているような体制でないとこれはそう簡単には解決しない。
第5章p183、みずほのシステム開発の歴史表は参考になる、
第5章p185、銀行各社の統合とそれに連動したシステム統合も参考になる、
どちらも、20-30年といった人のキャリアすべてを費やすような単位で進行するので、人生をかけてシステム開発に携わる覚悟のある人を何人も囲い込まないと成功させるのは難しいよなぁと思う。
第6章p262「(セブン銀行は)東阪交互運用方式を導入する」、予備システムをホットスタンバイさせるのをさらに進めて、何もなくてもメインサブを定期的に入れ替えてシステム運用するの、ウワサには聞いたことあるけど本当にやってるのかなぁこれ。
