ハクソク

世界を動かす技術を、日本語で。

Show HN: ほとんどのユーザーは、報告が非常に簡単でない限りバグを報告しない

350日前

概要

  • バグ報告 は多くのユーザーにとって面倒な作業
  • 従来のフィードバックツール は手間が多く利用されにくい
  • Bugdrop.app はシンプルで直感的なバグ報告体験を提供
  • 非技術者でも利用しやすい 工夫
  • 実際に 利用率が向上 した事例

バグ報告ツールの課題とユーザー心理

  • 多くのフィードバックツールは、 「ユーザーが自発的にバグを報告する」 前提で設計
  • 実際には、 ほとんどのユーザーがバグ報告を避ける 傾向
  • 報告手順が 複雑・長いフォーム入力 や メールアドレスの入力 を要求
    • バグ内容の説明 や アカウント作成 まで求められるケースも
  • ユーザーは 面倒な手順を嫌い、離脱 しやすい
  • SaaSプロダクト運用時にも、 バグは多いが報告は少ない 現実

Bugdrop.app の特徴と工夫

  • Bugdrop.app は ドラッグ可能なバグアイコン を提供
    • ユーザーは 画面上の問題箇所にアイコンをドロップ し、 簡単なメモを入力 するだけ
  • ログイン不要・フォーム入力不要 のシンプル設計
  • スクリーンショット・ブラウザ情報・コンソールログ も自動取得
  • 非技術者も「アイコンが楽しい」 という理由で利用
  • 重厚なフィードバックスイート ではなく、 軽量・高速・直感的 な体験を重視

利用状況と効果

  • 実際に利用率が向上 し、 非技術者からの報告も増加
  • 「何か壊れてる」と言って去るだけのユーザー にも対応可能
  • 開発チームが実際に使える文脈情報 を収集できるメリット

まとめと呼びかけ

  • 同様の課題を感じている開発者 への共感
  • Bugdrop.app のような シンプルな仕組みの有用性
  • 売り込みではなく、自身の課題解決の共有 として紹介
  • 読者の類似体験や意見の募集

Hackerたちの意見

バグ報告が難しいのは、「ページが動かない」ってだけの説明不足な報告や、「隣の人が政府のスパイで証拠もある」みたいな報告をフィルタリングするのに手間がかかるからだよね（実際、ブラウザ会社とかでこういう報告はあるし、Facebookみたいな他の場所でも同じことが言える）。バグ報告が難しいのは同意だけど、効果的なオープンフォームの後に続くスパムの量は、役に立つバグ報告を上回ることが多い。簡単なスクリーンショットを取って、問題の部分に円を描けるタイプの報告と、もっと詳細な報告の2種類があれば便利だと思う。役に立たない報告をフィルタリングするLLMがあれば、それも良さそう。

└

LLMのアイデアについてだけど、報告を問題ごとにグループ化できればいいと思う（ユーザーが提供した入力やページのスクリーンショットから保存したコンテキストを解析して、何かの埋め込みにする）。それから、異なるIPから同じことがX時間内に報告されたときだけエスカレーションするようにすれば、一石二鳥だと思う。スパマーの迷惑度を減らせるし、いくつかのバグ報告を組み合わせることで、良い報告が理解しやすくなるはず。だけど、LLMで報告を短縮したり変形させたり、スパム報告をアクセスできなくするのはやりたくないな。ただエスカレーションのための意味的グルーピングをするだけ。ユーザーから無料で仕事をもらってるのは確かだし、人間の要素はかなり重要だよね。LLMが時々誤解することもあるし。

└

敬意を表して言うけど、それはユーザーがあなたのために_無料_でソフトウェアテストをしてくれる代償だよ！私たちは「ユーザーの声を聞く」聖地にいるのに、ユーザーの声を聞くのが難しいって文句言って、機械に手伝ってほしいなんて。

└

バグ報告が難しいのは、「ページが動かない」ってだけの説明不足な報告をフィルタリングするのに手間がかかるからだよね。 これ、めっちゃわかる。技術サポートを求める人が「プログラムを読み込むとエラーが出る」って言うけど、エラーの内容を全然言わないことがどれだけ多いか。ほとんどの人がQAの仕事をしたことがないから、良いバグ報告の書き方がわからないのは理解できるけど、せめてエラーメッセージをコピー＆ペーストするくらいは期待したいよね。

バグ報告は仕事で、双方向のやり取りが必要なんだ。もし提出がブラックホールみたいな状態（バグ修正に関与していない人からのスクリプト返信があるかもしれない）なら、バグは報告されないよ。

