インシデント管理・問題管理業務についての話

私が参画していたインシデント管理・問題管理業務についての話 現場体験記

はじめに

キーボード画像

こんにちは、やさおです。
今回は、タイトルにも記載させていただいておりますが、「インシデント管理・問題管理」について、私が業務に携わらせていただいた体験談を書き綴らせていただきますので、お付き合いください。
本記事は、主に現在サポート事務現場におり、他にどんな現場があるのか気になっているエンジニアに向けての内容となります。

インシデントとは

まず、インシデントとは?
ITサービスマネジメントの分野においては、事業者が提供するサービスがシステムや人為的ミスなどによっての不具合・事故、サービスの中断、または阻害され、質や利便性が損なわれる事象、利用者に対して正常なサービスの妨げになる事象を「インシデント」と呼ばれております。

また、不具合・事故だけでなく、事故を引き起こす可能性のある事象も含んでおります。
詳細のインシデント判断基準については、各会社によって、それぞれ基準が異なりますが、不具合・事故、もしくは事故を引き起こす可能性のある事象をインシデントと称している点は同じです。

インシデントを未然に防ぐ、またはインシデントに対して迅速に対応し、顧客満足度を高く維持するための管理というのが「インシデント管理」となります。

根本的原因を発見し、解消することでインシデントの再発を予防するための管理というのが「問題管理」となります。

主に私が行っていたインシデント管理・問題管理業務は、「顧客満足度を高く維持するための管理」の部分と「根本的原因を解消することでインシデントの再発を予防するための管理」の部分である、作業担当者へのフォローアップ、社内報告用の集計データ作成および表作成などとなります。

業務内容

インシデント管理の始まり

フローチャート図1

インシデント発生部署から発生の報告を受けます。
報告いただいた内容から、インシデントのカテゴリー(事象、発生日時、検知日時、影響範囲、影響サービス、影響度合いなど)を確認し、現時点で把握できている内容を社内の管理ワークフローシステム(※)へ登録します。
追加で報告いただいた内容は、都度社内の管理ワークフローシステムへ情報を更新していきます。

また、インシデントの発生報告は検知からなるべくすぐ報告するルールとなっているため、検知から報告までに大分時間が経っている場合は、なぜ報告が遅れてしまったのか経緯をヒアリングする必要があります。
インシデントのカテゴリーが埋め終わったら、社内の管理ワークフローシステムで復旧対応をされる担当部署・担当者を割り当てます。

※管理ワークフローシステム
Webやシステム上で申請から承認まで行えます。紙や口頭で行っていた申請作業を電子化して作業の効率化や迅速化を図ったり、定型業務を自動化できたりするのがメリットとなります。
さらに、関連書類をシステム上で保管できる他、申請手続きの進捗状況が可視化ができます。
ワークフローシステムについては、様々な機能を持った製品が多数ありますので、本記事では、詳細の説明は割愛させていただきます。
申請作業をWebやシステム上で行っているものと覚えていただけたらと思います。

復旧対応完了まで

フローチャート図2

発生部署および関係部署にて、事象の調査を行っていただき、調査結果の報告を受けます。
報告いただいた内容から、直接的原因、再発有無、復旧対応方法、復旧対応時期を確認し、社内の管理ワークフローシステムを更新します。

復旧対応が直ぐに実施できない場合(原因調査に時間を要している、他のシステムにも影響を与えるため定期サービス停止時に修正予定など)については、復旧対応完了までどういった暫定的な対応を実施するのか、業務への影響度合いは考慮できているのかなど詳しく報告をいただく必要があるため、都度対応状況をヒアリングします。
復旧対応担当者に社内の管理ワークフローシステムへ対応の時系列を明確に記載していただき、上長に確認依頼を回付していただきます。
上長全員の承認が得られて、復旧対応が完了となります。

復旧対応完了後

フローチャート図3

