”実践”システム障害対応：1週目：アラート・故障申告の棚卸と精査

今週から12週にわたり「”実践”システム障害対応」と題して記事を書かせていただきます。

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

それを実行した結果として、顧客との関係がより良いものになり、顧客にとっての成功（顧客の利益にも貢献）を得られる結果になる事を目指し、システム障害対応の改善におけるカスタマーサクセスとは何か？を考えながら、お伝えさせていただきつつ、更に意見交換できたら幸いです。

初回となる今回は、アラート・故障申告の棚卸と精査です。

アラート・故障申告の違い

みなさまのシステム障害対応の契機（又はインシデント管理が発生する契機）は何があるでしょうか？
大きく分けると「アラート」と「故障申告」に分かれると思います。

この二つの大きな違いは「自分たちで気づく」か「顧客・利用者が気づくか」です。
インシデント分類と気づく方法などを以下に書いてみました。

アラート・故障申告の棚卸が何故大事なのか？

機能追加などを行い日々進化していくシステムにおいて、アラートや故障申告の洗い出しを全網羅する事は難しいと思います。
ただし、洗い出しや精査をしておく事がなぜ大事なのか、主に以下3つあると考えます。

1.ユーザーの業務影響を極小化し、早期に業務を復旧できる可能性が高まるから

人は想定外の事がおきるとパニックになります。
それはシステム障害発生時においても同様で、「不安」「苛立ち」「恐怖」「困惑」の感情を抱いた状態になるのは、システム障害対応の経験者なら理解できると思います。

予兆しているシステム障害対応においては、「ある程度想定済みだ」と不安はありつつもそのレベルは大きく下がり、未知事象よりは比較的落ち着いた対応ができるのではないでしょうか。

未知事象率が高いと、いざアラートが発生した時に対処が遅れ結果、影響範囲が大きくなります。
既知事象であれば、対処も早く行える可能性が高まり、影響範囲を小さくできる可能性があります。
そのため、未知事象率を少しでも減らすために棚卸しが大事だと考えます。

2.顧客の利益につながるから（まだ見ぬ大きなコスト削減になる）

システム障害が起きると、サービス停止や遅延による機会損失、ブランドイメージ低下、関係者の稼働コスト増大、顧客への損害賠償など、システム障害によって発生した色々なマイナス事象を元に戻すために、様々なコストをかけて元に戻そうとします。

まだシステム障害が発生していないからと危機感がない方も少なからずいるかもしれませんが、いざシステム障害が発生した後に発生するコストを抑える事は、顧客側（サービス提供側）も、システム保守する側も、両方にメリットがあり、最終的に顧客の利益につながる事だと考えます。

3.属人化の防止、各インシデントの対処ナレッジが溜まるから

システム障害を対応されるシステム側の多いケースとして、システム構築された詳しい方など有識者を中心に対処を行い、その対応ナレッジが残っていない事が少なからずあると思います。

その詳しい方が異動や退職などでいなくなってしまった場合、引継ぎ対応はあるにしても、そのノウハウレベルは低下し、その後発生するシステム障害対応の速さには差が出ると想定しています。

棚卸しや洗い出しをした結果、障害時のアクションを運用設計する事で各インシデントに対するナレッジが溜まり、それが属人化の防止につながり、組織全体としてレベルアップも可能だと思います。

それによりアラート対応をしている保守の方、申告対応しているカスタマーサポートの方に入れ替わったとしても、教育コストなども抑えられると考えます。

アラート・故障申告の洗い出し

次にそれぞれの洗い出しをしてみましょう。

「アラート」についてはおそらくインシデント管理ツールに蓄積されていて、それを一覧にすると概ね洗い出しができるかと思います。
何か月分ぐらいをまとめるとよいかは件数やチームによりますが、過去の経験上の目安として「アラートが少ない」チームでは100件以上、「アラートが多い」チームでは3か月程度を見るのが良いのかなと思います。一定のサンプル数、もしくは、月の変動を捉えるための必要な数・期間だと考えています。

「故障申告」については洗い出しが少し大変かなと思っています。
顧客からの申告はすべてヘルプデスクツールに蓄積されています。ということであればそちらを同様に「故障申告が少ない」チームでは100件以上、「故障申告が多い」チームでは3か月程度を見ていただければと思います。

ここで注意が必要なのは、「記録されていないものこそを洗い出す」という点です。
ぜひ一度やっていただきたいのは「顧客から故障申告を受けたのに記録せずクローズしているものが無いか」ということです。
私の現場でもありましたが、顧客から保守担当者・営業担当者が電話を受けて、その場で答え記録をせずにクローズしてしまうものが週2,3度ありました。

この「見えない故障申告」は網羅的にすべてを洗い出すのは難しいのですが、ぜひ頻度が多いものだけでも洗い出せるとこの後の対処で改善が図りやすくなります。ご自身のチームの有識者の方や、運用で顧客と直接電話されている方、営業担当者など幅広くヒアリングを実施してみてください。

チームによっては以外と顧客接点のチャネル数があると思います。
電話受付、WEB受付、メール受付、チャット受付、担当営業からの声など、それらをヒアリングで洗い出していく事で新たな課題発見や棚卸し項目が見つるかと思います。

またカスタマーサクセスのための改善として、顧客と継続的・長期的に、顧客の成功を考え進めていく上で、それらを対応する各チームが良好な状態でないと成り立たないと思います。
このヒアリングなどで各チームメンバの困り具合や疲弊具合も確認でき、何か対処をうつべき事に気づけたりする事があるかと思います。

ここまでお読みいただきありがとうございました！
次週は「アラート・故障申告の分類」について触れていきたいと思います。
何かございましたら遠慮なく、感想、コメントいただけますと、幸いでございます。