アプリケーション担当者は基本設計の段階で業務フロー図を作成する。ここから一歩踏み込んで、「システム停止」という例外系の業務フローを設計しよう。システム停止時に利用する業務の代替手段を作るのだ。
システムが停止しても継続しなければならない業務がある。システムなしで業務を継続するには、代替手段となる業務フローを設計しておく必要がある。アプリケーション担当者が基本設計の段階で実施すべきだ。
楽天証券は、その代替手段を用意した1社だ。同社のシステムには、顧客からの注文を受ける「受注システム」、取引所との間で顧客の注文を約定する「基幹系システム」の大きく2系統がある。受注システムが止まると、顧客からの注文を受けられなくなる。基幹系システムの停止は注文執行(取引所への注文・約定)の停止に直結する。どちらもネット証券会社の生命線だ。
受注システムは、取引チャネルごとに別システムとして設計した(図1)。あるシステムが停止しても、ほかのシステムには波及しないようにするためだ。取引チャネルはPCのWebサイト、PCのクライアントソフト、携帯電話のWebサイト、スマートフォン向けアプリ、電話の5種類がある。
「それぞれの受注システムが、別の受注システムに対する代替手段となる。もし障害が発生したら、その旨を顧客に通知して、別の受注システムを使うようお願いする」。同社の平山 忍氏(常務執行役員 情報システム本部長)はこう説明する。
基幹系システムは「システム障害が原因で注文執行ができなかった場合は、顧客の注文時の価格で復旧後に注文執行する」(平山氏)という代替の業務フローを設計した。
この代替業務フローを実現するため、「注文・約定検証システム」を運用している。受注システムが受けた注文情報をすべて記録し、システム障害がなければ注文が成立していたかどうかを検証する。成立していたはずの注文は、システム障害からの復旧後に注文時点の条件で成立させる。
楽天証券はシステムだけで代替手段を用意したが、企業や業務によっては紙を使ったり、Excelを使ったりといった方法もある。例えば東京海上グループのコールセンターでは、システム停止時でも保険金請求を受け付ける紙ベースの業務フローを用意している。
災害対策と似ているが異なる
システム停止に備えて業務の代替手段を用意するのは、災害対策で作成する「BCP(事業継続計画)」と似ている。業務の継続がゴールという点では同じだが、両者は別物である。
災害対策では人命への影響、拠点の物理的な損壊、電力や通信など社会インフラの停止など「大規模な経営リソースの喪失」を想定している。BCPはそこからの回復を目的としている。一方、システム停止は特定システムのサーバーが止まるだけだ。社員は全員そろっているし、PCも問題なく利用できる。停止したシステムに対する、応急的な代替手段を用意することを目的とする。