この記事はRachel Kiblerによるゲスト投稿です。

こう言うとびっくりされるかもしれませんが、私たちのソフトウェアが完璧な状態でリリースされることはありません。モバイルアプリはクラッシュすることがありますし、特定のデータを処理できなかったり、ナビゲーションフローが複雑すぎたりする場合もあります。

レグレッションの大部分も含め、私たちはたくさんのバグをリリース前に見つけて修正します。それでも、どこかの時点で修正する予定のバグのバックログはかなりの量になります。

当社の主力製品のテストリードとして、私はバックログに囲まれて暮らし、バグを吸っているようなものです。通常のリリースでは、新規部分とは関係ないバグが20個ほど修正されます。約200個のバグのバックログから修正すべきバグを選択するという状況の中で、私はバグに優先順位をつけ、リリースごとに「適切な」バグを選ぶ方法を否応なく学びました。

選択の方程式というものはありませんが、学んだことは数多くあります。以下は、対処すべきバグを選択する際に重要な5つのポイントです。

1.ルールを決めておく

私たちの製品では、週1回、プロダクトオーナーと開発リードとともに、バグの優先順位を決めるためのミーティングを開いています。登録されたバグを確認し、優先度の高いものから手を付けます。バグを評価し、ユーザーエクスペリエンスについて議論し、必要であればバグの重要度、発生確率、優先度を変更します。

勘で優先度を決めるのではなく、重要度および発生確率に関するガイドラインがあり、独自に開発したマトリクスを基にして優先度について議論します。優先度はビジネスニーズに基づいて変更されることもありますが、マトリクスによる判断とバグを発見したテスターの意見が異なる場合、ルールがあることが役に立ちます。

誰にでも、これを直したいというバグがあり、自分が見つけた良くないエクスペリエンスは最高の優先順位を持つと考えるものです。基本となるルールは、客観的な視点を提供します。

2.グループで判断する

バグ優先順位付けミーティングは非常に疲れるものでもあります。優先順位付けはプロジェクト開始時に始まったものではありませんし、2018 年からずっと残っているバグもあります。そういったバグのことはよくわかっていますが、それでも独断で修正を決定することはありません。判断はグループで行っていますし、そうでなければなりません。

みなそれぞれ違う経験をして違う意見を持っています。共同で優先順位付けを行うということは、バグをより注意深く検討し、以前はあいまいだったことを明確にすることを意味します。また、正直に言って、バグを「修正せず」としてクローズする場合も、合意のうえで決定したほうが気が楽です。

フィードバックについても、単独では処理しません。私たちは自社のソフトウェアを使っており、ユーザーサポートのメンバーが隣の席にいます。誰かが部屋に入ってきたとき、バグを知らせに来たのだなというのは、どれくらい私とアイコンタクトを取ろうとするかと携帯の持ち方でわかります。ありがたいことに、ほとんどの人はバグを見つけるための工夫に感心しているだけで、それを参考にしたいと思っています。

3.緊急度を判断する

ただちに修正しなければならないバグがある場合、たいていはホットフィックスという形式をとります。カスタマーサポートのコールが急増する、あるいはストアでアプリの評価が急落するなどの事態が起こると、バグの緊急度は非常に高くなる可能性があります。ビジネスがかかっている場合、バグは緊急です。重役からの要請である場合、緊急度は下がりますが、重要度は増します。

緊急のバグがあらかじめ計画されたリリースまで待てるようであれば、そうします。リリースまで待てるようであれば、結局、それほど緊急ではないのかもしれません。

4.重要度を評価する

企業や製品の長期的な目標に関わるような問題は重要です。そういった問題は、多くの場合、フィーチャーとして入ってきます。私のチームでは、バグがユーザーエクスペリエンスの「平穏」に影響を与えるかどうかも考慮しています。平穏は企業の長期的な目標であるからです。つまり、平穏を乱すバグを修正することが、他のタイプのバグよりも優先されることが多いのです。

この点は、最初の「ルールを決めておく」の範疇かもしれません。なぜなら実際、「ルールを決めておく」とは、会社を動かすものは何か、会社が将来どのようになりたいかを知ることにほかならないからです。何が重要かは、企業によって異なるでしょう。

対処しなければ緊急の問題になるまでは、あまり使われない機能を徐々に廃止することは重要かもしれません。後で緊急の問題にならないよう、重要なバグに対処しておく必要があります。

5.（ある程度）放任する

私はJIRAに自分用のラベル「qa-list」を用意しています。このラベルをバグに追加または削除できるのは私だけです。ラベルがついたバグは、優先順位付けと評価、議論を経て、他のバグより優先して修正したいものです。その多くは緊急のバグというよりは重要なバグです。

リリースで修正するべきバグを探すときは、このリストから選択します。開発チームに時間の余裕があれば、リストから修正するバグを選択していいと知らせてあります。リストの管理が容易であるよう、またリストを消化できるよう、リリースに含まれないバグが20以下になるよう努力しています。パラメーターを設定したら、その範囲内で自由にさせています。

私と私のチームにとっては、このような仕組みでうまくいっています。私はより広い範囲のバグをみる視点を必要としていました。何が重要かを理解し、それをめぐって議論することが、プロセスの策定に役立ちました。

Rachel Kiblerは、MySudoを開発するAnonyome Labsのテストリードです。Twitterアカウントは@racheljoi、Webサイトはracheljoi.comです。

（この記事は、開発元Gurock社の Blog 「Bug Priorities: 5 Tips for Balancing the Urgent and the Important」2019年11月21日の翻訳記事です。）