こんにちは、品質管理部の Y.K です。
品質管理部のメンバーからお届けする、二本目の記事になります。

初めは、二番打者らしく、"分かりやすいバグ票の書き方" みたいな記事を書くつもりでした。
けど、そんなものは今さら私が書かなくても、ググればいくらでも出てくる。
そこで、もっと自分の経験に基づいた記事を書いてみよう、と思いました。

この記事では、
「なぜ、バグ票が意図通りに処理されないのか？」
…について、私が感じた原因と、対策をお話しします。

きちんと書いたのに…

新人のころ、自分なりにきちんとバグ票を書いているつもりでした。
手順を飛ばさずに記載する、テスト環境を記載する、再現時のキャプチャを添付するなど、それこそ、"分かりやすいバグ票の書き方" は網羅できていたと思います。

それなのに、
放置されたり、戻ってきたと思ったら意図していた処理がされていなかったり…
「きちんと書いたのに、なんで？」とモヤモヤしていたことを覚えています。

今振り返ると、バグ票を書いただけで、自分の仕事を終えた気になっていたことが問題でした。

バグ票管理の落とし穴

ところで、多くのチームでは、BTS（バグ・トラッキング・システム）を用い、バグを「バグ票」という形で管理していますよね。
私のチームでも、My Redmine というシステムを利用しています。

バグ票で管理を行うことで、バグのステータスと担当者を可視化でき、チーム全体で状況を共有しやすくなります。
正直、バグを見つけるたびに直接報告するのは気が引けるので、「バグ票を登録するだけで報告したことになる」のも有難いポイントです。

ですが、その便利さが落とし穴です。

報告の本質はコミュニケーションですよね。

そのはずが、バグ票を経由することで、
「バグ票を登録すること」自体が目的化し、単なる作業になってしまうんです。

さらに、中間成果物として残るため、
「形式的にしよう」「余計なことは書かないようにしよう」という意識が働きます。
その結果、相手への配慮や意図を伝える工夫が抜けてしまう。

前述の私の失敗も、まさにこのことに起因していたと思います。
要は、「意図を伝えきれていないから、意図通りの処理が返ってこない」という話でした。

バグ票による管理は、こういったリスクを孕んでいることを理解するべきです。

バグ票管理のメリットを享受しながらも、コミュニケーションを疎かにしないよう、
普段意識していることをご紹介します。

「バグ票を登録したから伝わるはず」
こう考えるのはやめました。

必要に応じて、直接コミュニケーションを取るのが大事です。

私のチームでは基本的に、Redmine に登録しておけば確認してもらえる運用ですが、以下のような状況では直接声かけもするようにしています。

私は、元々「バグ票には、客観的事実だけを記載しなければならない」と思い込んでいました。
しかし、先輩社員のバグ票を見てみると、事象に加え、報告者の意見がしっかりと書き込まれていました。
そして、開発者の方とのやりとりの中で、問題が適切に処理されていく様子を見て、考えが変わりました。

意見を伝えることで、判断の助けになりますし、
お互いにとって良い落としどころが見つけやすくなります。

以下の状況では、事実と主観を混同しないよう気をつけつつ、自分の意見も積極的に書くようにしています。

重大度が分かり辛い場合
⇒ 　なぜ問題と感じているのか伝える
（○○のユースケースで致命的な影響が出る、
　別の製品と連携したときに問題が起こる　など）
期待結果が不明瞭な場合
⇒　どのような理由で、どう対処してほしいのか伝える
（別の画面と統一し○○にする、
　妥協案としてユーザが分かるようメッセージを表示する　など）