バグ管理の基本｜報告の書き方と優先度の決め方

2026年1月25日

＠SOHO編集部

この記事のポイント

✓重要度と優先度の決め方
✓受け付けから完了までの状態の流れ
✓再発を防ぐ振り返りまで順に説明します

開発や試験の仕事をしていると、毎日のようにバグ（プログラムの不具合）が見つかります。見つかったバグがメールやチャットに散らばったままだと、同じバグが何度も報告されたり、直したはずのバグが放置されていたり、どれから直せばよいか分からなくなったりします。バグ管理とは、見つかったバグを1か所に記録し、直す順番を決め、直ったことを確かめるまでを追いかける仕事のことです。うまく回すための要は、道具より先に、報告の書き方と、優先度の決め方と、状態の流れの3つをチームでそろえることです。この記事では、報告のひな形、重要度と優先度の決め方、受け付けから完了までの流れ、再発を防ぐ振り返り、道具の選び方までを順に説明します。小さなチームで担当と期限を共有したい人向けに、国産のプロジェクト管理の Pinateca を使う方法にも触れます。

バグ管理とは何か

バグ管理は、英語ではバグトラッキング（bug tracking）とも呼ばれます。「追跡」という言葉のとおり、バグが見つかってから直るまでの道のりを、途中で見失わないように追いかけるのが目的です。バグを記録して状況を追う仕組みは、一般にバグ管理システムと呼ばれます。

バグ管理システム（バグかんりシステム）、バグトラッキングシステムとはプロジェクトのバグを登録し、修正状況を追跡するシステム。バグ管理システムの多くは、ウェブサーバ上で動作し、ウェブブラウザ経由でアクセスできるようになっている。出典: ja.wikipedia.org「バグ管理システム」

バグ管理で記録し、追いかける情報は、大きく分けて次の4つです。

何が起きたか：症状、再現する手順、期待した動き、実際の動き
どれだけ困るか：影響の大きさ、急ぎの度合い
誰が、いつまでに：担当者と期限
いまどうなっているか：受け付けた、調べている、直した、確かめた、といった状態

この4つが1か所にそろっていれば、チームの誰が見ても、どのバグがどこまで進んでいるかが分かります。逆に、どれか1つでも欠けると、バグは「誰かが直しているはず」のまま、何週間も放置されることになります。

バグ管理は、開発者だけの仕事ではありません。試験の担当者、顧客の窓口の担当者、プロジェクトの管理者、発注する側の担当者など、バグを見つけ、伝え、直し、確かめる人がすべて関わります。関わる人が多いほど、書き方と決め方をそろえておくことが大切になります。

バグ管理が必要になる背景

ソフトウェアは、規模が大きくなるほど、バグの数も増えます。小さなWebサイトなら、気づいたときに直せば済むかもしれません。しかし、利用者が多いサービスや、複数の会社が関わる開発では、同時に数十件、数百件のバグを抱えることも珍しくありません。

近年、ソフトウェアの開発においてはバグの修正が重要な作業と考えられている。バグを漏らさず修正し、再発を防ぐには、バグの発見日時や発見者、再現方法、修正担当者、修正履歴、修正方法、重要度、テスト状況などの多くの情報を残し管理する必要がある。出典: ja.wikipedia.org「バグ管理システム」

近年は、開発の進め方そのものも変わっています。短い期間で機能を追加して公開する進め方が広まり、リリースの回数が増えた分、バグが見つかってから直して公開するまでの時間も短くすることが求められます。バグの記録が整っていないと、どのバグを次の公開に含めるかを決められず、公開の予定が遅れます。

また、在宅や業務委託で開発に加わる人が増え、同じ部屋にいない人同士でバグをやり取りする場面が増えました。口頭で「ここがおかしい」と伝えられない環境では、文章だけで正確に伝わる報告の書き方が、チームの生産性を大きく左右します。

バグの中には、情報が漏れたり、他人に操作を乗っ取られたりする危険につながる「脆弱性」もあります。脆弱性は、ふつうのバグと同じ一覧で誰でも見られる状態にしておくと、直す前に悪用される恐れがあります。脆弱性が疑われるものは、見られる人を限った場所で扱い、ほかの製品やサービスで見つけた場合は、開発元の窓口や、IPA（情報処理推進機構）の脆弱性関連情報の届出の窓口に相談する、と決めておきます。

