アカウント名:
パスワード:
受け取る相手に寛容さが皆無な場合は悲劇にしかならない。
「このファイル(相手もアクセス可能)を読み込んで、こーやってあーやって操作すると、こんなメッセージを吐きました。メッセージから推測すると、これが原因ではないかと思うのですが」
という私の報告に「あんたのファイルが悪いんだろ(文章は当然違うが、文意は同じ)」と返事が返ってきたときには、さすがにキレた。
ファイルがどうのという前に、せめて「再現出来ませんでした」と言えないのか。てゆーか、そもそも再現させようとしてないだろ?こっちは、複数のマシンおよびユーザーで再現することを確認してから報告したんだが。
結局のところ、こいつらは同じ社員で、要は「単なるハードのお守り役」なので細かいとこはよく判らん、というのが真相らしいが。
報告するにしても、相手は選ばないとね。選べるなら。
それは本当にそのファイルが悪かったんじゃなくて?
例えて言うなら「Photoshopでデータを読み込んで、ツールパレットのとある機能を選択した瞬間に落ちる」という感じ。
むしろ余計な推測を挟まれると気分を害する人も居ますし、推測が的外れだった場合にはプログラマに小ばかにされるだけですし。
小ばかにされても結構。それで結果的にこっちの仕事が進むなら。「バグではなく仕様です」と言い切っても構わん。他の手を考えるだけだから。
# 実際Windowsじゃ、そうでもしなきゃやってられないでしょ? #(この件はWindows上の話じゃないけど)
私は使うことが仕事であり、向こうは使う人の面倒を見ることが、少なくとも仕事の一部なはずなのに、自らの職務を放棄した態度が許せなかっただけっすよ。
そんな彼らを「プログラマ」と呼ぶことには思いっきり抵抗がありますが、少なくとも一流のプログラマに必要な資質の一つとして「バグはバグとしてきちんと認める」つーのもあるかな、と思った次第。
どう考えても、その機能自体にバグがあるとしか考えられなかった。
では元ネタのまとめを参考に、自分のバグレポを振り返ってみました。
バグ報告の最初のねらいはプログラマに自分の目で故障を分からせることである。彼らのところに行って失敗するところを見せることができないなら、彼ら自身で失敗させることができるような詳細な指示書を与えよう。
ソフト、ハードのセットアップは彼ら(私がバグレポをした相手)が行ったものです。したがって環境はすべて把握しているはず。基本的にユーザーが環境を変更することは許されていないし、実際していませんでした。そういう環境下で、特定のファイルを読み込み、特定の操作を行うことで確実にフリーズする、という内容でした。
確かに蛇足だったかもしれない推測は、裏で動いてたシェルのコンソールに出力されていたメッセージを全文引用し、その上で自分の考えを書き添えたものです。
最初のねらいがうまくいかなくて、プログラマ自身では失敗が確認できなかったら、バグ報告の次なるねらいは何がおかしくなるのかを記述することだ。全てを詳細に記述しよう。何を見たのか、どうなるべきだと思うのか述べよう。エラーメッセージを書き留めよう。特に数字が含まれているものは。
彼らが確認できたのかどうかすら判りませんでした。これではその先に進めません(藁
ホントに最初のコメントの内容(「お前のファイルが悪い」)としか書いてなかったんですよ。ま、電子会議室上での文字データだけのやり取りの話なので、バグレポの内容がどうの以前にコミュニケーション能力に問題あり(私もその一言で頭に血が上ったんで、多分双方とも)、ということではないかと。
行間が読めなかったのなら説明するが、彼らは同じ社内にいる管理者、すなわちrootで、こっちは一般ユーザー、しかも設定変更すら許されていないただのアプリユーザー。
セットアップすべてを行った彼らに、いちいち動作環境を報告する必要があるか?マシン名だけで十分だろ。ファイルを提供したのかって?まさか今時各個人がリムーバブルメディアでデータを持っている、とか思ってる?当然サーバー上のファイル名を教えたが、それじゃ不足だとでも?
俺がムカついたのは、バグレポは俺の本来の仕事じゃないにも関わらず
結果として小馬鹿にされた挙句仕事も進まない罠
禿同。
結局その機能自体を無視することに(藁
そん時は、便利そうな新機能だったので使って見たかっただけなのよ。で、今はダメダメでも、バグレポすればより良くなると思った訳よ。妄想だったけどな。
上のスレッド、読んでから書こうね。
# 元発言もろとも「-1:フレ-ムのもと」でモデ希望。
他のファイルを読み込んでも同じ現象が出るんですか? ファイルによって現象が違う場合、何がキーになってるか推測できてるんですか?
混乱されているようですが、問題報告と問題対策は別の過程ですよ。
内部構造に詳しい者以外、見付けても報告しないという体制は敷けるでしょう。その結果、見過ごされたバグだらけのシステムになりますが。
それを中途半端にやってるから問題なんでしょ。
中途半端な原因追求というなら
まさにこれがそうですね。 症状を的確に報告した時点で担当者が正しく原因を推察できるのはよくあることで、 その場合、上記の作業は全く無駄な工数にしかなりません。
# 他のファイルで正常動作したからどうなんだというのはさておき
報告者は問題の再現条件を正しく伝えれば必要充分です。 あとは、どうしても再現できないときに、 依頼されて環境の相違点を突き止める手伝いをするくらいでしょう。
見付けた奴が直すというのは、オープンソースでこそ有効な方策ですが、 業務の現場で、他人の分担の中身まで詳しかったり、 片手間に修正する余力があったりする人はまれでしょう。
# そういう人のいる環境であって欲しいですけどね
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
効果的に報告をしたつもりでも (スコア:1, 興味深い)
受け取る相手に寛容さが皆無な場合は悲劇にしかならない。
という私の報告に「あんたのファイルが悪いんだろ(文章は当然違うが、文意は同じ)」と返事が返ってきたときには、さすがにキレた。
ファイルがどうのという前に、せめて「再現出来ませんでした」と言えないのか。てゆーか、そもそも再現させようとしてないだろ?こっちは、複数のマシンおよびユーザーで再現することを確認してから報告したんだが。
結局のところ、こいつらは同じ社員で、要は「単なるハードのお守り役」なので細かいとこはよく判らん、というのが真相らしいが。
報告するにしても、相手は選ばないとね。選べるなら。
効果的な報告と思っていても…… (スコア:1, 興味深い)
この説明だと、本当に仕様外のファイルを読ませて仕様外の操作をした結果、仕様外だっつーのっていうエラーが表示されたのを、「エラーだ!」と騒ぎ立ててバグ報告をして、向こうに「だから仕様外だって言ってんだろ!」と呆れられた、というシチュエーションも想像できてしまいます。
バイナリファイルをcatしたら画面が崩れた、とか。
あと「メッセージから推測すると、これが原因ではないかと思うのですが」という報告は基本的に必要無いものです。メッセージがあれば開発者なら原因は推測できるし。
むしろ余計な推測を挟まれると気分を害する人も居ますし、推測が的外れだった場合にはプログラマに小ばかにされるだけですし。
Re:効果的な報告と思っていても…… (スコア:1, 興味深い)
例えて言うなら「Photoshopでデータを読み込んで、ツールパレットのとある機能を選択した瞬間に落ちる」という感じ。
小ばかにされても結構。それで結果的にこっちの仕事が進むなら。「バグではなく仕様です」と言い切っても構わん。他の手を考えるだけだから。
# 実際Windowsじゃ、そうでもしなきゃやってられないでしょ?
#(この件はWindows上の話じゃないけど)
私は使うことが仕事であり、向こうは使う人の面倒を見ることが、少なくとも仕事の一部なはずなのに、自らの職務を放棄した態度が許せなかっただけっすよ。
そんな彼らを「プログラマ」と呼ぶことには思いっきり抵抗がありますが、少なくとも一流のプログラマに必要な資質の一つとして「バグはバグとしてきちんと認める」つーのもあるかな、と思った次第。
Re:効果的な報告と思っていても…… (スコア:1)
バグレポートに原因の推測を含めないも意味がない理由は、
なので、やっぱりバグレポートはなるべく推測を排除して書いたほうがいいと思います。
// 以前ぼくもとあるソフトウェアに関して、「原因の憶測」を付けたバグレポートを書いてしまったことがありますが、たぶん意味はなかったでしょう。害にならなかったみたいなのでまあよかったですが。
鵜呑みにしてみる?
Re:効果的な報告と思っていても…… (スコア:1, 興味深い)
では元ネタのまとめを参考に、自分のバグレポを振り返ってみました。
ソフト、ハードのセットアップは彼ら(私がバグレポをした相手)が行ったものです。したがって環境はすべて把握しているはず。基本的にユーザーが環境を変更することは許されていないし、実際していませんでした。そういう環境下で、特定のファイルを読み込み、特定の操作を行うことで確実にフリーズする、という内容でした。
確かに蛇足だったかもしれない推測は、裏で動いてたシェルのコンソールに出力されていたメッセージを全文引用し、その上で自分の考えを書き添えたものです。
彼らが確認できたのかどうかすら判りませんでした。これではその先に進めません(藁
ホントに最初のコメントの内容(「お前のファイルが悪い」)としか書いてなかったんですよ。ま、電子会議室上での文字データだけのやり取りの話なので、バグレポの内容がどうの以前にコミュニケーション能力に問題あり(私もその一言で頭に血が上ったんで、多分双方とも)、ということではないかと。
Re:効果的な報告と思っていても…… (スコア:1)
つまり動作環境に関しては報告しなかった、ということですよね?
こういう~だから~はず(今回だとセットアップしたのは彼らだから動作環境は把握しているはず)みたいなのは報告を聞く側としては嬉しくないでしょうねえ。
異常動作したファイルというのは開発側に提供されたのでしょうか?
>(私もその一言で頭に血が上ったんで、多分双方とも)
なんにしろ短気すぎでは。
Re:効果的な報告と思っていても…… (スコア:0)
行間が読めなかったのなら説明するが、彼らは同じ社内にいる管理者、すなわちrootで、こっちは一般ユーザー、しかも設定変更すら許されていないただのアプリユーザー。
セットアップすべてを行った彼らに、いちいち動作環境を報告する必要があるか?マシン名だけで十分だろ。ファイルを提供したのかって?まさか今時各個人がリムーバブルメディアでデータを持っている、とか思ってる?当然サーバー上のファイル名を教えたが、それじゃ不足だとでも?
俺がムカついたのは、バグレポは俺の本来の仕事じゃないにも関わらず
Re:効果的な報告と思っていても…… (スコア:0)
違うと断言してもよいよ(w
Re:効果的な報告と思っていても…… (スコア:1)
>
> 明らかでないことは、間違っていて判断の邪魔になるかもしれない
> 明らかなことは書かなくてもわかる
>
>からです。
開発者の立場からするとそうなのだろうな、ということは参考になります。
ある実行環境のバグを再現するためにプログラムを書いて報告する際に、バグが
現れたソースから徐々に問題なかった部分を削っていってできるだけシンプルな
ソースにして送ったことがありましたが、その際には完全にピンポイントでは
報告できないが問題なかった部分はこれとこれだからサンプルコードに含まれる
あれかこれに原因があるのではないか、とメールを書いたことがありました。
他にもあるファイルを読み込ませると異常な動作をすることが再現できても
秘密の保守のためなどでそのファイルを渡すことができない場合、推測でも
参考になるだろうと期待して報告することはありましたが、それも邪魔なので
しょうか。反論ではなく開発者の立場から考えたらどうなのだろうと。
kaho
Re:効果的な報告と思っていても…… (スコア:1)
データが秘密のため開発者に渡せないというのは、開発者にとっても報告者にとっても もどかしい状況ですが、そういう状況にどう対処するというノウハウって何かあるのでしょうかね。やっぱり報告者に推測してもらうしかないのでしょうか。
// でも、それができない状況も多々ありそうですし。報告者に正しいバグの原因がわかるというのは、稀な状況のような気がします。
もちろん、報告者が開発者に渡せるような秘密でない(でもちゃんとバグが再現する)テストデータを作ってあげることができれば一番いいのでしょうが。
鵜呑みにしてみる?
Re:効果的な報告と思っていても…… (スコア:0)
>小ばかにされても結構。それで結果的にこっちの仕事が進むなら。「バグではなく仕様です」と言い切っても構わん。他の手を考えるだけだから。
結果として小馬鹿にされた挙句仕事も進まない罠
Re:効果的な報告と思っていても…… (スコア:0)
禿同。
結局その機能自体を無視することに(藁
そん時は、便利そうな新機能だったので使って見たかっただけなのよ。で、今はダメダメでも、バグレポすればより良くなると思った訳よ。妄想だったけどな。
これが「フレームのもと」? (スコア:1)
相手の気持ちを推し量ることも、効率のためには軽視すべからざることかと思います…自分はできてないけど。
Re:効果的に報告をしたつもりでも (スコア:0)
開発側からすると、
バグレポートしてくれるユーザも、選べないんですよね。
Re:効果的に報告をしたつもりでも (スコア:0)
で、その行動内容は報告したんですか?
他のファイルを読み込んでも同じ現象が出るんですか?
ファイルによって現象が違う場合、何がキーになってるか推測できてるんですか?
ろくに切り分けもせず
Re:効果的に報告をしたつもりでも (スコア:1)
上のスレッド、読んでから書こうね。
# 元発言もろとも「-1:フレ-ムのもと」でモデ希望。
Re:効果的に報告をしたつもりでも (スコア:1)
Re:効果的に報告をしたつもりでも (スコア:0)
それを中途半端にやってるから問題なんでしょ。
やるなら全部やれ、やらないなら手を出すな。
Re:効果的に報告をしたつもりでも (スコア:1)
混乱されているようですが、問題報告と問題対策は別の過程ですよ。
内部構造に詳しい者以外、見付けても報告しないという体制は敷けるでしょう。その結果、見過ごされたバグだらけのシステムになりますが。
Re:効果的に報告をしたつもりでも (スコア:0)
バグ報告の時に原因追及までやりたいんなら、きっちりやってくれ。
やりもしないで、やったような顔して報告すんな
できないのなら、報告だけしてくれ。
ってことで。
曖昧な{責任|役割}分担は諸悪の根源 (スコア:1)
中途半端な原因追求というなら
まさにこれがそうですね。 症状を的確に報告した時点で担当者が正しく原因を推察できるのはよくあることで、 その場合、上記の作業は全く無駄な工数にしかなりません。
# 他のファイルで正常動作したからどうなんだというのはさておき
報告者は問題の再現条件を正しく伝えれば必要充分です。 あとは、どうしても再現できないときに、 依頼されて環境の相違点を突き止める手伝いをするくらいでしょう。
見付けた奴が直すというのは、オープンソースでこそ有効な方策ですが、 業務の現場で、他人の分担の中身まで詳しかったり、 片手間に修正する余力があったりする人はまれでしょう。
# そういう人のいる環境であって欲しいですけどね
Re:効果的に報告をしたつもりでも (スコア:0, 余計なもの)
>受け取る相手に寛容さが皆無な場合は悲劇にしかならない。
そういう場面で「寛容さ」なんぞを問題視する人こそが、
該当文で指摘されてる問題をおこしてしまう人、だと思います。
寛容じゃ話になりません。該当文の趣旨からも判ることかと思いますが、
むしろ厳格さが重要です。
理由は簡単。ソフト自体が厳格だからです。
ほら、プログラマが書いたとおりに厳格に動くでしょ?
バグが入るように書けば(書いたつもり、ではなく)、その通り動くでしょ?
>私の報告に「あんたのファイルが悪いんだろ(文章は当然違うが、文意は同じ)」と返事が返ってきたときには、