IT関係の業務に就いていれば、耳にする機会の多い「障害報告書」。
人間が作業する上で必ずといっていいほど起こってしまう人為的ミスに始まり、外部からのサイバー攻撃やシステムのスペックなどが原因で、ITに障害が起こることがあります。
障害報告書は、システム関連の障害が起こったときに作成するものですが、ただ障害をアウトプットするだけのものではありません。
この記事では、障害報告書とは何かという基礎知識から、より活用的な障害報告書を作成するためのポイントまでを詳しく解説します。
障害報告書とは？
障害報告書とは、何らかの原因でトラブルが起きた際にそのトラブルなどについてユーザーに報告するためのものです。
どういったトラブルを詳しく報告するだけでなく、原因は何だったのか、どのような対応で復旧したのか、同じようなトラブルを今後起こさないためにどういった対策が必要なのかなど、細かくレポーティングしたものでなければなりません。
障害が起こったあともユーザーが安心して作業にあたれるように、似た障害が再び起こった際の早期対応や再発防止が求められます。
障害報告書を書く目的
障害報告書の作成には次のような目的があります。
- 関係者への正確な障害内容の伝達
- トラブルの再発防止
- サービスの改善
- 信頼回復
障害報告書を読む相手は、システムに関する専門家ではない場合が多いため、発生した事象について正確に理解していないことも多くあります。
そのため、まずは何が起き、誰にどのような影響があったのか、障害の内容について正確に伝えることが重要となります。
次に、障害回復のためにどのような対策を取るのか、今後同じトラブルを起こさないためにどのような改善を施すのかを明確にします。
対策内容を明文化することは関係者にとっても重要なナレッジとなります。
今後担当者が変わったり、新たな担当者が増えたとしても、この情報をもとにトラブルの再発防止の取り組みを継続できます。
そして、トラブルが起こってしまうと社内外の関係者に不信感や不安を抱かせてしまいますが、障害報告書で正確な情報を明らかにし真摯な対応を行うことで、その後の信頼回復の可能性を高められるでしょう。
社内トラブルにも障害報告書は必要？
結論から言うと、社内外に関わらず、何かトラブルがあれば障害報告書が必要です。
前述しましたが、障害報告書は発生したトラブルの内容だけを記すものではありません。
原因や対応の仕方、再発防止策などが書かれ、障害報告書を読めば「どこで」「なにが」「どうなった」のかを把握できるようになっているはずです。
障害報告書があれば同じトラブルが二度と起こらないようにでき、作業の質を向上させることが期待できるでしょう。
また、似たようなトラブルが起こっても即時対応が可能となるので、パニックを防ぐことに繋がります。
退職などで対応する社員が変わっていたとしても、障害報告書をテンプレート化させることで、トラブル発生時の対処を標準化することが可能です。
障害報告書を書く意義
- 関係者への正確な障害内容の伝達
- トラブルの再発防止
- サービスの改善
- 信頼回復
適切に障害報告書を作成すれば、上記4つの効果が得られます。
障害報告書を読む相手は、システムに関する専門家ではない場合が多いため、発生した事象について正確に理解していないことも多くあります。
そのため、まずは何が起き、誰にどのような影響があったのか、障害の内容について正確に伝えることが重要となります。
システムやフローなどを改良すれば同じトラブルの再発防止になり、提供するサービスをより良いものにできます。
また、トラブルが起こってしまうと社内外関わらず利用者に不信感や不安を抱かせてしまいますが、障害報告書で確実な対応ができれば、信頼回復なども図れるでしょう。
障害報告書のテンプレート
障害報告書のテンプレートはさまざまありますが、効果的な障害報告書のテンプレートを以下に紹介します。
〇〇〇(発生した事象)の障害報告書
20〇〇年〇月〇日に～～～～といった問題が発生したためご報告いたします。
株式会社〇〇様ならびにご利用の皆様へご迷惑をお掛け致しました事、深くお詫び申し上げますと共に、本書にて障害内容の詳細と経緯・原因、今後の対応についてご報告いたします。
- 障害発生日：20〇〇年〇月〇日 〇時〇分〜〇時〇分
- 障害復旧日：〇時〇分〇〇の復旧を確認
- 発生した事象：発生した事象を簡潔に記載
- 発生原因：事象が発生した原因を細かく記載
- 一時対応：発生した事象を解決するためにどんな対策を行ったか記載
- 根本対処：同じ事象を発生させないためにどんな対策を行ったか記載
- 復旧までの経緯：事象発生から復旧までの経緯を時系列順に記載
ここからは、障害報告書の項目について記載すべき内容や注意点を詳しくご紹介します。
また、障害報告の対応についてより詳しく学びたい方向けに、情シス必読のシステム障害対応にまつわる参考書をご紹介します。
システム障害の適切な対応方法について悩まれている方におすすめです。
障害報告書で書くべきこととは？
- 発生した事象
- 障害の原因
- 暫定的な対処内容
- 再発防止に繋がる根本対応の内容
前項で障害報告書のテンプレートを紹介しましたが、盛り込むべき上記4つの内容について詳しく説明します。
発生したトラブルの内容とその原因、応急処置として何を行ったか、そして再発防止策を入れることが重要です。
どれも障害報告書に欠かせない内容となりますが、ただ記載すればいいというわけではありません。
それぞれの項目についてどう記せば有効な障害報告書になるかポイントを押さえながら作成しましょう。
発生した事象
まずは発生した事象と時刻を記録するようにしましょう。
障害報告書のなかではとても重要な部分となります。
いつ何が起こったかを端的に記載しただけでは、有益な情報を報告することはできません。
そのため、下記のポイントを抑えて記録するようにしましょう。
- 「トリガー発生時刻」（障害のきっかけが発生した時刻）
- 「事象発生時刻」（トラブルが発生した時刻）
- 「検知時刻」（事象を検知、または報告した時刻）
- 「復旧時刻」（障害を解決した時刻）
障害が発生した日時はもちろんのこと、対象のシステムやトラブルの内容、影響を及ぼした範囲などの被害状況も併せて記載することが重要になります。
障害の原因
障害の原因は、システム停止などの「直接的な原因」と、設定ミスなどの「根本的な原因」を分けて記載しましょう。
例えば、サーバに一時的な負荷が掛かり、メモリ不足によってシステムがダウンした場合、直接的な原因は「メモリ不足によるシステムの停止」になります。
しかし、この場合システムが停止すること自体は正常な動作となりますので、根本的な原因としては、メモリの容量が適切かどうかが問題になります。
このように、直接的な原因と根本的な原因を分けてどう対処すべきかを見分けるようにすることが大切になります。
また、注意点として、特定の人の作業ミスとして捉えられるような、属人的・人為的な原因であるような書き方をしてしまうと、メンバーの心理的な負荷が増え、その後の組織運営に影響を及ぼす事になりかねません。
そのため、属人性を感じさせるような報告書の書き方は避けるようにしましょう。
暫定的な対処内容
トラブル発生時に応急処置的にどう対応したのかを報告しましょう。
暫定的な対処内容を障害報告書に記載しておくことで、似たようなトラブルが再発した際も迅速に対応することが可能です。
復旧するまでの間、応急処置でどうにか対応できれば、業務をストップさせたり遅延させたりせずに済みます。
再発防止に繋がる根本対応の内容
障害報告書で最も重要な項目と言えるのが、再発防止に繋がる根本対応の内容です。
安心してユーザーが作業にあたれるよう、今回の障害に対してどういった再発防止策がとられたのかを恒久対応の内容を報告しましょう。
恒久対応が長期間に及びそうな場合は、実施する対策の内容と実施日の目処を明記します。
また、同一のシステムや製品でも同じような障害が発生しないか必ずチェックしておきましょう。
同じような条件になった場合、同様の障害が発生するようであれば、状況を報告したうえで対策を講じる必要があります。
発生した経緯、発生～復旧の日時
トラブルが発生してから復旧するまでの事柄を時系列順に報告しましょう。
障害に気付いた経緯、障害の確認や原因特定、応急処置として行った暫定対応、完全復旧、恒久的な対応といった流れが一般的です。
担当者やそれぞれの作業に要した工数なども報告書に記載しましょう。
再発防止策をすぐに講じることが可能であれば、いつ再発防止のために行ったことも記す必要があります。
再発防止策を講じるまでに時間がかかりそうな場合は、再発防止策の内容といつまでに対応できるかを書きましょう。
障害報告書作成時のポイント
- ユーザー視点を忘れずに
- 専門用語を使わない
- 障害発生要因の深掘り
障害報告書を作成する際、上記3つのポイントを押さえると、わかりやすく、かつ今後に活かせる報告書になります。
システムを利用しているのはユーザーですので、開発者視点で作成するのはおすすめできません。
また、誰が見てもわかるように作成する必要があるため、難しい専門用語を使用しないようにしましょう。
障害発生の要因について深掘りし、なぜ障害が起こったのかを遡るだけでなく、なぜ予見できなかったのかまで詳しく追及したものを記載することが重要です。
ユーザー視点を忘れずに
社内向け、社外向けに限らず、システムの開発者や提供者目線で記述すると、ユーザーが理解しにくい障害報告書になってしまいます。
ユーザーから見えたトラブルや影響を記述し、ユーザーが認識しやすい報告書となるようにしましょう。
例えば、「システムが停止した」という事象を「サーバーが使えなくなった」と記載するなど、ユーザーが利用するうえでどうだったかという表現に変換しながら作成するのとわかりやすくなります。
専門用語を使わない
システムを専門的に扱っている開発者側は、専門用語を障害報告書に使いがちです。
障害報告書は、第三者が見ても認識しやすいものである必要があります。
ユーザーにとってわかりやすいものとなるだけでなく、同じようなトラブルが起こった際に誰でも早期対応が可能となるでしょう。
急に担当者が休んだり変更になったりしたときも、対応者の知識レベルを問わず対処できる可能性が高くなります。
障害発生要因の深堀り
障害が発生した原因を特定することは必ず行わなければなりませんが、なぜ障害の原因要素が発生したのか、可能な限り要因を掘り下げる必要があります。
また、障害が予見できなかった理由やこのタイミングで障害が起こった原因など、あらゆる方向からの要因を深掘りしましょう。
徹底的に調査をすれば再発防止に繋がるだけでなく、システムの質を向上させ、より良いサービスを提供することにも直結します。
詳しい検証は信頼回復にもなるので、顧客との関係に亀裂が入るのを防げるでしょう。
ITアウトソーシングで障害報告書作成もサポート
障害報告書は日常的な業務ではなく、イレギュラーである障害が発生してしまった際に作成するアドホック作業と言えます。
いざ作成しなければならない場面になったとき、有益な障害報告書といえるまでのレベルで作成ができない可能性も高いでしょう。
しかし、ITアウトソーシングでは、IT業務のサポートから障害報告書の作成まで請け負ってくれる場合があります。
障害報告書の作成をアウトソース先に任せれば、慣れない障害報告書の作成のせいでコア業務を圧迫することなく、わかりやすい障害報告書を手に入れることが可能です。
こだまシステムのITサポートでは、障害報告書の作成はもちろんのこと、障害報告書作成にまつわるノウハウの提供も含めてサポートしておりますので、細かなご要望にお応えしながら柔軟な対応ができます。
まとめ
障害報告書は、何かトラブルが起こった際に障害の内容や発生原因、対応や再発防止策などを報告するものです。
ただ障害を報告するだけでなく、よりわかりやすく、より有効なリソースとするためには、書き方のポイントやコツを押さえなければなりません。
障害報告書の作成はルーチン業務ではありませんので、時間がかかったりクオリティが低い報告書になったりしてしまうこともあります。
工数をとられてコア業務に影響を及ぼす可能性もあり、そのような状況の発生を未然に防ぐこともより重要となります。
そこで有効なのが「ITアウトソーシング」の活用です。
ITアウトソーシングでは、日頃のIT業務の代行や効率化のアドバイスなどITに関する業務の負荷軽減のための様々なサポートを依頼することが可能です。
今回ご紹介したような障害報告書についても、ITアウトソーシングを活用することで、作成の代行や専門的な視点からのアドバイスを得ることが可能になります。
また、障害そのものの発生リスクを抑えるという視点からも、ITアウトソーシングは有効な手段です。
当社こだまシステムのITサポートでも、日常のIT業務サポートからリスクに強い環境構築のためのアドバイスなど、幅広いニーズに対応しています。
障害発生のリスクを感じているが、どう対処すればいいかわからないという場合や、日頃のIT業務の忙しさゆえにその他業務に手が回っていない場合など、ITに関するお悩みをお持ちの方は、ぜひご相談ください。