バグ報告の書き方

バグ管理の出発点は報告です。報告の質が低いと、直す人が状況を聞き返すやり取りが何往復も続き、直すまでの時間が延びます。良い報告とは、直す人が報告を読んだだけで、同じ症状を自分の手元で起こせる報告です。

報告のひな形

報告には、次の項目を入れます。

項目	書く内容
件名	どの画面で、何が起きるかを1行で
環境	端末、OSとその版、ブラウザとその版、アプリの版、本番か試験環境か
再現手順	番号付きで、操作を1つずつ
期待した動き	本来どうなるはずか
実際の動き	実際にどうなったか。エラーの文言はそのまま
再現の頻度	毎回か、10回に1回か
添付	画面の写真、動画、記録の抜粋
影響	誰が、どのくらい困るか

良い例と悪い例

悪い例は「ログインできません」です。どの端末で、どの手順で、どんな表示が出たのかが分からず、直す人は何も調べられません。

良い例を示します。

件名：スマートフォンのSafariで、パスワードの再設定後にログインするとエラーになる

環境：iPhone、iOSの最新版、Safari、本番環境

再現手順：

ログイン画面で「パスワードを忘れた方」を押す
届いたメールのリンクから新しいパスワードを設定する
設定直後に表示されるログイン画面で、新しいパスワードを入力する

期待した動き：ログインしてマイページが表示される

実際の動き：「認証に失敗しました」と表示され、ログインできない。5分ほど待ってからやり直すとログインできる

再現の頻度：3回試して3回とも起きた

このように書けば、直す人は同じ手順で症状を確かめられ、「設定直後だけ失敗する」という手がかりから、原因の当たりも付けやすくなります。

書くときの注意

1つの報告には、1つのバグだけを書きます。複数の症状を1つの報告にまとめると、一部だけ直ったときに状態を付けられなくなります。また、報告には事実だけを書き、「たぶんデータベースの問題です」のような推測は、分けて「気づいたこと」の欄に書きます。推測が外れていると、直す人を誤った方向に導くことがあるからです。

報告の前には、同じバグがすでに報告されていないかを検索します。同じものが見つかったら、新しく作らずに、既存の報告に「別の環境でも起きた」といった情報を追記します。

重要度と優先度の決め方

報告されたバグには、直す順番を付けます。このとき、「重要度」と「優先度」の2つを分けて考えるのが、バグ管理の基本です。

重要度はバグそのものの深刻さ

重要度とは、そのバグが起きたときに、どれだけ深刻な結果になるかを表します。一般には、次のような段階で分けます。

重要度	目安
致命的	サービス全体が止まる、データが失われる、お金の計算を誤る
重大	主な機能が使えない。回避する方法がない
中程度	機能の一部が使えないが、回避する方法がある
軽微	表示の崩れ、誤字など、使うことには支障がない

優先度は直す順番

優先度とは、ほかのバグや作業と比べて、どの順番で直すかを表します。優先度は、重要度に加えて、影響を受ける人の数、起きる頻度、締切や事業の都合を合わせて決めます。

重要度と優先度は、多くの場合そろいますが、ずれることもあります。たとえば、会社のロゴの誤字は、重要度は軽微でも、明日の発表で多くの人の目に触れるなら優先度は高くなります。反対に、年に1回しか使われない管理画面で起きる重大なバグは、次に使う時期までに直せばよいなら、優先度は中程度で構いません。

決める人を決めておく

重要度は、報告した人や試験の担当者が、症状をもとに付けることが多くあります。一方、優先度は、事業の都合を知っている人が最終的に決めます。誰が優先度を決めるかをチームで決めておかないと、報告するたびに全員が「至急」を付け、優先度が意味を失います。

対応の目安の時間を決める

優先度ごとに、対応を始めるまでの目安の時間を決めておくと、判断がぶれにくくなります。たとえば、最優先は見つけたその日のうちに着手、高は次の公開まで、中は今月中、低は手が空いたとき、といった形です。目安はチームの体制や契約によって変わるので、業務委託で保守を受ける場合は、契約のときに取引先と決めておきます。

