見出し画像

「バグ」という言葉を使わないようにしたら、世界が広がった話

T-Pen

QAエンジニアとして、バグを報告すると、基本はありがとうだけど、たまーに空気が変になることないですか？
今日は、その空気が変になることに向き合った話。

QAから指摘する内容の原因にも種類がある

プロダクトとして、挙動や得られる結果に問題がある場合、バグ報告をする。
しかし、その問題が生まれた原因にも種類がある。

  • シンプルに実装時のミス（タイポとか）

  • 要件の抜けや漏れ

  • 仕様の不備

などだ。
そして、この種類によって、対応出来るロールは異なる。
実装時の問題なのであればエンジニアが解決出来る。
要件の抜けや漏れに関しては、企画者（PO）がどうするかを決める。
そして、新たに決まったことは、バグ対応ではなく、追加の新規開発の類になる。
仕様の不備に関してもそうだ。
不備を正す場合、それはバグ対応というより、追加開発だ。

広い意味では、バグ対応なのだが、ここの言葉と認識の定義を曖昧にすると、誰かの心の中にモヤモヤが生まれる。

問題を直接的に解決することが出来るのはエンジニアであるケースが圧倒的に多い。

しかし、要件の抜けや漏れから発生した追加開発の内容を、「バグ対応」というようなニュアンスで扱っていると、エンジニアもモヤモヤする。
人によってはモヤモヤでは済まされず、なんなら傷ついてしまう。

実際、僕は何人ものエンジニアと、「バグ」という言葉でコミュニケーションを取ったために、傷つけてしまったり、言い争いになってしまうこともあった。

解決すべき問題＝バグ　というニュアンスで扱うべき言葉では無いことを学んだ。

「バグ」という言葉を使わないようにしてみる

企画者も、要件の抜けや漏れを埋め込みたいとは思っていない。
エンジニアも、ソフトウェア的な不具合を出したいとは思っていない。
QAエンジニアも、ユーザー目線を持って、よりよいものにするために、遭遇した問題を報告したいはずだ。

プロダクトに関わる仲間は全員、品質の高い、人に使われる、使いやすいプロダクトを開発していきたいはずだ。

QAという活動に対して、みんなが前向きに考えている。
役割や立場が違っても、目指す理想や形は違わない。

しかし、「バグ」というキーワードを使ってしまうと、そこに認識の齟齬みたいなものが生まれやすいように感じた。
だから僕は、「バグ」という言葉を表舞台から消すことにした。

ボイスやテキストでのコミュニケーション

チャットでのやり取りや、Mtgなどでの口頭でのやりとりの際、今までバグと表現していたものを違う言葉に置き換えた。

具体的には、より丁寧に伝えるような言葉を選んだ。

〇〇になる問題が起きています。
✗✗画面のレイアウトが崩れています。
△△が保存できません。

など、起きている事象を伝えるようにした。

そうすることで、ざっくり「 バグ が見つかりました。」っと報告するよりも、起きている問題自体に皆の意識が向きやすくなった。
ノイズがなくなったという表現が正しいかもしれない。

バグ という言葉を 不具合 とか、 問題 とか、 イシュー とかに置き換えて試してみたが、個人的には 問題 が一番しっくり来ている。

ドキュメント上でのコミュニケーション

ドキュメント、ここではバグチケットとか、バグレポートとか呼ばれる、不具合を報告するドキュメントのことを指す。

もともとは バグチケット という名前で呼んでいた。

そこで、名称を QAチケット に変更。

ここで、嬉しい誤算が生まれる。
バグチケットのときは、要件の抜け漏れや、仕様の不備などを報告すると違和感が生まれていたが、QAチケットにしたことで、QAエンジニアが検出した問題をあげても違和感が無くなった。

違和感が無くなったのには、チケットの運用方法も関わるので、ここで一緒に紹介する。

QAチケットのフロー

  • 不具合改修は特に変化無し

  • 要件/仕様の再考が入り、変更内容の規模や影響範囲が大きい場合は新規開発として扱う

    • その際、QAチケットはその旨記載し、closeする

というもの。

補足

  • Sprintごとの開発内容の管理は 開発タスク として管理/運用している

  • QAチケットは、開発タスクとは混ざらないように別で管理/運用している

開発タスクとQAチケットが、同じボード上にあると、視認性がすごく悪かったため、僕はこういった棲み分けをしている。

良かった点

  • QAチケット自体の扱いがシンプルになったこと

    • 不具合が改修されたら、改修内容記載してclose

    • 新規追加開発規模の話になったら、QAチケットはcloseして、新たに開発タスクを作り、そこで進める

  • 要件/仕様の抜け、漏れ、不備もQAチケットとして扱えるようになったこと

  • QAチケット＝なんか問題がある みたいな認識なので、解決方法の選択肢を広く持って考えるようになったこと

    • エンジニアによる実装だけが解決方法ではない

    • 要件を削ることで解決したりする

    • サービスを運用しているチームのオペレーションを変更すると解決したりする

    • 機能自体を削ってしまうことで解決したりする

最後に

正直、僕のQA人生の大半は、バグ という言葉にここまで力があるとは思っていなかった。
しかし、僕らはバグをゼロにすることがゴールではない。
掲げているゴールとなる品質を目指すためにQA活動をメインで行っている。

そう考えると、検出した問題を バグ と丸めて表現することは、今の僕はむしろ気持ち悪くなっている。

チーム全体で、変なモヤモヤが起きるくらいなら、それを回避したほうが品質に対しては良い方向に向かう。

QAチケットという名前も、QAチケットのフローも、僕のいる場所での話。

でも、バグ という言葉を使わないようにしたら、明らかに色々な可能性や、連携、物事の運び方が変わった。
今現在も、色々といい感じに進化している。

今回はQAチケットの扱いと、フローの表面的な部分しか紹介できていないが、いつかもう少し詳細な内容も紹介したいと思う。

いいなと思ったら応援しよう！