目次

10月10日の悲劇を振り返る

経緯を振り返る

原因をもっと振り返る

再発防止策を斜めに見る

なぜ「いろいろなこと」が遅いのか？

金融業界はスーツ満開

10月10日の悲劇を振り返る

前回（2023年12月）のコラムでは、あの「全銀トラブル」について語りました。
　第参拾六夜　全銀システムトラブルで悩む管理者の夜
それから、約3ヶ月以上経過して、続編というか裏版を書くことになりました。

振り返りますと、2023年10月10日に発生した全銀システム（正式名称　全国銀行データ通信システム）のトラブル。ちょうど半期過ぎたところでのトラブル。各所にかなりの影響を与えたはずなのですが、、、あまり騒がれなかったですね。影響が低かったというより、マスコミ対策がしっかりしているためだと思います。そして、諸々あって、2023年12月1日に、全国銀行資金決済ネットワーク及びNTTデータから「全国銀行データ通信システムの障害について」という報告書を公開しています。

https://www.zengin-net.jp/announcement/pdf/announcement_20231201.pdf

以下では、この報告書などをベースにしつつ、あの事件を振り返りたいと思います。

<図表37-1 発生事案>

経緯を振り返る

経緯については、前回のコラムで時系列で説明しています。元ネタは日経コンピュータ誌ですが、今回の報告書を基に修正/追記いたしました。

上記のタイムテーブルを見ますと、まず【暫定対処1】で対処しようと修正を始めたが、修正に時間がかかったり、その他の問題が発生したため、【暫定対処2】で対応したことがわかります。システムトラブルの対処について、現場が試行錯誤して苦労したことがよくわかります。そう、一発で修正案が立案され、解決に向かうことなどありません。時間や外的プレッシャーなどに襲われながら、エンジニアたちは進んでいるのです。
そして、一律0円対応である【暫定対処2】ですが、このような対処は辛い。泣きたくなるような対策です。結構ドキドキしながら、決意したと思います。会議でもかなり紛糾したはず。この「こんな対処をしたくないけど、仕方ない」という断腸の思いはひしひしと感じます。

原因をもっと振り返る

上記の経緯にも書かれていますが、報告書には「内国為替制度運営費情報を取得する前段でアクセスする共有メモリ上のインデックステーブルにある加盟金融機関の値の一部が破損したことによるものです。この結果、RC23 シリーズ内のプログラムが内国為替制度運営費付加・チェック処理を実施する際に、インデックステーブルから正常な値を取得できず異常終了してしまい、RC 本体装置のシステムダウンに繋がりました。
」とあります。さらに、「このインデックステーブルは RC 起動時にロードファイル6から展開されますが、ロードファイルを生成するプログラムのテーブル作成処理の不具合（一時的に確保する領域が不足）により、ロードファイルの内容が破損」です。
簡単に言いますと、マスターテーブルのメモリー展開をしたかったが、その領域のメモリー不足が発生したためです。今回のRC17からRC23への移行に際し、OSのバージョンアップ(*1)があり、テーブルのサイズ拡張が必要でした。また、テーブルは4つ使用するのに、作業領域の拡張をしたのは1つのみ。あきらかに、エンジニアリングの段階でのミスになります。よくある「有識者によるレビュー」(*2)も行ったらしいですが、そこでもすり抜けが発生し、見逃したらしいです。

再発防止策を斜めに見る

再発防止案ですが、NTTデータと全銀ネットで分けて記載されています。まずは、開発を担当したNTTデータの再発防止です。

2-2.の実取引相当データを利用した試験とか、既にやっているはずですし、もしやっていないとしたら大問題。また3-1のガイドラインや3-2の訓練もやっているはず。そもそも東日本大震災（2011年3月）、その前の阪神・淡路大震災（1995年1月）などでしっかりとガイドラインは策定してあるはず。それでも動けない要員/要因が問題です。つまり、本音は「こんなことはなんとなくやるべきだと思っていたけど、反省してこれからはしっかりやっていきます」宣言です。でも、たぶん、きっと数年後には喉熱(*3)で、形骸化しちゃうんでしょうけど。