インシデントの発生原因部署に根本的原因を解決していただく必要があるため、社内の管理ワークフローシステムで再発防止策を策定および対応される担当部署・担当者を割り当てます。
ここでインシデントの再発防止策を策定していただく担当部署・担当者へフォローアップをします。
社内または部内の方針、どういった内容であれば現実的に運用が可能か、どれだけの改善が見込まれるか、根本的原因に対して妥当性がある再発防止策を担当部署・担当者と相談しながら策定していきます。

例えば、

直近の案件で混入したインシデントであり、混入した箇所が結合テスト時の考慮漏れであると判明

  • YYYY年MM月DD日にシステム改修をリリース
  • 結合テスト時に確認するチェックリストを充実させる(実現的に運用できるようボリュームも考慮する)

など

再発防止策を策定後、再発防止策がいつ頃までに実現可能であるか、担当部署・担当者と期日を設定します。
再発防止策の進捗状況を都度ヒアリングします。
もし、対応に遅れなどが発生していた場合、理由などを明確にヒアリングし、期日を再設定します。
再発防止策が完了したら、担当部署・担当者から対応完了が分かる証跡を受領します。(リリース実施ログ、稼働確認結果、整備したチェックリストなど)

担当部署・担当者から受領した証跡の内容が再発防止策に対して、整合性が取れている内容であるか確認します。
受領した証跡の内容が再発防止策に対して、整合性が取れている内容であることが確認できたら、担当部署・担当者に社内の管理ワークフローシステムへ再発防止策の証跡を添付していただき、上長に確認依頼を回付していただきます。
上長全員の承認が得られて、再発防止策が完了となり、インシデントの対応が完了となります。

集計データおよび表作成

月や週毎に発生したインシデントの件数を抽出、そのうち重要障害、案件起因、業務起因、などの分類分けをし、復旧待ちの件数、再発防止策完了待ちの件数、対応が完了している件数などの集計データを作成します。
集計データを元に月次で社内へ報告するために一覧化した表を作成、週次で部内へ報告するために一覧化した表を作成します。
報告用の表には、対応が遅滞している理由など、担当者からヒアリングした内容も記載します。

色々なインシデントを見てきて

エラーの対処法などが属人化されており、対応出来る方が不在だったことから、対処が遅れ、インシデントになってしまったようなケースもあり、そのために知見を蓄積したうえで部内やチーム内で共有し、適切な管理体制を整えておく必要があるのだと気づけました。
また、過去の知識や知見を蓄積し、まとめて管理することで、問題の分析が出来るようになることから、迅速で正確な対応が実現でき、顧客満足度を高く維持することへ繋がるのだと実感いたしました。

さいごに

コミュニケーション画像

私が携わらせていただいたインシデント管理・問題管理について、業務概要を説明させていただきましたが、利用者目線では感じることが出来なかった問題意識というのを多く実感できました。
あくまで今回私が携わらせていただいたのは、作業担当者へのフォローアップという位置づけでしたが、どういったパターンで発生したインシデントなのか、具体的に伺うことができましたし、開発プロセスを深く理解するという点でも非常に勉強になりました。

また、作業担当者に対応状況を確認させていただいた際、聞いた情報を持ち帰り、自分の分かりやすい言葉で噛み砕いて理解するという癖も身につき、理解した内容を言語化することについても、すごく成長に繋がり、次に作業担当者へ状況を伺う際に、「前回は~と伺っていることから、~と認識しており、~と考えておりますが、いかがでしょうか?」などと話を進めることが出来るので、作業担当者も丁寧に情報を共有していただけましたので、コミュニケーションするうえでも、相手の見ている先に目線を合わせて話を進めるという重要性もより理解いたしました。


もし、開発プロジェクトに携わる機会があれば、インシデントを起こさないためにはどうするべきか、インシデントが起きてしまったらどうするべきか、「インシデント管理・問題管理」という点で問題への意識を強く持っていただけたらと思います。
また、プロジェクトに関わらず、関係者と情報共有をしっかり行い、相手の意向を汲み取って業務に当たって欲しいと思います。

作者情報

三度の飯より珈琲が好き。自宅で挽いた珈琲をマイタンブラーに入れ、仕事へ持って行くのがこだわり。今は3Dラテアートを修行中の元飲食店員。いつか創作動画とかアップしてみたいです。