こんにちは、asatoです。
以前書いた『 バグチケットをつくらない 』のブログの内容が誤解を生んでるかも、というフィードバックをScrum Fest Niigata 2025でもらいました。それはよくないなってことで、補足的なブログを書くことにしました。
先のブログのコンテキスト
当時、僕はスクラムマスターであり、プロダクトマネージャーでもありました。プロダクトマネージャーとしてユーザーストーリーや受入基準に日々向き合っていました。この辺のResponsibilityをチームで共有していきたいなと思っていたので、自分はこういう思いでユーザーストーリーに向き合っているよ、ということを書いていました。
また、チームがすぐにバグチケットを作成していることも気になっていました。「マニュアルテストしたらここ気になったので、バグチケット作って元のチケットはDoneにしておきますね」みたいなやつです。これに対して、僕には以下のような課題感がありました。
- 受入基準はProduct Ownerが定義したものを変えてはいけない、それだけ満たしておけばよい、みたいなマインドが醸成されている？
- 実装とテストが分かれていて、一緒に一つのProduct Backlog Item（PBI）の品質を保証しようという感覚が薄いかも？
- バグを見つけてチケットを作成することが仕事になっている？それよりも前からチームで品質保証しようという視点を持てていないかも？
このような課題感に対するもやもやを殴り書きしたものでした。
まぁもう2年も前のことなので、違うかもしれないですけど。
先のブログで伝えたかったこと
もっとWhole Teamでユーザーストーリーと受入基準に向き合ってほしい
- 「これバグですかね」という会話が起こらないくらいに、価値や期待動作を前段で定義することにこだわってほしい
- リリース後に見つかった不具合が「新たにわかったこと」だと胸を張って言えるくらい、ユーザーストーリーや受入基準に向き合ってほしい。そのときに検討できたことは全部検討できたと思えるくらいこだわってほしい。
バグであってもユーザーストーリーにこだわってほしい
- バグチケットのフォーマットには「ユーザーストーリー」がない
- これだと他のPBIと優先度が比較できない。バグだから最優先とか、軽微なバグだから手が空いたときにとかの意思決定になりやすい。ユーザーストーリーを明確にして他のPBIと対等に比較してほしい。
バグチケットで本当は終わってないPBIを隠さないで
- DoneになっていないPBI起因の不具合は、そのPBIのユーザーストーリーを達成するために必要なら、新たにバグチケットを作るのではなく、そのPBIをOpenなままにしてそのPBIで解決してほしい
- 本当にDoneしたユーザーストーリーが何かを明確にするため
- 見かけ上のVelocityが増え、見通しが役立たなくなるため
シフトレフトの視点を持てるようにしてほしい
- 実装後のバグにフォーカスが当たっている限り、より早い段階での品質保証に目が向かない
- バグを発見するよりも、バグを混入させない活動にフォーカスしてほしい。そしてそれは１つの職能に閉じてできることではない。
バグ分析に使うのでは？
はい。もしバグ分析に使うのであれば、バグという色を付加したチケット管理は有効だと思います。
実は、個人的には経験不足で、いままでバグ分析が効果を発揮した現場にあまり出会ったことがありません。 小さなチームでの経験が多いので、全体的なバグ分析よりも、ひとつひとつの不具合に対して議論し対策を実践していく方法が効果的でした。
これも僕が「バグチケットは極力なくていい」と考えている要因の一つだと思います。
バグ分析に活用し、より網羅的・効果的に不具合の未然に防ぐ手段を適応できるのであれば、バグチケット管理は有効なのだと思います。
これは極論です
先のブログでも書いたとおり、これは極論であり、理想論です。実際には、バグと呼べるものは出てくるでしょうし、それを管理する必要性はあります。それでも僕は、この理想論の状態をチームで作っていきたくて、あのブログを書きました。多分。
個人的には、極論というのは変革には必要なものだと思っています。極論には反対意見がでます。それによって、ちょうどいいところに落ち着きます。一方で、極論がなければ、ちょっと変わったかな？くらいのところにしか辿り着けません。先のブログもこのブログも、その議論を始めるための極論として使ってもらえると嬉しいです。
この極論は全くもって唯一の正解ではありません。でも、チームの議論を熱くする効果はあるかもしれません。ぜひそうやって使ってください。ぜひ疑ってください（今回のFBが妄信されてる的なやつだったので）。
では、また。
サポートもお待ちしております！