優先度は一度決めたら終わりではありません。同じバグの報告が次々に届いて影響の広さが分かったとき、取引先の大きな発表が近づいたときなどは、優先度を上げ直します。見直したときは、理由を報告に一言書き添えておくと、担当者が順番の変化に戸惑わずに済みます。

届いた報告を仕分ける手順

報告の書き方がそろっても、届いた報告を誰も仕分けなければ、新規の状態のバグがたまり続けます。届いた報告を確かめて、重要度と優先度を付け、担当者に渡す作業は、英語の医療の言葉から「トリアージ」と呼ばれることもあります。この仕分けを、誰が、いつ行うかを決めておくことが、バグ管理を回すうえでの要になります。

仕分けの頻度と担当を決める

報告の件数が少ないチームなら、毎朝15分ほど、新規の報告をまとめて確かめる時間を取れば十分です。件数が多いチームでは、仕分けの担当を週ごとの持ち回りにする方法もあります。大事なのは、新規の報告が丸1日以上放置されない状態を作ることです。報告した人から見ると、出した報告に何の反応もないことが、いちばん報告する気持ちをそぎます。

仕分けで確かめること

仕分けでは、1件ごとに次のことを確かめます。

同じバグがすでに報告されていないか。重複していれば、元の報告にまとめて閉じる
報告の情報が足りているか。足りなければ、報告した人に追加の情報を頼む
本当にバグか。仕様どおりの動きなら、その理由を書いて閉じる
重要度と優先度はどれか
誰が担当するか

情報が足りない報告への返し方

情報が足りない報告には、責めるのではなく、何が分かれば調べられるかを具体的に伝えます。例文を示します。

「ご報告ありがとうございます。調査のため、次の2点を教えていただけますでしょうか。1つ目は、お使いの端末とブラウザの種類です。2つ目は、エラーが表示される直前に押したボタンの名前です。画面の写真があれば、あわせてお送りください。」

このように聞き返すと、報告した人は次から同じ情報を最初から書くようになり、チーム全体の報告の質が少しずつ上がっていきます。報告のひな形を共有の場所に保存しておき、聞き返すときにひな形の場所も一緒に案内すると、効き目が大きくなります。

受け付けから完了までの状態の流れ

バグには、いまどの段階にあるかを示す「状態」を付けます。状態の名前と、どの状態からどの状態に移れるかをチームで決めておくと、バグが途中で見失われにくくなります。よく使われる流れは次のとおりです。

新規：報告されたばかりで、まだ誰も確かめていない
受け付け：内容を確かめ、重要度と優先度を付け、担当者を決めた
対応中：担当者が原因を調べ、直している
修正済み：担当者が直し、確認を待っている
確認済み：報告した人や試験の担当者が、直ったことを確かめた
完了：公開まで終わった

このほかに、「再現しない」「仕様どおり」「重複」「対応しない」といった、直さずに閉じるための状態も用意します。直さずに閉じるときは、なぜ閉じたのかを必ず書き残します。理由が書かれていないと、同じ報告が何度も繰り返されます。

直した人と確かめる人を分ける

修正済みから確認済みに進めるのは、直した人とは別の人にします。直した人は、自分が想定した手順でしか確かめないことが多く、別の手順で同じバグが残っていることがあるからです。報告した人が再現手順のとおりに操作して、症状が出ないことを確かめるのが基本です。

再び起きたら戻す

確認済みや完了にしたバグが、また起きることがあります。その場合は、新しい報告を作るのではなく、元の報告を「再発」として対応中に戻します。同じバグの履歴が1か所にまとまっていれば、前回の直し方のどこが足りなかったかを調べやすくなります。

原因の切り分けの進め方

担当者がバグを受け取ったら、まず報告の手順で症状を再現できるかを確かめます。再現できれば、原因の半分は見つかったようなものです。再現できないときは、報告した人の環境との違いを1つずつ確かめます。

切り分けでは、条件を1つずつ変えて、症状が出るかどうかを確かめていきます。

端末やブラウザを変えると起きなくなるか
別のアカウントでも起きるか
試験環境でも起きるか、本番だけか
前の版に戻すと起きなくなるか
特定のデータのときだけ起きるか

