山本　慎一郎

皆さんご存じかと思いますが、先日、全国の銀行間の送金を担うシステムで障害が起きました。
すでに復旧しているようですが、多くの取引に影響が出てしまったようです。

原因としては、データを中継する装置のプログラム異常が有力視されています。
冗長化（同じ処理用の中継ルートを複数用意しておくこと）はされていたようですが、一斉に交換する計画だったとのことで、障害を回避することはできなかったようです。
もっとも、そもそも冗長化は、バージョンアップでの障害への対策ではなかったと思いますので、そこを責めるのは少し見当違いかなと思います。

一方で、少し視点を変えると、「事業継続計画（BCP：Business Continuity Plan）」に、今回のような『全銀ネットが使用できなくなる事態』が盛り込まれていたのかは、大いに気になるところです。
銀行間で送金ができないとなると、金融事業に大きな影響を与えますから、全銀側でも利用している銀行側でも、当然、事業リスクとして認識しておくべきケースです。

ただ、一部の情報では、全銀のシステムは50年間一度も大きな障害がなかったとも聞きました。
この点について、各組織でどのように評価されていたのか。
そして、どのような対応がとられていたのか。
コンピュータ側の原因を追究することも重要ですが、組織側の準備も十分だったか、確認する必要があるのではないかと思います。

また、システム移行をする側で考えると、『移行失敗時の切り戻し作業』に関する教訓も見えてきます。

一部の情報では、移行自体は正常に終了し、取引が開始された後に障害が明らかになったとも言われています。
通常、『移行失敗時の切り戻し作業』は、移行作業が正常に遂行できなくなった場合に、元の状態に戻す作業として考えられていると思います。
ですが、この情報のように、移行作業が成功裏に終わった後で問題が発覚したケースについては、切り戻し手順などが用意されていないのではないかと思います。

一方で、『移行作業完了後に障害が発生したのなら、それは移行作業の問題ではなく、単なるバグではないか？』という考え方もあります。
そうなると、その障害への対応を定める手順は、移行計画の中ではなく、平時の運用マニュアルの中にあるべきとも考えられます。
このあたりは、中々線引きが難しいように思います。

いずれにしても、送金が滞ったという事実があるのは確かであり、銀行の信頼を揺るがしたことも確かです。
システムエンジニアとしては、これを他山の石として、しっかりと今後に活かしていくことが重要だと思います。

どの時代の、どの業界でも、バージョンアップというのは神経質になる作業です。
今回の件を受けて、私としても、その失敗のリスクについて、もう一度考えてみたいと思います。

それでは、どれほどの経済損失が出たのかも気になる、山本慎一郎でした。