バグデータベースを読む

開発者と利用者のコミュニケーションの手段としてのバグデータベースをどう利用するかのHOWTOというのは実はあまり議論されていないような気がする。(お、大きくでたな＞自分)
最近ではメーリングリストでのやりとりに関しての(ありがたい)ガイドラインみたいなのがあって、どーすれば自分の意図する回答を得られるか、得られる可能性を大きくできるかというようなことを、ご丁寧にも指南してくれたりする。 http://www.hyuki.com/writing/techask.html とか http://www.geocities.co.jp/SiliconValley/5656/ とか。まあ、どうでもいい話であるが、当事者はそれなりに切実なので、必ずしも無用な長物というものでもない。
商用ソフトの場合、仕様や実装上の問題はバグデータベースを介して開発者と利用者がやり取りをする場合が多い。実際はその間にベンダーの営業やらSEと呼ばれる人や、サポートエンジニアと呼ばれる人が介在するので直には開発者とやり取りする事は少ないのかもしれないが、まあなんらかの形でのコミュニケーションがある。
利用者がサポートのお世話になるのは、利用者の環境で利用者自身が解決不可能な問題に遭遇した場合である。利用者にとって解決不能な問題というのは必ずしもバグとか実装上の不都合というような話ばかりではなく、ちょっとした利用方法が分からないとか、使いにくさへのクレームとかいうも物も含まれる。利用者にとっては自分のブチ当たっている問題を解決してくれればいいわけでそれは必ずしもバグの修正だけではなく簡単な回避策の提示だけでも十分なこともある。まあ、ここらへんはケースバイケースである。
サポートエンジニアのミッションは顧客の問題を解決する事だとすると、とにかく回避策でもなんでもいいから今ここにある問題を解決したいということになる。簡単な回避策が見つからない場合は(なにがなんでも)問題を修正してほしい(狭い意味でのバグを修正してほしい)ということになる。
できるサポートエンジニアはもちろんコミュニケーションのエキスパートである。単に技術的に優れているだけではなく、顧客の解決したい真の問題を探り当てる天才である。現象的にはソフトウェアのバグのようであるが、そのバグを修正する事が目的ではなく、ある作業を行いたいのにたまたまそのソフトウェアのバグXXXに遭遇しちゃったので、別にXXXという機能を使わなくて、ある作業を問題なく遂行できるのであれば、極論すればバグXXXが直ろうが直るまいが、まあ頓着しないという立場である。その落とし所を動物的勘で見付けて来る天才である。
そーゆー人にとってのバグデータベース利用のHOWTOをぜひ知りたいというのが今日のお話であるが枚数が(？)尽きたので明日に続く。(ほんまかいな)

宿題： https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136290 を事例として検討したい。各自よく読んでおいてほしい。