Search Console

さぷログ

メーカーの人事部門で働いています。

【書評】元ITエンジニアだけど、「みずほ銀行システム統合、苦闘の19年史」を読んでみた

東京スカイツリーの建設費7本分」

IT業界のサグラダ・ファミリア教会と陰口を叩かれ、2ちゃんねるでは常にスレッドが立ち続けていたみずほ銀行の勘定系システム「MINORI」がついに稼働したというのはニュースで知ってました。

また、みずほ銀行のシステム障害を執念で追い続けてきた日経コンピュータさんの事も知っていましたが、書籍化されたので早速買って読んでみました。

僕は以前金融系システム会社に勤めており、ホスト系(勘定系ではない)のエンジニアだったので大変興味深く読ませて頂いたのですが、この本はちょっと変わった3部構成になっており、1部で「MINORI」の開発成功の話、2部で2011年の東日本大震災義援金が処理出来なかった事を発端にした大規模障害、3部では合併直後の大規模障害という感じで時系列を遡る構成になっており、日経コンピュータさんのみずほ銀行さんへのシステム統合の期待や裏切られた無念さ、しつこさ(褒め言葉)といった執念が感じられる一冊です。

個人的な感覚としましては、フルスクラッチの大規模システム開発はほぼ失敗するんじゃなかろうかという感覚を持ってしまうのですが、最近でも京都市が30年使い続けた基幹システムの更新に失敗して訴訟をかかえていたり、弊社でも大々的にシステム化するとブチ上げたはいいものの、要件定義すらまともに出来ず頓挫したと言いますか塩漬け状態の案件があるのですが、2度の大規模障害を乗り越えて完成にこぎ着けたみずほ銀行さんの執念には頭が下がる思いです。4000億円、35万人月って尋常な桁数ではないですね。

そんなみずほ銀行や情報システム子会社のおそらく上層部の方に日経コンピュータさんがしっかり食い込んで内部状況を克明に記録したのが本書だと思うのですが、会社全体としての動きが大変よく分かる本になっています。

その一方で現場サイドの記述はなく、生々しさはあまり感じられないのですが、記述内容から察するに10日間まともに家に帰れなかっただろうなとか、旧システムはDBが採用されておらず、おそらく固定長のデータセットバッチ処理で夜間処理がアベンドしたら頭から流し直しで、刻々と翌朝の処理開始が迫ってくるから生きた心地しなかっただろうな、運用側としては泣きたくなる仕様だよなとかいろいろ想像する事は出来ます。今はシステム屋じゃないのになんだか当時を思い出して頭痛がしてきますね。重要顧客の処理を土日でするのにメインフレームのメンテナンスでサービス停止日だったのを確認してなくて詰んだ日の事を思い出しましたよ。あ”あ”あ”-。

あとは0C7とかでコケるともうあたりのつけようがなくなって、コケた可能性のあるところにdisplayをかませまくって確認してみたりしてた日々を思い出しました。まさか勘定系が0C7でアベンドする事はないと思いますが読んでて胃が痛くなりますね。うぅー。

こういうITシステム失敗系の話ですと、ITに理解のない経営者、旧行の縄張り争い、ベンダー側の思惑、現場の非協力といったもはやテンプレート系の話は2部、3部でしっかり描かれています。現場のプロマネの方にとっては勝ち目が全くない絶対に勝てない戦いだったのだろうなと思いますが、事実を淡々と伝える書き方が逆に恐怖を感じさせます。「神はおれに死ねと言っているのか」と。

ただ、やはり注目すべきは1部で、どうやって「MINORl」をカットオーバーにこぎ着けたのかというのが分かる内容になっています。

SEをやっているといつも頭が痛いのは要件定義です。現場にヒアリングに行く訳ですが、だいたい嫌な顔をされつつフローになんとか落とし込むのですが、現場サイドは仕事を変えられる事に抵抗がありますからASISになりやすい中で、みずほ銀行はユーザー部門にフロー作成のツールを渡して、現場に書かせ、自分達の非合理的な業務フローを分からせたとか、旧三行の用語の統一から始めたとか、「技術アドバイザリーデスク」という会議体を作り、みずほの主要メンバーとベンダーの部長クラスでお互い立場は一旦脇に置いて、難問の技術的解決の話し合いをする場を作ったりとか、コードを自動生成するツールを作り、生コードを書かせないルールで統一したりとか、かなり有効な取り組みをされてたのだと感じました。

コードの保守性を考えると、生コードを書かせないというのは重要だと思います。変数一つとってもネーミングとか守らせるのは大変ですし、「ネストは3重までとあれほど言ってるのに」とか、「ほんとこのソース読めねえなー、誰が書いて誰がレビューしたんだよ、あとこういうのに限ってコメントがねえし(怒)」というのは一定数出てきますからね。

また、テストケースとその実行についても興味深いのですが、そこはちょっと割愛させて頂くとして、いよいよ導入フェーズに入ると頭が痛いのはユーザー教育なんですよね。各部門からシステムユーザーを集めて説明会とかするんですが、明らかに忙しいのに余計な事しやがってみたいなメンタリティで来られる方もいるのでひたすら平身低頭に進めたりするのですが、みずほ銀行は全社的な勘定系システム更新ですから規模が凄くて、講師が約170名規模で、しかも店舗で働く特定職(一般職)の方が講師だったそうです。

システムのリプレイス時に特に重要だと思っているのが、システムを日頃使用する一般職の女性を絶対に敵に回してはいけないという点だと強く思っているのですが、この講師役は公募もしたようで、40名の方が公募で講師になられたようです。

おそらく、大規模障害を2度の経験し、現場で相当に苦労された中で、今回のシステム更新は失敗する事は出来ないという使命感が行員ひとりひとりにあったのだと思います。

世間を賑わすようなトラブルという劇薬がないとここまでは意識は統一出来ないのかと少し気が重くなりますが、一冊でシステム開発の失敗と成功を両方読める稀有な本だと思います。


「稼働期間が20年を超えると基幹系システムは非常に危険な状態になる。(中略)本書が紹介するみずほFGのあゆみが参考になるはずだ」(本文から)