1. プログラマに優しい
バグレポートの書き方
東京開発グループ
リードソフトウェアエンジニア
牧野 克俊

2. バグとは？

3. コンピュータプログラムに含ま
れる
誤りや不具合のこと

4. バグを修正するためには
何が必要？

5. プログラマがバグを再現する

6. そのためには？

7. 〜をしたら〜になった
「原因と結果」

8. バグレポート

9. 何を報告したらいいの？

10. • 分かりやすい要約
• 前提条件
• 時間・ユーザ（キャラクター）名
• 起きた現象の詳細
• 証拠
• 詳しい再現手順
• カテゴリ
• 重要度・優先度

11. • 分かりやすい要約
–結論から記述し、理由や経緯を簡
潔にまとめる

12. • 前提条件
–アプリのバージョン
–接続先サーバ
–自分の環境
• 時間・ユーザ（キャラクター）名
–サーバにあるログを特定するため
の情報

13. • 起きた現象の詳細
• 証拠
–画面のキャプチャー
–ログ

14. • 再現手順
–同じことが複数の方法で可能なら
ば、自分がとった方法を
–あるならば回避方法

15. • カテゴリ
• 重要度・優先度
–過大評価しない
–頻度（＝再現の手軽さ）
–影響範囲（人数）

16. • オンラインゲームでは
進行不能 >= データ不整合
> サーバダウン > ルール
> クライアントダウン > グラ
フィック
> 文言

17. プログラマの反応

18. 「いや問題でないよ」

19. 「いや問題でないよ」
• プログラマの手元では動いている
• 動かないのは環境や状況に違いが
ある

20. 「いや問題でないよ」
• なので、
–操作、手順に違いがないが
–環境にどんな違いがあるか
–勘違いしていないか

21. 「どうやって再現する
の」

22. 「どうやって再現するの」
• 操作を正確に伝える
–手順
–対象
• 勘違いに気をつける

23. 「もう起こせないの」

24. 「もう起こせないの」
• 何かがおかしくなったら、ただち
に何をするのもやめる
• 可能なかぎり状況を保存した上で
再現確認

25. 「もう一回試してみて」

26. 「もう一回試してみて」
• 面倒くさがらないで
• 以前との違いに注意
–特にエラーメッセージの違い

27. その他諸注意

28. • すみやかに報告する
• 既に報告されていても報告する
–（正しい）情報は多いほどいい
• 再現方法がわからなくてもとりあ
えず報告する

29. • 推測は書かない
–書くならば推測だと分かるように
書く
• 問題を切り分ける
• 要約以外は冗長なぐらいがいい

30. • 代名詞は避ける
• 絶対に読みなおす
–間違い・抜けがないか
–何も知らない人から見て理解でき
るか

31. • 仕様を調べる
–期待した動作が間違っていないか