障害報告書の書き方｜目的や項目、書き方のポイントをわかりやすく解説

システムを開発している際に切っても切り離せないのが障害です。開発者側は完璧だと思っても、何かの拍子に不具合や障害が発生することはあります。これらの障害が発生した際には障害報告書を作成する必要がありますが、作成する目的は何なのでしょうか。

本記事では、障害報告書の概要と作成目的、具体的な書き方について解説します。

株式会社SHIFTでは、ソフトウェアテストに関して豊富な実績とテストナレッジを保有しており、あらゆるお客様のニーズを満たしたテスト・品質保証を上流～下流（テスト計画・テスト設計・テスト実行・テスト品質管理）まで一気通貫でご依頼いただけます。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

障害報告書とは、システムなどを使用したサービスで障害が発生した場合に作成しなければならない報告書です。認可事業の場合は、事業を統括する各省庁に報告するために必要になる場合もあります。

一般的には原因判明後に作成しますが、途中経過報告として利用されることもあります。内容は、障害が発生した原因や障害による影響であり、障害報告書の情報をもとに顧客に報告される仕組みです。また、障害の回復がいつ頃になるのかの目途を連絡するためにも使用されます。

障害報告書を作成する主な目的は次の3点です。

・発生した障害内容を正確に関係者に報告する
・発生した障害の原因を特定する
・今後の再発防止に努める

障害報告書は、ただ障害が起きた事実を伝えるだけの報告書ではありません。障害の発生によって被害を被った人物や関係者に対する報告とともに、今後同様の障害が発生しないことを明確にするために必要な書類です。それぞれどのような意味をもっているのか、詳しく見てみましょう。

もっとも大きな目的が、障害内容を正確に関係者に報告することです。ここでいう関係者とは、システムを提供している企業の担当者や責任者だけはなく、サービスの利用者や企業の株主などのステークホルダーも含めた人物のことです。また、復旧目途を告知するため、第三者にもわかるような内容を記載しなければなりません。

障害発生により、関係者は当該システムの信頼性や、作業チームに対して不信感を抱いていることが多くあります。システムを提供する側は、真摯な姿勢で発生事象の詳細説明から再発防止策まで文書化して報告することが重要です。

なぜその障害が発生したのかを、障害報告書上に明記しなければなりません。発生した原因が不明瞭では、再発防止策を講じることも、責任の所在も明らかにならないためです。後述する再発防止を図るためにも、障害の原因特定は必須といえます。

もし、障害の原因が提供しているシステムやプラットフォームである場合、提供元である企業が引き続きそのシステムを利用しても問題ないのかを検討する材料にもなります。障害の原因は、システムの老朽化や不適合の可能性も考えられるため、障害報告書を通じて判断する必要があるのです。

発生した事象に対する具体的な解決策は、関係者にとって貴重なナレッジになります。もしもこの先、類似事象が発生してしまった場合でも、報告書に書かれている内容を参考にして迅速に対処できるようになるでしょう。

また、当該事象を経験したことのない第三者に報告書を展開してナレッジ共有できれば、当該事象を未然に防止できる可能性もあります。ヒューマンエラーによって発生した場合は100%の防止は難しいかもしれません。しかし、何かしらの形で原因が究明・明文化されていれば、のちのトラブルを防ぐための貴重な資料となるのです。

このため、第三者が報告書を読む際に、事象の内容から再発防止策まで誰が読んでも理解できるようになっていることが理想的です。難しい書き方や、当事者しかわからないような書き方をしてはいけません。

障害報告書に記載すべき内容と注意点について、項目ごとに説明します。

発生した障害の内容を正確に記載します。発生した障害をトリガーに複数の障害が発生してしまった場合には、時系列で発生したすべての事象を記載しましょう。

発生していた可能性はあるが、事実確認が取れていない事象については記載する必要はありません。

障害内容に記載した事象がいつ発生していつ収束したのか、システムのログなどから正確な日時を確認して○○○○年○○月○○日～●●●●年●●月●●日の形式で記載しましょう。

SLA（Service Level Agreement）によっては、障害が発生していた長さによって賠償問題となることもあるので正確さが重要です。

エビデンスを提出して正確さを証明する必要がある場合には、別紙として添付してください。

障害発生を検知したトリガーが何か、検知したあと誰がどういう対応をしたか、障害が収束するまでに実施したことを事実として時系列で列挙しましょう。

システムの調査・対処内容だけでなく、「誰が誰に対し、何を報告し、どういう判断がされたのか」というコミュニケーション履歴も必要です。

必要な対処の漏れ、対処の順番の誤り、適切なタイミングで報告できていたかといったプロセスについても後に検証する必要があるためです。プロセスに誤りがあると二次障害として扱われてしまうこともあります。

直接的な原因と、根本的な原因の両方を記載します。

例えば、人為的な作業ミスが直接的な原因である場合には、根本的な原因として、「そもそもなぜ作業ミスが発生したのか」を考察して結論づける必要があります。

個人の作業ミスによって障害が発生しないように、「複数人によるチェック体制を設けていたか＝組織として対応する手段を取っていたのか」、「作業者のスキル不足＝アサインミス／教育不足でなかったか」など、考えられるあらゆる観点で該当する原因をあげていきましょう。

経緯のパートで書いた情報と一部重複する部分もありますが、改めて暫定対応について記載します。

ここでは、現在発生している障害事象を今すぐ収束するために実施した暫定的な対応内容を記載してください。「システムを障害発生前の状態にロールバックした」などが該当します。

