四十三庵

蔀の雑記帳

みずほ銀行のシステム統合の本読んで思ったこと

みずほ銀行の新システムMINORI稼働に至るまでを追った本を読んだので、それに関連することを書く。
記事のレベル感はちょっと迷うところなのだが、ある程度リテラシーが高い読者を前提にするので、用語の解説などは行わない。

目次

本の構成

本書は三部構成になっていて、
第一部でMINORIの概要、プロジェクトの詳細。
ここが本書のメインといってもいいか。
第二部は東日本大震災(2011)のあとのシステム障害の教訓、第三部は経営統合時(2002)の障害の教訓。

第一部がメインで、第二部第三部は以前から日経コンピュータが出していた書籍の内容の焼き増しを入れました、という感じがする。
ただ19年の長すぎるシステム統合プロジェクトの教訓として入れるには十分意味があるかとも思う。

システム開発のベストプラクティスの本ではない

本を読んでいて思ったが、けして大規模プロジェクトをやる上でのベストプラクティスを紹介する本ではない。
むしろMINORIのプロジェクトの進め方についても、ツッコミたいことは多々ある。

けれどとにかく完成した、ということが重要なのだと思う。
ベストではないが、今までのように失敗はしなかった。

システム開発に魔法はない。
突然スターPMがあらわれて、プロジェクトが見違えるように進み始めた……なんていうことなく、
ひたすら要件定義書書いて、ひたすらコーディングして、ひたすらテストした、というのが現実のよう。

金融システムの持つしがらみ

本著によれば、MINORI開発にかかったコストは4000億円半ばだという。
東京スカイツリーの総事業費650億円らしいので、スカイツリー7本分がシステム開発で溶けたことになる。
ヘタな会社だったら、年間売上十年分ぐらいになる額だろう。
むしろその金を払えてしまうのが問題なのかもしれないが……

そこまで工数が肥大化するのは、金融システムの持つしがらみがある。
思いつくままに列挙する。

  • 経営陣のITリテラシーが低すぎる
    • ただでさえ意思決定プロセスが不透明なのに、わからないから尚更決定が下りない
    • その経営陣が気に入る部下はやはりリテラシーが低い
    • ヘタすると現場の上司もそうだったりする
  • 組織がデカすぎる
    • 元々別システムだったものを合併のたびにつないだ歴史
    • システム子会社(みずほ情報総研)がいて、ベンダーがいる下請け構造
  • システムが古すぎる
    • 技術者がいない
    • 技術情報がない
  • 金融庁に監視されている
    • 金融庁が監視しているのは障害が発生しないか
    • UI/UXを高よう、みたいな発想にならない
    • 結果的に現行踏襲を繰り返すシステム変更
  • システムが巨大すぎる
    • 一人の人間が追いきれない量のコード
    • 仕様のブラックボックス化

組織的にもシステム的にも厳しい状況になっていて、
しかも金融庁という日本の新陳代謝を阻害する親玉みたいな奴が障害にだけ目を光らせているので、
金融機関側の最適解は現行のシステムを死んでも使い続ける、ということになる。

幸い銀行業界はベンチャーの参入のような競争がほとんどないので、
システムが劣化していても預金者が離れることはそんなにない。
ここ二十年でまともに参入したのってジャパンネット、SBI、楽天ぐらいだと思うけども、
結局メガバンクからのそちらへシフトする流れはそこまで続かなかった。

ブラックボックスと化したシステムはどうする?

僕は前職で割とブラックボックス化したシステムを運用していた。
そのとき、
「もう中のロジックを理解するのは諦めて、ひたすらテストして挙動を見て、逆引きするしかないな」
と最終的には思うに至った。
エンジニア失格? 知らん。

アジャイルで金融システム作れない?

LINEも金融システム作るとなったら、富士通にシステム開発投げた。
LINEのイケてるエンジニアで、イケてる金融システムを作って欲しかったのだが……

イケてるエンジニアが集まって金融システム作った例だと、FOLIOが一応ある。
ただ下記のブログなんか見ると、そんな単純なものでもなさそう。

itohiro73.hatenablog.com

