はじめに
私の書いたチケットがわかりにくくて、他のメンバーにフォローしてもらったことがありました。
その際に上司と一緒に自分が作成したチケットをもとに、良いチケットの書き方に関する振り返りをしました。
それをもとに自分で改めて考えた内容をまとめてみました。
前提
- QAエンジニアをしています！
- 開発者が実装した機能のテストをして、その際に見つけた不具合に関するチケットを作成することが多いです。
いいチケットの定義
いいチケットとは、以下の要素が反映されていることだと私は考えています。
ひとつずつ確認していきます。
現象を誰でも容易に再現することができる
現象を確認するためにはその現象を再現する必要があります。
そのためには誰でも容易に再現できるようになることが望ましいです。
その機能に詳しい人であれば詳細な再現手順が記載されていないくても対応できるかもしれませんが、必ずしも詳しい人が対応できるかわかりません。
またチケット作成した人が不在のときでも確認できる必要があります。
現象を容易に再現するために最低でも以下の項目はチケットに記載します。
- ブラウザの種類：GoogleChrome、Safariなど
- 実行環境：本番環境やデモ環境、ステージング環境など
- 再現手順：Aというユーザーが○○をしたときに▲▲が発生する、など
必要最小限の情報だけを記載する
必要以上に情報が記載されていると、それを見た人が 「これは結局何が言いたいの？」 となってしまいます。
そうなると確認のやり取りが発生して、不具合修正までに時間がかかってしまいます。
その結果、開発が遅れ品質の低下へとつながっていきます。
情報を適切な量で整理して記載するには、以下の点を意識しています。
ただ、情報を整理することに熱中しすぎていると、「気づいたらチケット起票に1時間かかってた！」ということになってしまうこともあります。
それでは本末転倒なので、僕は「〇〇分以内に起票する！」とチケット作成にかける時間を決めるようにしています。
期待される結果が記載されている
伝えたい情報が正しく記載されていても期待される結果の記載がなければ、**「結局これはどうなっていたらいいの？」**と思われてしまい、読み手も困ってしまいます。
そうならないためにも期待される結果が端的に書かれていることが望ましいです。
いいチケットを書くにはどうしたらいいか？
いいチケットを書くには、相手の立場にたって考えることだと僕は思っています。
相手にとって読みやすいか、自分が書いたチケットを見た人が「これってどういう意味？」とならないか、を考えてチケットを書くことが大事だと思います。
わかりやすいチケットを書ければ開発がスムーズに進みますし、働ているメンバーもストレスなく働くことができます。
参考
チケット作成は良い質問をするための能力と似ているな、と思いました。
Discussion