2024.02.09
さまざまな人が利用するシステムには、障害のリスクが少なからず存在します。システムの運用体制を万全に整えていても、障害を100％防ぐことはできません。システム障害に正しく対処するために、重要となるのが「システム障害報告書」です。
今回は、システム障害報告書の書き方を例文付きで紹介します。システム障害報告書の書き方におけるコツもお伝えするため、ぜひ参考にしてください。
- もくじ
1．システム障害報告書とは
システム障害報告書とは、システムで発生した障害の情報を記録し、関係者へ伝えるための報告書のことです。「Redmine」といったツールを用いるWeb形式、「Microsoft Word」のような文書形式など、企業やチームによってフォーマットは異なります。
また、システム障害報告書の意味合いは企業によりさまざまです。たとえば、「リリース前のシステムテスト中に発生したバグ情報を伝える報告書」を指すケースも少なくありません。本記事では、「リリース後のシステム運用時に生じた障害情報を伝える報告書」として解説していきます。
1-1 障害報告書を作成する目的
システム障害報告書を作成する目的は、企業やチーム、システムによってさまざまですが、主なものは次の3つです。
関係者への正確な情報共有
システム障害報告書は、障害内容や原因、再発防止策など、さまざまな項目に分けて情報を整理します。そのため、関係者へ正確に情報を共有することが可能です。性格な情報共有によって、開発チームや顧客、ユーザーなどの誤解や混乱を防げるでしょう。また、開発チームが原因調査やプログラムの修正を行う際にも、重要な手がかりとなります。
社内での障害管理
システム障害は、「暫定対応→原因調査→対策検討→修正→恒久対応」といった流れで段階を踏んで解決させていきます。複数の障害が未解決で残っている場合、どの障害がどの状況にあるかを把握することは難しいです。システム障害報告書として記録し、状況に合わせてアップデートすれば、社内での障害管理がしやすくなります。
障害の再発防止
システム障害報告書には、再発防止策を含めることが一般的です。同じ障害を繰り返すことは避けなければなりません。障害が解消して終わりではなく、再発防止策を明確にして記録することで、再び同様の事象が発生することを防ぐ目的もあります。
1-2 障害報告書を書くタイミング
システム障害報告書は、障害の発生を確認した際、当事者が速やかに記載することが理想です。多くのケースでは、システムの運用担当者が記載することになるでしょう。
ただし、急を要する大規模な障害だと、障害報告書の作成よりも障害の解決を優先する場合もあります。こうしたケースでは、報告書の作成が原因判明後となることも少なくありません。
2．項目別・システム障害報告書の書き方【例文付き】
ここでは、システム障害報告書の主要な項目について、例文も交えながら書き方を紹介します。ただし、企業やチームによってルールが変わる場合もあるため、参考程度にご覧ください。
2-1 タイトル
システム障害報告書のタイトル（題名）は、関係者に大まかな障害情報を伝えるために重要です。障害の概要がわかりやすく伝わる簡潔なタイトルを付けましょう。たとえば、「エラー1234により管理者ログインできない」のような情報を入れると、概要が伝わりやすいです。
タイトルに管理番号や日付、重要度、分類コードなどを付ける場合もあります。そうすることで、過去の障害情報をタイトルで並べ替えたり検索したりしやすくなるでしょう。また、重要度がわかる情報を入れることで、重要な障害が見逃されにくくなります。あまりにも冗長なものは良くありませんが、簡素にして情報が欠落するくらいであれば多少冗長なほうが良いです。
2-2 障害発生日時
障害発生日時は文字どおり、障害がいつ発生したかを記載する箇所です。システム画面やシステムログで障害の発生タイミングが明確であれば、その日時を記載します。反対に、発生タイミングが不明確な場合は「2023年1月23日14時頃と推定」などと推定日時である旨がわかるように書きましょう。必要に応じて、「障害が発生した日時」と「障害を検知した日時」がわかるように記載すると良いでしょう。
2-3 障害復旧日時
障害が復旧済みの場合は、その日時を記載します。障害復旧日時は障害管理において重要な情報です。発生から復旧までの時間をもとに、被害範囲を推定する際にも役立ちます。
2-4 障害内容
障害内容には、どのような事象が発生し、どのような問題が起きているのかを記載します。タイトルよりは掘り下げつつ、簡潔に障害の内容を記載しましょう。なお、顧客やユーザーが読み手に含まれない場合は、「だ・である調」を使用するケースもあります、
例として挙げられる障害内容の記載方法は、以下のとおりです。
「運用担当〇〇が受注管理システムに管理者アカウント（xxx-xxx）でログインを試みたが、ログインボタン押下時にエラー1234が表示され、ログインができない。」
2-5 影響範囲
障害がどの範囲にまで及んでいるのかを、わかる範囲で記載します。機能や画面、権限など、できる限りの情報を記載することが理想です。影響範囲は推測が含まれることが多いため、その根拠となる実施内容などを補足的に記載すると良いでしょう。
たとえば、次のような影響範囲の例文が考えられます。
「受注管理システムのログイン機能において、管理者アカウントでのみ問題が発生している模様。〇〇以外の運用担当者2名も、管理者アカウントでログインできない。一方、一般ユーザーアカウントの社員10名は問題なくログイン可能。」
2-6 経緯
経緯には、障害が発生するまでの流れを時系列で記載します。障害の原因調査や再発防止策の検討にも役立つため、できる限り具体的に記載することが大切です。
たとえば、次のような経緯が考えられます。
2023年1月23日10時頃：管理者アカウント（xxx-xxx）でログインに成功。
2023年1月23日11時頃：データベース管理ソフトのアップデートを実施。
2023年1月23日12時頃：管理者アカウント（xxx-xxx）をログアウト。
2023年1月23日14時頃：管理者アカウント（xxx-xxx）でログインを試行。しかし、ログインボタン押下時にエラー1234が発生し、ログインができない。10回ほどログインを試行したが、同様の問題が発生。
2023年1月23日19時頃：他2名の管理者アカウント（yyy-yyy、zzz-zzz）でログインを試行したが、同様の問題でログインができない。
2-7 暫定対応
暫定対応には、障害に対して暫定的に施した対応内容を記載します。関係者に状況を伝える意味もあるため、暫定対応は忘れず記載しましょう。たとえば、「運用担当者3名に臨時の管理者アカウントを貸与」といった内容が考えられます。
2-8 恒久対応
恒久対応には、根本的に障害を解決するための対応内容を記載します。障害の原因調査・対策検討が完了していない場合は「原因調査中」「対策検討中」などでも構いません。
恒久対応の粒度は、システム障害報告書の想定読者や運用ルールにより変わります。顧客やユーザーも見る場合は「ログイン機能のプログラム修正」程度でも良いでしょう。一方、社内向けのシステム障害報告書であれば、より具体的に修正内容を記載します。
2-9 原因
障害の原因が判明している場合は、その内容を記載します。障害の根本解決を早期化するために、推測レベルの内容でも有用となる可能性があれば記載して構いません。ただし、事実と推測は分けて記載するようにしましょう。
たとえば、次のような原因の例文が考えられます。
「管理者アカウントのログイン判定処理に用いているライブラリが、最新のデータベース管理ソフトと互換性がないことが判明。2023年1月23日11時頃に実施したデータベース管理ソフトの更新によって互換性の問題が顕在化した。」
2-10 再発防止策
再発防止策には、同様の障害が再発しないための施策内容を記載します。誰が実施するかがわかるように記載しましょう。再発防止策の検討が完了していない場合は「検討中」などでも構いません。
たとえば、次のような再発防止策の例文が考えられます。
「運用担当者は、受注管理システムの周辺ソフトをアップデートする場合、必ず開発チームに互換性のリスクについて事前確認する。また、確認した旨はチェックリストにて記録を徹底する。」
3．システム障害報告書を作成する際の３つのポイント
システム障害報告書の書き方に明確な決まりはありませんが、押さえておくべきコツはあります。システム障害報告書における書き方のポイントは、主に次の3つです。
3-1 できる限り具体的に書く
できる限り具体的に書くことを心がけましょう。たとえば「商品管理画面が正しく表示されない」では、読み手はどのような問題があるのか把握できません。「商品管理画面において、商品名と価格が表示されない」と具体的に書いたほうが、客観的に伝わりやすいでしょう。具体的な数値を用いることも効果的です。5W1H（いつ・どこで・誰が・何を・なぜ・どのように）の考え方に基づいて記載しても良いでしょう。
3-2 誰にでも伝わる表現を心がける
システム障害報告書を読む全ての人に伝わる表現を心がけましょう。たとえば顧客やユーザーが見るシステム障害報告書の場合、プログラムの専門用語を用いても伝わりません。自らのチーム内でしか伝わらない表現や専門用語はできる限り避けるか、かっこ書きで補足すると良いでしょう。
3-3 事実と推測を明確に区別する
事実と推測を明確に分けることも大切です。システム障害報告書には、事実ではないが障害の解決につながりそうな推測情報を記載することが少なくありません。推測を事実のように書くと誤解が生じ、根本解決が遅れる場合があるため注意が必要です。推測の場合は「～の疑いがある」「～と見られる」など、推測とわかる表現を用いましょう。
まとめ：明確で具体的なシステム障害報告書を作成しよう
システム障害報告書とは、システムで発生した障害の情報を記録し、関係者へ伝えるための報告書のことです。システム障害報告書には、関係者への正確な情報共有や社内での障害管理、障害の再発防止といった目的があります。
システム障害報告書で書くべき項目は主に以下の10項目です。
・タイトル
・障害発生日時
・障害復旧日時
・障害内容
・影響範囲
・経緯
・暫定対応
・恒久対応
・原因
・再発防止策
システム障害報告書の書き方はさまざまですが、不明確でわかりづらいと障害の根本解決が遅れてしまいます。そのため以下の3つのポイントを意識して作成しましょう。
・できる限り具体的に書く
・誰にでも伝わる表現を心がける
・事実と推測を明確に区別する
作成方法に悩んでいる場合は、本記事の内容を参考にしてみてください。
