ども！まとんです。
Twitterで話題となっていた「みずほ銀行の本」を読んだ感想です。
みずほ銀行システム統合、苦闘の19年史
IT業界のサクラダファミリア案件が、ついに完成したらしいですね。
数年前に友人らと「みずほの統合はやばいらしい」という話をしたのが懐かしい。
僕はみずほユーザーではないので知らなかったですが、ここ数年はATMが何度も停止していたとか。
しかし、それは正常に移行作業が実施されていた計画停止だったようです。この本のおかげで、みずほのことが良く分かりました。
色々と思ったことを書きます。
ミステリー小説か
この本の構成は面白くて、現在から過去に遡る構成になっています。
第一章で新しく作ったシステムの話、第二章で2011年の東日本大震災後に起きた2回目の大規模障害の話、第三章で2002年のみずほ銀行統合直後に起きた1回目の大規模障害の話が語られます。
もし、時系列順に昔から現代に語る構成にしていたら、1回目の大規模障害の章で辛すぎて読むのを止めていたでしょう。
しかし、現在から昔にさかのぼることで、「この障害が起きた背景には、こんな過去があったのか・・・」と伏線が回収されていきます。
第三章を読んだあとに第一章を読み返すと、伏線があちこちに散りばめられていたことに気が付き、しかも伏線が現実に起きたみずほ銀行の本質的な問題と一致していたりして（例えば、1988年製のシステムを使い続けていた伏線が、実は2002年の銀行の統合時に権力争いがあって、１銀行のシステムに片寄せするために新しく作らず、88年製を改修した結果だった、とか）、現代のノンフィクションミステリー小説か、と思いました
実際、こんな感じで現在→過去に遡るミステリー小説を読んだことがあります。香港警察のミステリー。面白いのでぜひ。
新しいシステムはSOAの設計思想で、確かにナウい
新しくみずほ銀行が構築した勘定系システム「MINORI」は、サービス指向アーキテクチャ（Service-Oriented Architecture: SOA）の設計思想を採用しています。
SOAとは、アプリケーションをサービスとしてコンポーネント化し、サービスを組み合わせることで機能を実現する方法。
互いのサービスは疎結合にしておくことで、サービスごとの改良やメンテが可能になり、従来のモノリシックなシステムと比べるとコストが下がる。
メガバンクでSOAを採用したのは、みずほが初めてだそうです。
僕も最近、SOAの発展形であるマイクロアーキテクチャの勉強をしたので、馴染みが深い話でした。
サービスをAPIとして呼び出せるようにしておけば、他のシステムとの連携も容易になって、新しい機能をもりもり作っていける。
令和の時代に生きる僕らからすると、GoogleMapが公開するAPIを使ってブログに乗せたりするのは当たり前の話だし、僕もTwitter APIを使ってTwitterを分析するオモチャとか作ったりできます。
ただ、GUIのOSも無い時代から続くシステムの分野では、当たり前ではないようです。
実際、みずほ銀行が今回刷新したシステムの前のシステム（旧第一勧銀のSTEPS）が作られたのは、1988年。
Windows95も無い時代のシステムから、一気に令和（平成？）へのジャンプ。すごい話だ。
ただし、クラウドには対応していないようです。
SOAのコンポーネントごとに、4つの巨大ITベンダー（みずほ情報総研、富士通、日立、日本IBM）が担当を割り当てられて、開発している。
それぞれオンプレのメインフレームを用意して実装している。
2020年にもなってメインフレームっていう言葉を聞くと頭がクラクラしますが、そういうことらしい。クラウドは使っていないようだ。
サーバーの保守で、各ベンダーは継続的に受注を受けられるのだろう。それが良かれ悪かれ、JTBCはこうやって、お互いに支え合って生きている。
というか、4つのITベンダーが入り混じって一つのシステムを仕上げるのは到底不可能な話だと思うので、その点、お互いが疎結合で結合部分の仕様だけ決めておけば開発できるSOAは必要不可欠だったのだと思う。
COBOLってマジで使われていたんか
僕が大学に入った時代は、スマホアプリ開発の全盛期で、JavaやObjective-Cなどが人気言語でした。
それからSwiftとかPythonとかJavaScriptとか、栄えたり色々ありましたが、当時でも「COBOLという古代言語があって、今でもATMで使われている」と講義で習った覚えがあります。
学生の僕らからしたら、そんな聞いたこともない言語、古代メソポタミア文明とかで使われていたのかな？というレベルで聞き流していたのですが、なるほど、ほんとうにみずほのシステムで使われていることを知りました。
しかしまぁ、1988年に作られたシステムでCOBOLを使っていたのは、よい。当時はイケてる言語だったのだと予想します。
しかし、今回新しく作ったシステムの一部でも富士通や日本IBMがCOBOLを使っている。
これ・・・大丈夫なのか？数年後、結局メンテできなくなるのではないか？
COBOLエンジニアがどれほどいる（今後増える）のか分かりませんが、持続可能じゃないだろこれ・・・SDGsに反していると思う。何か強い圧力が働いたのだろうか。
ちなみに、一部意外のシステムは、富士通も日立も日本IBMもJavaを使って書いている（一つだけC）。全部Javaで良かったのでは。。。
移行のストーリーはアツい
2018年から1年ほどかけて、旧システムから新システムに移行していく話はアツかったです。
営業店舗のスタッフに新システムの使い方を教育するため、女性職員170人が全国を回って研修、セミナーを実施。
新システムの意義を説明し、ボトムアップで現場の不満を解消していく。
大勢のスタッフが関わるシステムでは、いきなり「明日からこれに変わります。マニュアル読んでおくように。」では破綻するでしょう。トップとボトムの両輪で組織を動かすプロジェクトはアツイ。
移行に関わったスタッフはキャリアをステップアップさせて、企画部門に異動したり、全社の研修マネジメントに異動するなど活躍しているという。良い話だ。
（ただ、こういうスタッフを「女性職員」と性別を含めて表現するのは、モヤッとしますね）
あと、移行の進捗を管理する「みずほ天眼システム」。名前がクソカッコイイ。
移行作業の実行時間や進捗を一元管理する専用システムで、独自開発とのこと。
本音を言うとRedmineとかOSSのプロジェクト管理ツール使えばよくね？と思ったけど、名前がカッコイイから良いのだ。すべてを見渡す天眼。NARUTOとかでありそう。
JTBCすぎるが、読む価値はある本
この本の真髄は、第三章のみずほ発足の話にあります。
みずほ銀行は、第一勧銀、富士銀、興銀の3行が統合して発足した銀行。
しかし、統合にあたってトップダウンのリーダーシップを発揮することが全くできず、現場のIT部門に丸投げしたため、難航。
銀行間で権力争いが勃発。「うちの銀行のシステムを絶対に残す！うちの力をアピールするチャンスだ！」とか言っちゃう。数年後には同じ「みずほ銀行」の仲間になるのに。
本では語られていないけど、みずほ銀行の中には元来の3銀行の派閥がめちゃくちゃあったんだろうなぁ。新入社員は派閥争いに巻き込まれただろう。かわいそう。
システム移行の場では、延々と不毛な議論を繰り返したり、と思えば「外部コンサルがこう言ったから仕方ない。私たちが判断したのではない」と無責任なことを言ったり、めちゃくちゃJTBCのリアルでした。
しかし、どうなんだろう？日本の大企業はこんな感じだと思うけど、世界でも同じでしょうか？歴史が長い大企業はどこも同じような状況なのかな、と思う。
インターネットもまともに使えない時代で、効率的なコミュニケーションを取るツールも無い中、日本企業だから悪いという問題でもないと思う。トップダウンができなかったのが悪い。
こういう話を読んでいると、小規模サービスならクラウドのインフラを使えば簡単に作れる時代に感謝。
エンジニア一人当たりの価値が上がっているんだろうな、とか思った。だからエンジニアの給料が（外資では）高いんだろうなと。
まとめ
- 本として現代のノンフィクションミステリーのように、面白くまとまっている。
- SOAの設計思想は良い。クラウド化はしていない。4社のITベンダーがそれぞれ開発して、よく完成したなと思う。
- COBOLは本当に使われていた。都市伝説ではなかった。しかも最新システムでも一部で使われている。ヒエェ
- 新システムへの移行をボトムアップで支えたストーリーはアツイ
- 現場任せのIT統合はカオス。トップダウンのリーダーシップが必要。詳しくは本を読んでみて。辛くなるから。
以上、メタラーまとんでした。
ではでは。
