みずほ銀行システム統合、苦闘の19年史
史上最大のITプロジェクト「3度目の正直」

 

日経BPのサイトの紹介文と目次

※ごめんなさい、パソコン画面でないと見づらいかも。



2020年2月の本ですが、私は先月、アマゾンのKindleで買いました。新たにトラブルが続いてから。

 

 

 

 

ただね、Kindleだと、図が小さいんですよね。

 

フォントサイズと違って図は拡大できないので(やり方があるのか知らないけど)、そこは不便なところ。

 

 

 

 

新しい基幹システムMINORI(みのり)の全面稼働は2019年7月。

 

本書は2020年2月18日発売。

 

過去2度の大規模障害についても収録されていますが、MINORIの部分については、開発から稼働にこぎつけるまでの成功譚とも言っていい話で、まだトラブルが生じていない段階の本。

 

そのため、みずほフィナンシャルグループの坂井社長の自信に満ちたインタビューや、颯爽とした写真も掲載されています。今読むと切ないです。

 

→たぶんこの記事が元になっています。日経クロステックのインタビュー記事(2019年9月)。


 

 

 

 

しかしその後、2021年2月から9月8日の時点で、トラブルが7回。

 

新システム構築に際しては、社内の事務処理を整理し直して、システムを一から全部作り直して、新しい技術を取り入れて。

 

プログラムの記述が属人化しないように作業を工夫し、システム変更する時も影響が広範囲に及ばず最小限の単位で出来るように作り。

 

それなのに、どうしてトラブル続きなんだろう??

 

 

私は技術者ではないので、どこが問題になりそうなのかは分かりませんが。

 

 

 

最近の報道では、全面稼働後に人員の削減・異動でシステム担当者が減っていたと言われています。

 

「みずほ、システム担当者3年間で6割削減 ブラックボックス化進む」

8/31(火) 産経新聞/Yahoo!

 

平成30年3月末時点で1143人だった担当者は今年3月末時点で491人となり、3年間で57%減った。6月の第三者委員会報告書では開発段階から関与していた担当者の減少に言及して「システム構造のブラックボックス化」が進んでいると指摘していた。

 

 

 

旧システムでは、長年使ったがゆえの機能の老朽化と、技術が後年に受け継がれないブラックボックス化があって、それで大規模障害が起きて。

 

システム刷新に際しては、それを防ぐための手立てを考えたのだと思うのですが、稼働から2年で早くもまたブラックボックス化?

 

 

日経コンピュータに散々、「経営層がITを軽視している」「経営トップがもっと情報システムを理解しようとしなければ」とか苦言を言われていましたのに。

そして、みずほ自身、システムを担当するIT人材の育成を図るとも言っていたのに。

 

 

(ただし、『苦闘の19年史』に収録されているみずほFG坂井社長のインタビューでは、社長は、過去の経営陣がITを軽視してきたという指摘を認めていない。「どうでしょうか。」)

 

 

 

 

 

本本の感想など。

 

 

「苦闘」というわりにはあまり苦闘の様子が窺えない、というカスタマーレビューがいくつかありましたが、確かにそれはそうかも。

 

全体的な流れは解りやすく書かれているのだと思うけど。

 

たとえばユーザー部門からの要求や要件定義が大変だったというのはちょっと出てきますが、具体的な苦労話はあんまりありません。

 

現場の苦闘の様子は、むしろ過去2度のシステム障害のほうが描かれていると思う。

 

 

 

第2部、第3部の過去の二度の大規模障害については、一部少し違いもあるけれど(2部の最後の章かな)、大部分は前著『システム障害はなぜ二度起きたか みずほ、12年の教訓』と重複しています。

 

なので本書を読めば、過去2度の大規模障害のこともカバーされます。

私は先に『12年の教訓』を買って読んじゃったけど。

でも個人的には、そこを先に読んで良かった気がします。

(本書で2部から読み始めればほぼ同じだけど)

 

 

 

MINORIの話は、技術者向けには物足りないというカスタマーレビューもありますが、どういう風に考えて作ったかというようなことは書かれています。

 

私はIT技術者ではないので、技術部分はさほど理解しておらず、システム的な良し悪しも判断できませんが、以下のようなことは解かりました。

 

 

 

・今までの旧システムをつないだのと違って、一から新しく作り直して、そこにデータを移行した。
 

・SOA(サービス志向アーキテクチャ)という設計思想を全面採用した。

 

・システム変更の際の影響が広範囲に及ばないような造りに工夫した(コンポーネント化と言うのでしょうか?)。

 

・大量バッチ処理していた方式をやめた(オンライン方式に変更)。

 

・使用するメインフレームの数がグループ全体で19台だったのを4台に減らした。

 

・属人化を避けるためにプログラムの手書きを禁止し、超高速開発ツールでのコード生成に統一した。

 

・グループ会社内でまちまちだった用語を統一した。

 

・利用部門も参加させて要件定義を全部整理し直した。

 

・プロジェクトマネージャーが組織を横断的に見るようにした。

 

 

 

 

当時のプロジェクトの取りまとめ役は、みずほ情報総研。

 

第一部第3章に出ている絵図によると、主要ベンダーは、富士通、日立製作所、日本IBM、NTTデータの4社。

 

アプリケーション開発はDTSなど5社。個別担当案件ベンダーというのが、日鉄ソリューションズ、SCSK、CTCなど7社。

 

その他ベンダーが50~60社で、合計した1次委託先が70~80社。

 

IT業界というのは分業な上に、下請け・孫請けがありますが、その2次、3次委託先が900社超。

 

約1000社が参加した大プロジェクト。

 

 

 

日本 札束 PC