全6547文字
PR

 システムは人が開発・運用するものなのだから、ソフトウエアのバグやハードウエアの故障、オペレーションミスなどは避けられない。しかしみずほ銀行が2021年2~3月に起こしたシステム障害の詳細をひもとくと、通常の組織では起こりえないような問題が多数発生したことによって、小さなトラブルを起点とするシステム障害が、顧客に大きな影響を与えていたことが分かった。

 4件のシステム障害は、いずれも2019年7月に本格稼働した勘定系システム「MINORI」で発生した。

 2021年2月28日にはMINORIの「定期性預金システム」でデータベース(DB)が更新不能になったことをきっかけに、ピーク時には自行ATMの7割超に相当する4318台が一時停止し、ATMが通帳やキャッシュカードを取り込むトラブルが5244件発生した。

 3月3日にはMINORIのデータセンターにあるネットワーク機器の故障がきっかけで通信が不安定になり、ATMが通帳やカードを取り込むトラブルが29件発生した。3月7日にはカードローン商品に関するプログラムのバグによって、定期性預金口座へ入金するバッチ処理(集中記帳処理)でエラーが発生し、24件の入金が不成立になった。

 3月11~12日にはストレージ装置内の通信制御装置が故障したことによって、外貨建て送金などに関する夜間バッチ処理が遅れた結果、国内他行向け仕向送金263件が当日中の期限に間に合わなかったほか、外為被仕向送金の入金案内処理761件が当日中に完了できなかった。

10年前、20年前の反省を生かせず

 4件のシステム障害はいずれも、システムの設定に関する見落としやプログラムのバグ、ハードの故障といった避けがたい小さなトラブルが起点となっている。しかしみずほフィナンシャルグループ(FG)が設置した「システム障害特別調査委員会(第三者委員会)」の報告書を精査すると、預金・融資・決済という社会インフラを担う金融機関ではあり得ないような問題が35件存在していたことが分かった。

 みずほ銀行は2002年、2011年にも大規模なシステム障害を起こしている。大規模障害を反省し、勘定系システムを全面刷新したにも関わらず、組織的な問題点は解消できないままだった。第三者委員会は「過去指摘された問題が依然存続していると考えられる」と厳しく指摘する。今回のシステム障害を時系列で振り返りながら、35の問題点を明らかにしていこう。

みずほ銀行で2021年2月28日に起きたシステム障害の主な経緯(その1)
(出所:第三者委員会の調査報告書などを基に日経クロステック作成、以下同)
日付時間状況
2017年11月16日新勘定系システム「MINORI」の定期性預金システムにおいて「取消情報管理テーブル」のインデックスファイルをディスクではなくメインメモリーに保存する仕様に変更すると決定。インデックスファイルに関する厳格なキャパシティー管理の必要性を運用担当は認識せず1
2018年6月18日MINORIの移行リハーサルにおいて、製品の既存バグの顕在化などをきっかけに、ATMがカードや通帳を取り込むトラブルが1821件発生。改善策が必要な恒常的な問題と認識せず2
2019年7月16日MINORIが全面稼働
12月15日MINORI共通基盤のハードウエア故障に伴い、ATMがカードや通帳を取り込むトラブルが187件発生。ここでも、ATM仕様の変更を検討せず、経営陣に対する報告もなかった3
2021年1月17日通帳を発行しない「みずほe-口座」の取り扱い開始に向けてMINORIの一部機能を改修。印紙税の納付額を削減するため、スケジュールありき(2021年3月中)でデータ移行計画を策定4
2月27日までe-口座への「一括切替処理」のシステムテストにおいて、インデックスファイルを「メモリ常駐」にしたことに伴うリスクを検出できず5
2月27日までe-口座への一括切替処理の間は、通常時に監視業務を担うMIデジタルサービス(MIDS)ではなく、みずほリサーチ&テクノロジーズ(MHRT、当時はみずほ情報総研)がエラー監視を担うことに。しかしMHRTにはエラー監視をする体制が整っていなかった6
2月27日e-口座への一括切替処理の1回目を実行。取消情報管理テーブルのインデックスファイルの使用率はしきい値(80%)を超える87%に。MHRTがアラートを見逃す7
2月28日8:242回目のe-口座への一括切替処理などセンター集中記帳処理を開始

 まずは2月28日に発生した、ATM4318台の停止を招いたシステム障害の問題点だ。発端となった定期性預金システムにおけるDBトラブルの原因は、MINORIの開発中だった2017年11月16日に埋め込まれた。

 この時みずほ銀行は、同システムのDBに存在する「取消情報管理テーブル」のインデックスファイルを、ディスクではなくメインメモリーに保存する仕様変更を行った。これによって同インデックスファイルについて厳格な容量管理が必要になったが、運用担当にその認識は無かった(問題点1)。

 2月28日のシステム障害では、MINORIに何かエラーがあると、ATMが問答無用で通帳やカードを取り込んでしまう仕様が問題を大きくした。もし通帳やカードはすぐに返すという他行では当たり前の仕様になっていれば、大規模障害には至らなかった。

 しかしみずほ銀行は、MINORIの移行リハーサル中だった2018年6月18日にATMがカードや通帳を取り込むトラブルを1821件も起こしたが、それを対外公表せず、改善策が必要な恒常的な問題とも認識しなかった(問題点2)。MINORI稼働後の2019年12月15日にも同様のトラブルが187件起きていたが、ここでもATM仕様の変更を検討せず、経営陣へも報告しなかった(問題点3)。

 みずほ銀行は2021年1月、通帳を発行しない「みずほe-口座」の取り扱いに向けたシステム改修を行った。そして2021年3月末までに、直近1年以上記帳が無い口座をe-口座に移すことを決定した。紙の通帳を発行する口座を減らすことで、印紙税を年間約16億円削減できると見込んだからだ(問題点4)。

 e-口座に切り替える定期性預金口座は約259万件。システム上の制限から45万件ずつ6回に分け、2月27日から3月14日までの土日にe-口座一括切替処理を実施することに決めた。この一括切替処理のシステムテストに際しては、実機での処理は8万件までしか試さず、DBの仕様にリスクがあることを検出できなかった(問題点5)。

 また一括切替処理の間は、通常時に監視業務を担うMIデジタルサービス(MIDS)ではなく、みずほリサーチ&テクノロジーズ(MHRT、当時はみずほ情報総研)がエラー監視を担う体制とした。ところがMHRTには、エラー監視をする体制が整っていなかった(問題点6)。

 2月27日にe-口座への一括切替処理の第1回を実施したところ、トラブルの兆候が出た。取消情報管理テーブルのインデックスファイル使用率がしきい値(80%)を超え87%に達したのだ。しかしMHRTはそれを見逃した(問題点7)。