はは、夢の中なら何でもありだね。もしユーザーのバグ報告が君の書いたコードよりも詳細だと本気で期待しているなら、その会社は倒産寸前だろう。
ほとんどのユーザーからのフィードバックはこんな感じだ。 「このソフト、全然使えない！」（どの機能が使えないの？どうして使えないの？） 「クラッシュした、クソ！」（どの画面で？どんな操作をした後にクラッシュしたの？） 「お金払ったのに、なんで会員じゃないの？」（あなたのアカウントはどれ？注文番号は？）
見ての通り、ユーザーの世界はシンプルだ。問題に遭遇し、目的が達成できず、不満を感じている。彼らは、テストエンジニアのように、筋道を立てて明確に教えてくれることはないし、その義務もない。
- どのスマホ/PCで（OS、ブラウザバージョン）
- どのようなネットワーク環境で（Wi-Fi/5G）
- 具体的にどのボタンを順番にクリックしたか
- 期待される結果
- 実際に見た結果（できればスクリーンショット付きで）
彼らが提供したくないのではなく、これらの情報が必要だということを全く知らないのだ。医者に行ってどこが悪いかと聞かれたとき、ほとんどの人は「お腹が痛い」としか言わず、「左下腹部に持続的な鈍痛があり、押すと悪化し、昨日冷たいスイカを食べた後から始まった」とは言わないのと同じだ。
もちろん、何事にも例外はある。たまに「エンジェル投資家」レベルの神ユーザーに出会うことがある。彼のバグ報告は、スクリーンショット、画面録画、コンソールエラー情報、再現手順がすべて揃っており、詳細すぎて思わずオファーを出したくなるほどだ。このような報告に出会ったら、すぐに額に入れて、お香を焚いて祀るべきだ。しかし、このようなユーザーの割合は、SSRを引く確率よりも低いかもしれない。
だから、正しい考え方は「ユーザーが詳細な報告を提供してくれることを期待する」のではなく、「ユーザーが有効な情報を何も提供できないと仮定して、どうすべきか？」だ。
- 人に頼らず、技術に頼る：あなたのアプリやウェブサイトにエラー監視ツール（Sentryのようなサービス）を統合する。そうすれば、ユーザー側で問題が発生するたびに、エラーログ、デバイス情報、ユーザーの操作経路などの詳細なデータが自動的にあなたのバックエンドにアップロードされる。あなたはユーザーよりも早く問題を発見し、彼らが文句を言う前に、すでに問題を修正していることさえ可能になる。
- プロダクトデザインに頼る：ユーザーに「自由に記述させる」ためのオープンな入力欄を与えるのはやめる。フィードバックフォームを設計し、選択肢やタグを使って彼らを誘導する。例えば、「機能の問題ですか、それともUI表示の問題ですか？」「どの機能モジュールで問題が発生しましたか？（A/B/C）」といった具合に。これにより、フィードバックの内容を大幅に標準化できる。
- カスタマーサポート/運用に頼る：彼らはあなたとユーザーをつなぐ架け橋だ。彼らを訓練し、探偵のように、優しく、巧みにユーザーの短い不満から重要な情報を引き出せるようにする。
要するに、ユーザーの報告は感情の吐露であり、エンジニアが求めるのは再現のためのロジックだ。感情をロジックに翻訳することは、起業家とエンジニア自身の必須科目であり、それをユーザーに代行させるのは非現実的だ。