QA担当者やカスタマーサポートが受け取るバグ報告の多くは「動きません」「エラーが出ます」で止まっている。悪いのは報告者の説明力ではなく、多くの場合はフォームの設計だ。自由記述欄をひとつ置いただけのフォームは、専門知識がない人に「何を書けば直してもらえるか」を教えてくれない。開発者が欲しい情報は、聞き方を変えるだけで最初から引き出せる。

なぜ「動きません」としか書けないのか

非エンジニアの報告者は、再現手順・期待値・実際の結果・環境情報という4点セットを知らない。知らないから書けないのは当然で、「詳しく書いてください」という注意書きは何の助けにもならない。有効なのは、質問そのものを分解して、埋めるだけで情報が揃うようにすることだ。

情報が落ちる3つの典型パターン

1. 操作手順が「結果」だけに要約される

「保存ボタンを押したら」ではなく「保存できません」とだけ書かれる。何をクリックし、何を入力し、どの順番で操作したかが省略されるため、開発者は最初の一歩から手探りで再現することになる。

2. 期待値が書かれない

「エラーが出ます」だけでは、それが本当にバグなのか仕様通りの挙動なのか判断できない。「本来こうなるはずだった」という期待値がないと、開発者は仕様書を読み直すところから始めなければならない。

3. 環境情報が抜ける

ブラウザ、画面サイズ、ログイン状態、扱っていたデータの種類——これらが揃わないと、開発者の手元では再現しないケースが増える。「自分の環境では動く」で調査が止まる典型パターンだ。

聞き方を設計する — Before/After

自由記述をなくす必要はない。ただし、自由記述の前に、埋めるだけで4点セットが揃う質問を並べる。

Before: 自由記述だけのフォーム

「不具合の内容を教えてください」（1つのテキストエリアのみ）

After: 質問を分解したフォーム

「どの画面で、何をしようとしましたか？」（操作の起点を固定）
「クリックした順番を教えてください（例：①保存ボタン→②確認ダイアログのOK）」
「本来どうなってほしかったですか？」（期待値を明示的に聞く）
「実際には何が起きましたか？」（結果を期待値と分離する）
「毎回起きますか、それとも時々ですか？」（再現頻度を選択式で）

ポイントは、質問の主語と時系列を固定すること。「何が起きましたか」という漠然とした問いを、「どの画面で」「何をした後に」「何を期待していたか」という3つの短い質問に分解するだけで、回答者は迷わず書けるようになる。

すぐ使える質問テンプレート

フォームやSlackのバグ報告テンプレートにそのまま使える例。

1. どの画面・機能で発生しましたか？
2. 発生直前に何をしましたか？（クリック・入力した順番）
3. 本来どうなるはずでしたか？
4. 実際には何が起きましたか？（エラーメッセージがあれば全文）
5. 毎回発生しますか？ それとも一部の操作・条件だけですか？

選択式にできる項目（発生頻度、ブラウザ、デバイス種別など）はプルダウンやラジオボタンにすると、自由記述より回答の負担が下がり、情報の粒度も揃う。

Bugoon での実践

Bugoon のウィジェットは、報告フォームの自由記述だけに頼らない設計になっている。画面に埋め込んだウィジェットからスクリーンショットとアノテーションを添付でき、クリックやページ遷移などの操作ステップも自動で記録される。報告者が「保存ボタンを押した後に」と手で書かなくても、実際の操作順序がログとして残る仕組みだ。

集められた情報は GitHub Issue として起票され、カンバンボードで管理できる。さらに MCP サーバー経由で Claude Code や Cursor に直接渡せば、再現手順を人力で書き起こす手間なく修正作業に着手できる。

プロジェクトごとにウィジェットの質問項目を業務ドメインに合わせてカスタマイズできると、この記事で挙げたような聞き方の工夫をフォーム側にそのまま反映しやすくなるかもしれない。

「動きません」を再現できる報告に変える聞き方