バグ報告の問題は、ほとんど修正されないことだよね。昔はもっとバグ報告をしてたけど、何も返事が来ないことが多くて、簡単に修正できるバグでも結局直らない。最近はあまりバグを報告しなくなったな。

└

公開チケットトラッカーの透明性があれば、それが解決すると思う。

└

ゲーム「Factorio」の開発者は、プレイヤーにフォーラムでバグを報告するように勧めてるんだ。開発者はフォーラムを問題トラッカーとして使って、バグに対して修正を返してくれる。バグを報告するのがより満足感があるかどうかはわからないけど、個人的にはそれがクールだと思ってた。

└

なんか、チームによってはマジで態度が悪くて、全然気にしないんだよね。GTKアプリでメニューが本来あるべき位置から5pxずれて表示されるバグを報告してみて、GTKの開発者が気にするか試してみてよ。あとは、react-testing-frameworkの人たちに「家が燃えてるのに、トイレに手すりをつけろって言ってるようなもんだよ」って言ってみて。そんな経験をすると、バグ報告するのが無駄だって思っちゃうよ。Linuxの産業界は特別なケースで、ソフトウェアエンジニアで問題を特定して素晴らしいバグ報告を提出できるなら、たまに「今四半期で最高のバグ報告をもらった」って言われることもある。特に、ウェブ技術を扱ってるチームだと、若い人たちが多くて、多様性もあって、GPLなんて聞いたこともないから、やりやすいんだよね。

└

そうそう、バグ報告の扱いが残念で、また誰かに報告しようって気が失せちゃうよね。報告者としては、詳細なバグ報告フォームに時間をかけて、スクリーンショットを添付したりすることもあるけど、1時間以上かかることもあって、その間にやってた作業の流れが崩れちゃう。で、その後に起こることって、だいたい以下のどれかだよね。* 無反応。 * 「はい、それは問題です。」って言った後に無反応。 * 6ヶ月後、自動メールで「このバグは非アクティブのため自動的にクローズされました。」 * 2年後に自動メールで「新しいリリースをしましたので、オープンなバグ報告は全て破棄します。」でも、新しいバージョンでまだバグが見つかったら、新しいバグ報告を提出してもいいよって、親切に言ってくれる。 * 「そのバグは知ってるけど、直すつもりはない。」理由は全然わからないし、文化的なミスマッチがあれば、トーンが敵対的に聞こえたりすることも。 * 「これはバグXの重複です。」違うのに。 * バグ報告を怪しくクローズする、たぶん見栄えやメトリクスのために。 * (無反応 FAANG特別版：高プロフィールなバグ報告で、何十人、何百人もの知識のある人たちが数年間も追加していて、みんなこのバグが大問題だって言ってるのに、FAANGの誰も自分たちのバグシステムでこのバグ報告を認識してない理由をコメントで聞いてる。) 提案された実践：もし他の人にバグ報告をするように頼むなら（そのバグ報告フォームを用意して）、受け取ったバグ報告には誠意を持って対応してあげてほしい。 （少なくとも、合理的に見えるバグ報告や、あなたのプロセスに努力を投資したものには。）

スクリーンショット、ブラウザ情報、エラーが出た場合はコンソールログも。もしかしたら、ユーザーが気づいていない敏感な情報を開示することになるかも。

反応が問題なんだよね。バグを報告すると、だいたい以下のどれかになる。1) 何もなし 2) 解決策があるかもしれない、ないかもしれない合理的な返答 3) 3時間もかかるデバッグの旅。3)の開発者は善意でやってるし、素晴らしいコミットメントがあるけど…そんな壮大な冒険に参加したくないんだよね。問題を指摘して、基本的な情報を提供したいだけなのに。最近は、クラッシュログを送ることがほとんどだよ。

ほとんどの会社は、ユーザーがバグを報告するためのアクセス可能な方法がないんだよね。たいていはサポートに電話して、マペットと話して、その後に自分の問題が本物だって納得させないといけない。信じて、私は製品のバグを見つけることが多いし、実際にバグ報告をしようとするけど、できることは稀なんだ。これには、最悪のバグ関連メトリクスの一つが「顧客が見つけたバグ」っていうのが関係してる。これは、開発者がユニットテストで見逃して、テストチームもシステムテストや最終テストで見逃したってことを意味する。実際、顧客がバグ報告できるようになるのは、チームにとって悪く見えるから、誰も望んでないんだよね。

