障害(不具合)報告書について

障害とは

　システムが正常に動かなかったり、仕様を満たすことができない状態を障害といいます。この障害は、ソフトウェア中の不備である欠陥(またはバグ)によって引き起こされます。そして、この欠陥は、間違った行為を生み出す人間の行為である、エラーによって生じます。似た言葉に不具合というものがありますが、これは実際の業務やテスト中に遭遇する何らかの異常な結果を指します。

　当たり前ですが、システムやソフトウェアにおける障害(不具合)には、原因があります。だからこそ、以前に経験済みの障害に関しては原因が特定でき、有効な対処法がとれます。障害についての情報をチーム内外で共有することは、提供するサービスの品質を高めることにつながります。

障害(不具合)報告書とは

　障害報告書とは、システムで発生した情報の詳細を記録し、原因解明や再発防止策をまとめるための報告書です。企業によってフォーマットは異なります（Web形式もあれば文書形式の場合もある)。

　多くは、障害の原因がわかってから作成されますが、原因解明の途中経過報告として作成されることもあります。記載される内容は、誰にむけて作成されるかによって微細が異なりますが、大まかには、障害の概要、影響範囲、発生原因、対応内容、再発防止策が記載されます。

作成されるタイミング

　障害報告書が作られるタイミングは様々です。その障害報告書が作られる目的によって異なります。理想としては、障害の発生が確認された直後に、発見者が記載することが望ましいですが、たいていの場合はシステム運用の担当者によって、原因判明後に作成されます。障害の規模が大きく、急を要する場合は、障害報告書の作成よりも先に障害の解決をすることになります。具体的なタイミングとしては、障害の影響範囲を確認した直後、一時対応が終了した後、根本原因が特定された後、影響範囲の評価が終了した後などです。

作成される目的

　障害報告書が作成される目的は様々ですが、主なものには以下のような２つのものがあります。ここでは、障害の記録と情報共有、再発防止とシステムの改善を紹介します。

障害の記録と情報共有

　前述したように障害報告書には、障害の概要、影響範囲、発生原因、対応内容、再発防止策が記載されます。これらの情報は、開発チーム、顧客、ユーザーなどの関係者に正確に共有されます。これらの情報が共有されるなら、顧客やユーザーから誤解されることを避けることができますし、顧客やユーザーに明確な説明ができるなら信頼性を維持することもできるでしょう。クレーム対応や契約上の義務を果たすことにも役立ちます。また、これらの情報が開発チームや社内で共有されるなら、原因解明やプログラムの修正、また、複数の障害に対応中であれば、それらの障害への対応を管理するためにも役立ちます。なお、障害への対応は通常、暫定対応→原因調査→対策検討→修正→恒久対応の順で進んでいきます。複数の障害への対応を管理するなら、障害報告書には必ず識別番号をつけるようにしましょう。

再発防止とシステムの改善

　再発を防止するために、まず障害の原因を特定する必要があります。障害の原因がなんであるかを特定するなら、障害の根本解決に役立ちますし、障害の原因を障害報告書に記載するなら、サービスを提供している企業や顧客がシステムを利用し続けてよいのかの判断材料にもなります。システムそのものではなく、ハードウェアの老朽化や接続環境の問題であることもあるので、原因を特定し、その情報を共有することはとても重要です。

　解明された障害の原因を解決できたなら、再発防止として障害報告書に記載することができます。この再発防止策は今後のシステムの改善に役立ちますし、類似の障害が起こった際に、ナレッジとして管理保管されているなら、その対応にも役立ちます。システムの問題ではなく、ヒューマンエラーが原因だとしても、それが記載されて明文化されるなら今後の開発に役立っていくはずです。

障害(不具合)報告書に記載する項目とその書き方

ここでは、障害報告書に記載する項目とその書き方について紹介します。企業によってルールが異なりますので、参考にとどめておいてください。

障害報告書識別番号

　この識別番号は社内での障害(不具合)の追跡に役立ちます。前述したように、企業内では、複数の障害に対応している場合があります。混同を避けるのに役立ちますし、類似の障害が起こった際の対応策を見つけるのにも役立ちます。

タイトル

　システムの障害報告書のタイトルは、関係者が障害の概要をつかめるように理解しやすく書きましょう。例えば、「データベース接続エラー(1234)によるシステム遅延の発生と対応」というように簡潔にわかるようにしましょう。重要度、日付、分類コードなどをつけるのも有用です。多少、長くなったとしても、報告書の内容がわかるようにタイトルをつけるようにしましょう。

障害の要約

　障害報告書の概要をつかむためにも障害の要約を書くようにしましょう。この部分を理解しやすく書いておけば、迅速な理解を助けますし、障害の内容、影響範囲、発生時間などの基本情報を統一して伝えることで、関係者の認識のズレを防ぐことができます。テストで見つかった障害であれば、この部分に該当するテストケースを記述するようにしましょう。そうすれば、欠陥の修正後に、障害が再度発生しないかの確認に役立ちます。

障害発生日時

　障害発生日時には、障害がいつ発生したかを記載します。システムログなどから正確な日時を記載します。形式は、「○○年××月△△日□□時～●●年◇◇月▲▲日■■時」で記載します。あいまいな場合は、「○○年××月△△日□□時頃と推定」と書きましょう。契約によっては障害が発生していた長さによって賠償問題が発生することがありますので、正確さが必要です。

障害復旧日時

　復旧済みの障害であれば、障害からの復旧日時を記載します。システムが使えなかったダウンタイムを記録するなら、その障害の影響範囲がわかります。また、関係者への報告の際には、その障害がいつまであったのかを説明することができます。さらに、障害対応の記録を残すことで、将来の 監査 や 類似障害の分析 に活用できます。

