みずほ銀行システム統合の苦闘19年史 レガシーシステムと2025年の崖

経産省のレポートでまとめられた 2025年の崖 — 日本企業が抱える旧式の基幹業務(レガシーシステム)をそのまま使い続けると、日本経済は年間約12兆円もの経済損失を被り続ける可能性があるので、国内SIerも デジタルトランスフォーメーション(DX) が大切だと声高に叫んでいる。

その基幹業務の代表例が、銀行の勘定系システム(預金/融資/振り込み等)であり、IT業界のサクラダファミリアと言われた みずほ銀行システム統合 は大変有名な話(書籍も何冊か出版されている)

みずほ勘定系システムは、部分的な改修を繰り返し、内部構造を把握しきれずブラックボックス化。

また資金調達の面では、世の中の流れが間接投資 → 直接投資(株式や債権発行)に変化。勘定系システムへの大きな投資判断が出来ない背景から、結果的に東日本大震災時の義援金振り込みが集中したことでサービスが停止する事態を招いた。

本書では、システム障害をキッカケに始まったシステム統合案件(旧行のいずれかに片寄せするのではなく、全面再構築)の話を紹介されている。普段システム開発に馴染みの無い方でも、老朽化した基幹業務を続けることは、大変危険だと思える一冊かなと。

人知を超えた案件規模

まず今回のみずほ銀行システム統合がどれほど過酷だったのか。

本書ではシステム開発の規模(要した金額と人月工数)が以下に紹介されている。

ちなみに私は赤い銀行(今後は赤銀と省略)のシステム部(情報系)に3年在籍した経験があり、その際に(勘定系の)先輩エンジニアから Day2案件のヤバさ(11万人月) を度々聞かされていた。

直接Day2案件に関わっていた訳ではないけど、Day2の残案件に携わり、それなりに大変な時期(半年間の終電帰宅)も経験。その過程で精神を病んで休職された方、また亡くなった方も目の当たりにしていたので、金融システム開発の厳しさを多少は理解している(つもり)

残案件より過酷なのがDay2案件で、Day2の規模すら凌駕するのが、みずほ銀行システム統合案件。

本書では何とか頑張ってシステム更改したと書かれているが、この一文の裏には、想像を絶する開発現場であったことは想像に難くない(それを匂わせる内容もちらほらある)

勘定系システムにSOAアーキテクチャ採用

みずほシステム統合では、SOA採用が目玉トピックとして挙げられていた。

当時赤銀のシステム開発に携わっていた頃、情報系ではSOAアーキテクチャを採用。

大規模モノリスなシステム開発を長年続けると、軽微な機能追加やリファクタリングでさえ、システム全体に大きな影響を及ぼしかねないので、影響範囲の調査や試験コスト(退行試験)は膨らむ。

そういった事態を防ぐため、みずほの勘定系でもSOAが導入された模様。

鍵は疎結合(マイクロサービス) — ちなみにこの話は基幹業務に限ったことではなく、昨今のシステム開発では、より一層のスピード感が求められているので、モダンな最新技術(クラウド/コンテナ)の活用で疎結合を実現することが急務だと言われている。

マイクロサービス、SOA、API:味方か敵か
マイクロサービスのメリットをざっくり言うと「変化に対応しやすい」こと

ちなみにSOAではシステム連携基盤ESBを採用するらしいが、銀行システムなど大金を使える大規模開発でない限りは採用されないので、実務経験を積む機会は少ない(正直詳細が分からない)

そもそも情報系と勘定系では、作りも全然違うだろうし、勘定系のSOAがどう実現されているのかは未知数。一応本書ではSOA採用で、従来コストの30%を削減出来ると言っているけど。

主要ベンダーIBMと富士通の争い

主要ベンダー間の苦悩話も面白かった。

赤銀にいた頃、勘定系ではIBMのメインフレームが使われていることを聞かされた。

赤銀情報系システムについても、少なくとも私が携わっていたシステムはIBM製(WAS/WACs/DB2)で統一され、IBMのコンサルが数人、他にも富士通や日立、NTTなど日本を代表するITベンダーのエンジニアが多く常駐していた(その下で雇われる孫請け、ひ孫請けベンダーは数知れず)

みずほ銀行のシステム部でも、主要な4ベンダーが参画し、各ベンダー(特にIBMと富士通)が自分の食い扶持(メーカーのフラッグシップとして、メガバンクの勘定系を抑えているという事実)を確保すべく、不毛な議論が長く続いたようだが、紆余曲折あってIBMのメインフレーム利用に着地。

勘定系システムを手掛けてきた富士通も、IBM基盤上でアプリケーションを開発する決断は難しかったと語っており、各ベンダーの不毛な機能比較の様子も描かれていた(コンサルとして入っていたA・T・カーニーは、さしたる優位性は無いと結論づけていたけど)

