みずほ銀行システム統合、苦闘の19年史_読了記＜備忘＞

毎日毎日、お疲れ様です。

いろいろなことがありますよね。

最近はとある資格を取ろうとよわよわエンジニアながら奮闘しています。

その資格、試験のpassが2つ必要でなかなか高額です...（1つ16,500円）。そのうち1つを片方を昨日取り終えました。LPIC101って言います。

ほかの方の合格体験記など読むと圧倒的に僕が費やしている時間が少なく、努力が足りないからいつまでたってもうだつの上がらない技術者なのかな、と合格したのに敗北感を感じています。

目標としている段階（Application EngineerだけどなんかかっこいいからLPIC300シリーズ取りたいんです...。）まで到達出来たら記事にするかもしれません。

以下HPです。興味のある方はのぞいてみてください。

LPIC | 世界標準のIT資格 | LPI日本支部 | Linux Professional Institute Japan

悔しいから勉強時間も実装する時間もめっちゃ増やしてやるわ！と息巻いています。 

さて、本題です。

本日はみずほ銀行勘定系の構築にあたっての本の感想をつらつら書いていこうと思います。総額にして4,000億円越え超弩級プロジェクトでした。

日本のシステム屋として、この話を知っておかないのはナンセンスかなと。

筆者は若輩金融エンジニアですので、他山の石とする必要があります。

www.nikkeibp.co.jp

さて、書く前に僕の今回の件の認識を。

学生のころにも少しエンジニアをやっていたのですが（2015年ごろでしょうか）、これはこれは当時大変ネタにされておりました。

完成しないだの、トイレにこもって出てこない方がいるだの、専門学生をタダで動員しただの（？？）、パワハラの嵐だの、サクラダファミリアだのいろいろ言われていました。一部内部情報が5chに書き込まれていました。

MHIRさんのリクルートページに「なんでもできるとても優秀なエンジニア（意訳、年収1000万）」が登場したときは「1000万円でデスマーチに参加してくれる強い勇者を募集しているらしい」とか「その給料では期待している人は絶対に来ない」などと書き込まれていた記憶があります。ひどい書かれようでしたが、当時の内情を想像すると募集したくなるのは容易にわかります...。

規模が大きすぎて日本中のエンジニアや、エンジニアもどき（テスターとかドキュメント整理役とか）とか、PMやら何やらをブラックホールのごとく吸い込んでいったために他の現場が人手不足に陥っていたとも聞いています。（慢性的にいつも優秀な方は不足していますけどね...）

遠巻きに（大変だなぁ...）と思っていました。

そんな前提で読んだのですが、今の仕事内容を考えるととてもためになりました。

目次

・合併前：各行の意地の張り合い

皆さんご存じの通り、みずほ銀行はかつて日本の商業銀行のTOP3ともいえる3行が対等合併してできた銀行です。第一勧業銀行、日本興業銀行、富士銀行です。

各行とも平成元年の時価総額で世界のTOP5（1989年07月基準）に入っていました。みずほ銀行を現在のテック企業風に例えると、MicrosoftとAmazonとAppleが合併してできたIT企業、といえばいいでしょうか。（サウジアラムコはNTTに見立てました、2020年06月基準）

それだけバブルが異常だったのもありますが...。

バブル崩壊後、全国に13行あった都銀を中心に日本の商業銀行は合併を繰り返す歴史を紡ぎ始めました。その中で一番大きな合併がみずほ銀行の誕生でした。

興銀マン、なんて固有名詞が出るくらいには鼻息の荒い金融マンたちだったので当然どの銀行のどのシステムを使うかで揉めたようです。

結果として、みずほコーポレート銀行（富士銀行）とみずほ銀行（勧銀と興銀）ができてしまうくらいの惨状だったようです...。

通常、銀行の合併時は力関係の大小があるため強い方が飲み込むだけでしたが（東京銀行と三菱銀行、さくら銀行と住友銀行）、対等合併はだめだったのでしょう。

最近まで3人の男性が出てきて対等に話してOneみずほ！みたいなテレビCMを流していましたが、あれは旧行意識の表れ以外の何物でもないと思ってみていました。

・2度の大規模障害

弊害の大きすぎる対等合併のためか、当たり前のようにシステム障害を起こしてしまいました。

1回目は2002年4月、2回目は2011年3月でした。

どちらも口座振替や振り込みなどといった勘定系の中核機能が障害のもととなりました。詳しくは省きますが、一括処理と呼ばれる「一連の処理がすべて終わるまで不完全な処理」であった機構の口座振替処理が終わらず、営業店システムの立ち上げが混乱し、結果として大規模な障害を起こしてしまいました。（本には詳しく説明があります）

RDBを基本とし、1件1件トランザクション処理を行う仕組みが決済機能の性質から見ても合理的です。が、ブラックボックス化したシステムを紐解いて勘定系を再構築するという考えが経営陣になく、投資もされなかったようです。

・ようやく動き出した勘定系の刷新PJ

2度の大規模障害と金融庁からの圧力によってか、やっと大規模な刷新PJが発足しました。

リテール事業が縮小し続ける中、サラリーマンからのし上がってきた人たちで構成される経営陣としては、大規模な投資は確かに難しいものがありますよね...。