障害内容

　ここでは、どのような事象が起こり、どんな問題が起こっているかを記載します。十分な情報を記述する必要があります。具体的には下記のようなことを記載します。

経緯

　障害発生を発見したきっかけ(トリガー)は何か、発見されたあとどう対応したか、障害が収束するまでに行われたことを時系列で挙げましょう。誰が誰に、どう報告し、どのような判断がされたかというコミュニケーションについての記録も記載しましょう。どのように障害に対応したか、そのプロセスについても記録しておく必要があります。もし対応プロセスに誤りがあると二次障害として扱われることがあります。

原因

　障害の原因が判明していれば、その内容を記載します。障害の根本解決を図るために、推測レベルのものでも有用であれば記載できます。ただし、事実と推測ははっきりとわけて記載します。

　この部分に記載する内容としては、主に3つです。直接的な原因、根本的な原因、再発防止策との関連です。直接的な原因としては、何が原因で障害が発生したのかを具体的に記述します。根本的な原因としては、なぜその障害が発生したのか、背景や経緯を分析して記載します。そして、再発防止策との関連としては、再発防止策を実施するために、是正するべき管理体制や対応方法について記載します。

影響範囲

　障害がどれほどの範囲に広まっているのかを記載します。障害の影響範囲を記載することで、対応の優先度を決めたり、関係者に明確な説明ができるようになります、特に顧客やユーザーに対しては、障害によってユーザーにどのような影響があったのか、障害によって滞ってしまった業務についても記載するようにしましょう。具体的には、障害が発生していた時間帯の影響と障害が収束した後の影響についてわけて書くことができます。

　対応の優先度を決めるためにも、チームや社内で障害の影響度を表すメジャーを決めておきましょう。このように、あらかじめ影響度のメジャーを決めておくなら、障害発生後の時間を有効に活用できるようになります。

暫定対応

　暫定対応として、障害をすぐに収束するために実施した暫定的な対応について記載します。例えば、「バグの影響を受ける機能を一時的に非表示にする」というように書くことができるでしょう。暫定対応を行うときに気をつけたい点として、修正箇所のバックアップをとっておくことが挙げられます。バックアップをとっておけば、手を加えた際に万が一、データが破損したり、問題が悪化したとしても、もとの状態に戻すことができます。また、のちのち、恒久対応を取る際にデータを比較することもできます。言わずもがな、なぜ、その暫定対応をとったのかということを説明するための材料にもなります。

恒久対応

　恒久対応とは、障害の根本的な対応策のことです。障害の原因が特定できていないときには、一次報告という形で、「原因調査中」「対策検討中」と記載しても構いません。また、スケジュールの調整や他社、他部署との調整が必要である場合はその旨を記載し、その時点で有効と思われる対策について記述し、調整中であることを記します。恒久対応をとった後であれば、その効果についても忘れずに記載するようにしましょう。

再発防止策

　同様の障害が再発しないために行える対策方法を記載します。再発防止策の担当者も記載します。しかし、再発防止策を記載する際には、個人の問題とするのではなく、組織的な対応がとれる方法を取りましょう。また、実現が難しいことは、再発防止策としてふさわしくありません。再発防止策の実施計画やその効果をいかに検証するかの計画もこの部分に記載します。

障害(不具合)報告書の書き方のポイント

ここでは、障害報告書を書くとき全体を通して意識したいポイントを取り上げます。目指すべきは、特定の個人や集団にしかわからないものではなく、障害がおきたシステムに関係する方々全体が、何が原因で、今どのような状態なのかをつかめるようにすることです。

原因を深堀する

　障害の原因を追究することは、障害報告書を書く上で重要です。原因を追究できれば、再発防止につなげられますし、将来、起こりうる似通った障害への対応策の材料にもなりえます。そして、原因がきちんと記載されていれば、それを読んだ人からの信頼をある程度回復させることができるでしょう。予見できなかった理由などは、信頼を回復するために役立つでしょう。

読み手にわかりやすい文章を心がける

　まず誰にむけての障害報告書なのかに意識を向けましょう。一般のユーザーや、顧客が読むものであれば、専門用語ばかりでは、文章の内容を把握することが難しくなるでしょう。そのような場合には、専門用語に(　)書きで説明を加えるようにしましょう。そして、できるだけ、事実と推測はわけて書くようにしましょう。障害報告書には、障害の収束になりえそうな推測が書かれることがありますが、推測と事実が混同されないように、推測部分には「～と推測される」など、はっきりとわかる形で記載しましょう。

　また、具体的な文章になるようにも心がけましょう。5W1Hを意識して、どんな問題が起きていて、どのように障害が収束されるのか、わかりやすく書くようにしましょう。しかしながら、システムの仕様に関わる内容や運用手順など関係者外秘に該当する情報や、再発防止策について書く際には、どこまで記載してよい内容なのか十分に確認するようにしましょう。あまりに詳細な情報が公にされるとサイバー攻撃の糸口になりかねません。

テンプレートを利用する

　記載するべき内容が一目でわかるテンプレートを利用することも役立ちます。自分で1から作成するよりも手間が省けますし、社内やチーム内で共通して使用しているものがあれば、読み手にとってもテンプレートを利用して書かれた障害報告書の方が理解しやすいでしょう。

まとめ

　障害報告書は、発生原因・影響範囲・対応策・再発防止策を記録し、同じ障害の再発を防ぐための重要な文書です。読み手に、どんな障害が起き、どのように収束したのか、正確に情報を伝えることが目的です。また、システムの継続的な品質向上にもかかわるものと言えます。

お問い合わせはこちら

この記事をシェアする