前の版で起きず、新しい版で起きるなら、その間の変更のどこかに原因があります。変更の記録が整っていれば、範囲を絞り込めます。調べた内容は、結論が出ていなくても報告に書き残しておくと、担当者が交代したときに同じ調査を繰り返さずに済みます。

障害の対応では、原因の究明と、利用者への影響を止めることを分けて考えます。サービスが止まっているときは、まず前の版に戻すなどして影響を止め、そのうえで落ち着いて原因を調べます。急いで原因を探して直そうとすると、別のバグを生むことがあります。

再発を防ぐための振り返り

バグを直して終わりにせず、なぜそのバグが生まれ、なぜ公開前に見つけられなかったのかを振り返ると、同じ種類のバグを減らせます。すべてのバグを振り返る必要はありませんが、重要度が致命的や重大のバグ、利用者に影響が出たバグは、振り返りの対象にします。

振り返りでは、次の3つの問いを立てます。

なぜ起きたか：仕様の読み違い、想定していないデータ、ほかの変更との組み合わせなど
なぜ見つけられなかったか：試験の項目に入っていなかった、試験環境と本番の違いなど
次はどうするか：自動の試験を追加する、確認の手順を変える、仕様書を直す

ここで大切なのは、人を責めないことです。「担当者が注意を怠った」で終わらせると、次も別の人が同じ失敗をします。注意で防ぐのではなく、試験を自動にする、確認の項目を一覧にするなど、仕組みで防ぐ方法を考えます。

振り返りの結果は、バグの報告に追記しておきます。直したバグの一覧を見返したときに、同じ種類の原因が繰り返されていることに気づけば、開発の進め方そのものを見直すきっかけになります。

利用者からの問い合わせをバグの報告につなげる

バグの多くは、開発の中の試験だけでなく、利用者からの問い合わせで見つかります。利用者は開発の言葉を知らないので、「動かない」「おかしい」という表現で連絡してきます。窓口の担当者が、この問い合わせを開発者に伝わる報告に書き直すことが、利用者のバグを早く直すための鍵になります。

窓口で聞き取る項目

窓口の担当者は、問い合わせを受けたら、次のことを聞き取ります。

いつ起きたか。日時が分かれば、記録から原因を探せる
どの画面で、何をしようとしていたか
画面にどんな表示が出たか。可能なら画面の写真を送ってもらう
使っている端末とブラウザ、またはアプリの種類
何度か試しても同じことが起きるか

利用者に専門的な言葉で尋ねると、答えに困らせてしまいます。「お使いのブラウザは何ですか」より、「インターネットを見るときに使っているアプリの名前を教えてください」のように、相手の言葉で聞きます。

利用者への返答

バグと分かったら、利用者には、原因の技術的な説明より、いま何が分かっていて、何をすれば回避できるかを伝えます。例文を示します。

「お問い合わせいただいた件について、こちらで同じ症状を確認できました。現在、修正に向けて対応しております。修正までの間は、パソコンのブラウザからご利用いただくと、問題なくお手続きいただけます。修正が完了しましたら、改めてご連絡いたします。」

修正の時期をはっきり約束できないときは、無理に日付を伝えず、進み具合をこちらから連絡すると伝えます。

直ったら知らせる

問い合わせから生まれたバグの報告には、問い合わせてきた利用者への連絡が必要であることを書いておきます。修正が公開されたら、窓口から利用者に知らせます。ここまでを1つの流れにしておかないと、直ったのに利用者は知らないまま、ということが起きます。直ったことを知らせる連絡は、利用者の信頼を取り戻す大事な機会です。

公開の前後で確かめること

バグを直したら、公開の前と後にそれぞれ確かめることがあります。修正そのものが新しいバグを生むことがあるからです。

公開の前

公開の前には、直したバグの再現手順で症状が出ないことに加え、直した箇所と関係のある機能が、これまでどおり動くことを確かめます。一部を直したことで、別の場所が壊れることを、デグレード（デグレ）と呼びます。デグレを防ぐには、主な機能の動きを自動で確かめる試験を用意しておき、修正のたびに実行するのが確実です。

また、公開してよいかの判断の基準を決めておきます。たとえば、「重要度が致命的と重大のバグが、未完了で残っていないこと」を公開の条件にすれば、公開の直前に誰が判断しても同じ結論になります。

