UXエンジニアになりたい人のブログ

エッチだってしたのにふざけんなよ!

「みずほ銀行システム統合、苦闘の19年史」が普通に称賛案件だった件について

各所で話題になってたみずほの本の話。

 

現システムは「大成功」

この本は3部構成になっていて、1部は稼働中の新勘定系システムMINORIの説明です。

 

本件、直接は知りませんでしたがネット上では「関わったら負け」と言われるほど悪評高く、また延期も2度行っていたので、勝手に「既存システムに〇〇を追加せよ、的な"阿吽の呼吸"の要求を元に開発して、レビューの名の下にしょっちゅう要件が追加されて、テストに入っても『運用が回らないから』とか言って要件が追加されて、出来上がったものはなんとか動いてはいるものの柔軟性のないそびえたつクソ」っていうよくあるパターン、銀行っぽいパターンなんだろうなと思ってました。

この本にもきっと「動き出しはしたものの3回目の大規模障害は時間の問題」的な裏事情が書かれているのだと思っていました。

 

しかし、第1部は予想に反してMINORIは「大成功」という体で話が進みます。

ハハッわろすと読み進めていたのですが、どうやらSOAの思想で構築された疎結合のシステムで、それゆえ機能追加時のテスト工数が減少でき、従来システムに比べて(そして競合他社に比べても)圧倒的に柔軟であるとのこと。実際たしかに本の記載を見るととても"良さそうなもの"が出来上がった感じがします*1

 

そして、読むにつれてプロジェクトの様々なことが「正しく」行われてるのがひしひしと感じられてくるのです。

驚きだったのは、要件定義にあたってasis(従来どおり・従来システムを踏襲)を全面禁止して、ユーザー部門に本来あるべき本質的な業務フローを1から考えさせてツールで表現させたというところ。

SOAはサービスやコンポーネントをいかに独立性/再利用性高く切り出せるかが鍵なので、正攻法ではあるのですが、本当に驚きでした。だってそんなことできた試しがないですから。

受託システム開発は「自分の業務すら正しく把握できない要求元が、システムを通じて浮かび上がってきた業務上の不整合を誰のせいだと揉める時間が大半を占める」というお約束で進むものであって、要求元の責務を果たそうとすること自体が珍しいのです。そして、よしんば本腰をいれてやる気があったとしても、そもそも現状と切り離して本来論を検討するというのはなかなかスキルが必要で、底力がないとできないことなのです。

しかもこれ、ちゃんと粒度や記載にばらつきがないようにみずほ側がガバナンスとってやってたらしいです。マジか。

考えてもみてください。「今の業務とはべつに自業務のあるべき姿を考えて謎のツールで表現してください。監査役からもろもろコメント入るかも知れないので対応してください。現行の業務システムから処理を書き起こすのは禁止です。」などというめんどくさい依頼を飲ませるだけでも相当大変ですよ?どれほどの苦労があったことか…

そしてSOAのサービス粒度はこの「あるべき業務」によって適切に決められたはずで、その事実だけでかなり"強い"システムが構築されたことがうかがい知れます。

 

その他プロジェクト運営に際しても痒いところに手が届くような施策をことごとくやっていて、圧倒的に「正しいこと」を頑張ってやったのが伝わってきます。またもや称賛。

例をあげるなら「最初に用語を統一する」話。さらっと書いてありますが、大企業で様々な部署がひしめく中、統一した辞書を作るだけでも超大仕事です。でもそれをしないとそのあとあらゆるところで困るので「正しい」です。そういう細かいことの積み重ね、間違った方向に行かないようにする施策がすごくたくさん出てきてだいぶスタンディングオベーションしたい気持ちになってきてました。

 

2回の延期も場当たり的に延期したのではなくて適切な時期に適切に見積もりを再評価した結果の延期で、うまくガバナンスが効かせられてたことが伺えます。

 

ひとつだけ、大丈夫か?と思ったのは「コードはすべてツールから自動作成」という記述。バグ修正などで正しい挙動を実現するコードはわかってるのに、それを自動生成させる手段がわからない、なんてことにならないかなあと。でもまあきっとそれを上回るメリットがあったのでしょう*2

 

