「みずほ銀行システム統合、苦闘の19年史」という本を読んでみた。
私はwebエンジニアなので、銀行のシステム開発については全く知識が無い。
本書は3部構成になっている。
まず、2011年6月に開始して、2019年7月に完成した新しい勘定系システム「MINORI」について。
最後は、2002年の3銀行統合の際のシステム移行で発生した大規模障害についてだ。
MINORIは35万人月、4,000億円という日本の歴史に残る大規模プロジェクトになる。
私は自社開発のweb企業で働いているが、web企業では10数人月もあれば中々の大規模プロジェクトになる。そこから考えると全く想像がつかないスケールだ。
MINORIはリリースまでに、公表したスケジュールを何度か延期している。それにより、IT業界関係者の間では「IT業界のサクラダファミリアと言われていた」、と書かれていたのには笑ってしまった。
SOAの採用
近年web界隈ではマイクロサービスアーキテクチャーが注目されているので、若い人の場合、こちらの方を聞いたことがあるという人の方が多いと思う。
モノリシックな一枚板の大規模システムではなく、機能をサービス単位に分割して疎結合にし、開発やテスト、デプロイを加速させる手法になる。
ちなみにマイクロサービスパターンいう本を読んだことがある。5千円するのでまあまあ高いが、内容は濃く読む価値のある良書だと思う。
マイクロサービスパターン［実践的システムデザインのためのコード解説］ impress top gearシリーズ
- 作者:Chris Richardson,長尾高弘,樽澤広亨
- 発売日: 2020/03/23
- メディア: Kindle版
MINORIに話を戻そう。
また、SOAにしたことで外部と接続がしやすくなり、事業展開の可能性を広げることにも繋がっている。今後、FinTech事業者と連携をしていくらしい。
こういう内容を見て、レガシーな印象があった銀行のシステムについて少し見方が変わった。
要件定義
要件定義について「ユーザー部門主体で要件定義をやり直した」ところが素晴らしい。
方法として、JBCCの上流工程支援ツール「Xupper」というものを使った。
本来エンジニアが設計に使うツールだが、それをユーザー部門に使わせたという。
旧システムの要件や現状の業務フローを踏襲する「AS IS」の考え方でこのツールを使うと、行き詰まるようになっているらしい。
これにより「AS IS」の要件定義を全面的に禁止することが出来る。
これはCIOの判断だという。
属人性の排除
「超高速開発ツール」を採用し、生のコードを書かせないようにした。これによりコーディングレベルの統制や、工数の削減が出来るらしい。ローコードの一種なのだろうか。
例えば、富士通の「Interdevelop Designer」の場合、業務ルールや数式を日本語で記述すると、コードとテストコードを自動作成してくれるそう。
私はこういったツールは使ったことはないが少し興味がある。
昔に発生した大規模障害
2011年の東日本大震災と、2002年の合併の際に発生した大規模障害の部分は、webエンジニアにとってはあまり縁が無い話かも知れない。
経営陣が「経営における最優先事項はITである」と言っておきながらCIOやCTOを設けなかったり、障害発生時の適切な指示系統が出来ていなかったことが障害の根本的な原因だと、著者は指摘している。私もその通りだと思う。
銀行はビジネスが先にあり技術は後から生まれたが、webは技術があったからビジネスが生まれた、という点が異なる。
そのため、web企業の場合は銀行で起こったような事象は発生しづらい。
今後色々な業界がITを経営の最優先事項として実践していく未来が出来ることは、エンジニアにとって嬉しいことだとは思う。
その他
どんな読者をターゲットにした本なのか、よく分からない部分はある。
経営者に向けての「ITを軽視するな」という警鐘としては弱いし、そもそもビジネス書にはカテゴライズされないため、彼らの目にとまること自体も少ないかも知れない。
本書において、みずほの経営陣ははっきりと自分たちのIT軽視が失敗だったとは認めていなく、企業体勢を改善出来た過程についても詳細には書かれていない。
ここが具体的に書かれているのであれば、DXを推進するCDO(最高データ責任者)などに向けて内容にはなったと思う。
また、エンジニアが知識を得る目的としてはやはり具体性に欠ける。
MINORIの開発や大規模障害について、現場のエンジニアの声は具体的に書かれていない。特に障害対応については、現場の鬼気迫る臨場感が全く伝わってこないのが残念だ。
また、IT業界の多重下請け構造の闇を描いた本でもない。
なので、どんな人におすすめ出来るのかという判断が難しい本ではある。
