「件名の入力がおかしいです」と連絡されても、受け取った人は何を入力したのか、どの画面で、どうなるはずだったのか分かりません。調べる側が再質問している間にも、同じ問題が起き続けます。
この場面では、原因の推測より、別の人が同じ条件を試せる記録を優先します。 最初の報告に「Controllerが悪い」と書く必要はありません。事実と推測を分けてください。
この記事では架空の問い合わせ管理アプリを使い、曖昧な報告を、開発担当者が着手できる報告へ書き直します。
「保存できない」では調査を始められない
まず、次の一文を考えます。
件名が長いと保存がおかしい。早く直してください。
これでは画面の入力制限、サーバーの判定、DB保存、画面表示のどこで問題が起きたかも分かりません。業務上の重要度も、受け取った人だけでは決められません。
書く順番は、対象・条件 → 操作 → 期待結果 → 実際の結果 → 証拠。Atlassianのバグ報告テンプレートも、環境、再現手順、期待と実際の結果を主要な項目としています。
記入済みのバグ報告書
以下は実際の顧客情報を含まない架空例です。仕様書には「件名は1〜100文字」と記載されている前提にします。
| 項目 | 記入例 |
|---|---|
| 表題 | 件名101文字で問い合わせを登録すると、上限エラーが出ず保存される |
| 確認環境 | 検証環境、アプリ版 2026.09.23-rc2、Safari 18、テスト用アカウント |
| 前提 | 「新規問い合わせ」画面を開き、必須の本文に「確認用本文」を入力済み |
| 入力 | 件名に半角英字 A を101文字。入力文字列はテスト票へ添付 |
| 再現手順 | ①新規画面を開く ②件名・本文を上記のとおり入力 ③「登録」を1回押す |
| 期待結果 | 件名の上限エラーが表示され、問い合わせは登録されない（仕様書「件名1〜100文字」） |
| 実際の結果 | 完了画面へ遷移し、一覧にも101文字の件名が1件表示される |
| 再現頻度 | 同じ条件で3回試し、3回とも発生。100文字では発生しない |
| 証拠 | 検証用データだけを映した入力前後の画面と、時刻・リクエストIDを記録 |
| 影響・暫定対応 | 上限外の件名が保存される。検証環境で確認。本番発生の有無は未確認 |
ここでの「101文字」は単なる『長い文字列』より重要です。100文字では正常で101文字では違反、という境界があるからです。日本語の文字数や絵文字の扱いが問題なら、使った文字を正確に残します。入力値を後で思い出して書き換えてはいけません。
「本番でも起きているはず」と推測で広げず、確認できた環境だけを書きます。影響が大きそうなら、本番での発生有無を調べる担当と期限を別に決めます。
再現しないときも、失敗した試行を残す
常に再現するバグばかりではありません。再現できなかった場合に「再現せず」で閉じると、条件を探す手掛かりが消えます。
| 追加で残すこと | 例 |
|---|---|
| 最後に見た時刻 | 9月23日 10:42 JST頃 |
| 見ていた状態 | 下書きから受付済みへ変更した直後 |
| 試した回数 | 同じ操作5回中1回発生 |
| 条件の違い | 発生時は通信が遅かった。通信速度との関係は未確認 |
| 追跡可能な情報 | 安全に共有できるリクエストID、版、ログの時刻 |
この場合、原因欄は空欄でも構いません。「通信遅延が原因」は仮説として明記します。開発側は報告された時刻と版からログを調べ、追加条件を絞れます。
証拠は多ければよいわけではない
スクリーンショットを添えるなら、入力値、エラー表示、一覧の結果が分かる範囲を選びます。画面全体の写真だけで、肝心の件名が読めなければ役に立ちません。動画は操作順が重要な場合に使います。
顧客名、個人のメールアドレス、認証トークン、Cookie、機密データをそのまま報告票や画像に貼らないでください。テストデータで再現するか、共有権限を確認して必要な箇所を伏せます。ログを引用する場合も、IDの一部で追跡できる仕組みを使い、秘密値を複製しないようにします。
「不具合の大きさ」と「いつ直すか」は別に決める
報告者が影響を観測した範囲を書くのは有効です。ただし、その場で修正の優先順位まで断定する必要はありません。例えば件名101文字の登録が業務停止に直結するかは、利用者、データ連携、運用上の制約で変わります。
報告票には事実を置き、修正時期は仕様責任者と開発側で影響・回避策・ほかの仕事を比較して決めます。もし顧客への影響が進行中なら、通常のバグ票だけで済ませず、チームの障害連絡手順に従って即時に伝えます。
提出前の30秒チェック
- 別の人が、手元に同じ入力を用意して操作を試せるか。
- 期待結果の根拠となる仕様や合意を示したか。
- 実際の結果を「エラーになる」などの曖昧な語で済ませていないか。
- 確認した事実と、原因・影響の推測を分けたか。
- 個人情報や秘密値をコピーしていないか。
まずは手元の報告を一つ選び、「期待結果」と「実際の結果」を一行ずつ書き分けるところから始めてください。再現条件を選ぶ考え方は、サイト内のテストケース作成記事へつなぐと理解が進みます。
