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

バグブラインドネス

2026年8月30日原文(danluu.com)

概要

  • バグや品質問題 に敏感な著者の観察と体験のまとめ
  • 多くの人が 同じバグ に気付かずに使い続けている現状
  • 自分のバグ検出能力 が特別かどうかの疑問と結論
  • ユーザーや開発者の盲点、ファン心理による欠点の見落とし
  • 習慣的な回避策 や適応行動が盲点を生む仕組み

バグを見抜く目と人々の盲点

  • 多くのバグ を日常的に発見する著者の体験
  • 一般ユーザーは 同じバグに気付かず、問題を見過ごす傾向
  • プログラマーにとっては バグ盲点の克服 が重要
  • 他人にバグを指摘 し続けることで、周囲も問題に気付きやすくなる傾向
  • 著者が 品質評価や改善提案 を依頼される理由
  • 重大なバグ は、普通のユーザーでも致命的な体験につながる
  • 社内評価と実際のユーザー体験の 乖離 がしばしば発生
  • 普通の使い方 でも再現するバグが多いという結論

具体例とファン心理による盲点

  • Google、Bing、Kagi などの検索エンジンの品質問題
    • 検索結果が 低品質なSEOスパム や詐欺サイトで埋め尽くされる事例
    • 一部ユーザーは問題を認めず、 フィルターや工夫で満足 していることが多い
  • Volvoフォーラム における信頼性データ否認
    • 客観的には信頼性が低いのに、 ファンは否定的データを受け入れない
  • Blackboard (コース管理ソフト)の不評
    • 社外では悪評だが、 社内や開発者は高評価 と誤認
    • Wikipediaや調査でも 圧倒的な不人気
  • Discourse (フォーラムソフト)のパフォーマンス問題
    • 指標上の数値を操作 して実際のユーザー体験を損なう事例
    • 開発者自身も 実態に気付かない/認めない 傾向

自分自身の認知と他者との違い

  • 自分の作品や能力の欠点 に敏感な著者の自己認識
  • 他人からの 批判や指摘を歓迎 するスタンス
  • 一般的には 自分や自社の仕事の欠点 を見落としがち

習慣的な回避策と適応

  • バグや不具合への適応行動 が盲点を生む仕組み
    • 例: マウスの不調 を無意識に手の動きで補正
  • 長期間にわたり 不便に慣れてしまう ことで、問題自体に気付かなくなる
  • Google Docs などで自動的に行う回避策の習慣化

まとめ:バグ盲点の克服と意識の重要性

  • バグや品質問題への感度 は、開発者にとって重要なスキル
  • ファン心理や慣れ による盲点に注意が必要
  • 意図的な観察と他者からのフィードバック で盲点を減らす努力の必要性

Hackerたちの意見

最初に著者が見える「バグ」の例が検索結果だった時、他の人には見えないのを見て、もう諦めるしかなかった。「場合によっては、実際の検索結果を送ってくれた人もいたけど、どれも私が見える良い結果は含まれてなかった。」期待に応えられないソフトウェア、特にSEOと検索エンジンの間の長い戦争のような分野では、これは「バグ」じゃないよね。たとえば、ランダムな本を手に取った時にそれがつまらないからって、出版業界に「バグ盲目」があるって言ってるようなもんだ。確かに何かが間違ってるかもしれないし、改善の余地もあるけど、「バグ」って言葉はもっと具体的なものに使おうよ。

後で記事の中で彼は「品質盲目」という言葉を使っていて、これは彼が話している問題のほとんどをより良く表現していると思う。

検索の質がどの時点でバグになるのか?バグとは、実際の動作が記載された動作や意図された動作と一致しない時のことだ。検索結果が検索した内容とほとんど関係がない場合、それはユーザーにとってバグだ。あるいは、意図しない逸脱に対して「バグ」という言葉を使うべきだと言いたいのかな?

ダンは必ずしもバートランド・ラッセルじゃないから、完璧な言葉を使わないことには目をつぶるよ。でも、この文章は、ソフトウェア製品の根本的な問題を説明するための最高の試みの一つだと思う。これほどうまく説明されたことは、僕の経験ではなかった。ぜひ最後まで読んでほしい。

ここには二つの逆の原因があると思う。過度に一致したメンタルモデルか、まったく一致していないメンタルモデル。開発者の場合、バグ盲目は彼らのメンタルモデルがシステムのモデルに非常に近いため、両者に同じ盲点があって、開発者はシステムの外で効果的に考えられないことが多いんだ(典型的な例として「QAがバーに入って、ビールを0杯注文し、-1杯注文し、0.999杯注文する」対「顧客がバーに入って、トイレはどこかと尋ねると、バーがすぐに炎上する」)。一方で、普通の人がシステムと関わる一般的な方法は、彼らが単に…モデルを持っていないこと。全くない。何かをクリックして、それが何をするかを見るだけで、期待通りに動かなければ、肩をすくめて別のものをクリックする。ソフトウェアを使っている非技術者を見ると、彼らが期待される動作と予期しない動作の違いを通常は判断できないことに気づく。なぜなら、そもそも期待を形成していないから。コンピュータは機械というよりもジンのような存在だ。この記事の中でもこう言ってるよね。「Google Docsは、ドキュメントを開いた直後にタイトルボックスに入力した内容が上書きされるような遅延を追加した。」これは開発者がシステムのモデルを形成している例。一般の人は、時々ボックスに入力するとテキストが表示されることを学ぶだけ。表示されない時もある。表示されなければ、もう一度試す。システムが理解されるように設計されているという前提を捨てれば、システムを理解する必要はない。実際には、ひどいエンジニアリングやアンチ機能、ユーザーへの敬意の欠如が広がっていて、それがこのモデルを情報理論的に最適なものにしていることが多い。そういう意味では、私たちを不幸にするものは、Google Docsをエンジニアリングされた製品として扱いたいという歪んだ欲求なんだ。

