チーム崩壊はふとしたきっかけから

「実装者とQAの対立」なんて言葉を耳にしたことはありませんか？
目的のために協力するのがチームのあるべき姿です。
しかし実装者とQAはしばしば信頼関係を失い、対立や無関心に陥りがちなようです。

時にクレームや果たし状に化けてしまうバグチケットは、そんなチーム崩壊の一因になりがちです。
いやいや大袈裟な、と思うかもしれませんが、意図せず組織を傷つけるのがバグチケットの怖いところです。
LMのQAチームが気をつけていることを思い返し、信頼関係を崩さずバグチケットを書くポイントを3ステップでお伝えしようと思います。

※この記事ではあくまで信頼関係の話をします。
バグチケットを書く技術についてはいい記事がたくさんあるので、ぜひ探してみてください。

Step1: 感情を取り除き、理性に絞る

テストに慣れていない場合、もしかしたらこんな感情に埋め尽くされているかもしれません。

喜: どうだ！こんな難しいバグを見つけてやったぞ！
怒: なんでこんなバグ出すんだ！もっと自分でも確認しろ！！
哀: このタイミングでバグが出たら納期に間に合わないよ...
楽: バグ出してバンバン指摘するの楽しいな〜！

そんな時は、バグチケットを書く前に一息ついて感情を整理しましょう。
文面で感情を伝えるのは難しく、ほとんどの場合に誤解を生みます。
バグチケットはあくまで理性的に記載しましょう。

感情に任せて筆を走らせるのはNGです。
どうしても伝えたい感情があるなら直接伝達しましょう。

Step2: 事実と意見を分ける

感情を取り除き理性に絞っても、対立のタネが実はもうひとつあります。
それが意見です。

バグを見つけた時、こんなことを考えたことはありませんか？

もっとこんな機能があればいいのに
こう改善されるといいなぁ
バグの原因は多分あれでしょ！

積極的な方ほど、バグを見つけるだけでなく意見や予測まで考えます。
しかし修正案などの意見を事実と混ぜて記載してしまうと、
読み手は事実と意見の境界がわからず、時に誤解につながります。

なのでまずは事実だけをまとめましょう。
意見や予測は、事実とは切り離されているとわかるように記載しましょう。

Step3: チケットの渡し方にも配慮を

ステップ２まで来れば、あとはチケットを実装者に渡すだけです。
しかしここにも落とし穴があります。

口頭で感情が滲み出たり、
相手の余裕を超えた提案をしてしまったり...

せっかくチケットの質が高まっても、対面で誤解を生んでは元も子もありません。

とはいえバグチケットを渡すのは、テストを長くやっていても未だに難しいと感じます。
通知を自動化したり、実装者が自らチケット確認する時間を設けたりと、チケットを口頭で渡す機会を減らす方が楽に問題を解消できるかもしれません。

バグを責めても人は責めるな

３つのステップに共通して大事なのはバグを伝える目的を意識することです。
目的はあくまで顧客価値に向いているべきで、人を責めても問題は１つも解決しません。
顧客価値を下げるバグを責めることで、チームの信頼関係を守っていきましょう。

この記事はモチベーションクラウドシリーズアドベントカレンダー2021の5日目の記事です。