「全銀システム障害」とは何だったのか　解明まで時間がかかった理由と、待ち構える“茨の道”とは（4/5 ページ）

レガシーとの“決別”は進行中

　今回の移行（レベルアップ）作業で問題となるのは2点ほど。1つはRC23におけるプログラムの品質が十分に保たれておらず、それが問題を引き起こしてしまったこと。2つ目は切り戻しの判断や、せっかく耐障害対策のために2系統用意したシステムを同時に移行させてしまったことだ。前者について、これまで問題のなかった事前のテストや評価方法をそのまま採用して作業したものの、それらを全てパスして問題のあるプログラムが本番環境まで残ってしまった。

　テーブル作成プログラムは従来よりロジックそのものは何も変更されておらず、今回の対応は「32bitから64bitへの書き換え」という視点のみで作業が進んでしまった。そのため、容量計算のミスという元の環境では問題のなかった部分の設定値がトラブルの元となってしまい、この部分をレビューする仕組みが存在していなかった。今後はポーティングを行うプログラマーのみならず、仕様設計などに見識を持つ担当者をレビューに組み入れることでミスの再発を防ぐ方策を採ることになる。

　もう1つは移行の手順自体が正しかったのかという点だが、今回は障害発生時に切り戻し（ロールバック）などの判断は行われず、プログラム修正を優先したために障害期間が2日間以上に及ぶという状態を引き起こした。3連休の入れ替え作業中の問題発生については切り戻しの判断があったというが、本番稼働直後の停止そのものは想定しておらず、復旧に際しての明確な指針が事前に示されていなかったことで対応に余計な時間を取られた点は否めない。今後は復旧におけるガイドラインを関係各所と事前に協議したうえで作業を進めていく方針が示された。

　また50年以上の稼働実績による自信もあるのか、せっかく2系統用意されたシステムを生かし切れず、同時置き換えによる同時のトラブル発生によるシステム停止を招いた。現在進んでいる24年1月より後のレベルアップ作業において、東京と大阪の2つのセンターでの入れ替えのうち、まずは片方を先行して行い、問題がなければ次の周期（1年に4回ある）での作業で全体を置き換えるような手順も全銀ネットでは検討しているという。

　だが全銀ネットによれば、今回のトラブルを受けての全銀システム全体の移行計画そのものに変化はないと説明する。障害への対応期間中、移行スケジュールの詳細を詰める議論などはいったん保留され、次回のRC23へのレベルアップ作業が行われる24年1月では、作業を予定していた金融機関3行のうち1行が移行を見送るといったことはあったものの、27年に第8次システム稼働という全体のスケジュール感はそのままだという。なぜ移行計画を現状維持するかという点については、RCならびに全銀システムのコアで動作するメインフレームの製品提供と保守期限の終了が迫っているという点が大きい。現状のRC23への切り替えを行うレベルアップ作業も、RCの保守期限が終了する金融機関から順番に行っている状態で、その総仕上げがコア部分の置き換えだからだ。

　27年から稼働を開始する第8次全銀システムでは、“レガシー”であるメインフレームを捨ててオープン環境へと移行する。かつて金融機関のシステム構築で大活躍したメインフレームのCOBOLプログラマーも老齢化が進み、担い手となるプログラマー人口も減少している。現在は既存システムの保守や、今回のようなトラブル対応でも数少なくなったCOBOLプログラマーが引っ張りだこの状態が続いているが、ハードウェアそのものの寿命が近づくなか、今後10年以上先を担うシステムでは、より“モダン化”を進めることで新しい世代のプログラマーや周辺システムの開発者を積極的に取り込んでいかなければならない。

　また、第8次の次となる第9次全銀システムでは「RCの完全廃止」が視野に入っている。RCの役割は、送金依頼である電文を規定のフォーマットに変更し、全銀システムを中継することで問題なく相手に届けることにあるが、これは「テレタイプ」と呼ばれる規定の文字長フォーマットに沿ったテキスト電送の仕組みを受け継いだもので、全銀システムが稼働した50年以上前から受け継がれてきた“レガシー”だ。

　RCが存在するのも、この長年培われてきたレガシーな仕組みを、各金融機関の基幹システムの違いを吸収しながら維持し続けることが理由で、これをAPIベースのものへと移行していくことが第8次システムでの狙いでもある。その稼働を前に、全銀ネットでは25年を目標に「APIゲートウェイ」の提供を計画中で、より柔軟に新しいトレンドを全銀システムに取り込んでいけるようパブリッククラウドの利用も含めた「アジャイルエリア」の第8次システムでの提供も予定しており、全銀システムは27年以降大きく変わることになる。

　RCや電文送信の手順そのものが“レガシー”の塊であり、今回トラブルの原因となったテーブル作成プログラムが過去のものから使い回され続けてきているのも、メインフレーム初期の時代からの文化をそのまま引きずってきた結果でもある。全銀システムに接続する金融機関にすれば、接続手順を急に変更されても困るし、願わくは既存の基幹システムを置き換えることなくそのまま使い続けられることが望ましいと考えるところも多いだろう。変化を嫌うのはごく自然な考えで、それが10年、20年先のトレンドを見据えてシステム整備を行わなければいけない全銀ネットと、そのスポンサーである金融機関の思惑との違いの板挟みの中で全銀システムの更新は進んでいる。

この記事の著者

関連記事

• 

  全銀ネット障害、いまだ根本原因特定できず　メモリ不足の指摘には「分からない」

• 

  全銀ネット障害、根底に“開発体制の不備”か　NTTデータの見解

• 

  全銀ネット障害、原因は仕様の”見落とし“　設計者がチェックしていれば防げた可能性も

• 

  全銀ネット、金融庁から追加の報告命令を受ける　10月の障害で

• 

  全銀システム不具合、受付済みの振込は「本日着金」に【追記あり】