金融システム開発がウォーターフォールなのは、要件がきちっとあるとか、
トランザクション処理の実装がシステムまたがるんでしんどいとか、色々細かいことはあると思うが、
文化的にアジャイルと相性が悪いというのが一番大きいと思う。
金融業界の減点法の価値観とアジャイルが完全に合わない。

アジャイルの朝会は、毎朝「俺が今日やろうとしているすごいこと」を皆に話すらしいが、
金融系の朝会はクソ早い時間に皆集まって、この世の終わりみたいな顔で毎朝集まって、なんか上司の言うこと聞いて、報告して終わりみたいな文化だ。

ただそれが金融庁の求めていることでもある。

みずほを巡る20年の主なできごと

本書の中に出てくるプロジェクト年表がよくまとまっているので、転載しておく。

できごと
1999年 8月 第一勧業、富士、日本興業の旧3行が経営統合すると発表
12月 リテールは第一勧銀、ホールセールは興銀の勘定系システムに片寄せすると発表。統合後、早期に後継システムを構築する方針だった
2000年 11月 リテール分野の統合作業を一時中断。第一勧銀と富士銀の感情系システムを「リレーコンピューター」で接続する方針に変更
2002年 4月 旧3行の統合初日に大規模なシステム障害が発生
2004年 新しい勘定系システムの開発を開始
12月 第一勧銀と富士銀の2系統に分かれていた勘定系システムを第一勧銀側に片寄せ
2005年 「ハブシステム」の開発が完了
2008年 次期勘定系システムの「業務共通基盤」を開発開始
2010年 「ローン」などの勘定系の周辺システムの開発が完了
2011年 3月 東日本大震災をきっかけに大規模なシステム障害が発生
5月 旧みずほ銀行と旧みずほコーポレート銀行の合併に向けて検討を始めると発表。併せて、みずほ信託銀行を含めた3行で勘定系システムを刷新・統合することも決定
5月 次期勘定系システムの開発を本格化。2016年3月末 の開発完了を目指す
2013年 7月 旧みずほ銀行と旧みずほコーポレート銀行が合併
2014年 4月 次期勘定系システムの開発完了を9ヶ月延期
2016年 11月 2度目の延期を発表。開発完了を数ヶ月延期
2018年 6月 システム移行を開始
2019年 7月 新勘定系システム「MINORI」が全面稼働

こうみると第一勧業+富士+日本興業+みずほコーポレート銀行+みずほ信託銀行でシステムを作ったことになる。
他のメガバンクはもっと単純に片寄せ、片寄せで進めたっぽい。

これどうなんだ?と思ったところ

どちらかと言うと日経コンピュータはIPAの試験に出てくるような、所謂プロジェクトマネジメントが好きな傾向があるので、
おそらく「これはいい取り組みだな」と思って紹介しているんだと思うが、
僕の価値観からすると、「これ悪手じゃね?」と思った箇所もいくつかあった。

たとえば「劇薬」のスパルタ式要件定義と言う章では、

MINORIの要件定義に当たっては、ユーザー部門はアズイズではなく「銀行業務を棚卸しして、あるべき業務フローを考えさせた」(みずほFGの加藤正樹事務企画部副部長)。
「劇薬」も用意した。
ユーザー部門が要件定義をする際に、JBCCが販売する上流工程支援ツール「Xupper」を使わせたのだ。
Xupperは業務フロー図やデータモデル図を作成して業務アプリケーションを設計するツールだ。
本来はエンジニアが使用する設計ツールであり、ユーザー部門に使わせるのは異例だ。そこにはこんな狙いがあった。

と出てくる。
Xupperってナニ? と思って調べたのだが、

www.jbcc.co.jp

うーん……という感じ。
要件をユーザーと一緒にちゃんとモデリングしようね、という目的自体はいいと思うんだけど、正直やり方としてはどうなんだろう、と思った。

あとはコーディングで、なんかツールを入れたらしいんだけども、

超高速開発ツールの採用はコーディングの統制に加えて、開発工程の省力化にも役に立った。
例えば富士通の「Interdevelop Designer」の場合、業務に関するルールを数式や日本語で記述すると、COBOLやJavaのコードを生成するだけでなく、テストケースも自動生成する。
みずほIRの田辺主税銀行システムグループ横断本部本部長は「コーディングの作業量は五分の一に減った」と振り返る。

