「使えるバグレポート」をあげてもらう秘訣は？ 46
ストーリー by reo
ハッカーと画家を読もう 部門より
ハッカーと画家を読もう 部門より
cheez 曰く、
本家 /. 記事「Ask Slashdot: How To Get Non-Developers To Send Meaningful Bug Reports?」より。
自分は現在主要な社内アプリケーションのメジャーロールアウトを控えている開発者である。β 版は全ての従業員が触れるようになっているのだが、どうすれば彼らから有用なバグレポートを上げて貰えるのか頭を悩ませている。送られてくるクラッシュ画面のスクリーンショットにはページの URL が含まれてなかったり、縮小されて読めないスクリーンショットを送ってきたり、バグレポートを送る意図はあるようだけど単なる苦情でしかないレポートなど、結局は何度もやりとりを往復せねばならずお互いの時間のロスとなってしまう。バグレポートはユーザにメールで送信してもらう形式をとっており、そのメールはトラッキングシステムに登録されるようになっている。どうすれば開発者ではない彼らに十分な内容が含まれている有意義なレポートをあげてもらえるだろうか? 効率的でユーザフレンドリーなバグ追跡システムや方針、基準を求めているのだが、何かないものだろうか?
なお、本家 /. では「システムにバグレポート機能を組み込め (そしてそこは最も重点的にテストしておけ)」といったアドバイスや「開発者がまともなバグレポートをあげられるかといったら大間違いだ」といった意見などが寄せられている。
BTSって一般顧客には無理？ (スコア:4, 興味深い)
最近のBTSを知らないのですが、BTSってやっぱり「ある程度わかってる人」向けなんでしょうかね？
私のところでBugzillaを試しに入れてみたときは顧客どころか、自社の営業の人達から
「使いにくい」と猛反発をうけてしまい、紆余曲折の結果、今は
専任のサポート担当がヒアリングして(BTSは使わず)redmineに直接チケットを入れている形になってます。
ただredmineも本来プロジェクト管理(TiDD)ツールである以上、BTSとしては辛いので
本格的BTS導入の野望は捨てきれてません。
理想は顧客に直接入力してもらうことですが、せめて営業の人達には使って欲しい。
ちなみに某調査 [internet.com]によると人気のBTSは
らしいです。実際に使われた方がいれば、是非イマドキの良いのがあったら教えて欲しいです。
Re:BTSって一般顧客には無理？ (スコア:1)
ツールがあまり導入できない環境で、ここ
http://japanese.joelonsoftware.com/Articles/PainlessBugTracking.html [joelonsoftware.com]やさしいバグトラッキング
を参考にExcelでバグレポート用テンプレート作ったことありますけどなかなかよかったですよ。
（Excelが良かったんじゃなくて入力項目が少なくできてよかった）
さすがに3項目はバグレポートの本質について言ってることなので名前、日付、ステータスなど追加はしますが、それでも報告者は4,5箇所くらい記述すればいいのでどこに書けばいいの？みたいなことはあまりありませんでした。
あとは修正を確認する人達だけが完了にできて、直す人は解決までにしかできないっていうルールを徹底することも参考にしてます。
# 5位以内でもないし10年前の記事でイマドキではなさそうですが。
# yes, fly. no, fry.
Re: (スコア:0)
一応プログラマのつもりだけど、Bugzillaのインターフェースは何が何やらわからない。
あれでバグレポート出してもらうにはそれこそ訓練されたテスターじゃないと無理だと思う。
似たようなケースで、Sourceforgeのプロジェクトページって使いやすいですか？
Re: (スコア:0)
BTSは、開発者レベルの顧客ならともかく、一般顧客には無理です。
せいぜいサポート担当と、調査・対策担当との間で、インシデント管理するのが関の山です。
Re:BTSって一般顧客には無理？ (スコア:1)
そういう意味だとBTSと裏で連携できるインシデント管理ソフトほしいねぇ...
# インシデントという意味でいうとITELとかいろいろな標準(正しい理解か自信はないけど)あるんだし、だれかやらね(チラッ
M-FalconSky (暑いか寒い)
re:バグレポートを送る意図はあるようだけど単なる苦情 (スコア:2)
ユーザが表明したいのは、まさしく苦情であって、
現象の詳細や、ましてや不具合の原因なんかではない。
詳細や原因を書きたがるような奇特なヤツなら、
バグレポートを受ける側になっちまうしね。
ユーザに記入させるのは「ドコでトラブったのか」を示す
ラジオボタンぐらいにしておくべき。
（だが、それすらも、まともな選択は期待できないけど）
トラブルが発生した事を検知したら、
＞何度もやりとりを往復せねばならずお互いの時間のロス
を繰り返して、対応するしかないんじゃないかなぁ。
Re: (スコア:0)
もろもろの事情は省略しますが、うちにはサンダーバードが常駐していて
「なんか変な動きしたよ」と連絡が入るとまず一号隊員が現場に飛んでいき、
状況を確認し、手に負えないと二号が・・・、という状態もありまして、
「変だよ」と連絡くれることが最上のバグレポートな環境でした。
環境や操作タイミングほか条件が様々で関係者が現場で見ないと話が
通じないので。
でもこれがそんなに悪くなかった。
で応対してあげると、よろこんでまた見つけてくれ、それが結構な大バグだったことも。
Re:バグレポートを送る意図はあるようだけど単なる苦情 (スコア:1)
二号のコンテナからLANアナライザとかの機材を取り出して
床の上に機材やコードのたくらせて解析する図を想像しました。
それくらい大仰にやって、障害対応やってます！とアピール
してると、エンドユーザ受けが良さそうです。
-- う～ん、バッドノウハウ？
本文読まずに、タイトルだけ見て、反射的に思った事 (スコア:2)
少なくとも、前提条件として、
「×キロステップあたり、テストで、バグを○件出せ」
とか言ってる検査部門の連中を絞め殺す必要は有るな。
#あえてID
Re: (スコア:0)
> とか言ってる検査部門の連中を絞め殺す必要は有るな。
なんで？
バグ仕込んどいて、それ見つけてもらえばいいじゃん。
どう考えてもWin-Winの関係。すばらしい職場だと思います。
まぁあれだ (スコア:1)
ユーザーに作らせちゃいけないってことですよ
Re: (スコア:0)
ここは、サポート担当がコンサルタントして、いかに顧客の怒りを鎮め、いかに有効な情報を聞き出すかが勝負だと思うのだが、いかに？
やれることといっても、サポート担当がコンサルタントして、既定のフォーマットに穴埋めし、添付資料として、ツールで作成した特定のファイルを送付してもらうしかないのでは？
そのシステムの内部設計まで知っている専門家でなければ、表層的に何が起きたのかは説明できても、本当に何が内部で起きたかは説明できないでしょ。
ユーザー曰く (スコア:1)
「では、バグレポートを出すことで私にどのようなメリットがあるか教えてください。」
Re:ユーザー曰く (スコア:1)
・使っているソフトのバグが直ってor機能が追加されて問題が解消する
(新しいバージョンを買ってくださいの場合もありますが)
・使っているソフトの仕様or既知の不具合で、運用で回避するか別ソフトでないと対応できないことが判明する
・使っているソフトとは別の部分での問題と分かって解決する
(ハードディスクの空き容量不足、必要な機器が接続されてない、OSの設定が違っている等)
・不具合でなかったことが判明する
(その本体スペックだと処理にその程度の時間はかかります、このソフトはその動作をするためのものです等)
・自分の使い方が悪かったことが判明する
(勘違いして別機能のメニューをいじっていた等)
といったあたりがメリットではないかと。
Re:ユーザー曰く (スコア:1)
-- 哀れな日本人専用(sorry Japanese only) --
Re: (スコア:0)
まさにそれですね。
『「使えるバグレポート」をあげてもらう』とかいってる時点でずれてる。
お客様相談室がそういう考えだったとしたら、だまって別の会社の製品買う。
たとえ社内に閉じた話であっても同じ。
Re: (スコア:0)
いや、ごめんですむならそれで良いと思うけど。
でも、それならβテストなんてせずにリリースするわけで。
どこも如何に有益な情報を引き出すかに腐心していると思うよ。
Re: (スコア:0)
っつーか、再現可能なデータまで渡したのにバグ直さないのはどうかと思うぞ＞某社
Re: (スコア:0)
次のバージョンアップから、自分でパッチあてなくても修正されたものがでてくる
オープンソースのフリーウエアを使っていて
ボタン押した順番とエラー出力のコピペと
（英語で状況説明が難しかったので）ソースの修正箇所の
修正前と後を報告したことがあります。
穴埋め式 (スコア:1)
メールみたいな自由記述欄だと、何を書くべきか分かっていない人にまともなものを書かせるのは難しい。
専用フォームかテンプレートを用意して、穴埋め式にしたら、多少はマシなレポートが来るんじゃないかな。
1を聞いて0を知れ!
/.読者に「ユーザ」と「テスタ」を区別してもらうには？ (スコア:1)
知らん。
今こそ逆に考えるべき (スコア:1)
バグレポートがそんなに欲しいのなら、バグを多めに盛り込んでおけばよい。
欲しいのはバグレポートじゃないだろ？なにもクレームが出ないシステムを作ることを忘れたら、
エンジニアはおしまいだぞ。
Re: (スコア:0)
そもそも、バグレポートが欲しいんじゃない。使えるバグレポートが欲しいんだ。
批判するために無理やりな曲解してんじゃねーよ。
レポートに期待しない (スコア:0)
すべての操作のログを取る。
Re:レポートに期待しない (スコア:1)
ログを出しまくった結果、DiskFullでダウンします
Re: (スコア:0)
…とは思うけど、中々難しいよね。
環境やタイミングに依存するバグもあるし、ログが膨大な量になる場合もあるし。
設計に組み込むのも、完璧なログを取るには一筋縄では行かなかったりする。
Re: (スコア:0)
操作ログには、当社および当社の顧客の機密情報が含まれている恐れがあるため、いかなるログの提出もコンプライアンス的にできません。
Re:レポートに期待しない (スコア:2, おもしろおかしい)
復原できないように暗号化(?)しますからって言って、ROT13かけて持ち出した。
さすがにAC
昔いたなぁ (スコア:0)
データを操るアプリケーションで「バグが出ました」としか報告しない人。
改めて「どのデータですか?」って聞かないと教えてくれない。
まずは感謝の気持ちから始めよう (スコア:0)
報告が全然具体的じゃないとか、斜め上から目線はやめよう。
なにか問題があるというのを教えてくれただけでもありがたいと思おうよ。
返事の最初には「ご指摘ありがとうございます」。
そして、困っている相手への共感。
それを心がければ、変われるよ。きっと。
Re:まずは感謝の気持ちから始めよう (スコア:1)
どっちかというとそれは目的と思っている。
感謝の気持ちを忘れてユーザーと向き合いたくない。
だから、やり取りを退屈なものにしないための方法を見つけたい。
↓
開発者ならシステムで解決しよう。
という発想だと思うよ。
Re: (スコア:0)
ベータテストに付き合ってくれる方に感謝の気持ちを持つのは当たり前だけど、そんな精神論ふりかざされてもね。
クレーム処理と混同してない？（クレーム処理も精神論じゃだめだけど）
Re: (スコア:0)
ネタ元の人はもうそのレベルは満たしていて、お互いやり取り多くて時間のむだだよねって思ってる状態なんじゃないかな。しかしどうも技術面がついていかない、具体的に報告したつもりが読み取りきってくれない。積極的に情報提供の意思はあるんだけど提供してくれる情報がどうも的を得ていない。結果3,4往復で済むところが7,8往復くらいになってしまってるとか。
中には苦情言いたいだけ（この手合いは「その苦情解決したいから」と言ってそれ以上の情報求めると「それはそっちの仕事だろ」とキレることも多い）もいるみたいだけど。
使えるバグレポート (スコア:0)
蟲姦物？
そんな都市伝説に踊らされてはいけない (スコア:0)
それはβ版ではないのでは？ (スコア:0)
使えるバグレポートが必要な段階という事はβとして出すのは早すぎたのでは？
なんかおかしい (スコア:0)
これってテストとしてバグだししてるか、単につかっててバグがでたのかで大きく話かわる気がするが・・・
ある日、テスト作業員ＡがＢへバグ報告
Ａ「なんかおかしい」
Ｂ「なにが、どうおかしいの？」
Ａ「こんなのがでるんですよ」
Ｂ「なにが正しい動作か知ってますか？」
Ａ「わからないけど、おかしい」
B「・・・」
省いてちょっと大げさにしてるが大体こんな感じだ。
Re: (スコア:0)
フォーマットを作る (スコア:0)
ユーザには、どういう観点/項目で情報を渡せば、解析の役に立つか、というノウハウは普通持ってませんから、
・発生までの手順
・問題発生の具体的な現象
・動作OS/ブラウザ
:
などのレポートしてほしい項目別に記入欄があるフォーマットを使うとかすると、多少は改善するかもしれません。
（上記の項目程度なら、ソフトウェア自体で情報収集してアップロードするという手も）
とはいえ、フォーマットなしでも開発者が感動するクオリティのレポートを上げてくれる人もいれば、フォーマットを作っても意味不明な情報を入れる人までいますから、銀の弾丸には程遠い…
また、フォーマット付きで入力できる掲示板に誘導して、類似現象はそこに追記してもらう、というのもよいかも。
似たようなことを何度かやったけどさ (スコア:0)
なにい？バグレポートを送る意図があるだって！？それはすごいよ！どんだけ職場の新システムに対する期待度高いんだよ！
β版を一般社員が触れるようにしていて意見くれと言ってる状況だと、一般社員はだいたいろくにテストする気もないか、目が節穴かのどちらかと相場が決まっておる。そして正式版使い始めてはじめて前者はシステムに触れるし、後者は業務フローでの全操作や例外を出すような操作ミスに手を付けるから怒濤のように苦情がくるんだ。
それが普通だよ。すごいよ！ 苦情の内容があさっての方向だったり決定済み仕様に対するお叱りだと凹むけど、αやβ段階で来るだけでうれしいよ。
Re: (スコア:0)
ならベータを外さなきゃいいじゃない
http://ja.wikipedia.org/wiki/%E9%80%86%E6%9F%B1#.E9.AD.94.E9.99.A4.E3.... [wikipedia.org]
# 前職の案件がやっていたのでAC
Re: (スコア:0)
世の無料サービスとかの公開βみたいに甘えられるもんじゃないですよ。
呼び名がβだろうと、業務システムなら本番環境に放り込んだ時点で、WEB系なら一般公開の時点で正式版です。作る側がなんと言おうと使う側の感覚では。
テスト環境（サンドボックス）を触れるようにしておいてある段階では全く意見のひとつもこないこともざらだし、使ってみてOKだと言っておいて本番が動き出してから烈火の如く怒り狂う人も居ますね。「手間二重だけど旧システムと併用で使え」と業務命令が出てるとかだとまた違うかもしれませんが。
開発者以外の人間を人間だと思ってはいけない (スコア:0)
やつらは猿だ
Re:開発者以外の人間を人間だと思ってはいけない (スコア:1)
つまり、開発者じゃなくてボス猿の方がまだ使えると
下手に協力仰ぐよりもむしろ (スコア:0)
「問題があると言うなら、証拠を出せ」という挑発的なスタンスで臨んだ方が、相手も躍起になって再現条件等を探してくれる
…かもしれない。
ちなみにこれと
・罵りながら良いレポートの書き方を丁寧に指導
・お礼ではないと断りつつレポート提出者を優遇（バグ修正版を優先的に提供するなど）
等の手法を併せて「ツンデレメソッド」とでも呼んだらどうだろうか。
パッチでしか受け取らない (スコア:0)
テストコードも含む。