[サイトTop] [As/R Top] [ヘルプTop] [戻る]
オマケ
※注意 バグを発見したらあんまりソフトとは関係ないですが、うまいバグ報告の方法を紹介します。多分、他所の作者さんも似たようなことを考えているんじゃないかなと思いますので、参考例として考えていただければと思います。 もちろん私も、ユーザーの立場にもなることがあるわけで、身につまされる思いがヒシヒシとしますし。（苦笑） この手の話題は検索すればいっぱい似たような記事が出てきます。 検索するためのキーワードだと「バグ報告 書き方」「不具合報告書」あたりなどが良いかもしれません。 これらを、作者視点でセキララに思いっきり噛み砕いた表現で語ってみます。 完璧なプログラムというのは、まず間違いなく作れないものですから、ソフトウェアにバグはつきものです。 作成当時は完璧であっても、周りの環境変化によって不具合になってしまうことも多々・・・Wind○ws Updateの○そ野郎・・・・あります。 不具合が解決したらユーザーさんのメリットにもなりますし、作者からすれば完成度を上げられます。 また似たような質問を受けなくて良くなるので、バグは発見し次第ガンガン報告してもらえると助かります。 正直なところ不具合修正って、すさまじい苦痛というか苦行ですからねぇ（遠い目） さて、顔の見えないコミュニケーションでは、言うべきことを正確に伝えるというのは、とても難しく、しかもめんどくさいです。 今回の最重要ポイントは「作者にどういう問題があるのかを認識させるか？」これが一番のキーワードです。 仕様かバグか切り分け ヘルプに書いてあったり、仕様通りだからといって、変な動作はやっぱし変であることが多々あります。基本的に「意図」して作ったモノは「仕様」という事になりますが、この「意図」そのものが間違っていることは良くあることです。 一般に「仕様バグ」という物で、考慮漏れや配慮漏れ、意図を伝える手段が欠けてるとか分かりにくいとか、様々な問題が埋まっていることがあります。 ですから「○○は仕様ですか？」とか聞いちゃうのは、まさに愚問です。 これはバグ報告ですらありませんし、ただの質問なのでほとんど役に立ちません。 まれに作者が機嫌や都合が悪いと「また、ヘルプ読め的な質問かよー」というありがちな経験則で判断し、第一印象でテンションが急降下、その結果適当な返事を返すことすらありえます。 それくらいの扱いがされちゃう聞き方（質問なので「報告」じゃない）なので、これはいけません。 最初にガツンとやらなきゃ、まとまる交渉事もまとまりませんので、きちんと裏付け調査をしておく必要があるのです。 まぁ、あらかじめ作者の逃げ道をふさいでおく方法を伝授します・・・という言い方でも良いかもしれませんね。 1.最新版に更新します。 β版が公開されている場合は、更新履歴を参照して該当項目が無いか確認します。新機能や目立つ項目は、やはり同じ事を考える人は多いものです。 目立つ項目＝報告数が多いとなると、改善可能性も高くなるので新しい版に反映されている場合も多々あるのです。 2.既知の不具合が公開されている場合は、そちらを確認します。 直したくても方法が分からないもの、行き詰っているものを催促されると、わりと心苦しいです。ずっと心に留めているんで、そっとしておいてあげてください。 3.制限事項の一覧が公開されていれば、記載されていないか確認します。 ウチはヘルプの該当項目に山盛り書いていますが、制限事項があまりにも多い（機能数多すぎ）なので、まとめていません。制限が発生しうるであろう箇所のヘルプに、その都度説明する形式を取っています。 大抵は、こうありたいという気持ちがありながら、何らかの制限を設けているもので、ご理解を頂きたいと思います。 4.FAQやヘルプの関連しそうな項目に目を通します。 おそらく「ヘルプ読め」と返事されるのは、誰しも嫌ですよね？実は、そんな返事する方も嫌なんですよ。 気まずい雰囲気をかもし出さないように＋作者がたわけた反論してたら 不具合であろうと思われる場合 アプリケーションが強制終了したというのは当然バグですが、意図しない動作をした場合もバグになる場合があります。それらを報告する段階で、注意した方が良い事項です。 1.何かしらのメッセージが表示されている場合。 冗談みたいですけど、「何かエラーが出ました」というのは、意外に多いものです。「何か」って何やー！って叫びたくなるわけで、もうこの時点で回答の意思が半分くらいなくなります。 動かぬ証拠として表示されているメッセージを正確に、写し取って報告します。 2.発生したバージョン、OSなどの環境情報をまとめる。 As/Rの場合だと、バージョン情報画面で必要な項目を、クリップボードへコピーすることができますので、これを貼り付けます。普通の人が思う以上に、いろんなことが推測できる、非常に重要な情報なんです。 というのも不具合の半分くらいは作者の環境で発生しない、環境依存のものです。 ほら作者の環境で発生してたら速攻修正しますし、ダメでも制限事項として挙げられるでしょう。 特定のバージョンで問題が出ていても最新版で解決済みというのは多々ありますし、特定のOS、特定のCPUでしか発生しないという方が多いのです。 3.再現手順を正確に示す。 正確な報告なんて、一般の方どころか、生半可なプロの人でもろくにできません。（断言）散々、回答してる私だって報告する立場に回るとボロクソです。 さて報告の仕方として、マウスでどこをどーしたとか、キーボードで何をどうしたとか、操作手順を記載することで作者は原因や影響範囲を特定するヒントになることが非常に多いのです。 「普通分かるだろう？」というのは素人判断であり、情報過多なくらいが丁度良いんですよ。 例えば「As/Rでファイルコピーの時に落ちました」って、ファイルコピー機能なんぞ30通り以上もあるので、ちっとも特定できません。 「As/Rでファイルコピーの時に落ちました」の例を詳しく報告してみると「マウスの右のドラッグで、タブバーに、エクスプローラーからファイルをドロップした直後に落ちます」と言う表現をして頂ければ、ピンポイントで問題を起こしている場所が特定できるわけです。（強調している部分で場所が分岐します） 今回の例だと、こんな感じで絞り込んでます。 マウス・・・キーボード、メニュー操作の可能性なし 右・・・左、中、進む/戻るボタン無し ドラッグ・・・キー操作、自動更新、タイマーイベントなし タブバー・・・その他の各種バー、リスト、メインフレームの可能性なし エクスプローラー・・・内部データ転送なし、プロセス分離無関係、タブバー並び替えなし ファイル・・・フォルダーなし、仮想アイテムなし ドロップした直後・・・ドラッグでウィンドウ内に進入なし、ドラッグ中なし、ドラッグスクロールなど多数の可能性なし 再現手順がないと、どのように不具合を再現させるか、作者の脳内で色んな言葉や操作を補完しなきゃなりません。 この例で一切絞り込みできない場合は、全ての組み合わせで約2,000通りの回答をしなければなりません。 大変でしょ？ だから、操作の手順を正確に述べるってのは、とても重要なんです。 4.ちゃんと名乗りましょう。 もちろんハンドルで良いのですが、「名無し」とか「匿名」とか名乗っちゃうと「こいつ適当なことを言ってるんだろうな」と経験上思っちゃいます。経験上ってぇのは、実際に何度も何度も何度も何度も（中略）嫌な思いを経験してしまったわけで、自動的に信用度のメータがぐぐーっと下がります。 想像してみてください。 見ず知らずである上に、全く名乗ろうともしない方を、あなたは信用できますか？という話ですね。 まぁ、人間だもの、しょうがないです。 5.丁寧な口調で、お互いに敬意を持って対話しましょう。 当然ですけど、当然と思ってない人もいるわけで、あえて取り上げてみました。嘘ついたり、悪口ばっかり言ってる人とか、お付き合いしたくないですよね。 しかも、作者の立場からすれば、ユーザーさんを選べませんし。 礼儀正しい方には誠意を持って応えようとしますが、乱暴な人はおざなりな対応になるのは、人間ですから致し方ないでしょう。 マゾヒストにも限度があるってもんです。 もちろん、無闇にへりくだったり、お世辞や、華美な賞賛は不要ですし、ごく普通に接していただければ怖い生き物じゃありません。 ネットの向こう側は、どこにでもいる、ごく普通にくたびれた中年男性を想像していただければと思います。 で、ウチなら掲示板なり、目安箱なりで不具合報告を受け付けています。 分かりやすいバグ報告を書いて感謝され、気分良く作者を働かせる・・・これくらいのスタンスで報告すれば良いんではないかと思います。 |