効率的なバグ報告をする方法 69
ストーリー by Oliver
考えて書けば答えが見える事も 部門より
考えて書けば答えが見える事も 部門より
k3c 曰く、 "PuTTYの作者Simon Tatham氏が書いた、効率的なバグ報告のあり方についてのドキュメント、"How to Report Bugs Effectively"が和訳され公開されている。「事実を省いてはならない」「エラーメッセージを書き留めよう」「おかしくなったら、何かをするのはすぐにやめよう」「診断もたまには役に立つが、いつでも症状を述べるようにしよう」「バージョン番号を提示しよう」…などなど、至言がいっぱい。ああ、顧客に読ませてやりたい。ていうか読んで？今すぐ？
この文章、プログラマの立場から読めば非常に良く理解できるし共感できるのですが、しかしタブン、知識のないエンドユーザーに読ませても全然理解してくれないんだろうなあ…。"
知ったか君の報告が一番厄介 (スコア:3, 参考になる)
半端に知識のある人のエラー報告だと、自分で勝手に原因を推測してその方向でレポートを書いてよこすので、症状等が偏向して伝えられることが多くて困ってしまいます。
何もわからないから、関係無いものまで症状を全部書いてよこす素人のほうが有難いです。
Re:知ったか君の報告が一番厄介 (スコア:1)
で、結局はデスクトップ画面で止まっただけでした。（まぁこれも問題か）
Windows2000の標準デスクトップは青い→青い画面→ブルースクリーン
Shiftに勝手に張られたシールが悪さをして、スタートアップが実行されなかったみたい…。
おぉ、こわ。
Tak.Miyoshi
というか (スコア:1)
アプリケーションプログラマがヨメ! (by OS屋)
Re:というか (スコア:1)
Re:というか (スコア:1)
Re:というか (スコア:1)
★田舎に生息する時代遅れのFortran&COBOLガイなオタク★
Re:というか (スコア:1)
以後、無限再帰。
"castigat ridendo mores" "Saxum volutum non obducitur musco"
呼ばれたうち99%は外部ファイルの遅れ (スコア:1)
で、呼ばれていってみると大体は外部ファイルが規定時間を過ぎても提供されていないというタイムアウトエラー。そのときはオペレータさんといっしょに「今日も遅いですねぇ」と待つわけです。そして、待つだけしかできないのでそのうちに話しかけて、ナニげに仲良くなってその処理が終わった後にご飯食べにいったりしました。
それはいいとして、そのオペレータさんには重々言い聞かせました。「何か起きたら、すぐに画面のメッセージをメモしてそのまま触らないように」それを守ってくれる人はいいんですけど、言ってもきかない人はいましたねぇ。
効果的な報告ができない人 (スコア:1)
> 共感できるのですが、しかしタブン、知識のないエンドユーザーに
> 読ませても全然理解してくれないんだろうなあ…。"
新聞の身の上相談を題材にした清水義範の小説を思い出しました。
＃ 今会社なんでタイトルとか調べようがないんですが。
つまり、新聞の身の上相談欄の文章に悪文が多いのは、書いた人が問題を
抱えており、悩み、困惑しているからだ、といったような趣旨でした。
効果的な報告のできるできないは、知識のあるなしじゃなくて、
いわゆる「羚羊」タイプの人か「マングース」タイプかによるんじゃないかな。
これを読んでも効果的な報告ができない人は、相変わらずウンザリするほどいると思う。
＃ この文が悪文なのは仕事の合間に書いてて、推敲の時間が取れないからです。私は決して…
あぁ、「ン」が消えてるんですよ。「ビーフン・カレー」ね。
ログを取ろう (スコア:1, 参考になる)
基本的にオペレータやお客さんは素人がやるもんだと考えて設計し、ログ採取とか行うようにしておけばどこで問題が発生したのかオペレータに聞く必要も（もちろん報告してもらった方がいいのは言うまでもないけど）無いわけで、エラーが発生したらメッセージ出力と共にログへ出力、一杯になったらバックアップするなりローテートさせるなりして場合によってはメンテ先へログを自動送付して保管しておくとかしておけば安心かも。
障害発生時にうまく報告してもらえなかった時のための保険をいくつ用意できるかがポイントかもしれません。
虫食い報告 (スコア:1)
『何とかが無いって表示されたんですけど…』
ってヤツ。
って、顧客だけじゃなくて身の回りでも、
『何とかが定義されてませんってエラーになった』
とか…。
どれも現場やログを見に行けば済む話だけど、報告はちゃんとして欲しいよね。
Tak.Miyoshi
Re:虫食い報告 (スコア:1)
「タイプなんとかエラーが出た」
とか言われます。解りやすいんだから、ちゃんと覚えててくれ。
それとも、2ケタの数字も覚えてらんないのか？ と罵倒したくなる不良サポートスタッフ。
Re:虫食い報告 (スコア:1, おもしろおかしい)
いやもちろん、その数字に意味があることが分かる人が
相手なら、それでもいいんですけど。
逆に、曰くありげな、でも素人には意味不明のメッセージ
もやっぱり覚えにくいですね。
そんなわけで、そういう時にはぜひ、
「エラー：りんごの森は大騒ぎ」
「エラー：青りんごのときめき」
「エラー：ふじとむつの競演」
などのインパクトの強いエラーメッセージを出すように
しませんか？ :-)
Re:虫食い報告 (スコア:1)
-- 哀れな日本人専用(sorry Japanese only) --
うぅむ (スコア:1)
バグ報告できるアプリの開発ってことになりますんかねぇ。
# 効率的なバグ？って思ったのは、俺だけ？
Re:うぅむ (スコア:2)
私も初めに戸惑いました。
元ネタの「てにおは」(っての?) はおかしいですよね。
この内容なら「効率的に 不具合を報告する方法」とかなるハズ。
-+- 想像力を超え｢創造力｣をも凌駕する、それが『妄想力』!! -+-
オフトピ(was Re:うぅむ) (スコア:1)
こういうのは英語の表現では良くあるので、直訳するとそういう日本語になってしまいがちです。
今回も直訳したからかな？と思いましたが、原題が "How to Report Bugs Effectively" なので、そういう事でもなさそうです。
ということでこれらの方が原題に近いし日本語的で良いと思います。
「効率的に不具合を報告する方法」by kamuy
「効果的にバグを報告するには」by 件の和訳者
＃ちなみに助詞を意味するのは「てにおは」ではなく「てにをは」です。
Re:オフトピ(was Re:うぅむ) (スコア:2, 参考になる)
「バグ報告をする効率的な方法」
「不具合を効率的に報告する方法」
「バグを効果的に報告するには」
Re:うぅむ (スコア:1, 参考になる)
どっちかというと、暗に、「アプリはログを出すように作っておいたほうが良いぞ」と
言いたいのではないか？という気もします。
ヘタにユーザーフレンドリーとかいうお題目のもと、こういう内部(?)情報を
「隠蔽」しまくっているアプリだと、いざトラブルになると、原因調査のきっかけに
なりそうな情報を得る手段が無くて、ユーザーも作り手も往生してしまいそう。
てゆーか(笑)、往生します。
ログとりのための仕組みで、便利な奴が有ると、色々嬉しいですよね。
DebugWriteを「コンパイルオプションレベルでオフにしてmakeしなおして出荷する」
のではなくて、
「設定ファイルとかデーモンとかをちょっといじるだけで動的にいつでもDebugWriteを取り出せる体制になる」
ようになってないと、色々しんどいっす。はい。
結局、情報を隠せば隠すだけユーザーも作り手も損をするんだよな。
そういう所はOpenSourceそのものとも通じるものを感じます。
Re:うぅむ (スコア:1)
めったに再現しないバグが出るのを恐れて、いつでもログを吐くようにしてあると、ログを出力する方法によっては使いにくかったり目障りだったりします。 Unix の syslog というのは普通に動いている限り不要な情報を出力してもほとんど邪魔にならない点で優れていると思いますが、それでも何でもかんでも吐きまくることはできないし、別にファイルを自分で作って吐くようにすると、普段必要のないログを書いたファイルができるのは使いやすくない、ということで、やっぱりになってしまうと思います。
まあ、どの程度普段からログを出力するか、というのは、明文化されていないけれど感覚的な基準があるように思うので、それに従うべきということでしょう。
// Windows のイベントログって、どう使うことが想定されているのだろう？
鵜呑みにしてみる？
Re:うぅむ (スコア:1)
「方法によっては」なのですか?
じゃあ、その方法ってやつを洗練することを、考えましょうよ。
よだん：
これだけ保存媒体が安くなったんだから、それこそ方法しだいでは色々と、
人に負担を感じさせないログ取りをやりやすいご時世なんじゃないかなあ?
おふとぴ (スコア:1)
ありゃあ、まったくもって意味不明ですな。
作った会社では、仕様なんだろうけどね。
Re:うぅむ (スコア:1)
SAMBAとかみたいにログレベル指定できるアプリあるじゃないですか。
それで良いのじゃない？
Re:うぅむ (スコア:1)
ログレベルが可変なのは重要です。特に、 #99940 [srad.jp] で G7 さんが書かれているように、 configure, make 時のパラメタではなく実行時のパラメタとして指定できると、報告者にとって便利です（報告者にとって便利であれば、もちろん開発者にとっても有利です）。
なぜログレベルが可変だといいかというと、
- 最低限の重要な情報はつねに出力して、ログの量を抑えつつ、めったに再現しないようなバグが発現した場合でも重要な情報が得られるようにしたい
- 重要度の低い情報はログレベルを高く設定したときだけ出力して、再現性の高いバグについては多くの情報を得られるようにしたい
という要求があるからです。バグの内容がわからない状態でどの情報が重要かを判断するのは、けっこう難しいことだと思います……というのが、ぼくが #100175 [srad.jp] で「どの程度普段からログを出力するか」と書いたときにぼくが思っていたことです。わかりにくかったですね。再現性の高いバグばかりならいいんですけどね。
鵜呑みにしてみる？
Re:うぅむ (スコア:1)
……などと書いていたら、危うく「バグがないのが一番いい」ということを忘れてしまうところでした。
鵜呑みにしてみる？
Re:うぅむ (スコア:1)
というわけなので、当然、
みたいな用途を想定したものだと思ったのですが。
まあ、個別のアプリの話してもしようがないですけど、そういうソフトも結構あるよ、ということで。
Re:うぅむ (スコア:1)
でも、例えば今何か新しくソフトウェアを書いていて、ログレベルを可変にしようと決めたとします。このとき、開発者はどの情報が重要かという判断をしなければならないわけですが、この判断はノウハウがないと（あるいは実際にソフトウェアをリリースしてみないと）難しいだろうな、と思ったわけです。
鵜呑みにしてみる？
Sambaのlog levelは動的に変更可能 (スコア:1)
smbd(8)のシグナルを参照のこと。 [samba.org]
効果的に報告をしたつもりでも (スコア:1, 興味深い)
受け取る相手に寛容さが皆無な場合は悲劇にしかならない。
という私の報告に「あんたのファイルが悪いんだろ(文章は当然違うが、文意は同じ)」と返事が返ってきたときには、さすがにキレた。
ファイルがどうのという前に、せめて「再現出来ませんでした」と言えないのか。てゆーか、そもそも再現させようとしてないだろ？こっちは、複数のマシンおよびユーザーで再現することを確認してから報告したんだが。
結局のところ、こいつらは同じ社員で、要は「単なるハードのお守り役」なので細かいとこはよく判らん、というのが真相らしいが。
報告するにしても、相手は選ばないとね。選べるなら。
効果的な報告と思っていても…… (スコア:1, 興味深い)
この説明だと、本当に仕様外のファイルを読ませて仕様外の操作をした結果、仕様外だっつーのっていうエラーが表示されたのを、「エラーだ！」と騒ぎ立ててバグ報告をして、向こうに「だから仕様外だって言ってんだろ！」と呆れられた、というシチュエーションも想像できてしまいます。
バイナリファイルをcatしたら画面が崩れた、とか。
あと「メッセージから推測すると、これが原因ではないかと思うのですが」という報告は基本的に必要無いものです。メッセージがあれば開発者なら原因は推測できるし。
むしろ余計な推測を挟まれると気分を害する人も居ますし、推測が的外れだった場合にはプログラマに小ばかにされるだけですし。
Re:効果的な報告と思っていても…… (スコア:1, 興味深い)
例えて言うなら「Photoshopでデータを読み込んで、ツールパレットのとある機能を選択した瞬間に落ちる」という感じ。
- データの読み込みは正常終了
- 他の機能は使える
という状態。どう考えても、その機能自体にバグがあるとしか考えられなかった。小ばかにされても結構。それで結果的にこっちの仕事が進むなら。「バグではなく仕様です」と言い切っても構わん。他の手を考えるだけだから。
# 実際Windowsじゃ、そうでもしなきゃやってられないでしょ？
#(この件はWindows上の話じゃないけど)
私は使うことが仕事であり、向こうは使う人の面倒を見ることが、少なくとも仕事の一部なはずなのに、自らの職務を放棄した態度が許せなかっただけっすよ。
そんな彼らを「プログラマ」と呼ぶことには思いっきり抵抗がありますが、少なくとも一流のプログラマに必要な資質の一つとして「バグはバグとしてきちんと認める」つーのもあるかな、と思った次第。
Re:効果的な報告と思っていても…… (スコア:1)
バグレポートに原因の推測を含めないも意味がない理由は、
- 明らかでないことは、間違っていて判断の邪魔になるかもしれない
- 明らかなことは書かなくてもわかる
からです。バグレポートに原因の推測を含めないほうがいい理由は、原因の推測を書くことで報告者が安心してしまって、開発者が必要としている情報を書き落とす可能性があるということでしょう。なので、やっぱりバグレポートはなるべく推測を排除して書いたほうがいいと思います。
// 以前ぼくもとあるソフトウェアに関して、「原因の憶測」を付けたバグレポートを書いてしまったことがありますが、たぶん意味はなかったでしょう。害にならなかったみたいなのでまあよかったですが。
鵜呑みにしてみる？
Re:効果的な報告と思っていても…… (スコア:1, 興味深い)
では元ネタのまとめを参考に、自分のバグレポを振り返ってみました。
ソフト、ハードのセットアップは彼ら(私がバグレポをした相手)が行ったものです。したがって環境はすべて把握しているはず。基本的にユーザーが環境を変更することは許されていないし、実際していませんでした。そういう環境下で、特定のファイルを読み込み、特定の操作を行うことで確実にフリーズする、という内容でした。
確かに蛇足だったかもしれない推測は、裏で動いてたシェルのコンソールに出力されていたメッセージを全文引用し、その上で自分の考えを書き添えたものです。
彼らが確認できたのかどうかすら判りませんでした。これではその先に進めません(藁
ホントに最初のコメントの内容(「お前のファイルが悪い」)としか書いてなかったんですよ。ま、電子会議室上での文字データだけのやり取りの話なので、バグレポの内容がどうの以前にコミュニケーション能力に問題あり(私もその一言で頭に血が上ったんで、多分双方とも)、ということではないかと。
Re:効果的な報告と思っていても…… (スコア:1)
つまり動作環境に関しては報告しなかった、ということですよね？
こういう～だから～はず（今回だとセットアップしたのは彼らだから動作環境は把握しているはず）みたいなのは報告を聞く側としては嬉しくないでしょうねえ。
異常動作したファイルというのは開発側に提供されたのでしょうか？
>(私もその一言で頭に血が上ったんで、多分双方とも)
なんにしろ短気すぎでは。
Re:効果的な報告と思っていても…… (スコア:1)
>
> 明らかでないことは、間違っていて判断の邪魔になるかもしれない
> 明らかなことは書かなくてもわかる
>
>からです。
開発者の立場からするとそうなのだろうな、ということは参考になります。
ある実行環境のバグを再現するためにプログラムを書いて報告する際に、バグが
現れたソースから徐々に問題なかった部分を削っていってできるだけシンプルな
ソースにして送ったことがありましたが、その際には完全にピンポイントでは
報告できないが問題なかった部分はこれとこれだからサンプルコードに含まれる
あれかこれに原因があるのではないか、とメールを書いたことがありました。
他にもあるファイルを読み込ませると異常な動作をすることが再現できても
秘密の保守のためなどでそのファイルを渡すことができない場合、推測でも
参考になるだろうと期待して報告することはありましたが、それも邪魔なので
しょうか。反論ではなく開発者の立場から考えたらどうなのだろうと。
kaho
Re:効果的な報告と思っていても…… (スコア:1)
データが秘密のため開発者に渡せないというのは、開発者にとっても報告者にとっても もどかしい状況ですが、そういう状況にどう対処するというノウハウって何かあるのでしょうかね。やっぱり報告者に推測してもらうしかないのでしょうか。
// でも、それができない状況も多々ありそうですし。報告者に正しいバグの原因がわかるというのは、稀な状況のような気がします。
もちろん、報告者が開発者に渡せるような秘密でない（でもちゃんとバグが再現する）テストデータを作ってあげることができれば一番いいのでしょうが。
鵜呑みにしてみる？
これが「フレームのもと」？ (スコア:1)
相手の気持ちを推し量ることも、効率のためには軽視すべからざることかと思います…自分はできてないけど。
Re:効果的に報告をしたつもりでも (スコア:1)
上のスレッド、読んでから書こうね。
# 元発言もろとも「-1:フレ－ムのもと」でモデ希望。
Re:効果的に報告をしたつもりでも (スコア:1)
Re:効果的に報告をしたつもりでも (スコア:1)
混乱されているようですが、問題報告と問題対策は別の過程ですよ。
内部構造に詳しい者以外、見付けても報告しないという体制は敷けるでしょう。その結果、見過ごされたバグだらけのシステムになりますが。
曖昧な{責任|役割}分担は諸悪の根源 (スコア:1)
中途半端な原因追求というなら
まさにこれがそうですね。 症状を的確に報告した時点で担当者が正しく原因を推察できるのはよくあることで、 その場合、上記の作業は全く無駄な工数にしかなりません。
# 他のファイルで正常動作したからどうなんだというのはさておき
報告者は問題の再現条件を正しく伝えれば必要充分です。 あとは、どうしても再現できないときに、 依頼されて環境の相違点を突き止める手伝いをするくらいでしょう。
見付けた奴が直すというのは、オープンソースでこそ有効な方策ですが、 業務の現場で、他人の分担の中身まで詳しかったり、 片手間に修正する余力があったりする人はまれでしょう。
# そういう人のいる環境であって欲しいですけどね
利用者はそうじゃないはず (スコア:1)
バグを報告したいならそれで良いでしょう。
でも多くの場合、ソフトウェアは利用したいからが利用するのであって、バグ報告をしたいから利用するものじゃないんですよね。
誰か、「効率的なバグ報告を受けるには」をマイクロソフト向けに書いてくれないかな～。
受け取る側がへそ曲がりだった場合はどうしたら良いんでしょうね。
マイクロソフトのコードにバグはない [unixuser.org]
Re:利用者はそうじゃないはず (スコア:2, すばらしい洞察)
この場合は単純でしょう。バグフィックスされた新バージョンは新機能がなくとも金になる、ということを説明してあげればよろしい。
＃問題はほとんどのユーザーがバグをバグと認識できず、自然現象だと思ってることだろうけど（笑）
Re:利用者はそうじゃないはず (スコア:1)
あの文章は、人間がヘソを曲げたかどうか?に報告の品質が依存しないようにする、
ための指南だと思います。
事実を脚色なく伝えることにより、人間の技量やヘソに依存せずにすむわけです。
こういうことを考えると結局、ソフトの内部状態を
あまさず(大袈裟か)さらけだすような構造になっているほうが
ソフトってものは(トラブルな時には特に)幸せなんじゃないか?と
思ってしまいます。
余談：
事実によってしか、ソフトは動きません。
そういう不粋なものであることを、いいかげんIT時代とか言われて何年もたってるんだから、
人々(ユーザーも作り手も)が学習してほしいもんだなあ。
そして、不粋ゆえに却って(従来の他のものには無かった)便利さが醸しだせてるということもね。
Re:利用者はそうじゃないはず (スコア:1)
あの文は、「伝言ゲーム」状態を回避するための指南です。
#その指南としてどれくらい優れた文か、は俺にはよくわかりませんが、指向としてね。
そういえば入力データが… (スコア:1)
社外秘だとか言って。
そういう時はユーザに指示して、ユーザ自身がバグが再現しつづけることを
確認しながらデータを修正してもらうんだけど、これがまた厄介。
結局社外秘の部分なしには再現させられなかったり、いつのまにか
エラーメッセージが変わってることにユーザが気が付いてなかったり。
あぁ、「ン」が消えてるんですよ。「ビーフン・カレー」ね。
Re:そういえば入力データが… (スコア:2, 参考になる)
結局、この文章は、オープンソースコミュニティとか、内製のイントラのソフトみたいな、ある程度開発者と使用者の間での協調関係みたいなのができている空間でバグを報告する際には、という話でしかないのだと思います。パッケージ売りする普通のソフトには適用できない。そもそも「一般ユーザ向け」ソフトだったら、エンドユーザに一定の「報告者」スキルを期待する（せざるをえない）のはやっぱり欠陥だと思う。
で、まあ、クラッシュしたらログを自動的に落としてネットワーク経由で送信するように、とかやることになるわけですよね。これまた、クラッシュ時の文書の内容とかを丸ごとログに含めると、それこそ情報漏洩だセキュリティだ、という話になる。難しいですよね。
もちろん、この文書は役に立つしいろんな人に読んでほしいものだと思います。でもこれがちゃんとできるシチュエーションって限定されるのを認識する必要はあると思う。結局は品質評価をしっかりやりましょう、ってことでおさめるしかないのかも、とちょっと思いました。
Re:そういえば入力データが… (スコア:1)
Re:語尾上げ? (スコア:1)
全く同感ですね。
これからは「て裕香」に統一の方向で。
--- （´-`）｡oO(平和な日常は私を鈍くする) ---
Re:語尾上げ? (スコア:1)
ぼくも優香より、平田裕香の方が20倍くらい好きです！
え、読みが違う。マアマア……