インシデント分析ってどうすんの?
![インシデント分析ってどうすんの?](https://www.lmis.jp/dcms_media/image/incident_management.jpg)
数週間ぶりのご無沙汰です。
前回の記事で、「次回はインシデント分析について」とお伝えしていたので、今回は「インシデント分析の進め方」について書いていきます。
インシデントの分析に必要な3つのステップ
「インシデントの分析」を進めるにあたってやるべきことは、
- インシデントの蓄積を行う
- インシデントの分析を行うチームを作る
- インシデントの区分わけを行う
の3つのステップです。
1. 情報収集をしてインシデントの蓄積を行う
インシデントの分析を行うために、まずは情報収集しないといけません。
過去にどのようなインシデントが発生したかを整理していきましょう。
情報の蓄積は、その後のステップにつながる重要な段階ですが、なるべく、負担をかけない形で情報を集めるのがベストです。
2. インシデントの分析を行う専門チームを作る
情報収集で過去のインシデントが洗い出せたら、次にインシデント分析チームを編成しましょう。インシデントが発生したチームで分析を行うのもいいですが、インシデント分析専門チームを作ることで、責任をもって分析が行えます。
3. インシデントの区分わけを行う
インシデント分析チームは「インシデント区分」を設定しましょう。区分けは、「インシデント蓄積」の段階でも行えます。ですが、最初の段階で区分してしまうと、問い合わせ情報を入れていくときに「問い合わせの区分はどれだろう?」となってしまい、正確な情報を入れるのに時間がかかってしまう可能性があります。
インシデント区分は以下のように設定してみましょう。
- トラブル
- Q&A
- 要望
インシデントを区分けすることで、どの段階での問い合わせが多いかが洗い出せます。
この区分けは、インシデントの範囲が広がるのと比例して広がっていきます。
インシデント区分の範囲を広げることで、分析精度は高まりますが、反面、広げすぎて中途半端になってしまう恐れもあります。
そのため、区分けは、上記の3つとその他の4個ほどに設定するのがおすすめです。
トラブルがわかることで事前の対応がみえてくる
類似のトラブルがみえてきます。トラブルが見えてくれば、事前にどう対応するかで問い合わせの減少につながります。
ユーザーからの要望は開発部門にフィードバック
インシデント分析をすることで、ユーザーが抱える要望を把握できます。どういうニーズが多いのか、どういう疑問を抱えているのかなどを、開発部門にフィードバックすることでシステム改善の一手となります。
頻出Q&Aを把握して業務の効率化
問い合わせのなかには、同じような内容の質問も多々あります。そのため、インシデント分析を行うことで、よく聞かれる質問をマニュアル化でき、作業工数を削減。業務の効率化が図れます。
インシデントを可視化することで部門ごとのするべきことが見えてくる
インシデント分析を行うことで、問題点が可視化され、各部門がどのようにインシデントに対処していくかが見えてきます。
これは、区分けを細分化することで、よりハッキリと浮かびあがり、例えば「トラブル」というインシデントひとつをとってみても、
- ハードウェアのトラブル
- ソフトウェアのトラブル
- インフラのトラブル
- ヒューマンエラー
と、どこに問題があったかを深掘りできます。こうすることで、それまでかかっていた工数を削減できるので、まずはどの対応にどれくらいの工数がかかっているかを把握しておきましょう。
生産年齢人口(主な働き手となる15〜64歳)が減少傾向にあり、人手不足が叫ばれている現在、インシデント分析を行い、業務の効率化を図ることは非常に重要になっています。まずは、これまでのインシデントを洗い出し、何が自社に発生しているかを確認していきましょう。
次回は、インシデントの可視化をテーマに、「インシデントの可視化の先に見えるもの(仮題)」と題してご紹介します。
それでは、See you next time!
※この記事は、2014/08/06に投稿した内容を2019/08/02にリライトしたものです。