公開の後

公開の後は、エラーの記録や問い合わせの件数を見て、新しい問題が起きていないかを確かめます。公開した直後の数時間は、とくに注意して見守ります。問題が見つかったときに、すぐに前の版に戻せるよう、戻し方の手順を事前に確かめておきます。

公開した修正の内容は、バグの報告に「どの版で直したか」として書き残します。後で同じ症状の報告が来たときに、利用者の使っている版が修正より前か後かを見れば、すぐに切り分けられます。

バグを数字で見る

バグの記録が1か所にそろうと、数字で状況をつかめるようになります。よく見られるのは次のような数字です。

新しく報告された件数と、完了した件数の週ごとの推移
未完了のバグの件数と、重要度ごとの内訳
報告から受け付けまで、受け付けから完了までにかかった日数
再発したバグの件数

新しく報告される件数が、完了する件数を上回り続けているなら、直す人手が足りていないか、新しい機能の開発を急ぎすぎている兆しです。公開の直前に未完了の重大なバグが残っているなら、公開を延ばすかどうかを判断する材料になります。

ただし、件数を個人の成績にするのは避けます。バグを多く報告した人を評価すると細かな報告が増え、バグを少なく出した開発者を評価すると、報告されにくい形で問題を隠す動きが生まれます。数字は、チーム全体の状態をつかみ、次の手を決めるために使います。

バグを生みにくくする日々の工夫

バグ管理は、生まれたバグを追いかける仕事ですが、そもそもバグが生まれにくい進め方をすれば、追いかける件数そのものが減ります。日々の開発の中で取り入れやすい工夫を挙げます。

変更を小さく分ける

一度に大きな変更を加えると、バグが生まれたときに、どの変更が原因かを特定しにくくなります。1回の変更は、1つの目的に絞り、小さく分けて積み重ねます。変更が小さければ、ほかの開発者による確認もしやすく、見落としが減ります。

ほかの人に確認してもらう

コードを本番に入れる前に、ほかの開発者に読んでもらう習慣は、バグを早い段階で見つけるうえで効果があります。書いた本人は、自分の想定に沿って読んでしまうため、想定の外にある入力や手順に気づきにくいものです。確認する側は、細かな書き方より、想定していない入力が来たときにどう動くか、を中心に見ると、バグにつながる穴を見つけやすくなります。

仕様の曖昧さを先に尋ねる

バグの中には、仕様の読み違いから生まれるものが少なくありません。「空欄のまま送信されたらどうするか」「同じ名前の登録があったらどうするか」のように、仕様書に書かれていない場合の動きは、作り始める前に尋ねておきます。業務委託で開発を受ける場合は、尋ねた内容と回答を記録に残しておくと、後で「仕様どおり」かどうかを判断する根拠になります。

過去のバグから試験を作る

一度起きたバグは、同じ形でまた起きることがあります。直したバグごとに、その症状が再び起きないことを確かめる自動の試験を追加しておくと、同じバグの再発を機械的に防げます。バグの記録が整っていれば、どの試験を追加すべきかを、記録から順に拾い出せます。

バグを管理する道具の選び方

バグ管理の道具は、チームの人数とバグの件数によって選びます。

スプレッドシートで始める

数人のチームで、同時に抱えるバグが数十件までなら、スプレッドシートでも管理できます。報告のひな形の項目を列にし、状態と優先度の列にフィルタを付ければ、「対応中の最優先」だけを抜き出せます。始めるのに準備が要らず、誰でも使える手軽さが利点です。

一方で、1件ごとのやり取りや画面の写真を残しにくく、誰がいつ状態を変えたかの履歴も追いにくいのが弱点です。件数が増え、関わる人が増えると、一覧が重くなり、更新の行き違いも起きやすくなります。

専用の道具を使う

規模の大きな開発では、課題管理の専用の道具が使われます。開発の現場では、オープンソースで公開されているRedmine、ソースコードの管理と一体になったGitHubの課題の機能、大規模な開発向けのJiraなどがよく知られています。これらは、状態の流れを細かく決められる、ソースコードの変更と結び付けられるなど、バグ管理に特化した機能を持っています。料金や機能は改定されることがあるので、導入するときは各製品の公式ページで最新の内容を確かめます。