これもなんか……
結局保守する側としてはきれいなコードがあって、必要最小限のドキュメントがあればそれで終わりなんだと思っているが、
(なんならドキュメントはなくても、十分に可読性が高いコードがあれば良い)
この手のコード自動生成ツールって、開発者目線ではイマイチなコードが生み出されてるんじゃないかな、という気がする。
この謎ツールの学習コストもあるし……

あとプロジェクトの体制図がこれなんだけど、

f:id:st43:20200215133200p:plain
↑政府機関の説明図なんか?

本著の記述によれば、部門横断で八千人を統率していた、らしい。

設計や開発、テストの実務は、みずほ銀行の情報システム部門やみずほIR、四大ベンダーを中心に進めたが、現場だけで判断を下せない難題も出てくる。
会社や部門間の利害対立を調整し、全体最適の視点で意思決定を下すため、みずほFGとみずほIRに特別な組織も設けていた。
みずほFGに置いたのが「次期システムプロジェクト統括会議」で、プロジェクトの司令塔といえる存在だ。
みずほFGの坂井辰史社長をトップに、みずほ銀行の藤原弘治頭取やみずほ信託銀行の飯盛徹夫社長らが参加し、月一回開く。
MINORIに関する事実上の最高意思決定機関であり、経営会議の直前に開催するのが通例だった。
その事務局としてプロジェクト全体を束ねたのが「次期システムプロジェクト統括PT(プロジェクトチーム)」だ。
統括PTの傘下に各ユーザー部門に対応する企画部会や財務・主計部会など十七の作業部会を置き、それとは別に部門を横串にした三つのタスクフォース(TF)を置いた。
プロジェクトの実務は関係する作業部会とTFが一体になって進めた。
例えばMINORIへの移行に向けた営業店のリハーサルは、営業部店業務対応TFと事務部会などが連携して進捗を管理した。

あとなんか四重にリスクを管理する体制があって、
現場のプログラマーの傍にプログラムの品質のチェッカー(なんだこいつ)がいて、
そのごシステムリスク管理室→業務監査部門の厳しいチェックを経てシステム品質を高めた、らしい。

現場のプログラマーからは、
「超高速開発ツールを使うよりも手で書いた方が速いし、シンプルな往路グラムができる」
という意見が出たが、

「ツールを使えば属人性を取り除けるため、保守性が高まる」
(みずほIRの山本健文銀行システム横断開発推進PT長)

とのことで、意見を却下したらしい。

これらのみずほの完璧なプロジェクトマネジメントが紹介されたあと、本の中では以下の記述に続く。

みずほFGはプロジェクトを円滑に進めるため、前述したいくつもの仕掛けを用意した。 それでもプロジェクトは難航し、開発完了時期を二回延期する事態に陥った。

どう見ても遅延するやり方だと思うのは僕だけなんでしょうか……

じゃあどうすればいい?

Q: みずほのSE*1が電球を変えるためには何人必要か?
A: 4人。1人が電球を変え、1人がその作業を現場でチェックする。
  そして1人の上司が電気がつくことを確認し、電球がつかなかったらその問題をもう1人の上司に報告する。
  また電球の取り換えにあたっては超高速電球交換棒を用いて、属人性を排除する。

これは今僕がテキトーに考えた電球ジョークなんですが、やり方としてはこんな感じのシステム開発ですね。

こんなやり方はバカげている、けれど、じゃあどうすればいいかという発想になったとき、
もっとスキルのあるエンジニアと、きちんと業務フローをモデリングして、いいシステム作ろうね、というのが正論ではあるんだけど、
問題になるのは前述の「金融システムの持つしがらみ」で列挙したしがらみで、結局ここを突破できないので、多くの金融機関がレガシーシステム使い続けてるんだろう。

Webシステムなら、「ちょっとぐらい画面表示が変でも、バグってても、クリティカルじゃなければいいよ」な世界なので、
バンバン新しいチャレンジが生まれるし、イキイキするんだけど、
金融業界はユーザー影響のある障害が出せないという制約があるので、減点主義になるし、
何でもかんでも管理する世界になる。