普通の人がシステムと関わる一般的な方法は、彼らが単に…モデルを持っていないこと。全くない。何かをクリックして、それが何をするかを見るだけで、期待通りに動かなければ、肩をすくめて別のものをクリックする。ソフトウェアを使っている非技術者を見ると、期待される動作と予期しない動作の違いを通常は判断できないことに気づく。なぜなら、そもそも期待を形成していないから。コンピュータは機械というよりもジンのような存在だ。これはほとんどの開発者には全く理解されていないから、インターフェースやUXデザイナーが存在するんだ。開発者、特にFOSSプロジェクトでは、ユーザーがドキュメントを読んでいないとか、ソフトウェアを理解するのに十分賢くないと見下すことが多い。でも、彼らは十分賢い—ただ、技術的な実装の詳細を学ぶ必要がないから。多くの開発者が個人の家計管理アプリを使うのに満足しているのと同じ理由で。ほとんどの非技術者は、技術的な問題を解決することでドーパミンを感じることはなく、そのために必要な知識も持っていない。彼らはただ、コンピュータに必要なことをさせて、自分が本当に情熱を持っていることに戻りたいだけなんだ。競合製品がそのメンタルモデルを持たない人のために作られたインターフェースを持っているなら、ほとんどの非技術ユーザーにとっては、かなり高価でない限り、明らかに選ばれることになる。

モデルを持たない人は、最も簡単に失われるユーザーでもある。彼らはバグを報告したり、何が壊れたかを説明したりしない。彼らはただ二回クリックして、製品が信頼できないと決めて、別のものを使う。そうすると、チームはバグ報告がないのを見て、すべてが大丈夫だと思い込む。

「Google Docsは、ドキュメントを開いた直後にタイトルボックスに入力した内容が上書きされるような遅延を追加した」。まあ、Jiraも多くの入力ウィジェットでそうだよね。ページが読み込まれている間に入力したものは、ページが読み込まれた後に消えちゃう。今やユーザーはこういう反応の悪さを受け入れるように慣れちゃった。

この観察から、ユーザーの下半分がソフトウェアの使い方を学ばないかもしれないという考えに飛躍するのは、まだちょっと無理があると思う。昔は、一貫したUIパターンを確立してたよね。このボタンはXをする、このボタンはYのように振る舞う、ここに問題を解決するためのツールがある。パターンを学んだ人は、すごく生産的になったけど、今はボタンがそれと認識できるかどうかなんて気にしない。下半分のユーザーはどこでもタップするから、彼らのためだけにデザインしようって感じ。もっと多くの人を支援するのはいいけど、その過程で何かを失った気がする。

これはdanluuに賛成だな、少なくとも見出しについては、実際の詳細には関係なく。私は毎日10〜20のソフトウェアバグに遭遇してる(もっと多い気がする)。プライベートデータを漏らすことがなければ、時々1週間くらい画面キャプチャをして、入力データ(キーボード/マウス/タッチパッド/画面)を記録して、その週に遭遇した100のバグを投稿したいと思うこともある。開けた時に黒い画面になるMacOSのバグにも遭遇したことがあるし、iOSのカメラアプリがカメラを開けないこともあった。iOSのキーボードが電話の幅の80%しか使わないことにも遭遇した(すべてのキーが小さい)。それをどうやって直すのか分からない。キーボードを閉じて再度開いてもダメだし、アプリを終了させるのも無理。なぜなら、フォームを入力中で、最初からやり直したくないから。最近、電話の画面がフリーズすることが多くて、指で押しても反応しない。ロックして再ロックすると復帰する。これは新しい問題で(1〜2週間前から発生)、一般的/非一般的。電話のカメラを使って物をスキャンするアプリ(チェックやIDなど)は、ほぼ常に何らかの形で失敗する。物を認識できなかったり、タイムアウトしたり。彼らがテストしたのはオフィスの完璧な条件だけで、実際のユーザーで試したことがないから。

iOSのカメラアプリがカメラを開けないことにも遭遇したことがある。うわ、思い出させてくれてありがとう。時々カメラアプリを開くと、ぼやけた画面が出てくる。電話をロックして再ロックしないと、カメラアプリがカメラが見ているものを表示することができない。私はそれを回避して、生活を続けて、解決策を探したりバグを報告したりしなかった。

これがコンピュータの使い方に関係してると思ってたけど、時間が経つにつれて、実際にはみんな同じバグにぶつかって気づいてないだけだって気づいた。なんで気づかないのか、理由は分かる気がする。下を見て。 >ちゃんと動くけど、開いて試してみると、直感的じゃない作業をいくつかしないと動かない状態になってる。ほとんどの人はUIのナビゲーションが下手なのは、良いUIでも直感的じゃないからだと思う。悪いUIも同様に直感的じゃない。彼らはそれがバグだと気づかない。だって、彼らにとっては全てがバグだから。新しいUIを使って、必要なものをすぐに見つけることができるけど、一般の人たちは、僕より10年も長くそのソフトを使ってても、いまだにいくつかの機能を理解できず、僕が数分や少しのリサーチでできることをできないことが多い。https://grumpy.website/に感謝。大好きだよ。

Hacker Newsで議論の続きを見る