小さなチームで担当と期限を共有したいとき

専用の道具ほどの作り込みは要らないが、スプレッドシートでは担当と期限と進み具合が追いにくい、という小さなチームには、カードで作業を管理するプロジェクト管理の道具が合います。選択肢の1つが、国産のプロジェクト管理の Pinateca です。Pinatecaの公式の案内によると、カンバン、リスト、ガントチャートなど8種類のボードが最初からすべて使え、カードには優先度や顧客名といった項目を自由に追加できます。カードごとのコメントと添付、カード、コメント、添付をまたいだ検索、自分宛てのメンションや担当の割り当てを集める受信箱、社外のゲストの招待にも対応しています。5人まで無料で、クレジットカードの登録も要りません。Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

バグ管理に当てはめると、カンバンの列をこの記事の状態の流れ（新規、受け付け、対応中、修正済み、確認済み、完了）に合わせ、1件のバグを1枚のカードにして動かす使い方になります。カードに重要度と優先度の項目を追加し、報告のひな形の内容をカードの説明に書き、画面の写真を添付します。表で全件を並べるリストのボードを使えば、優先度で絞り込んで、未完了のバグを一覧で確かめられます。

業務委託でバグ管理に関わるときの注意

業務委託で開発や保守を受けると、取引先のバグ管理の仕組みに加わることになります。最初に確かめておきたいのは次の点です。

バグの報告と相談はどの道具で行うか。メールやチャットで受けたバグも、そこに記録するか
優先度を決めるのは誰か。「至急」の連絡を受けたときに、誰の判断で作業の順番を変えてよいか
修正した内容を誰が確かめ、いつ公開するか
保守の契約の範囲に、どの種類のバグの対応が含まれるか。対応を始めるまでの目安の時間はあるか

特に、保守の契約の範囲は、後でもめやすい点です。「納品した機能のバグの修正」と「新しい要望に応じた変更」の境目を、最初に取引先とすり合わせておきます。仕様どおりに動いているのに「バグ」として報告されるものは、仕様の変更として扱うかどうかを相談します。報告の段階で「仕様どおり」の状態を使い分けておくと、範囲の外の作業を記録として残せます。

自分で見つけたバグを報告するときも、取引先の報告のひな形に合わせて書きます。自分のコードで起きたバグを見つけたら、直す前に記録を作り、直した内容と確かめた手順を書き残します。報告の質と記録の丁寧さは、そのまま仕事の信頼につながります。

バグ管理の知識が活きる仕事

バグ管理の考え方は、開発に関わる多くの仕事で求められます。アプリやシステムの開発の仕事では、自分が直すバグも、自分のコードで生まれたバグも、記録の上でやり取りすることになります。開発の仕事の種類はアプリケーション開発のお仕事で紹介されています。再現手順の書かれた報告を出せる開発者は、チームのほかの人の時間を節約でき、どの現場でも頼りにされます。

セキュリティやマーケティングの仕事でも、問題の記録と追跡は欠かせません。脆弱性の対応や、計測の不具合の調査は、まさにバグ管理と同じ流れで進みます。こうした仕事は AI・マーケティング・セキュリティのお仕事にまとまっています。画面のデザインを担う仕事でも、表示の崩れの報告を受けて直す場面が多くあり、デザイン職の働き方はデザイナーの年収・単価相場で確かめられます。

在宅ワークとフリーランスの仲介を2004年から続けてきた運営者として見てきた限りでは、保守や改修の仕事で長く取引が続く人ほど、直した内容を丁寧に記録し、「何を直し、どう確かめ、何が残っているか」を取引先に分かる言葉で伝えています。取引先から見て、記録を読めば状況が分かる相手は、安心して任せられる相手です。中間の手数料が乗らない直接の取引では、同じ予算でも受け手の手取りが厚くなり、こうした地道な信頼が継続の依頼に結び付きやすくなります。

バグ管理の基本は、再現できる報告を書くこと、重要度と優先度を分けて順番を決めること、状態の流れをそろえて最後まで追いかけることの3つです。この3つがチームでそろっていれば、使う道具がスプレッドシートでも専用の道具でも、バグは見失われずに直っていきます。