みずほ銀行のシステム障害特別調査委員会報告書を読んで
おはよう人類。
2月28日のみずほ銀行のシステム障害を発端として、3月に計3回、その後も8月に3回のシステム障害が発生し世間を騒がせている。メガバンクの中でも最新かつ先進的なシステムを採用し、しかも本格稼働してすでに2年以上たっているシステムで、なぜこのような障害が連続するのか、なかなか理解しがたいものがある。
このうち、2月28日の第1回目障害から3月中に発生した計4回の障害については、6月15日に外部の有識者によって構成されたシステム障害特別調査委員会による報告書が発表されている。本文は167ページに渡るボリュームなのだが、結構内容に目を通している方も多く、TwitterやBlog、Yotubeなどでも報告書の解説を試みている方もおられる(あまり目を通してはいないが)。
みずほFGの全面的なバックアップがあったとはいえ、限られた時間でこれだけの内容をまとめ上げるのも大変だったと思うし、少なくとも4回の障害がどのような原因で発生し、それに銀行は組織としてどう対応したかという状況は把握できるので、資料的な価値は高いと思う。他方で、弊猫はこの報告書、一読したところで事件や事故の調査報告としては決定的に欠けている何かがあると感じていた。
端的に言えば、この報告書には(1)基礎勘定系システムMINNORIの設計の妥当性、(2)発生した障害の要因分析、(3)上記2つから導かれる中長期的な経営的な対応提言がとても薄いと感じている。薄いというよりも、歯切れの悪さのようなものだ。
MINORIの設計妥当性について
MINORIは、2011年に発生した旧みずほ銀行(MHBK)における大規模オンライン障害を契機に、2013年に合併したみずほコーポレート銀行(MHCB)と、現在も存在するみずほ信託銀行(MHTB)がそれぞれ個別に運用していた勘定系システムを統合したもので、統合に際して様々な新機軸が盛り込まれている。
報告書の中に、MINORIの設計思想について触れられている部分があった(27項)。設計思想というのは、ITシステムに限らず何らかの製品を設計する際に、企画の基礎となる基本構想に近いものだと思っている。基本構想から、具体的なシステムの企画に進み、基本要件、フィットアンドギャップ分析、基本設計(要件定義)、詳細設計、実装、テストと進んでいくので、基本構想はその発端となる(後工程で問題が発生すれば立ち戻るべき根本的な考え方)のでとても大切な部分だ。
これを読むと、かなりコンセプトが混乱しているように思える。好意的な表現をしたとしても総花的と言えて、まぁよくもまぁここまで様々な要件を詰め込んだものだと感心する。まず、2011年のシステム障害の反省からシステムの安定化という点に関しては最後の6番が入っているが、その他に関して言えば6番と同列の優先順位に入れていいものか、とても疑問に思えてしまう。
これを実現したのがMINORIであるが、出来上がったシステムには整理すると三つの目的があると思われる。一つはシステム刷新による安定稼働、二つ目がシステム統合、三つ目がBPR(Business Process Re-engineering)だ。安定稼働のためにはシステムの全面刷新が必要で、どうせ刷新するならば似た機能を持つグループ内の他の二つのシステムも統合する方が良い、また統合するならビジネスプロセスの合理化を行う必要がある、という理屈なのだろう。
ただし、この三つは一つ一つがとても重い仕事であるし、かつ同時に進めるにはとてもリスクが高い仕事となる。また、費用も構築期間もかかってしまうので、技術的にカバーするためにSOAアーキテクチャが取り入れられている。
SOAの話をする前に、そもそも統合対象となった三つのシステムはどのようなものだったのかを見ていきたい。2011年にトラブルを発生させたMHBKのシステムはSTEPSと呼ばれていて、元々第一勧業銀行(DKB)が開発したシステムとなる。主に、マスリテール顧客(個人事業主や中小企業、個人顧客が対象)としたもので三つのシステムの中では最も規模が大きい。もう一つのMHCBのシステムはC-Baseと呼ばれていて、主に公共法人や大企業などを対象とするホールセール向けのシステムで、口座数は少ないが処理量はSTEPSほどではなくても大きい。こちらは、旧日本興業銀行が開発したITISを根本から作り替えたもので、ITISを担当した日立がプライマリベンダーとなっているが、C-baseはITISとは全く別モノに近いシステムに作り替えられている(旧3行のシステム統合で最も費用が掛かっている)。三つ目がMHTBのBESTで、信託業務を扱うため銀行勘定系としては規模は三つの中では最も小さいが、複雑な信託業務を扱うため信託系システムの規模が大きい。こちらは変異があるものの、基本的には旧安田信託銀行で開発されたシステムがほぼそのまま使われている。
以上の三つのシステムを機能別に並べてみたのが上の表だ(本猫作成)。〇と●で書かれているものが機能を有しているもので、三つのシステムではほとんどの項目が重なっている。言い換えると、似たような機能があるのにシステムが分かれていることによって二重に開発しているものが多い(無駄)と言える。
そこで、似たような機能を持っているシステムを統合して、システム間に持っている機能をすべて実装してしまうのではなく、共通化を図って再利用性を高めよう、というのが広義の(そして基本的な)SOAの考え方だ。そして、複数ある広義のSOAの実現方法の一つとして、狭義のSOAとしてMINORIに採用された手法が、サービス化による疎結合化と分散トランザクション化である。
先ほど挙げた機能は、旧システムでは単一のシステム上に統合されたデータベースとアプリケーションによって実装されたモノリシックなシステムだ。これに対して、機能をサービスという単位に分割した上でそれぞれのサービス内に必要な機能が完結するように再構成し、サービス間は標準化された電文によって統合されてる。これが疎結合化で、トランザクションは複数のシステム間を通るために、このトランザクションの制御と疎結合化されたシステムを結ぶシステムとして、取引共通システムという中核部分が存在する。
基本的に、この取引表通システムがOSで言えばKernelのような役割を果たしていて、オンライン処理だけでなくバッチ処理やセンターカットのような処理も同じプログラムを使ってリアルタイムに処理するというのがMINORIの特徴だ。一見してとても複雑なシステムに見えるが、システムの再利用性が高まっている点と、オンラインとバッチでプログラムの共通化が図られたことで開発工数もかなり減っていると思う。
ただ、ゼロベースでシステム開発されたとはいえ、実際のサービスの設計にあたっては何か規準になるシステムが必要になる。先の機能別の表で●で示したものが、おそらく基準となるシステムとして参照された機能になると思われる(弊猫推定)。これを見ると、マスリテールや預金などの基本部分はSTEPSから、与信・融資・外為などの機能はC-Baseから、信託はBESTの機能をそのまま実現している。
こうしてみると、MINORIは一見して各論でみれば合理的なシステムのように見えるのだが、総論で見るとシステム刷新・統合のスコープ(範囲)がとても大きく、採用されている技術的実装手法についても、これまでみずほFGが構築してきたシステムにはない新機軸が取り込まれていることがわかると思う。実際に構築が難航し、費用も期間も大幅にオーバーしてしまったのは、システムの基本要件が非常に混乱したものだったからだと言えないだろうか？ そして、それ次に述べる品質問題にもつながってくる。
MINORIで起きた一連の障害分析の妥当性
報告書の方に戻ろう。
167ページもの超大作である本報告書であるが、1回目から4回目の障害の発生原因とその対処の説明に116ページ費やされている。また、2021年以前に発生した障害事例の共通項について分析を試みている部分もあり、過去の障害を受けた改善が反映されていない点を厳しく指摘しているという点で評価されるべきものだと思う。
しかし、この報告書、なぜ2月から3月にかけて重大な障害が連続して起きていて、その後の8月にも障害が発生してるのかという点に答えられていない。多くの人が抱いているであろう、共通した障害の要因があるのではないかという疑念に対しての分析が示されていない。
実は要旨版側ではなく、概要版(9-10頁)にはただ一文「Minoriを中心とするITシステムのメカニズム面において共通する原因を認めない」という文章があるが、この結論に至った分析が要旨版には見当たらない。限られた時間で報告をまとめなければならないという制約の大きさがあるにせよ、経営やIT統制にまで踏み込んだ提言を行っているのに、実際に発生した障害の分析が欠けているというのはどうも腑に落ちない。
ここで、当猫が各障害について詳細に検証していくことも可能であろうが、すでに本稿は非常に長大になっているのであまり適切ではないと思う。そこで、本報告が対象とする3月までの5回目障害までのシステムの影響範囲に加えて、8月までに発生した7回目の障害の影響範囲を、影響したシステム別に当猫がまとめたのが下記の表である。
表の縦で示したものが、MINORIの基本構成ブロックで、●で示したものが影響があった部分、◎が障害の原因となった部分だ。色分けの意味は青と緑がMINORIの構成ブロックで、このうち青が取引共通システムと呼ばれるMINORIの中核部分、緑色の部分がSOAアーキテクチャによりサービスとして分離されたシステム部分、オレンジ色がMINORIの外のシステムになるがチャネル系と呼ばれる、実際にMINORIを使って取引を行う営業店やATMといったフロントエンド部分を示している。
こうしてみると、障害の発生個所自体には共通性がないように思えるが、ほとんどの障害で複数の機能ブロックの間をまたいで発生していることがわかる。また上の表で表現しきれていないのだが、障害の発端となったブロックや故障が別のシステムに影響を与えるという障害が多く、特にサービスに分離されたブロックで発生した障害が、他の業務に影響しているパターンが目立つ。また、ATMに影響を与える障害は、即カードを取り込み顧客に影響を与える対外的・対顧影響度が高い障害になっている。
また、障害の発端を見てみると、第1回目と第2回目がソフトウェアに関する障害が発端になっているが、その他の障害についてはハードウェア障害を発端とする障害になっている点についても特徴性がある。とりわけ、緑またはオレンジで示した部分は、メインフレームやESSを使っていない部分で、信頼性が低い分、安いシステムを使って多重化・分散化・並列化を図って信頼性を担保すべきところだ。実際にそういった設計になっていたのか疑念が生じる。
そして、各障害が影響を受けている部分が多岐にわたっている点自体が、それぞれの機能ブロックの品質レベルが低く、テストされていないと思わざるを得ない。特に、第1回目の障害については、報道や報告書を読んだ方の指摘レベルでは、発端となった定期性預金システムDBの取消情報テーブルのINDEX超過に対する指摘が多いのだが、報告書を詳細に読んでみると、エラー発生時に適切なエラーハンドリングがなされていないため、トランザクションのロールバック動作に失敗する二重エラーを発生させるようなバグに関する記述がある。MINORIのような分散トランザクションシステムでは致命的な障害だ。
ざっと報告書を眺めただけでも、こういった共通点と思われる部分はあるし、調査委員会としても検討すべき項目であったはずだ。これが欠けているならば、そもそもこの報告における提言の根拠はどこにあるのだろうか？ 問題があると言わざるを得ない。
中長期的な提言の欠如
以上二つの問題を踏まえた上で、結論部分と経営への提言部分となるのだが、その内容は大きく分けると(1)システム面での対応、(2)危機管理体制、(3)企業風土の改革が盛り込まれている。
しかし、この三つの提言よく見ると、4月5日にみずほFGが発表したシステム障害にかかる対応状況に記載されている内容に沿ったもので、おそらくは金融庁への報告に沿った内容ではないかと本猫は考える。内容の精密さとか、ボリュームが違うという程度の違いで、大きな逸脱や第三者機関による独自の視点といったものは特にない。
特に、システム側面での提言では、5項目挙げられている提言のうち、(a)顧客への影響が大きかったATMの通帳・カード取込仕様の変更、(b)運用監視体制の改善、(c)MINORIシステムの総点検の実施といった、障害を受けての直接要因に関係する対応策で、当然行うべき短期的に対処すべき問題への対応である。また、(d)障害対応訓練の高度化、(e)人材や組織の対応といった長期的な課題についての記載はあるが、中期的にMINORIだけでなくITシステム全体で取り組むべき方向性についての記載がないのだ。
これは、一連の障害に対する原因の深掘りがないためどうしてもかけてしまう点になってしまっている。システム品質を、銀行としてどう担保するかは目下の預金者・取引先の重大な関心事であり、その方向に向けた具体策が必要なはずだ。
現に、8月中に新たに3回の障害が発生しているが、提言にも取り込まれている短期的に対処すべき項目(a～c)に入っているはずの項目で再び障害が発生している。システム品質を担保する定量的なアプローチと、具体的なアクションプランがないため、今後も類似の障害が繰り返される可能性すらある。
ここで、立ち返ってみるべき点は、システムの設計基本構想と現状とのギャップである。現在重視されるべき点は、6番の安定性と堅確性の確保であるはずで、長期的な対応策に沿う形の行動の具体化が必要だ。
そういった意味で、本報告書は発生した事象への理解を深める内容にはなっているものの、第三者報告書としては片手落ちではないかという気がしてならない。過去3回にわたって繰り返された大規模システム障害の教訓が、このまま生かされないまま次の障害を迎えたとなれば、あまりに従業員、預金者、取引先、投資家が報われない話になってしまうだろう。
この記事が気に入ったらサポートをしてみませんか？