当初予算2000億円だったようです。

NTT、富士通、IBM、日立を主軸としたベンダーが集結し始まりました。

結果、4,000億円を軽く超えるプロジェクトになりましたが...。

・ホストシステムの残存と目利き

さて、ここからは新勘定系システム「MINORI」を構築するにあたって僕が学ぶべき点だと断定した箇所をつらつらと書いていきます。

ブラックボックス化した勘定系システムを刷新したものの、ホストシステムが残っていると聞いて不思議に思っていました。なぜjavaで構築したのにホストシステムを残したのかとても疑問に思っていたのですが、慧眼を持った方が設計にあたったのだと理解しました。

SOAを採用した「MINORI」は、各営業店やスマホからのダイレクトバンキングからのアクセスを受けつけるゲートウェイ部分をホストシステムで構築していました。

ゲートウェイとなるインタフェースを高性能、高信頼性のハードで一手に担うことによって、コンポーネント化した各金融サービスへアクセスすることになります。これによってシステム間の疎結合を実現し耐障害性を大きく向上させています。

クラウド全盛のご時世ですが、個人的にこういったことはハードウェアの知見がたまっていないとこんな設計はできないと確信しています。

（同時に、この情報、本なんかに書いていいのだろうかと不安になりました...笑）

・ゼロベースからの要件定義

よくあるシステム構築の話なのですが、SAP導入する企業にあるあるなのが、

「カスタマイズてんこ盛りの現状業務に合わせたSAP導入」です。

ユーザからすると、今の業務フローから変更するのは嫌なものですから、そこを変えないようにシステム部に調整をかけます。

で、そのシステム部から委託を受けるSIerはたくさん機能作った方が儲かりますから、乗り気でカスタマイズを受け入れます。

システム部の評価項目としては、ユーザ部の満足度評価なんかが多いので、三方よし、となるわけです。

僕個人としては、2重の意味で無駄をしているのでこれ大嫌いなんです。

①現状の業務に改善点があるからSAPを導入して効率化しようとしているのにユーザのわがままでできていない無駄

②カスタマイズ機能の開発、という目先のお金を追ってしまい目的を見誤っている技術者がいる事による無駄（お客様の利益のためにプロとして仕事しろよ、思ってしまう）

互いの利益が一致してしまうのでよくある話になっています。

みずほ銀行は、このいわゆる「現状踏襲」を理想とする要件定義をやめさせるべくユーザ部自身にツールを使わせ、「あるべき」業務フローを作成させました。（MHIRがツールの使用方法の補助に入ったようではありますが）

この経営判断は見事だったと思います。これをもとに要件定義を行っていったようです。

・品質担保に向けた取り組み①

この巨大なシステムを構築するにあたって、コード規約を統一し、しかも守らせるのは至難の業です。僕自身、PMの観点から見ても、一人ひとりコードを書かせていたら絶対に偏りが出てしまうことは避けられないと考えます。

みずほは、コードを「書かせない」ことにしたようです。

すべてのコードを、ツールを用いて生成させたのです。（富士通さんのツールです）

手直しも許さなかったとのこと。

これにより、品質の偏りなく技術的負債のとても少ない成果物ができたようです。

もちろんエンジニアの皆さんからは不安の声が上がったようですが、性能面などの検証で明らかになったボトルネックはほとんどがRDB周りだったようです。（インデックスがちゃんと張れていないとか、SQLの書き方が悪かった、TABLE設計が悪かったなど）

個人的には、UIを生成するノンコードツールは性能が重視される場面で採用するのはいまだ非常に危険だと思っていますが（salesforceなど）、コード生成ツールなら局所的には賛成です。

・品質担保に向けた取り組み②

様々な部（基本、MHIR社の部です）で担当するシステムは決まっており、それぞれがそれぞれのシステムを構築する流れでした。

もちろん、それぞれ担う業務が違うためインタフェースなどに対し考え方やとらえ方など違う箇所があり、それがシステムに対し顕出している箇所も多いでしょう。

そこに横串確認を通すための組織を設け、原則から外れた実装は許さなかったようです。属人性の排除と原則の徹底によって、技術的負債を作らなかったということになります。

素直に脱帽です。これは本当にすごいことです。

・現在のみずほのシステム要員のすごさ

 この誰もがやりたくない、新勘定系構築を乗り越えてきた方たちは、いわば地獄をくぐってきた方たちです。

エンジニアって、サイヤ人じゃないですけど修羅場をくぐればくぐるほど強いエンジニアになります。

昨今、テクノロジーを用いて新しい金融サービスを提供する事業者が乱立する中、これだけの修羅場をくぐってきた強いエンジニアをたくさん抱えているみずほは、かなり強いです。多分何でもできます。

事実、「MINORI」開発に携わったMHIRの方はどこに行っても一騎当千、とのことです（本より）

3メガで4位のみずほ、とまで言われてしまうみずほ銀行はいなくなるかもしれません。 

ビジネスを構築できれば、ですが...。

以上、読了記兼備忘録でした。

若干よいしょしている部分はあると思うのですが、同業としては強いエンジニアをたくさん抱えているみずほさんは怖いですよ...。

最後までありがとうございました。