ITエンジニアがみずほ銀行システム統合、苦闘の19年史を読んでみて

IT系エンジニアの中で超話題担っている　みずほ銀行システム統合、苦闘の19年史　史上最大のITプロジェクト「3度目の正直」を早速読んでみました。

やはりシステム開発の内容なので他人事ではなく一気に読んでしまいました。

そもそもみずほ銀行のシステム統合とは

みずほ銀行が地震の義援金のシステムの際に２度目の大規模障害を起こしてから2019年7月の完了までに行ったシステムの刷新及び、ずっと別々に運用していた統合前の三つの感情系システムを一つに統合すること。

システムを開発する際に発生するトップのシステムに対する投資がなかなかできなかったり、伝達がうまくいってなかったりと「あーありそう・・・」という感じになりつつ現場の人たちのことを思いつつ読むとより楽しめる？かと思います。

元のシステム、設計思想を知る人が少なくどんどんヤバイ状態になっていくのは以前のシステム開発ではあるあるだったなぁと思います。特に金融系は歴史も長くバージョン管理ソフトがなく、単体テストが少ない状態でシステムを変えるのは非常にむずかしいだろうなぁと。しかも、触りづらいので余計理解が追いつきづらい。

新システムでは基本、「Interdevelop Designer」などのコード自動生成を使ってやっているとありましたが、これが選択肢に入るのか・・

多くの方が関わる場合は人間が書いた際の差を減らすのはとても正攻法ですが、このレベルの超大人数の場合はそこまでやるのかぁーという感じです。

数人月レベルでも一気に開発する場合は人によってコードの品質が下がる場合があるので事前にコードチェックを自動化するといいかと。

事故が起こってから一気に導入が進んではいますが、直接利益を生まないシステムの保守系に対する投資を上がなかなか実行できないのはその企業の風土などもあると思います。

ただ、どんなサービスにおいても新技術の導入などうまくいくか分からない、それでユーザーが増えるかどうか分からない技術の導入などに関してはエンジニア側からの説明や普段からコミュニケーションが大事だなと感じます。

人のスキルについて、このPJに入ることによって成長したと書いてある箇所がありましたがこれは結構言われていることで、若い時につよつよな所で揉まれると一気に成長するっていいますよね。（ただし、辞める可能性も高く、生存バイアスの可能性大）

あと、個人的にはこれはぜひ見習いたと思った箇所があり、それは要件定義を作成する際にユーザー部門、つまり実際に業務を行う人が業務フロー図などを作るソフトを使わせた点。これによって実際の業務がシステムにかなり落とし込みやすくなるかと。

とまぁ、１章ごとに感想を書きたい所ではあるのですがｗまじでキリがなくなるのでPVや反響があったら細かく書こうと思います。

という訳でエンジニアはもちろん、非エンジニアの方にもおすすめな本でした。