昔は、バグの詳細や自分がやってたこと、可能ならそのバグを引き起こす方法を報告してたんだけど、数年後にすごく一般的な作業をしてるときに同じバグに遭遇すると、報告するのが無駄だって思っちゃう。最近は、数週間前にリリースされた新しいソフトウェアか、新しいバグがある古いソフトウェアの新しいリリース以外は、ほとんどバグを報告しない。プログラムの使用ケースを完全に壊してないバグや、有効なワークアラウンドがない場合は、直ることを期待しないから、時間を無駄にしたくないんだ。報酬もないし、直る可能性も低いし、遭遇するバグの49/50は、実際のQCで見逃すのが不可能に思えるものだから。ユーザーとしてちゃんとしたバグ報告をするのは、まるでカブのトラックを追いかけて、落ちたカブを拾って農家に渡すけど、最初から気にしてなかったから、結局捨てられちゃうって感じなんだよね。もし気にしてたら、最初からトラックを過積載しないようにして、道端にカブが落ちないようにしてたはずだし。

└

プログラムの使用ケースを完全に壊してないバグや、有効なワークアラウンドがない場合は、直ることを期待しない Yep。それが業界全体の一般的な感覚だよね。 [1]: > ここに修正する価値のない別のバグがある：巨大なファイルを開くとプログラムが完全にクラッシュするバグがあって、それがOS/2を使ってるたった一人のユーザーにしか起こらない場合、彼が大きなファイルを使ってるかどうかもわからないのに、直さないよ。海でより悪いことが起こったこともあるしね。同様に、私は一般的に16色の画面を持ってる人や、7年間アップグレードなしの市販のWindows 95を使ってる人に対して、気にするのをやめたんだ。そういう人たちはパッケージソフトにあまりお金を使わないから。

└

いくつかのプロジェクトでバグを報告したことがあるけど、私の経験では、ソフトウェアのチームが小さいほどバグが修正される可能性が高いと思う。Bloomz（私の学校が使ってるひどいコミュニケーションアプリ）や、jpmonette/feed（Node/TypeScriptのRSSフィード生成ライブラリ）、それにNewsblurにも一度報告したことがあって、全部修正されたよ。

└

うん…残念ながら、私の会社はスタートアップだから、報告したバグが無視されることが多くて、同じバグが数ヶ月後もアプリに残ってるのを見ると、モチベーションが下がるよね。15分で直せたかもしれないのに。

└

会社によるね。Appleにバグを報告するなんて夢にも思わないよ、彼らは気にしないから。あなたの言う「カブのトラック」の例えが当てはまると思う。一方で、iA Writerはいつも丁寧に返事をくれて、バグを修正してくれることが多い。企業を一括りにするんじゃなくて、個別に扱うことが大事だよ。個別対応ができる良い会社は成長するし、逆に一括対応だと悪い行動を助長することになる。質に投資する会社はコストを負担する一方で、競合と利益を分け合うことになるし、逆に扱いが悪い会社はコストを削減して、あなたが競合に不満をぶつけることになる。

2022年と2023年には、静的解析ツールを使ってOpenZFSのバグを見つけて修正することに力を入れたんだ。いくつかの難解なバグを見つけたよ。そのうちの一つは、理論的な問題でビッグエンディアンシステムに影響を与えるはずだったけど、誰かが影響を受けたというバグ報告はなかった。修正を含むPRを開けた後、影響を受けた人たちがいたけど、バグ報告をする価値がないと思ってたって言われて、驚いたよ。これがそのPRだよ： https://github.com/openzfs/zfs/pull/13968

私にとって、大きな報告ループで最も致命的なのは、バグを報告しても無反応だったり、あっさり却下されたりして、バグがそのまま残るところだね。MacOS用のTelegramには、何かを削除しようとするとたまにクラッシュするバグがあって、2年前に報告したんだけど、まだ修正されてない。一方で、去年Fireboardのパルスプローブをいくつか手に入れたんだけど、Yoderのスモーカーに接続できない問題があった。すぐにチケットを出して、いくつかの簡単なデバッグ手順をほぼ非同期でやったら、原因と修正策が見つかった。スモーカーのBluetoothスタックがしばらくするとクラッシュするから、使ってないときはスモーカーのプラグを抜くのが簡単な解決策だった。バグはファームウェアに残ってるけど、私には機能する解決策があるから、ファームウェアのアップデートを待ちながら、満足してるよ。

HNでのLLM生成の文章は、もっと軽めにした方がいいと思う。みんなが自分で書いたものより、全然本物っぽくないから。もしエムダッシュのせいだと思ってるなら、それは違うよ；2段落目の終わりで明らかだったから。