ともかく、第1部を読み終わる頃にはなんか想像と違ったけどすごく良い本だな、という気持ちでした。

 

余談ですけど、第1部には新システムの操作教官として一般職から有志を募って教育にあたらせた話が出てきます(ちなみにこの人達が困らないようにバッチリフォロー体制もあった旨も記載あり)。その人達の現在の肩書がなんかすごいんです。出世した感が肩書きからもわかって、サクセスストーリー感がわくわくします。

みずほ経営陣は「人が育った」ことを大きな成果として認識してるとの記載がありましたが、さもありなんといったところ。

 

圧倒的クソな過去事案のせいで今がより輝く

第2部と3部は2011年の東日本大震災直後に起きた2回目の大規模障害と、2002年の合併直後に発生した1回目の大規模障害に至る軌跡の解説。

これはね、まごうことなきクソです。

 

2011年は(合併後のごたごたがあったにせよ)ずっとなあなあで動かしてきて、異常発生時のリハーサルしてないどころか異常発生時の例外フローすらない、なんならデータフロー図さえないシステムで障害起きて、非常時にもかかわらず全くリーダーシップを発揮できなくて解決まで10日もかかったという、想定以上のクソ事案。

 

2002年は、IT投資増加のために合併するというふれこみだったのに、CIOも配置せず担当レベルに検討を丸投げして、ベンダーと組みながら新銀行の主導権争いに奔走し、システム統合方針さえ二転三転した挙げ句、システム開発会社のできますやれますを鵜呑みにして見切り発車で大障害を起こすという、半沢直樹みたいな話ってほんとにあるんだな、と謎の感動すら覚えるほどの救いようのないクソ事案。

 

でもこれ、最終的に成功に終わることがわかってるので、これらの事案がマイナスに働くより、こんな文化の会社でようやったよな、という気持ちが止まらなくなるんですよ。

ほんの一年前までデータフロー図すらなくて平気だったような文化背景で、ゼロベースで本質フローを書き起こさせるだなんて、ようやったよなと。

合併先の片方にシステムを寄せる「片寄せ」すらまともにできず右往左往する文化背景だったのに、SOAで疎結合なシステムをスクラッチ開発とか、ほんとにようやったよなと。

よくこんなマイナスからのスタートでやりきったなと。

 

やっぱり合併前後くらいで入社して10年間くらいずっと「みずぽ(笑)」とか言われてた人たちが心を一つにしたのだろうか。

ぐうたらな社員でも「3度目やらかしたらマジでやばい」という危機感が共有できて一体感が醸成されたのだろうか。

いろんな想像をかきたてつつ、クソな過去が今をより輝かせるという胸熱な展開です。

 

でもホントのところも知りたい

まあでもちょっと出来すぎてるとも思うわけですよ。ホントのところはどうなんだと。実はみずほ主体じゃなくて裏でコンサルが暗躍してたんじゃないかとかさ。SOAなんて掛け声だけで実は従来通りのスパゲティ・モノリシックなんだとかさ。ただSOAは話半分だとしてもレガシーシステムと比べれば雲泥の進化だからなあ。

そもそもネット上の超悪評はいったいなんだったのかと。すくなくとも2011年以降は「正しい」ことを根気よくやってるようにみえて、ではなにをもってどんな視点でそこまでdisられてたのかと。

まああと最近できてるネット専業銀行とかに比べてアドバンテージはどうなんだろうな、とかは気になる。

 

なにはともあれ、とても良い本でしたし、無事やり遂げられたこと、心の底から称賛いたします。こういう話は元気が出るし、たしかに2025年の崖を乗り越えるヒントになるね。

ブラボー!

*1:というか旧来システムレガシーすぎるだろとビビる

*2:生コードは様々なスタイルで記載できるので、データとその扱い、異常時のポリシーのようなコーディングルールで縛れないような設計上の制約を均質化できるのはメリットかなと。