品質管理の羅針盤

不具合報告はシンプルがベスト

　不具合をなおせる人が不具合の存在を知らなければ、不具合はそのまま残り続けることになる。不具合を見つけ開発者へ知らせるのは、品質管理の大切な仕事のひとつだ。どういった不具合が、どういった手順で発生するのか。原因は何であるのか。それらの情報がわかりやすければわかりやすいほど、くわしければくわしいほど、開発者の不具合修正ははかどる。

　不具合報告は「です・ます」の丁寧語で、最低限の礼儀さえおさえていれば十分だ。尊敬語や謙譲語が使われたしっかりとしたビジネス文は、不具合報告の場面においては、誰にも求められていない。読まなければならない文字の数が少なければ、内容の理解がスムーズになる。「読む」のでなく「見る」でパッと理解できる報告は、さらに助かる。開発者に敬意をあらわすのは良い行いだ。しかし、不具合報告の場においては、敬意よりも報告の伝わりやすさを優先しよう。

　以下の例を見てほしい。同じ不具合を報告したものだ。1と2では、どちらがわかりやすいだろうか。

　例.

　不具合：コンテンツAの公開日付が、資料上では過去の日付になっている

　報告

　1.

　資料〇〇を拝見致しましたところ、コンテンツAの公開日付が過去の日付2000年1月1日になっておりましたので、お忙しい中大変申し訳御座いませんが、資料の情報が正しいものかどうか、ご確認いただきたく存じます。

　2.

　コンテンツAの公開日付が、以下のとおり誤っています。

　誤：2000年1月1日

　正：2001年1月1日

　参照資料〇〇

　1の報告はやたらと長い。かしこまりすぎていて、不具合報告として「読まなくていい文字」が多い。不具合を伝えたいのか、自分の礼儀正しさを伝えたいのか、目的錯誤を起こしている。

　2は実にシンプルだ。「何が」「どうなっている」を簡潔に述べている。開発者がそう望むのであれば、『コンテンツAの公開日付を、2001年1月1日に修正してください。以上』と、もっと簡潔に述べることだってできる。

　シンプルな不具合報告は、起こっている事象を短い時間で伝え (知り) 、すばやく修正するために欠かせない。不具合報告はシンプルなのがベストである。