アプリケーション担当者は基本設計の段階で業務フロー図を作成する。ここから一歩踏み込んで、「システム停止」という例外系の業務フローを設計しよう。システム停止時に利用する業務の代替手段を作るのだ。

 システムが停止しても継続しなければならない業務がある。システムなしで業務を継続するには、代替手段となる業務フローを設計しておく必要がある。アプリケーション担当者が基本設計の段階で実施すべきだ。

 楽天証券は、その代替手段を用意した1社だ。同社のシステムには、顧客からの注文を受ける「受注システム」、取引所との間で顧客の注文を約定する「基幹系システム」の大きく2系統がある。受注システムが止まると、顧客からの注文を受けられなくなる。基幹系システムの停止は注文執行(取引所への注文・約定)の停止に直結する。どちらもネット証券会社の生命線だ。

 受注システムは、取引チャネルごとに別システムとして設計した(図1)。あるシステムが停止しても、ほかのシステムには波及しないようにするためだ。取引チャネルはPCのWebサイト、PCのクライアントソフト、携帯電話のWebサイト、スマートフォン向けアプリ、電話の5種類がある。

図1●楽天証券は顧客向けに取引の代替手段を用意
図1●楽天証券は顧客向けに取引の代替手段を用意
システム障害が発生しても顧客への影響をできるだけ小さくするため、顧客に対してシステム停止時の代替手段をあらかじめ用意している
[画像のクリックで拡大表示]

 「それぞれの受注システムが、別の受注システムに対する代替手段となる。もし障害が発生したら、その旨を顧客に通知して、別の受注システムを使うようお願いする」。同社の平山 忍氏(常務執行役員 情報システム本部長)はこう説明する。

楽天証券の平山忍氏

 基幹系システムは「システム障害が原因で注文執行ができなかった場合は、顧客の注文時の価格で復旧後に注文執行する」(平山氏)という代替の業務フローを設計した。

 この代替業務フローを実現するため、「注文・約定検証システム」を運用している。受注システムが受けた注文情報をすべて記録し、システム障害がなければ注文が成立していたかどうかを検証する。成立していたはずの注文は、システム障害からの復旧後に注文時点の条件で成立させる。

 楽天証券はシステムだけで代替手段を用意したが、企業や業務によっては紙を使ったり、Excelを使ったりといった方法もある。例えば東京海上グループのコールセンターでは、システム停止時でも保険金請求を受け付ける紙ベースの業務フローを用意している。

[専門外でも本PARTが理解できるポイント!]
災害対策と似ているが異なる

 システム停止に備えて業務の代替手段を用意するのは、災害対策で作成する「BCP(事業継続計画)」と似ている。業務の継続がゴールという点では同じだが、両者は別物である。

 災害対策では人命への影響、拠点の物理的な損壊、電力や通信など社会インフラの停止など「大規模な経営リソースの喪失」を想定している。BCPはそこからの回復を目的としている。一方、システム停止は特定システムのサーバーが止まるだけだ。社員は全員そろっているし、PCも問題なく利用できる。停止したシステムに対する、応急的な代替手段を用意することを目的とする。

次ページ以降はITpro Active会員(無料)の方のみお読みいただけます。