勘定系メインフレームはIBM天国なので、かなり儲かっているのでは?と思いつつ、今後は大規模金融開発も減るのでIBMも厳しいのでは?と指摘する人もいる … IBMクラウドも流行らなそうだし、OSSに馴染みのある開発者は今後もIBMと絡むことは無さそうだ。

日経コンピュータが検証した三十もの不手際

東日本大震災時のシステム障害について、システム障害特別調査委員会がまとめた報告書を、日経コンピュータが検証したところ、三十もの不手際 が積もり重なって起きたものとしている。

その三十の不手際(いずれの問題も経営陣のIT軽視、及びITへの理解不足)を4種類の問題に分類し説明されており、この点は戒めの意味も含め、システム開発に携わる人なら読むと良いかも。

① システム仕様や設定の不手際 — 詳細な仕様の理解者が減り、上限値設定の存在を担当者が知らなかったり、部分的な機能改修を続けたことによるシステムのブラックボックス化。

この事態を招いた大きな要因は、長い間大幅な刷新を行わなかった事だとされている。

ちなみに本書では一人の一般的なエンジニアが一ヶ月仕事をして、開発出来るプログラムのステップ数は500〜800行と記載があり、普通の開発者は「本当に?」と思ってしまう。

ただ大規模モノリスがブラックボックス化しているので、まず影響範囲の調査や仕様理解、試験にも膨大なコストを要するし、軽微な改善でも面倒な事前調整を多く求められ、調整コストも増大。

改善には大幅な刷新が求められるが、実現には経営者の勇気と実働部隊となる多くの兵士が必要。

② システム運用の不手際 — 必要なデータを誤って削除したり、重要な運用操作を失念したりなど、運用の自動化が行われておらず、操作ミスが多発。

システム部に属している時にも、本番環境へのアクセスやリリース後の動作確認ではExcel手順書(大体コピーして追記する程度)を作成していたり、昔現場にいた開発者が作った運用ツール(秘伝のタレ的なやつ)を使い回し、誰も仕様を知らないのでメンテ出来なくなっていたり。

運用面は特に属人化する傾向が強く、いざと言う事に困ったり、障害を起こした事はよく聞く話。

昨今はクラウドの発達でCI/CD技術が発達し、人の手を介する事なく、環境構築/試験(一部)/デプロイを自動化出来るようになった。ただ銀行などお堅い現場で、これらを実現出来るOSSを導入する日は来ないだろうなぁ〜と思っていたら、政府や赤銀も一部でAWS導入を決定したので変わるかも。

③ リスク管理 — システムリスク点検の不備と、新サービス導入の差異とリスク評価。

本書では、みずほシステム部門の品質管理チームや、監査部門による内部監査/外部監査が機能しておらず、勘定系システムのリスクも最高レベルではなく、一段階低く見積もっていた点に言及。

具体的な内容は書かれていないが、金融庁や日本銀行が検査マニュアルや調査論文を通じて、システムリスクの考え方や注意すべきポイントを公開されているので、気になる方は確認が吉。

④ 緊急態勢 — システム障害が発生し、システム担当者から役員がそれを知るまでに十七時間、頭取が報告を受けるまで二十一時間を要している事実から分かる危機対応能力の欠如。

調査報告書では、一連の障害を通じて、システム全体を俯瞰でき、かつ、多重障害の陣頭指揮を執り得るマネジメントの人材の不足とされている(かなり希少な人材だけど)

基幹業務の統合案件

本書でも言及されているが、企業の合併で最も大変なのが 情報システムの統合 で、情報システムは企業の業務と表裏一体のため、業務の一本化が終わらないとシステム統合出来ない。

案件として求められるレベルが高いのは言わずもがな。

開発者の観点で考えると、単なる技術理解だけでなく、深い業務知識が求められる故、他の案件に比べると単価は高いが激務なことが多い(鬱になる人が多く、追い詰められ死ぬ人もいる)

規模が大きくなると管理が難しくなり、進捗会議では問題無いと聞かされていても、蓋を開けてみるとプログラムが出来ていなかった(完成度が非常に低いプログラム)みたいな悲しい事も起きたりと、みずほの事例を聞けば、大変な現場であることは想像出来る。

そーいえば(勘定系の)先輩に金融開発独自の文化や風土があるので、若い頃からやってないと馴染めずに辞める人が多いと聞いた事がある(その馴染んだ人って、洗脳なのでは?)

なんだか結果的に、勘定系のシステム開発をdisってしまっているが、金銭的な面では確かに恵まれており、一次受けベンダーのコンサルの単価は300万だったり、一部のフリーランスは勘定系システムの開発案件を500万で契約する人までいたりと、にわかに信じがたい相場感だったりらしい。

とにかく本案件に携わられた(強制も含む)方々は本当にお疲れ様でした!