バグ報告フォーム

優先度判定のルール

影響度（Q8）と再現性（Q5）の組み合わせで、エンジニアの対応優先度を自動判定できます。

• 業務が完全に止まる × 毎回再現 → P0：当日対応
• 業務に支障あり × 毎回 〜 ときどき → P1：48時間以内
• 回避策あり × 毎回 → P2：次スプリント
• 小さな不便 × 1回だけ → P3：バックログ

営業時間外でも P0 は即時通知が望ましく、Webhook で Slack / PagerDuty に自動連携する運用が標準です。

再現手順の質を上げるコツ

Q4（再現手順）は自由記述ですが、回答者の負担が大きく、空欄や不十分な回答が多い項目です。プレースホルダーで例を示すと品質が大きく上がります。

• 「1. /dashboard を開く」「2. レポートタブをクリック」のような番号付き手順
• スクリーンショット URL を貼る欄を別途追加してもよい

Q2（何が起きたか）と Q3（本来どうなるべきか）を分けて聞くことで、回答者の頭の整理を助け、結果的にQ4の質も上がります。

環境情報を必ず取る理由

OS（Q6）とブラウザ（Q7）が分からないと、エンジニア側で再現できず無駄な調査時間が発生します。「iOS Safari でだけ起きるバグ」「Edge 特有の挙動」など、環境固有の不具合は全体の20〜30%。

さらに精度を上げたい場合は、以下の追加項目を検討します。

• ブラウザのバージョン番号
• 画面サイズ（モバイル/タブレット/PC）
• アプリのバージョン（モバイルアプリの場合）
• アカウントID（社内ツールで重要）

サポート ↔ エンジニアの引き渡し

回答が来たら、サポートチームが以下を確認してエンジニアへ引き渡します。

• Q1〜Q5：再現可能か（不明なら回答者に追加質問）
• Q6〜Q7：環境を再現可能か（テスト環境準備）
• Q8：優先度を確定（緊急ならエスカレーション）
• Q9：進捗連絡先（修正後の確認依頼用）

Webhook で GitHub Issues / Jira に自動起票する運用なら、サポート手作業を削減できます。

カスタマイズの提案

本テンプレートは汎用バグ報告ですが、プロダクトによって以下を追加すると有効です。

• 影響範囲：自分だけ / チーム全体 / 顧客にも影響
• 発生日時：いつ初めて気づいたか
• 既存のワークアラウンド：回避策があるか
• スクリーンショット添付欄

レポアンはAIで「バグ報告フォームに『影響範囲』設問を追加して」とチャットすれば即座に反映可能です。