この記事では、QAチームが現在進行形で取り組んでいる不具合チケット棚卸の取り組みについてお話しします。
はじめに
こんにちシステム開発において、バグを追跡・管理・分析することは非常に重要です。 そのため、JIRAやBacklog、RedmineなどBTS(バグ・トラッキング・システム)の運用は必要不可欠です。 チケットを起票したり編集したり、皆さんも経験があると思います。
その中で、こんな状況に出くわしたことはないでしょうか?
TOPページに表示される、夥しい数のオープンなチケット
X年前に起票されていまだ残っているが、 担当者がもういなくて迷子のチケット
『いつか直す』のまま一生動かないチケット
スタンバイも例外ではありません。 2021年8月時点でおよそ4割のチケットが手つかずのまま、放置されていました。
開発が進むにつれ、チケットは増え続けます。 半年後、数年後、五年後、十年後はどうなってしまうのでしょうか?
どうにかしたい
どうしてやろうと思ったの?
プロジェクトの風通しを良くしたいからです。具体的には、『現存するバグがいくつで、どの程度の影響があるのか瞬時に判別できる状態』を理想としています。これにより、QAのみならず全てのメンバーが不具合の現状を正確に把握でき、共通の問題意識を持てると考えています。 どうしたい? 『直す予定のあるチケットだけが残っている状態』にしたい。 できるだけそこに近づけたい。
そこで、いろいろやりました
1. みんなで棚卸ミーティング
PO(Product Owner)、エンジニア、QAの各チームからメンバーを募り、オープン中のチケットの処遇を決めるMTGを実施しました。 確かに処遇は決められたのですが、30分で4件が限度だったため、残っているチケットすべてに実施するのは負担が大きすぎました。また、チケットの処遇はPO主導で決めることが多く、全員の意見を募る必要性が薄い=MTGである意義がない、ということに気づきました。
2. 棚卸リスト作成
上記の反省を活かし、非同期コミュニケーションでの棚卸に切り替えました。 対象とするチケットのリストを作り、個々のチケットにおけるQAの懸念事項(不具合が残っていることによるユーザーへの悪影響)を記載しました。 POは懸念事項を基に『改修予定』『リスク許容』の判断を下し、『リスク許容』とされたチケットはQA側でクローズできるようになりました。
やるときの考え方
チケットはいつ閉じる?
チケットができる条件はハッキリしています。『不具合を見つけた時』です。 一方、チケットが閉じる条件はいくつかあります。 『不具合が直ったことを確認した時』『不具合を改修しないことを決めた時』などなど。 前者は明白ですが、後者は誰が・いつ決めるのでしょう? スタンバイではPOが主導して随時決定するため、POへの連絡に重点を置いています。
『いつか』は来ない
開発・リリースを止めて既存不具合の改修のみ行うタイミングがあるならともかく、大半の現場で『いつか直す』はいつまでも直りません。また、期限や重要度が決まらないチケットはそもそも優先順位が極端に低い=改修する意義が薄い、とも言えます。このようなチケットが生まれる背景として、QAが過剰品質な考え方をしている場合もあると思います。 逐一声を上げて判断を仰ぐか、『改修しないことを決めて閉じる』ようにします。
迷ったら閉じる
部屋の掃除をしてる時に、ありませんか?
「捨てようかな……でも、いつか使うかもしれないし残そう!」 ⇒使いません。
チケットも同じです。『使うかもしれない』は使いません。 迷ったら=オープンにしている理由が言えないならクローズしましょう。 幸い、チケットはモノと違って後から再オープンできます。 『いつか直す』の『いつか』が来た場合も、当初とは状況が違うかもしれないので新しくチケットを作ってもよいでしょう。
いずれにせよ、残している理由がはっきりしないチケットは閉じましょう。 ただし、原則的に『直った』『直さないと決めた』のいずれかで閉じるべきです。 後者の場合、不具合を改修していないというリスクがある旨をきちんと共有しましょう。 チケットを閉じたいあまり、QAが不具合を黙殺してしまっては本末転倒です。
やってみた結果
活動を開始した結果、不具合(チケット)のクローズ率は順調に向上し、4か月後には80%以上を達成しました。 この高い水準を維持するためには、継続的な取り組みが必要です。 おわりに 『チケットの棚卸で、PJの見通しを良くしよう』というモットーのもと、ある程度の成果を出すことができました。大事なのは『POを巻き込む姿勢』と『継続的な取り組み』です。 これからもQAが主体となって取り組んでいきます。
スタンバイのプロダクトや組織について詳しく知りたい方は、気軽にご相談ください。