そして、次に全銀ネットの再発防止策です。

文章が長いです。さらに、1.2.3.については対策期限が2024年3月です。4.は期限が4月のものと4月以降のものがあります。しかし、【裏版】なのであえて言いますが、職員は派遣さんや外注も多いでしょうし、どうやって習得させるのでしょうか？　さらに4-3は第三者評価です。この第三者が絡むチェックやら監査やらは面倒です。どこかで、コラムのテーマにしたいネタでもあります。4-1はシステム人材の強化なのですが、どの会社でも不足しているんですよね。どうやって引っ張ってくるんでしょう。それにここに勤務したいエンジニアって、、、マゾ？

しかし、毎回この手の再発防止を見て思うのですが、要するに「やるべきこと/やったほうがよいこと」を「やらなかった」ために発生した事案がほとんどです。さらにヒューマンミスは確実に発生しますし、プライオリティを上げる項目をピックアップすれば、選ばれなかった項目が下がってしまいます。それらが起因で新しい障害が発生し、追加の再発防止案が策定され、現在の再発防止策がランクダウンします。そして、もし、新たな障害が発生しない場合、安堵感から、もしくはコストカットの外圧から、形骸化したり、有名無実化します、そう「みずほ」のように。

なぜ「いろいろなこと」が遅いのか？

さて、今回のシステムトラブルですが、発生したのが10月10日で、10月13日に天下の金融庁から「資金決済に関する法律第80条第１項にもとづく報告徴求命令」を受領(*5)。それに対応したこの報告書を12月に公表。そして、12月18日には、改めて「資金決済に関する法律第80条第１項にもとづく報告徴求命令」を受けました。

　　10月13日の報告徴求命令について
　　12月18日の報告徴求命令について

金融業界では金融庁が絶対で、金融庁のご機嫌や顔色をうかがいながら、アクションを起こします。それを鑑みると主観的な感想ですが、事前に某省庁のコメントを受けただろうなと思われる報告資料っぽくなっています。そのような監督官庁やら、外部の圧力団体が関係するシステムや業務って、かなり面倒ですし、非スピーディー(*6)です。また、いつもブラックボックス化していますし、プロセスも不透明な気がします。うん、この業界は花咲舞やら半沢直樹(*7)がキレる業界ですからね。

金融業界はスーツ満開

今回は「全銀システムトラブル」について語りました。公開された報告書は、やっぱり「公開された」報告書であり見えていない事実もたくさんありそうです。金融庁絡みはシロでもクロでもないグレーな世界(*8)で面倒です。パンダさんを見習ってほしいです。そして金融業界の自称エンジニア、いつもグレーなスーツなんですよね（謎）。スーツに萌える方、スーツフェチは金融関連、そして全銀のエンジニアを目指しても良いかもしれない。人材募集中なのです。

では良き眠りを（合掌）。

2024年4月下旬　追記

全銀ネットが3月11日に開催された「有識者会議」の議事等を公開。次期全銀システム開発プロジェクトの概要なども説明されました。それによると、次期システム開発の立ち上げは延伸、再発防止案を盛り込んで再計画の立案。さらにアジャイルエリアなどというものも追加されています。
https://www.zengin-net.jp/zengin_net/epm_tf/index.html#n1
金融系はなにかあるとすぐ延伸ですよね。仕方がないことでもありますが。スケジュールを再確認してみますと、2027年にサービス開始っぽかったのですが、そのころまでにはさらに新技術/新基盤、そして新開発手法が出ていると思います。でもそれが金融。

「お前が寝る前にベッドで無駄にスマホを見て過ごした十分は明朝お前が死ぬほど寝たかった十分」by明光寺の掲示板（？）