【所感】みずほ銀行の本

先週の金曜日、バレンタインを血に染め上げんばかりの勢いと話題性を持って発刊された「みずほ銀行システム統合、苦闘の19年史」を読みましたので、簡単に雑感などつらつらと書いていきたいと思います。

この本の章立て

この本は時系列の通りに構成されておらず、ややドラマチックな章立てが取られています。

第１部	2011年～2019年	次期勘定系「MINORI」誕生秘話
第２部	2011年	東日本大震災を発端とする障害
第３部	1999年～2002年	みずほ銀行開業初日の障害

ちょっと分かりづらいので、時系列に沿ってご紹介します。

【第３部】合併直後、「まさか」の大規模障害

みずほ銀行の前身は第一勧業銀行、富士銀行、日本興業銀行でした。3行は1999年に経営統合の方針を発表します。

経営統合≒業務プロセス統合ということでもあり、この本では正しくここに焦点が置かれます。3行はそれぞれ異なるベンダーのシステムを使っており、統一化の方向性も運用上また政治上の両面で紛糾したことと思います。

そんな事情の皺寄せが開発にも影響してか2002年4月1日、みずほ銀行発足と同時に稼働した新システムは大障害を引き起こします。旧富士銀の勘定系と他行NWを繋ぐ接続システムの訂正処理に問題があり、取引データに不整合を起こしました。

そのほか夜間バッチの口座振替処理が追いつかず、二重引き落としや二重送金のミスも発生しますが、これらの問題を人海戦術で何とか乗り切ります。

【第２部】震災直後、「またか」の大規模障害

2011年3月。「国難」とも呼ぶべき大規模災害が発生しました。そう、東日本大震災です。ここに書かれているのは、元も子もないことを言ってしまえばある意味「地震さえ起きなければ発現しなかったかもしれない」障害だと言うこともできます。

直接の原因はTV局が開設した（元々開設してあった？）口座に義援金の振り込みが大挙して押し寄せ、1日の処理上限を超えたことでオンライン、夜間バッチともにオーバーフローしたというものです。客観的に見て「処理上限って何だよ」ってなる人もいるかと思いますが、実際当時の行員もそう思ったんじゃないかと思います。システム的な観点から言えば少なくともバッチ処理については開発時の負荷テスト的な問題もあるので「ここまでのデータ量なら○○時までに終わることを保証します」とSLAで規定していることも多々あります。システム屋さんの責任逃れと言われればそれまでですが、システムなんてそういうものなのでしょうがないです。ハードウェア以上の性能なんか出ないのです。

著者の言で「この障害は20年以上同じシステムを使い続けてきたツケだ」というような主旨のことが書かれていました。また当時のみずほ銀行経営者の言で「勘定系のリプレースなど、何かなければ踏み切れない」とも書かれていました。これは一見矛盾しているようでどちらも正しいことを言っています。

システムは長年使い続ける以上、必ずレガシー化の問題がついて回ります。それはアーキテクチャ的にもそうかもしれませんが個人的には属人化の方が致命的だと思っていて、運用手順などのドキュメントがなくなったり、そもそもなかったりで、レガシーシステムに詳しい人が段々いなくなっていくのです。最近はそういう問題がそこかしこで浮き彫りになってきて、だからこそマイクロサービスとか構成管理とかInfrastructure as Codeとか叫ばれるようになってきたわけです。

そんな状況なので「触らぬ神に祟りなし」だし、まして勘定系といったら銀行にとって心臓に等しく、それに輪をかけて金融庁からの目もあったということで「動いているのにわざわざ手を加えて、もしくは全く新しいものを入れて、万が一何かあったらどうするのか」というある面保守的な立場を取りたくなるのは、至極当然ともいえるのです。

そして、結果論ですが「何かあった」のがきっかけとなって、リプレースに踏み切ったのでした。

【第１部】IT業界のサグラダファミリア、ついに完成す

IT界隈では「サグラダファミリアとどちらが完成するのが早いか」など専らネタにされていた（少なくとも2chにおいては）みずほ銀行の次期勘定系「MINORI」。8年の月日と4000億円の投資の末、去年7月に完成しました。

開発規模にして35万人月。ここで人月（にんげつ）とは1人が1ヶ月でこなせる作業量の単位であり、35万人月の表すところは極端に言えば「1人でやったら35万ヶ月（約3万年）」「1ヶ月で終わらせるには35万人の人的リソース投入」ということになります。

この章では「みずほ銀行はいかにしてこの超大規模更改を乗り切ったか」「過去2度の障害をどう生かしたか」に主眼が置かれ語られます。また3次オンラインのモノリシックなアーキテクチャからサービス指向アーキテクチャ（Service Oriented Architecture: SOA）に思い切り再構成した経緯、それにより将来他行といかにして差別化を図るか、詳らかに紹介されています。

金融領域において「あってはならない」過去2度の大規模障害。これを乗り切り、産みの苦しみを味わったからこそ、勘定系のここまで全面的な刷新に辿り着けたのだと本書は語ります。ここに書いてあることが嘘偽りない真実なのだとすれば、みずほ銀行はこれから新たなサービス、FinTechビジネスにメガバンクとして先陣を切って取り組んでくれることと思います。

突き詰めると

「現行踏襲」というのは魔法の言葉で、「動いてるんだからいいじゃん」と言われると返す言葉もなくなるのがベンダーの正直な立場なんじゃないかなと思います。ベンダーはユーザーの説得はできても意思決定までは関われないからです。最終的には経営層の考え方次第ではありますが、これは「今のままでいい」「今の仕事をずっとやっていれば、食いつないでいける」と思っているから生まれる言葉ではないでしょうか。要するに「変革を必要としていない」と暗に示しているのです。

ですが、今の世の中、大きな社会変革が流動的に巻き起こっている世の中で、立ち止まっていることが赦される業界はそうないんじゃないかなと思います。金融も例外ではないと思います。キャッシュレスが一般化したことで金融領域自体への参入障壁が低くなり、中小ベンチャーを中心に次々と新しいサービスが提供され始めています。

これから、新しく、より多くの付加価値を提供し続けるために、然るべきリスクは取っていかなければならないのかなと思います。そりゃもちろんノーリスクでこのレベルの刷新ができればそれに越したことはありませんが、少なくともシステム開発の現場において「絶対」はあり得ませんよね。「このPMだから」「これだけヒトを投入したから」「これだけのテストを網羅したから」これらはシステムの品質を担保する理由の一片でしかないわけで、何かが起こるときは起こります。終わったことを根掘り葉掘りぶり返す「なぜなぜ」もやればいいですが、それよりも重要なのは「問題が発生したときの対策・回避策」つまりコンティンジェンシープランを立てておくことです。ロールバックなのか前進対応なのか。こちらの立場で言うとエラく後ろ向きに思われるかもしれませんが、障害は起こることを前提にして運用を考えなければなりません。

「みずほ銀行システム統合、苦闘の19年史」。刺さるかどうかは人を選ぶかもしれません。ベンダーや業務システムに携わっている方々であれば、読んで損はない、教師も反面教師も盛り込まれたバイブルというべき逸品になっているかなと思いました。