未来のいつか/hyoshiokの日記 2004-11-04 バグデータベースを読む http://d.hatena.ne.jp/hyoshiok/20041104 より引用

サポートエンジニアのミッションは顧客の問題を解決する事だとすると、とにかく回避策でもなんでもいいから今ここにある問題を解決したいということになる。簡単な回避策が見つからない場合は(なにがなんでも)問題を修正してほしい(狭い意味でのバグを修正してほしい)ということになる。
できるサポートエンジニアはもちろんコミュニケーションのエキスパートである。単に技術的に優れているだけではなく、顧客の解決したい真の問題を探り当てる天才である。現象的にはソフトウェアのバグのようであるが、そのバグを修正する事が目的ではなく、ある作業を行いたいのにたまたまそのソフトウェアのバグXXXに遭遇しちゃったので、別にXXXという機能を使わなくて、ある作業を問題なく遂行できるのであれば、極論すればバグXXXが直ろうが直るまいが、まあ頓着しないという立場である。その落とし所を動物的勘で見付けて来る天才である。

そう思わせないと"できる"なんて言われないですよね。(苦笑) http://d.hatena.ne.jp/tmpfile/20041014#p1 のとおり、がんばろうっと !

(最後まで)頓着しないってのは、場合によりますね。変更して欲しいという思いは、要求される側より持っている事もあります。
回避策が明確かつ妥当なのに回避策を採用されない時は、技術以外のどこに"真の問題"が潜んでいるのか、これを見つけるのは難しいですね。実例としては「あなたに一度会ってみたかったから」なんてのもあるんですよね．．．
あと、(これはサポートエンジニア一般ではないかもしれませんが、) 問題の根本が実装上のミスであるバグか仕様かなんてどうでも良いと思うこと(またはタイミング)がありますね。事象や再現方法を明確に報告した上で結果が異なる理由が全くわからない内からバグか仕様か決める事ができない場合もありますので。開発してくれる方々へ修正をお願いする段階になったら、どちらなのかによって要望の仕方や要望する事すらできない理由などを確認する上では必要となります。
仕様で発生している不具合だが、まさかそんな使い方して問題になるとは思っていなかったなんて時もありますし．．．これはバグって言いたくないし。

2004-11-05 バグデータベースを読む(その２) http://d.hatena.ne.jp/hyoshiok/20041105 より引用

バグデータベースを読む人の立場から、すなわちバグを直す人の立場から、バグデータベースの書き方のコツを一つ二つ。
バグと思われるものを発見したあなたはどのようにバグを報告するか？あなたはその問題を解決してほしいとせつに願っている。
* 現象の記述
* 再現方法の記述
* 期待される結果
最初にやることは現象をあるがまま報告する。次にその現象を再現する方法を明確にかつ簡潔に記さなければならない。その現象を再現するのに必要なOSのバージョン、ソフトウェアのバージョン、その他関係しそうな事を厳密に記す。そして再現方法を逐一記述する。
最後に本来期待される結果を記す。XXXでYYYするとZZZとなるが、AAAという結果になるべきである。

問題解決の基本中の基本。これが明確になっていなくて問題が片付かないのは、あたりまえ。そろえば一発で解決ってのが物凄く多いわけです。比率はちょっと言えないけど、ここまでが明確になっていればいるほど、解決も速い。例え二度と再現しなくっても問題点が明確になる場合が多いです。

共通の理解をするために、バグの再現方法は重要である。バグを再現できればその問題について９割方解決したと言っても過言ではない。デバッグの最初のステップは問題を正しく理解し、バグを再現することだ。そしてバグを再現できれば最初のステップはクリアしたことになる。
開発者はその実装について詳細をしっているので現象をみれば多くの場合、ほとんど瞬時に原因を特定できる。問題の８割はそのような簡単な問題であると言う事を経験論は示している。残りの２割はソースを読んで詳細を検討しないといけないような問題である。

φ（．．）メモメモ．．．参考にさせて頂きます。

2004-11-07 バグデータベースを読む http://d.hatena.ne.jp/hyoshiok/20041107 から引用
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136290 に対して

コミュニケーションとしては失敗の例である。ここから皆さんは何を学ぶか？どうすればよかったか？

とあるので、明日同じ事を言っているかわからないけど、寝る前の戯言を書いてみます。

何を学んだか。そもそもなぜ今無いのかという理由。それと、要望の具体的な理由や例示した意味が不明確なので、もっと具体的にした上で、かつ相手の返答を加味した上での要望をしたら良いのに、それをしないとこうなってしまうという事。

どうすれば良かったか。まず回避策を実行した上での例示を持って、その回避策のデメリットとメリット(：感謝も含め)の両方を説明。そして、ではこういうやり方はできないだろうかと案と例を提示すれば良かったのではないか。ただ、それで、元々の要望された方の本当にしたかった事が開発者に依頼しただけで実現できたかどうかは、わかりませんね。