2024.02.07
ソフトウェアにはさまざまな「不測の事態」が起こることが考えられます。不測の事態に迅速・正確に対応するうえで、重要となるのが「インシデントレポート」です。
本記事では、ソフトウェア開発におけるインシデントレポートの基礎知識や書き方、作成時の注意点についてお伝えします。
- もくじ
1．ソフトウェア開発におけるインシデントレポート（欠陥レポート）とは
インシデント（incident）は直訳すると「出来事」「事件」といった意味です。ソフトウェア開発においては、「ソフトウェアに発生した何らかの異常な現象」を指します。
つまり、ソフトウェア開発におけるインシデントレポートとは、「ソフトウェアの異常な現象に関する情報を記載した報告書」のことをいいます。
なお、ソフトウェアテスト技術者資格認定の運営組織であるJSTQBではインシデントレポートを「欠陥レポート」と表記し以下のように定義しています。
欠陥レポート（defect report）
欠陥の発生、特性、およびステータスを報告するドキュメント。
これはインシデントレポートとほぼ同義ですが、特に「テスト時の欠陥をまとめるレポート」という意味合いが強くなるでしょう。本記事では、「インシデントレポート」で統一します。
2．インシデントレポートを書くタイミング
インシデントレポートは、ソフトウェアに異常な現象が確認されたときに書くものです。具体的には、主に下記3つのタイミングで書くことになり得ます。
- 開発中（コードレビューや静的解析、デバッグなど）
- テスト中
- 運用中（顧客やユーザーの使用中、監視システムによる検知）
テスト中はもちろん、開発中やリリース後の運用中に見つかったインシデントもレポートの作成対象です。「開発中」には、以前リリースしたソフトウェアの問題が次期開発で判明する、などのケースを含みます。
レポートの作成者は「インシデントの確認者」が理想ですが、顧客やユーザーの代わりに運用担当者が書くこともあるでしょう。なお本章の後半では、テスト時におけるインシデントレポートの書き方を紹介します。
3．インシデントレポートを書く目的
なぜインシデントレポートを書く必要があるのか知っておきましょう。インシデントレポートを書く主な目的は、次の3つです。
不具合に関する情報共有
インシデントレポートは、不具合に関する情報共有の役割を果たします。
インシデント発生による影響は開発やテスト、運用といった各担当者に波及します。たとえばテスト中にインシデントが発生した場合、開発者は問題の原因調査や修正、運用者は暫定対応策の検討・実施などが必要でしょう。それぞれに異なる対応が求められるため、可及的速やかに情報共有すべきです。
しかし、電話や口頭でインシデントに関して報告するのでは非効率なうえに、正確性に欠けます。そのため、インシデントレポートという形で情報を漏れなく記載し、関係者へ情報共有を図るのです。
ソフトウェア品質の評価
インシデントレポートは、ソフトウェアの品質を評価するうえでも役立ちます。
当然ながら、ソフトウェアの品質が低いほど、重大なインシデントが発生しやすくなります。言い換えれば、ソフトウェア品質の良し悪しはインシデントレポートの件数や内容にある程度反映されるのです。インシデントレポートはリリースなどの際に品質の判断材料となるでしょう。
ケーススタディの蓄積
インシデントレポートの作成を通して、有用なケーススタディの蓄積が可能です。ケーススタディを活用すれば、類似のインシデント発生時に早期解決しやすくなるでしょう。
またインシデントレポートには、プロセス改善のヒントが詰まっています。データの蓄積に加えてインシデントの分析も行えば、再発防止策の検討に役立ちます。
4．項目別・インシデントレポートの書き方
インシデントレポートを作成する場合、さまざまな項目を埋めなければなりません。ここでは主な項目別に、インシデントレポートの書き方を適宜例文も交えて紹介します。ただし、フォーマットは現場によって細かく変わるため、参考としてご覧ください。
識別番号
インシデントレポートには識別番号が必要です。識別番号がないと、レポートの件数が増えたときに管理できません。識別番号があれば、インシデント情報を検索する際にも役立ちます。
インシデントの概要（件名）
インシデントレポートを読む人は、概要（件名）を見てインシデントの大まかな内容を把握します。下記例のように、インシデントがどのような内容か、ひと目でわかる内容を記載しましょう。なお、頭に識別番号を付けるケースもあります。
『商品登録画面にて、エラー1234が表示され商品登録ができない』
作成日時・作成者・担当者
問い合わせなどの際に必要となるため、インシデントレポートの作成日時、作成者を記載します。作成者は別の人と混同されないようにフルネームで記載するのが理想です。運用担当者が顧客の代理で記載する場合など、作成者と担当者が異なる場合はわかるように記載しましょう。
発生したソフトウェア・環境・バージョン
インシデントが発生したソフトウェア・環境・バージョンに関する情報を記載します。ブラウザやデータベース管理システムなど、バージョンがあるものは極力すべて記載しましょう。細かいバージョン違いで発生有無が変わってくるケースも少なくありません。
発生フェーズ・発生日時
インシデントが発生した日時とともに、開発・テスト・運用といった発生フェーズも記載するのが理想です。インシデントレポートのフォーマットを共用する場合、発生フェーズを明記すると区別しやすくなります。
期待結果
インシデントは、「期待結果と実際の結果が食い違う」ことが問題となります。そのため、どのような結果が期待されるのかを簡潔に記載しましょう。記載例は次のとおりです。
『商品登録ボタンを押下後、エラーなく登録完了画面に遷移する』
実際の結果（発生した現象）
期待結果に対して、実際の結果がどうだったのかを簡潔に記載します。以下の例文のように期待結果との違いがわかるように記載しましょう。
『商品登録ボタンを押下後、エラー1234が表示される。OKボタン押下後には商品登録画面に戻る』
操作手順
操作手順が正しくないために期待結果と差異が生じるケースもあります。操作手順からインシデントの原因がつかめる場合もあるため、漏れなく記載しましょう。
操作手順においては、1つの手順に1つのアクションだけを記載すべきです。1つの手順に複数のアクションがあると、見落としたり手順が前後したりしやすくなります。また、「人の操作」と「ソフトウェアの動き」を分けると見やすくなるでしょう。
発生頻度
同じ手順を実施しても、発生有無がまちまちなインシデントもあります。原因調査のヒントになり得るため、発生頻度も記載しておきましょう。「10回中3回発生」のように、パーセンテージよりも回数で表したほうが、試行回数も把握できるためおすすめです。
エビデンス
開発側と運用側で現象に対する認識が異なるケースがあるため、エビデンスも必要です。画面キャプチャーやシステムログ、ダンプファイルなど、ソフトウェアに合ったエビデンスのパスやリンクを記載しましょう。
注意点として、エビデンスの取得・保存ルールは明確にし、関係者間で周知すべきです。エビデンスの取り方が間違っていると、再実施が必要となる場合もあります。
重要度・緊急度・優先度
開発者が修正対応の着手順序を決めるために、重要度・緊急度・優先度のいずれかが必要です。フォーマットによって項目名や設定値は変わるでしょう。
設定内容は、インシデントレポート作成時点のもので構いません。重要度や緊急度、優先度は後から変わるケースもあります。
ステータス
インシデントへの対応状況を関係者が把握するために、ステータスを記載します。ステータスの設定値は現場によって変わるため、事前に定義しておく必要があります。下記は例ですが、関係者間で誤解の生じない表現が理想です。
『検出・報告』『原因調査・修正判断中』『修正中』『修正確認中』『クローズ』
備考欄
備考欄は、関係者間で補足情報を共有するための項目です。原因調査の担当者は、できる限り原因や影響範囲について備考欄に記載しましょう。インシデントレポート作成者は、原因に心当たりがある場合は推測内容を記載することも効果的です。
修正情報
修正後には、修正した内容やバージョン、日時などの情報を記載します。修正後の再テストや状況確認に必要となります。
5．インシデントレポートを書く際の注意点
インシデントレポートを書く際の注意点として、次の3つを押さえておきましょう。
重大なインシデントは報告を優先する
インシデントレポートを書くうえで、ある程度の調査は必要になるでしょう。しかし、インシデントレポートの作成に時間がかかり、重大なインシデントの報告が遅れるのはNGです。重大なインシデントの場合は、報告を優先しましょう。
すぐにレポートを作成できない場合は、メールでの簡易報告でも構いません。特に、テストの進行に影響を与えかねないブロッキングバグなどは迅速に連絡しましょう。
なお、運用時に発生したインシデントは緊急度が高いため、「インシデント管理」の一環としてレポートを作成することも多いです。インシデント管理とは、インシデントの検出からクローズまでの一連のプロセスを指します。詳しくは以下の記事をご覧ください。
操作や設定にミスがなかったか確認する
インシデントレポートの作成前に、自分の操作や設定にミスがなかったか確認しましょう。正常な現象をインシデントと勘違いして報告すると、関係者に迷惑がかかります。
また、インシデントレポートを書き終えた後も、深呼吸して確認するようにしましょう。急いでいるときほど、記載ミスをしやすいものです。バージョン情報やエビデンスなどの内容に間違いがないことをチェックしたうえで、関係者へ展開してください。
不確かな情報を事実のように記載しない
不確かな情報を事実のように記載してはいけません。裏の取れていない情報が事実と異なる場合、関係者が誤解して原因発見が遅れる場合があります。たとえば、2回連続で再現しただけで「100％発生します」と記載しても、3回目には再現しないかもしれません。
ポイントは、「事実」と「推測」は分けて書くことです。たとえば、「～ではないかと推測しています」のように、推測であれば推測と明確にわかる書き方を心がけましょう。
まとめ：適切なインシデントレポートを作成してスムーズな不具合対応を
ソフトウェア開発におけるインシデントレポートとは、「ソフトウェアの異常な現象に関する情報を記載した報告書」のことです。不具合に関する情報共有やソフトウェア品質の評価、ケーススタディの蓄積など、インシデントレポートにはさまざまな目的・役割があります。
インシデントレポートを書く場合、さまざまな項目を埋めることになります。書き方に問題があると、関係者に迷惑がかかったり、インシデントの解決が遅れたりしかねません。適切なインシデントレポートを作成して、スムーズな不具合対応を実現しましょう。
