プログラマに優しいバグレポートの書き方

東京開発グループリードソフトウェアエンジニア

牧野 克俊

バグとは？

コンピュータプログラムに含まれる

誤りや不具合のこと

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

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

そのためには？

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

バグレポート

何を報告したらいいの？

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

• 分かりやすい要約–結論から記述し、理由や経緯を簡

潔にまとめる

• 前提条件–アプリのバージョン–接続先サーバ–自分の環境

• 時間・ユーザ（キャラクター）名–サーバにあるログを特定するため

の情報

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

• 再現手順–同じことが複数の方法で可能なら

ば、自分がとった方法を–あるならば回避方法

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

• オンラインゲームでは進行不能 >= データ不整合

> サーバダウン > ルール> クライアントダウン > グ

ラフィック > 文言

プログラマの反応

「いや問題でないよ」

「いや問題でないよ」

• プログラマの手元では動いている• 動かないのは環境や状況に違いが

ある

「いや問題でないよ」

• なので、–操作、手順に違いがないが–環境にどんな違いがあるか–勘違いしていないか

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

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

• 操作を正確に伝える–手順–対象

• 勘違いに気をつける

「もう起こせないの」

「もう起こせないの」

• 何かがおかしくなったら、ただちに何をするのもやめる• 可能なかぎり状況を保存した上で

再現確認

「もう一回試してみて」

「もう一回試してみて」

• 面倒くさがらないで• 以前との違いに注意–特にエラーメッセージの違い

その他諸注意

• すみやかに報告する• 既に報告されていても報告する–（正しい）情報は多いほどいい

• 再現方法がわからなくてもとりあえず報告する

• 推測は書かない–書くならば推測だと分かるように

書く• 問題を切り分ける• 要約以外は冗長なぐらいがいい

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

るか

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