“実践”システム障害対応：5週目：アクションの仮説立案

12週にわたり「”実践”システム障害対応」と題して、システム障害対応の改善のプロセスを約3か月で実行できるように、各週ごとに何を実践すればよいか？を考えていきたいと思います。

4週目は、結果目標・アクション目標をもとにテスト運用した結果を「見える化」し「振り返り」することで、より良い結果目標・アクション目標への見直しや課題に対してどのような対策をとるべきかについてお話させていただきました。

5週目からは、「システム障害発生時のアクション」について考えていきましょう。

顧客視点で運用設計についておさらい

こちらの記事でも記載しておりますが、簡易的におさらいさせていただきます。

システム障害における改善ポイントで重要な事は「顧客や関係者の運用設計を起点に、自分たちの運用設計をする」です。

システム障害発生時に顧客がどうしたいか事前に知っていれば、顧客の事業やサービスに対して影響を極小化できると考えています。
システムが利用できない時の代替手段を決めておけば、そのシステムを利用しているエンドユーザーが困る可能性が低くなります。
エンドユーザーに対して正しい情報を還元し判断していただくために、またエンドユーザーへのフォロー対応を行うために、関連情報取得や還元方法の事前準備を行えば、いざという時には早く情報が出せます。

つまり、顧客側のインシデント対応（エンドユーザーにしてあげたい事/システム保守にやってもらいたい事）を起点として、以下三つを決めることをおすすめしております。

①アクションの候補・・・どんなシステム障害時に、どんな行動をとるかの選択肢を考えておく
②判断情報・・・行動の選択肢を、何の情報をもとに選択するかを考えておく
③判断基準・・・情報をどのような観点で判断するのかの基準を考えておく

イメージ図としては以下のようになります。

ご自身のビジネスによって、上記アクターなどが変わる事はあるかと思います。
（今後もう少しブラッシュアップ予定です）

考え方をお伝えするためにいくつか事例を書かせていただきます。

システム障害時のアクションの仮説立案

具体的なアクション事例①-1 チェーン展開する飲食店×決済サービス×決済端末

一般的には代替手段として①が思い浮かんで、この手段を取ることが多いと思いますが

• 少なくともこの①というのが何分ぐらいでやるべきか？
• その時間で本当にできるか？

を確認すべきだと思います。
例えばですが、「全店舗へ一斉に”確実に”連絡を取る手段はあるか」次第ですが、メール・チャット・FAXなど、営業中は気づかないかもしれません。

• 気づかないことを許容するのか？
  　　→　許容できないならば、確実に連絡を取る手段が必要です。
• 張り紙は必要か？
  　　→　張り紙は良くされていますが、手書きの張り紙でよいのか？
• 張り紙の文言はどうすべきか？
  　　→　その内容は本部から送るのか？文面は誰が承認を出すのか？

などなど…

アクションも実際にやることを考え出すと、考えること・準備することがたくさんあります。

具体的なアクション事例①-2 高級ホテル×決済サービス

今度は業態だけ変えてみました。
高級ホテルの際には高い現金をエンドユーザーは持っていない事が多いという仮説であったとします。

その場合、チェックアウト時の決済で多くの時間待たされることは、その高級ホテルの”印象悪化”（ブランドイメージダウン）につながり、次回へのリピート率が大きく下回る可能性が高いため「エンドユーザーを待たせたくない」となった場合②の「今回は、お代はお支払い頂かなくても結構でございます」という選択肢を選ばざるを得なくなります。

あまり知られていない手段ですが、クレジットカードは”電話”をすれば決済することができたりします。フロント業務の方がこの手段を認識できており、1~2度やり方を練習/実践して試しておけば完了する見込み時間がわかります。
「お待たせしてしまい申し訳ございません。xx分ほどお時間いただきます。」と伝えれば、エンドユーザーは完了見込時間がわかり”印象悪化”を多少押さえられます。

具体的なアクション事例②-1 医療×情報管理サービス

今後このような事例集を各業界ごとに様々なケースを掲載できるようにアップデートしたいと考えております。

アクション実行決定者の設定

アクションが決まったら、それを「誰が実行を決定できるか」を決めておきましょう。

• 店長で判断していいものか？
• エリアマネージャーが判断していいものか？
• 課長なのか、部長なのか、社長で判断するべきものなのか？
• もしその実行決定者に連絡はつかない場合は、上位権限のどこまで連絡をし承認をもらうのか？

これらは次回決める「判断情報」「判断基準」にも関わります。
ここで言いたい大事な事は、「アクション実行決定する方にアクション候補を認識してもらうこと」です。

緊急対応時は特に時間がないため、アクション実行決定者が突然言われても決定する事ができません。
部下からの報告聞いて「（おそらく大丈夫だろうから）それでよい」と判断する場合がほとんどです。
連絡や承認する時間までおしく、その時間をロストしたくないケースであれば、権限移譲したほうがアクションが早くなります。
部下に任せられない部分もあるから自身で判断して実行決定を出したいという上司の方も、もちろんいらっしゃるかと思います。
その場合、実行決定者を巻き込んで意識合わせをして証跡として記録を残してあげてください。

システムベンダ側は是非勇気をもって、事業会社側は少し興味をもっていただき、
最低でも2社間でアクションのすり合わせをして、誰が決定するかを合意することをお勧めいたします。

次週は「判断情報」「判断基準」に触れていきます。
ここまで、ご覧いただきありがとうございました。