2025.11.05
ソフトウェア開発では、不具合に直面するリスクを完全に防ぐことはできません。発生した不具合を適切に共有・対処するために重要となるのが「不具合報告書」です。しかし、不具合報告書の書き方や記載すべき項目が分からない、といった方も多いでしょう。
本稿では、不具合報告書の基礎知識から記載項目、作成のポイントまでまとめてお伝えします。不具合対応や品質管理に関わる方はもちろん、これから業務に携わる方もぜひ参考にしてください。
- もくじ
1. 不具合報告書とは
不具合報告書とは、ソフトウェアの開発時や運用時に発生した不具合を記録し、関係者へ伝達するための文書です。不具合の発生状況や影響範囲などを正確に共有することで、スムーズな原因特定や対処を可能にします。
組織やプロジェクトによって「バグ報告書」「バグ票」など呼び方は異なりますが、本質的な目的はおおむね同じです。不具合を明確に記録し、社内（場合によっては一部の社外関係者）へ情報を共有するために活用されます。
2. 不具合報告書を作成する目的
不具合報告書を作成する目的は、主に次の3つです。
2-1. 不具合情報の共有
不具合報告書の重要な役割は、関係者へ不具合情報を正しく共有することです。不具合情報を整理して一元管理することで、関係者が必要な情報を把握しやすくなります。たとえば、開発者が原因調査の手がかりを得たり、運用担当者が暫定対策の方法を把握したりできるでしょう。不具合に対する共通認識を持てれば、認識のずれによる新たなトラブルの発生も防げます。
2-2. 不具合分析による再発防止
不具合報告書は、不具合分析による再発防止のためにも欠かせません。不具合分析では、機能別の発生件数や発生タイミングなどのデータを集め、傾向や問題点を多角的に分析します。こうしたデータを豊富に持つ不具合報告書は、不具合分析の大きな助けになります。適切な不具合分析によって、不具合の再発を防ぐためのヒントが得られるでしょう。
なお、ソフトウェアの不具合分析について詳しくは、次の記事を参考にしてください。
2-3. 品質保証や顧客対応のための記録
不具合報告書は、品質保証や顧客対応のための記録としても有用です。たとえば、テスト分析の際に過去の不具合傾向を参考にしたり、顧客からの問い合わせに対する回答の材料を得たりできます。不具合情報を記録として残しておくことで、後からの確認や改善活動に活用しやすくなるのです。
3. 不具合報告書に記載する主な項目
不具合報告書には、さまざまな項目があり、正確に記載することが求められます。ここでは、不具合報告書に記載する主な項目の書き方やポイントについて、例文も交えて見ていきましょう。なお、記載項目は企業やチームによって変わることがあります。
3-1. タイトル
不具合内容がひと目で分かる簡潔なタイトルをつけましょう。たとえば、『エラー123で商品登録が完了しない』のように、問題の核心を端的に示すのがポイントです。必要に応じて日付や分類コード、重要度などを付けることで、データとして活用しやすくなります。多少長くなったとしても、最低限必要な情報は盛り込むほうが良いでしょう。
3-2. 発生日時
不具合が発生したと思われる日時をできる限り詳しく記録します。発生時間が定かでない場合は、『2025年1月23日21時ごろと推定』のように推定日時を記載しましょう。システムログなどで発生日時が明確な場合は、分単位で断定的に記載しても問題ありません。
3-3. 発生条件・発生環境
不具合が発生した条件や環境を記載しましょう。OSやブラウザ、利用中の端末や設定など、再現に必要な情報を記載することが大切です。バージョン情報なども含め、できる限り詳しく記載してください。また、必ず発生するわけではない現象の場合は何回か試行し、大まかな発生確率を記載すると有用です。
3-4. 報告者・報告先
不具合を発見した人物と、報告書を共有する相手を記載しましょう。関係者や責任の所在を明確にするためにも必要な項目です。担当者や関係部門も忘れずに記載してください。
3-5. 不具合の概要
不具合の事象や症状を簡潔にまとめましょう。専門用語を必要最低限に抑え、読み手が状況を理解しやすいよう意識しながら記載します。次の文章が一例です。
商品管理システムに管理者ログインし、商品情報をすべて入力して登録ボタンを押下した。しかし、商品登録画面のまま遷移せず、エラー123が表示されて登録は完了しなかった。商品情報がデータベースに登録されていないことは確認済み。10回試行したが、毎回同じ現象が発生した。
3-6. 再現手順
不具合を再現できる操作手順を順序立てて記載しましょう。手順が明確であれば、関係者が同じ状況を確認でき、原因特定や対応策の検討に役立ちます。次の文章は一例です。
【1】商品管理システムに管理者アカウントでログインする
【2】商品登録画面を開く
【3】必須項目を含む商品情報をすべて入力する
【4】登録ボタンを押下する⇒画面遷移せずエラー123が表示される
3-7. 影響範囲
不具合が業務やユーザーに及ぼす範囲を記載しましょう。影響を受ける機能や操作、利用者数などを具体的に記載することで、優先度や対応方針の判断がしやすくなります。次の文章は一例です。
商品管理システムの商品登録機能全体に問題が発生している模様。運用担当者3名全員が商品情報の新規登録を行えない状況となっている。一方、商品情報の閲覧や編集、削除といった他の機能は正常に動作することを確認済み。
3-8. 原因・対策
不具合の原因が判明している場合は記載しましょう。推測レベルの内容であっても、不具合の解決につながり得る情報は記載することが理想です。次の文章は一例です。
2025年1月23日10時頃に実施したデータベース管理ソフトのバージョン更新後、商品登録処理で利用しているSQLクエリの一部が新仕様と互換性を持たなくなった。その結果、商品登録時にデータベースへの書き込みが失敗し、エラー123が毎回発生する状況となった。
また、判明した原因を根本的に解消する恒久対策と、問題を一時的に回避する暫定対策もあわせて記載しましょう。次の文章は一例です。まだ原因や対策が固まっていない場合は『原因調査中』『対策検討中』などでも良いでしょう。
【暫定対策】
運用担当者が商品情報を手動でデータベースに直接登録することで対応
【恒久対策】
商品登録機能で使用しているSQLクエリを修正し、更新後のデータベース仕様に適合させるプログラム改修を実施予定。修正版は2025年2月上旬にリリース予定のバージョン1.2.5へ組み込み、適用後に不具合が解消される見込み。
4. 不具合報告書を作成する際のポイント
作成した不具合報告書に不備があっては、関係者に誤解を与えかねません。不具合報告書を作成する際の3つのポイントを押さえておきましょう。
4-1. 具体的に書く
不具合情報はできる限り具体的に記載しましょう。たとえば、「正しく動作しない」といった抽象的な表現では、読み手が状況を正しく理解できません。「商品管理画面で商品名が表示されない」のように、発生している事象を明確に記載することが大切です。数値や条件を盛り込むと具体性が増し、再現や検証がしやすくなります。
4-2. 事実と推測を区別する
不具合報告書には、確定している事実と調査中の推測が混在することがあります。不要な混乱を招かないよう、両者をしっかり区別しましょう。推測の場合は「～の疑いがある」「～と推測される」など、推測であると明確に分かる表現を使用すべきです。事実であれば「システムログから確認済み」など、裏付けを添えると信ぴょう性が高まります。
4-3. テンプレートを活用する
不具合報告書をゼロから書くと時間がかかるうえに、記載漏れや表現のばらつきが生じやすくなります。不具合報告書の作成を効率化したい場合は、テンプレートを活用するのが効果的です。記載項目やフォーマットが用意されていると迷わず記載でき、ミスも抑制できます。チームに合ったテンプレートを整備しておくと、日常的な対応がスムーズになるでしょう。
5. まとめ
不具合報告書とは、ソフトウェアの開発時や運用時に発生した不具合を記録し、関係者へ伝達するための文書です。不具合報告書の作成では、さまざまな項目を記載する必要があります。基本を押さえて漏れなく正確に記載しましょう。
不具合報告書の作成を実践する際には、今回の内容をぜひ参考にしてください。
