バグレポートは伝え方が9割(※個人の感想です)

こんにちは。カルバートです。

GW前に参加してきた、「"Issueの書き方と伝え方"勉強会」の内容と、当日感じたことを書きます。

connpass.com

当日のツイートまとめ

togetter.com

エラーと欠陥と故障と不具合/バグの違い

JSTQB用語を学ぶときの最初の障壁(※個人の感想です)、エラーや欠陥などの用語の違いについて、秋山さんのスライドがとてもわかりやすかったです。

エラー：てへぺろ→人間だもの間違うことはあるよね

欠陥：家のヒビ→てへぺろの結果埋め込まれてしまったもの(ディフェクト)。経年劣化などで表面化してきたものはフォールトと呼んで区別する場合もある

故障：期待と違う結果→ヒビのところから家が壊れた、ディスプレイの画面が乱れた

不具合/バグ：故障が表出した(人間が観測できた)もの→レポートの対象になるのはこれ

私のまわり(おもにWEB系ドメイン)では、これらの概念を特別に区別して扱っていることはないのですが、厳密な分析を行ったりする場合には、区別して整理する必要がありそうですね。

「報告する人」と「報告を受ける人」は対立構造になりがち

今回は4名の方が発表されましたが、バックグラウンドが皆様それぞれに異なっており、注意すべきと考えているポイントも異なっていると感じられたのが印象的でした。

本来、不具合/バグを報告するレポートは、「サービスが期待する振る舞いをしていない」という事実を伝え、サービスを改善するために書かれるべきだと思います。実際、レポートそのものは事実を伝えるべく書かれるのですが、内容がネガティブなものにならざるを得ないため、「報告する人」から「報告を受ける人」への攻撃と受け止められがちなのかなと感じます。

「報告する人」の視座

秋山さんやリナさんの発表では、「報告する人」の立場から、テスト担当者と開発担当者が明確に別れている前提で、どのように感情を損なわず、お互いの納得感をもって、事実を記録し、情報の同期を適切に行うかという趣旨のお話をしていただきました。

リナさんのケースは個人的にとても衝撃的で、自分なりに表現すると、映画の中の理想の世界でした。黒い白鳥なんてお話の中の世界なんだから、現実を見なさい。白鳥は白いのよと教わってきた人が黒い白鳥を見たときの衝撃という感じでしょうか(伝われ)。

関係性ががっちり構築されていると、こんなにも理想的な立ち回りができるのだなあ。。。と感じた発表でした。普通の人にはマネできないと思います。

「報告を受ける人」の視座

一方、渋谷さんの発表では、「報告を受ける人」の立場で、様々な考え方を伺うことができました。僕自身の経験でいうと、とある案件の本番導入に「報告を受ける人」の立場で立ち会ったことがあるのですが、それはもう地獄でしたね。「おまえらの作ったサービスがちゃんと動かないから大変なことになっている！どうしてくれる！」という感情が篭ったレポートを毎日何十件も読んでいました。ただ、その感情の先に、「サービス提供者として気づけていなかった、隠れていた要件」が存在していたりするので、二度と思い出したくない反面、自分の原点のひとつになっている経験でもあると感じています。

みっきーさんの発表は時間の関係で深く議論できませんでしたが、また別の機会があると嬉しいです。