バグ報告の書き方

「サイトが変です」と報告されて、どこを見ればいいのかわからない。報告を書く側も、受ける側も、困ってしまう場面です。

ひなたが、バグを見つけてケンジのところに駆け込んできました。

バグ報告の目的

バグ（不具合）の報告で、いちばん大事なのは、直す人が、同じ現象を自分で起こせることです。

自分の環境で再現できないバグは、原因を探る手がかりがなく、直すのが大変です。報告を書く人の仕事は、直す人の時間を節約することです。

3 点セットで書く

バグ報告は、次の 3 つを書きます。

項目	書くこと	例
再現手順	どう操作すると、起きるか	1. トップページを開く 2. 右上のメニューを押す 3. 背景部分を押す
期待する動き	本来は、どうなるはずか	メニューが閉じる
実際の動き	実際には、どうなったか	メニューが閉じず、そのまま残る

再現手順は、番号つきで

「トップで、メニューを開いて、背景を押すと」のような文章より、番号つきの手順のほうが、同じ操作を再現しやすくなります。手順は、初めて見る人にもできる細かさで書きます。

期待と実際は、必ず両方

「期待」と「実際」の 2 つを書くと、何が問題なのかが、はっきりします。「実際」だけでは、直す人が「仕様どおりかも」と迷います。

再現手順の書き方の例です。

1. 1
   トップページを開く

   端末は iPhone、iOS の Safari

2. 2
   右上のメニューを開く

   ここまでは問題なし

3. 3
   背景部分を押す

   期待：メニューが閉じる / 実際：閉じずに残る

番号つきで、初めて見る人にもできる細かさにします。

環境も書く

バグは、環境によって起きたり起きなかったりします。次の情報を添えます。

• 端末: iPhone 15、Windows の PC など
• OS: iOS 18、Windows 11 など
• ブラウザ: Safari、Chrome など（バージョンも）
• 画面の大きさ: スマホ、タブレット、PC
• ログインしていたか、どのアカウントか（会員サイトなどの場合）

特に Web 制作では、ブラウザと端末の違いが原因になることが多いです。

あると助かるもの

• スクリーンショットや画面録画
• 発生する頻度（毎回か、たまにか）
• 発生した日時
• エラー画面や、メッセージの文面（そのままコピーして貼る）
• 試したこと（再読み込みしたら直った、など）

画像は、文章 100 行より、伝わることがあります。

悪い報告と、良い報告

悪い例です。

サイトが変です。直してください。

良い例です。

件名: スマホでメニューが閉じない 環境: iPhone、iOS の Safari 手順: 1. トップページを開く 2. 右上のメニューを開く 3. 背景部分を押す 期待: メニューが閉じる 実際: 閉じず、そのまま残る 頻度: 毎回 添付: 画面録画

バグ報告の課題は、こんな見た目になります。

• 種別が「バグ」の札になっている
• 件名は、起きている現象（「スマホでメニューが閉じない」）
• コメントに、環境（iOS の Safari）と、起きることが書かれている

原因を推理しすぎない

報告では、見たことを書きます。「たぶん CSS のせいです」のような推測を入れると、直す人が迷います。推測を書くなら、事実とは分けて、「推測ですが」と添えます。

バグ報告を出す前に、見直す項目です。

• 件名が、起きている現象になっている
• 再現手順が、番号つきで書いてある
• 期待する動きと、実際の動きの両方がある
• 端末・OS・ブラウザを書いた
• スクリーンショットや録画を添付した

全部にチェックがつけば、直す人がすぐ再現できる報告です。

まとめ

• バグ報告は、直す人が同じ現象を起こせるように書く
• 再現手順・期待する動き・実際の動きの 3 点セット
• 手順は番号つきで、環境（端末・OS・ブラウザ）も書く
• スクリーンショットや頻度があると助かる
• 事実を書き、推測は分けて書く

akamine でやるなら

akamine では、課題の種別を「バグ」にして報告できます。種別ごとに、必須にする入力項目を決められるので、バグには再現手順を必須にしておく、といった運用ができます。スクリーンショットや録画は、課題に添付できます。「課題の項目」「添付ファイル」「種別と入力項目」を見てください。

• 上に、タスク・バグ・要望・その他の種別が並ぶ
• 下の「入力項目」で、種別ごとに項目の「使う」「必須」を切り替える

関連する記事

• 種別を分ける意味
• 良い件名の書き方
• テストとチェック