みずほ銀行の勘定系システムの全容と過去と未来
2002年4月と2011年3月に2度の大きなシステム障害を起こしたみずほ銀行。3度目を起こさないために銀行システムのど真ん中である勘定系システムを刷新しました。本書は構築した勘定系システムがどのようなものなのか、銀行統合の歴史と共に刷新前のシステム構成も含めて記載されています。3度目はない、という覚悟を持って刷新したものの、2021年2月-3月の期間に再度大きなシステム障害（ATM、定期預金、インターネットバンキング、外為）を起こしてしまいました。2021年の障害については3月末期限の金融庁への報告書に詳細が記載されると思います。本書は2019年7月に移行完了した（開発完了は2017年7月）情報システム開発プロジェクトの内容と2002年4月と2011年3月の障害の振り返りをしています。タイトルにある通り、みずほ銀行の情報システムに対する「苦闘」がわかるものになっています。
本書は、開発完了時期を2度延期したため、IT業界のサクラダファミリアと呼ばれたみずほ銀行の勘定系システム開発の軌跡がわかる一冊になっています。そのため、特に同業界に勤めている方、もしくはシステムに関する一定の知識を持っている人が想定読者になっています。ただ、システムを知らない方でも第2部・第3部にある過去の障害時に関する内容は何が起こったかがわかりやすく書かれているため、事象を理解できると思います。
みずほ銀行の新勘定系システム（以降、MINORI）は既存システムを流用するのではなく、一から作成されたものです。そのため、2011年6月に着手してから移行完了まで8年の歳月を費やしています。ただ、勘定系システム刷新の構想はみずほ銀行の誕生（1999年に旧3行による経営統合発表）当時からあったため、19年越しの悲願ということになります。一からの作成ということで金額も4,000億円（スカイツリー7本分）を投じ、開発工数も35万人月というとんでもない数字になっています。本書はMINORIの中身とこの大規模プロジェクトがどのように進められたかが書かれています。
本書が描くのは、みずほFGにおけるシステムの刷新と統合に関わる「苦闘」の十九年史である。
はじめに
システム開発プロジェクトに何度も失敗し、二度の大規模システム障害を引き起こしたみずほFGが、どのようにして社内を立て直して、巨大システム開発プロジェクトを成功に導くまでに「成長」したのか。そこにあらゆる企業にとっての学びがあると考えているからだ。
（中略）
経済産業省は二〇二五年になると、二十一年以上稼働し続けている基幹系システムの比率が六十％を超えるのではないかと警戒を強めている。経産省は二〇一八年五月に発表したリポートでこの問題を「二〇二五年の崖」と名付け、システムの老朽化によるリスクの高まりに伴う経済損失が年間十二兆円にも達する恐れがあると警告した。
二〇二五年の崖から落ちないために、企業は老朽化した基幹系システムにどう向き合って、問題を解決していけばいいのか。本書が紹介するみずほFGの歩みが参考になるはずだ。
本書の著者は日経コンピュータ編集部です。そのため、各方面での取材を通じて書かれたものになっています。上記引用にあるとおり、本書に書かれている内容は決してみずほFGだけに起きる話ではありません。経産省レポートにあるとおり構築後20年以上経過している基幹システムを保有する企業は多くあります。それだけの年数が経っていると、中身を正しく把握している人も限られていますし、どのような経緯で現在の姿になっているかわからないことも多くなります。
そうなると本書で書かれているみずほFGの事例のように、動かなくなるリスクを考慮し刷新を先送りにしてしまいます。先送りにしても問題が解決するわけではなく、ビジネス市場の変化への対応ができなくなるなどのデメリットが多く出てきます。
属人性を徹底的に排除
第一部 第3章 参加ベンダー千社 驚愕のプロジェクト管理
ピーク時で八千人ものエンジニアが参加した開発プロジェクトだ。コード記述の統制がとれていないと、後々の保守性が下がる。そこでみずほFGはコードを自動生成する「超高速開発ツール」を全面的に採用した。生のコードを書かせなくすることで属人性を排除した。
超高速開発ツールの採用はコーディングの統制に加えて、開発工程の省力化にも役に立った。
MINORIの開発には「超高速開発ツール」というコード自動生成ツールが利用されました。生コードを書かないことで開発者ごとのブレ（属人性）を排除することを目的としています。
私の個人的な意見を書かせてもらうと、コード自動生成ツールで属人性を排除するのは無理だと思います。IT業界で20年程度開発を経験していて、何回か自動生成ツールを利用したことがありますが、だいたいうまくいきません。理由は様々ですが、属人性という観点で言うとツールのインプットとなる設計書に属人性が出てしまいます。プログラミングの属人性の排除は可能かもしれませんが、設計書に属人性が必ず残ります。保守・運用の観点からもその設計書をメンテナンスし続けるのは大変です。
みずほFGがどのような評価をしてコード自動生成ツールを導入したのかは非常に興味があるので、どこかでレポートされることを期待します。
五年で七百二十億円のITコスト削減
第一部 第5章 次の課題はデジタル変革
MINORIの導入効果として現時点ではっきりと見えているのはコスト削減だ。システム装置産業とされる金融機関にとって、情報システムに関するコスト負担は頭の痛い問題である。
（中略）
みずほFGはMINORIの導入によって、今後アプリケーションの開発コストを三割程度削減できると見込む。SOA（サービス指向アーキテクチャー）を採用したMINORIは、システム構造が疎結合になったことで、金融系のシステム開発で最もコストがかかるテストの対象範囲を限定できるようになった。テストにかかる工数を大幅に削減できることから、全体で三割のコスト削減につながるわけだ。
MINORIを一から構築したことで、アーキテクチャも全面的に変更することができました。その効果としてテスト工数の削減をあげています。銀行の勘定系システムのような大きなドメインを複数に分割し、互いの凝集度を下げる、それをすることでテスト範囲を限定することが可能になります。今後はFintechベンチャーなどからアクセス可能なようにAPI基盤を整備していくそうです。
本書は購入してから1年くらいずっと積読状態だったのですが、2021年2月の障害を機に読んでみました。本書には過去2回（2002年と2011年）の大規模障害を受けてどれだけ慎重にMINORIの開発を進めたのかが書かれています。開発完了後、1年以上を掛けて行った移行作業についても様々な事象を想定した訓練を行い、各店舗での研修についても全社をあげて取り組んでいることが書かれています。慎重に慎重を重ねてMINORIを構築したみずほFGですが、その後の運用で大規模障害を起こしてしまいました。どのような経緯があったのか、その原因究明が待たれます。
コメント