よくあることだけど、やっぱり良い慣習とは言えないね。

まさに「誰かがこれで問題ないって言う前にコメントしに来た」って感じで、最初のコメントが「これで問題ない」って言ってるのには驚いたよ。ソフトウェアの人たちがローカルオプティマムを最適化してる感じがする。プログラマー版の「重要なら連絡が来るだろう」みたいなもので、こういう方針の現実的な影響を完全に無視してる。

Appleみたいな会社なら、バグ発生時のシステム状態を完璧にキャッチできる複雑なツールがあるべきだよね。

実際に何もできないのにバグを開けておくのも悪いかもしれない これを他の人からも聞いたことがあるけど、その考え方が本当に理解できない。バグを開けておくことに何の害があるの？

それがどう悪いの？ 開いたままにしておくと、検索してる人にはまだ問題があるってわかるじゃん。アクティブなバグのフィルターにも引っかかるし。修正せずに閉じると、状況がわかりづらくなるだけだよ。実際に問題があるなら、「Issues (1)」のままにしておくのは何も損しないし（プライドを除いて？）。

キャリアの別の部分で、MacをActive Directoryに接続する仕事をたくさんしてたんだ。その実装に関するバグについてAppleからよく聞いたフレーズは「17.x.x.xで動く！」ってやつ。ジョークは、Appleがインターネット上の17.x.x.xクラスAの範囲を持っているってこと（早くに取得したから、第二のクラスBも持ってたし、昔は第二のクラスBも持ってたけど返した）。エンジニアたちが本当に言いたかったのは、Appleが設定したADシステムでは再現できなかったってことなんだ（多くの場合、ADが.localドメインで設定されていたからで、これは本当にダメなことだったんだけど、当時はMicrosoftのトレーニング資料に例として載ってたんだよね…）。

すべてのバグが簡単に再現できるわけじゃない。Appleは再現できないとは言ってないし、修正したとも言ってない。ただ「macOS 26.4 beta 4で確認して」って言うだけだった。 それに、ユーザーにとっては100%再現できても、開発者にとってはそう簡単じゃない。 ユーザーにとっても簡単じゃないよ！ブログにも書いたけど、普段ベータ版は使わないから、このバグをテストするためにmacOS 26.4 beta 4をインストールするのは大変だった。むしろ、Appleがベータを開発してる時の方がテストしやすいんじゃないかな。 一番「効率的」なのは、ユーザーに再テストをお願いすることだね。Appleから見れば効率的だけど、バグ報告者からしたらめちゃくちゃ非効率だよ。 現実的には、これに対して何もできない。 今回は、AppleにサンプルのXcodeプロジェクトと再現手順を提供したから、実際にはそれを試すこともできたはずだよ。

マイクロソフトの（有料）サポートの経験から言うと（5件チケット出したけど、いつも違うチームに回されるし、チケットを内部で移動させるのは負け犬のやることらしい）、再現の証拠を求められるよ。で、彼らは責任を押し付けるチャンスを逃さないんだ。「ああ、ログにアンチウイルスが動いてるのが見えるから、そっちにチケット出して。閉じるね」みたいな。

著者は企業向けソフトウェアで働いたことがないんだろうな。オープンソースプロジェクトとも。クソったれのスターボット。

大企業のソフトウェア業界のベテランなら、毎週または隔週でPMが設定するミーティングがあることはみんな知ってるよね。PMはJIRAのチケットを見て、「これまだ起こってる？」って聞くだけ。デフォルトの答えは「いいえ」、つまり「再現する時間すらないと思うけど、試す気ある？」って感じ。腰抜けのQA担当者のデフォルトの答えも「まだ試してない」だし。それで、PMがチケットを閉じる。リモートで、開発者が君の悪いポーカーフェイスの嘘を見抜けないなら、「はい、確認しました」って言う方がずっと楽だよ。

そうだね。裏側では、これが悪意あるものではないことが多い。あるユーザーが文句を言っていることに時間をかけるか、もっと優先度の高いビジネスのバックログに時間をかけるかの単純なコスト/ベネフィット分析なんだ。自分の仕事でもこれを見たことがあって、ユーザーにとっては悲しいけど、バグ報告を通すのには結構努力が必要なんだよね。

ユーザーが最小限の再現例を考え出さなきゃいけないっていうプレッシャーも嫌だな。これって、ある程度の複雑さのバグは絶対に修正されないってことだよね。だって、いつも数ステップに減らせるわけじゃないし、統計的なものかもしれないし。バグはバグだよ、開発者の意見やバグの複雑さに関係なく。

もちろん、これに対抗する唯一の方法は「はい、確認しました」と言うことだけど、実際には確認しない。嘘はつかないよ。俺はそんな人間じゃない。もしAppleがバグが修正されてないのにバグ報告を閉じたいなら、それは彼らの良心にかかってるね、もし良心があるなら。

すごいね。俺は数年前にChromiumにバグを一つ報告したことがあるけど、それだけだよ。それはCSSエンジンのバグで、完全な再現用のHTMLファイルも添付したんだ。でも、最初に担当になった人が全然やらなかったせいで、修正されるまで数年かかった。結局その人はGoogleを辞めちゃって、しばらく誰も引き継がなかったんだ。でも、最終的には修正されたから、まあ良かったのかな。編集：スレッド内のこのコメントが俺の経験に近いかな。: https://news.ycombinator.com/item?id=47523107 自分がGoogleにいた時も同じことを見たよ。優先度が低いバグは全然見てもらえなかった。

基本的に、無給のシステムエンジニアのQC担当になれって言われてる。 Microsoftのサポートはこれが特にひどい、特にAzureや365の問題に関して。ごめんだけど、君たちのソフトウェアをデバッグするためにお金もらってないから。報告書はこれだし、問題を再現した証拠とログもある。これ以上は提供しないよ。君たちのソフトウェアなんだから、自分たちでデバッグしてよ。

Googleには独自のバージョンがあった。確か、バグには優先度と重大度があって、理由はわからないけど（99%の確率で同じだった）0から4の範囲だった。だから、標準的なバグはp2/s2だった。p0/s0が最も重大で、ユーザーに深刻な影響を与える障害を意味してた。人々はよくp2/s2をp3/s3に変更してたけど、これは基本的に「これには絶対に手を付けないし、二度と見ない」って意味だった。うん、俺もやったことある。自動的に古くなったとして閉じるより、ずっと正直だと思うし、報告者に何度も確認させるのも嫌だ。バグが存在する記録は残ってるから。いつか世界が変わって、これに取り組む時間ができるかもしれない。中優先度のバグにSLAを設定したリーダーたちは、多くのバグが低優先度になることを予想してたんだろうね。彼らはトリアージを強制した、それがポイントだ。> 人々は、自分のバグが格下げされたかどうかを確認するために自動ルールを書いていた。この部分は、人々が「通知しない」ボックスを不適切に使っていて、報告者やウォッチャーが格下げに異議を唱える機会を奪っているサインだね。