ただメガバンクぐらいの規模の大きさの組織やシステムなんて、管理できるのか?
管理できないと思う。
でも管理できている、ということにしなければ、金融機関としてやっていけないので、管理できていることになっている。

今のシステム開発の主流はアジャイル開発で、小さく開発して、だんだん大きくしていく方式で行う。
管理できない単位で作るな、ということになっている。

みずほの場合、そもそもが巨大システムで、ボトムアップで変更することすらできない、
けどトップダウンでやったのが現場に降りてくるとなんか歪んだ形になる、
けど金融庁はノーミスで移行することを要求してくる。

「いいシステム」を作りたいんであれば、間違いなくちゃんとわかっているエンジニアを集めて、
業務を整理して、「小さいシステム」を作って、そこからだんだんスケールさせていく、のが鉄則なんだけど、
もはやみずほは、いいシステム作ろう、という発想ではないのだろう。

業務系システムというのは、BtoCに比べて、情報が外に出づらい。
だからみずほよりいいプロジェクト運用している、似たような金融機関もあるのかもしれないが、いかんせん情報が出ない。

コードを読んで、書くしかない、んだけど……

正直古いシステムのリプレイスなんて、ひたすらコード読んで仕様理解して、ひたすら書き直すしかないわけなんだけども、

(たとえばそれをした例)
speakerdeck.com

現実的にアセンブラ(IBM/富士通/日立)もPL/ⅠもCOBOLもJavaも読めて、IMSもDBも知識があって、
メインフレーム環境でもRHELでも戦えて、しかもその上で技術軽視の組織の中で出世して行って、
みずほの巨大なピラミッドの中で決定権持っている、なんて人いますかね?
もしくはあなたはそうなれますか?

色々考えたんだけど、なんか結局金融業界とIT技術の食い合わせが悪すぎるのが本質なんじゃないかなと思うに至った。

かつてはそうではなかったはずなのだけれど。
90年代くらいまでは、金融業界=当時最先端のコンピューターのユーザーだったらしいのだが。

本書は、巨大組織が巨大システムをウォーターフォールでリプレイスした、いい例になると思う。
方法論自体はよくないプラクティスもたくさんあるのだが、とにかく泥臭く、統合プロジェクトを前に進めた記録として読んだ。

記事の途中、あまりに官僚主義的なプロジェクトの進め方をバカにするテイストになったが、
進め方はバカにしていますが、みずほという企業及び組織に所属する人をDisる意図はありません、というのは一応念押しで書いておきます。
実際のところ自分がやったらもっと上手く行った、という案件でもないので。

まとめ(ポエム)

4000億円を投入する。
要件定義は重要だ。
大量の要件定義書のExcelができる。
要件定義書から概要設計書を作る。
SEの腕の見せ所だ。
そして詳細設計書を書いて、それを元にコーダーがCOBOLだかJavaだかのコードを書く。 超高速開発ツールを使っているので、属人化は排除している。
そしてコードはチェックするおじさんがたくさんチェックする。
超高速開発ツールがテストケースも作ってくれるらしいので、それに従って死ぬほどテストする。
テストした結果はスクリーンショットをとって、Excelに貼り付けて、証跡として保存する。
その証跡をチェックするおじさんもちゃんといる。完璧。
よし単体テスト/結合テストはオッケーだ。

総合テストをしよう。
……あれ? なんだこの不具合は! おい!
クソッ、こんなんじゃ実施できねーよ! 延期だ!延期!

4000億円から、大量のExcelと、自動生成された冗長なコードが生まれました。
よかったですね。
(そして将来の更改PJまで巨大なブラックボックスが動き続ける……グオングオン……)

おまけ

誤植かと思ったら、誤植ではありませんでした。

(了)

*1:正確にはみずほ銀行はSEを抱えていなくて、みずほ情報総研がシステム開発会社として存在して、更に言うとみずほ情報総研は上流工程しかやってなくて、下流工程は協力会社に投げていると思われるんだけど、そこら辺をふわっとさせて、「みずほのSE」と呼んでいます