暫定対応を行う前には、手を加える箇所のバックアップを取得してデータの保全を行いましょう。時間経過とともに中身が変わっていくシステムのログや、データベースのスナップショットなどが対象です。暫定対応を行うにあたり、間違った対応をして障害が収束しない場合や、別の二次障害が起こってしまった場合に、対応前の状態に戻さなくてはならないことがあるためです。また、後の調査やエビデンス提示にも必要となります。

経緯のパートで書いた情報と一部重複する部分もありますが、改めて恒久対応について記載します。

ここでは、根本的な解決をするために実施する対応内容を記載してください。「プログラムやサーバー設定を修正し、テストを行ってからリリースする」「ミドルウェアのアップデートを行う」などが該当します。

根本的な解決に向けて複数のタスクがあり、スケジュールの検討や他社や他部署との調整が必要な場合には、そのように記載します。現時点で考えられる対策とタスクを記載して調整中であることを伝えましょう。
先に調査を行ってから方針決めを行う場合には、別途対応内容を報告する旨を記載し、障害報告書の作成を優先して一次報告としても問題ありません。

システムに障害が発生したことで、システム利用者に対してどのような影響があったのか、システムが通常利用できないことで滞ってしまった業務内容などを記載します。記載する障害の影響は、以下の2つに分けて記載しましょう。

・障害が発生していた時間帯に発生した影響
・障害が収束した後にも継続している影響

場合によっては、過去の実績から推測される機会損失の記載も求められる場合があります。

例えば、ECサイトで障害が発生し30分間商品購入が出来なかった場合は、同じ曜日、同じ時間帯の平均売上額を調べてその額を損失額として記載します。

原因のパートであげた内容に対して、どういう策を講じて再発防止していくのかを記載します。特定の個人の問題として処理するのではなく、チームとして組織的な対応が取れる内容にしましょう。

その際、実施できれば再発はしないであろうと思われる内容であっても「実現が難しい対策は書かない」、「できない約束はしない」ことが重要です。

障害報告書を作成する際は、以下の3点を意識して書くようにしてください。

・障害が発生した原因は深堀すること
・わかりやすく簡潔に書くこと
・テンプレートを利用する

障害報告書は、障害を起こしたシステムを提供した人物だけがわかる内容とならないことが重要です。関係する人物全員が目を通したときに、何が原因でどのような状態なのかなどがわかるようにしておく必要があります。そのためには上記の3点を意識し、活用するとよいでしょう。それぞれ詳しく解説します。

障害が発生した原因を可能な限り深堀する必要があります。障害発生の原因を記載するのは当たり前ですが、それ以上に重要なのが発生した原因の追究です。徹底的に原因を追究することで、再発防止につながることはもちろん、システムの品質向上に役立つため、結果としてサービスの価値向上を図れます。

また、詳細な原因を記載しておくことで、報告書を読んだ人物からの信頼回復が見込めます。100％信頼が回復できるわけではありませんが、ただ事実として原因を記載するのではなく、障害が起こった原因やタイミング、予見できなかった理由を記載しておくことで信頼回復が早くなるかもしれません。

障害報告書を記載する際は、わかりやすく簡潔に書くことを心掛けてください。システムのユーザーが一般消費者であった場合、運営会社としてユーザーへの説明責任を果たす目的で公式サイトやSNS上で事象の説明をすることがあるかもしれません。そのような時、障害報告書が専門用語だらけでは内容を理解することは難しいでしょう。誰にでもわかりやすく書くためには、わかりやすい言葉や簡潔な文章で報告書を仕上げる必要があります。

その際、システムの仕様に関わる内容や運用手順など関係者外秘に該当するる情報、原因や対処内容は掲載しないよう注意しましょう。このような情報が知られてしまうと、サイバー攻撃のヒントを与えてしまうことになり、セキュリティリスクが高まってしまうためです。どこまでが社外に公開して良い情報かしっかりと精査した上で報告を行いましょう。

障害報告書にはテンプレートがあり、それに沿って記載することである程度わかりやすく障害発生の原因や被害の規模などを明確にすることができます。1から作るよりも時間が省けるため、ステークホルダーなどに対しても早急に原因を報告できるでしょう。

障害報告書は、何らかのシステムを使用している以上、誰もが書く可能性がある書類です。障害が起こる原因はさまざまであるため、書いたとしてもそれを恥じる必要はないでしょう。

それよりも、障害報告書を書く際はわかりやすく簡潔な内容で、なおかつ原因を深堀したものを仕上げるようにしてください。企業の信頼回復にも直結した書類であるため、事実だけを書くのではなく、なぜそれが起きてしまい今後どのような対策を講じていくのかまで明確にすることをおすすめします。

「システム障害が解消しない」「原因の特定はできたが再発の可能性が残っている」「絶対にこれ以上障害を出すわけにはいかない」・・・

このような場合は、いち早く第三者の視点を取り入れ、専門的な観点で検証を行うことをオススメします。“ソフトウェアテスト・品質保証の専門会社”であれば、専門的な知見をもっているだけでなく、あらゆるケースに対応したフレームワークやノウハウなど“答え”をもっている可能性が高く、事態の収拾に向けて迅速に動いてくれるでしょう。

株式会社SHIFTでもご相談・緊急対応のための窓口を設けておりますので、お困りの方は以下よりご相談ください。品質コンサルタントが丁寧にご対応させていただきます。

■株式会社SHIFT ご相談・緊急対応窓口
TEL：0120-142-117 （TEL：03-6809-2979）　※受付時間 平日9:00～18:00
お問い合わせフォームはこちら　／　会社情報はこちら

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座