zero-bugポリシは単純だが効果的なバグ管理システムだ。数か月、時には数年前のバグに埋もれてしまう事態を回避する上で、有効に機能する。修正の必要があると合意した重要なバグは即座に修正し、そうでないバグは修正せずにクローズするのだ。
Redgate SoftwareのソフトウェアエンジニアであるTom Walsh氏は、Lean Agile Exchange 2020で、同社がzero-bugポリシを適用した方法について講演した。
zero-bugポリシの背景にある考え方について、氏は次のように説明する。
正直に言いましょう — 今すぐ修正する必要がないのならば、おそらくは永遠に修正する必要はないのです！本当に重要なものであれば、再び指摘されるでしょうから、その時に対応すればよいのです。
RedgateのWalsh氏のチームでは、長期にわたって続行すべきかどうかを判断する目的で、1か月の短期的な実験としてzero-bugポリシを実践した。まず最初に、バックログにあった既存の100件のバグを再度トリアージし、修正の必要がないと判断した90件程度をクローズした。次に、残るバグの修正にひとつのスプリント全体を割り当て、可能な限り白紙の状態で始められるようにした。
zero-bugポリシによって得られるメリットは、チームのミーティング回数が少なくなったことと、バグがすぐに対処されるので割り込み作業が少なくなったことだ、とWalsh氏は述べている。さらに、プロセス全体を完全に非同期にすることが可能になるというメリットもあった、と氏は言う。チーム全員が自宅からフレキシブルに作業する上で、これは非常に有効だ。
Walsh氏があげたもうひとつのメリットは、バグの優先順位設定と解決が非常に簡単になったことだ。
同時に5,6件以上のバグがオープンされることはまったくなくなりました。実際に、ほとんどの場合は数件なのです！これにより、バグが以前よりも迅速に修正されるようになりました。これは私たちにとっても、ユーザにとっても素晴らしいことです！
Redgateでzero-bugポリシを適用した方法について、Tom Walsh氏にインタビューした。
InfoQ: Lean Agile Exchangeでの講演では、zero-bugに関するいくつかの誤解を否定していましたね。それらについて、紹介して頂けますか？
Tom Walsh: 誤解として最初に挙げられるのは、zero-bugポリシとは、バグのまったくないソフトウェアを書くということではない、という点です。私たちは皆、現実の世界に生きています。クリティカルなアプリケーションを除けば、これが現実的でないということは分かっているのです。
第2に、一般的に信じられているのとは違い、バグを修正しないという意思でクローズしたとしても、周囲の怒りを買うようなことはない、という点です。私の経験から、ユーザに対して誠実かつ率直に接すれば、ほとんどの場合は理性を持って納得してくれます。
InfoQ: バグを解消すべきかどうか、どうやって判断するのですか？
Walsh: どのバグを修正すべきか、どれをクローズすべきかを判断するためには、それまでの週次のトリアージミーティングのような手間のかかる方法に代わる、新しい方法が必要でした。この目的のために、絵文字によるトリアージ(triage by emoji)という新しいプロセスを立ち上げました。この方法は、私たちのチームメンバが現在、新しいバグを私たちの決めたSlackのトリアージチャネルにポストする際に、サポートのエスカレーションを処理するために用いている方法に関連しています。他のチームメンバはそのバグを調査して、3つの絵文字リアクションの中のひとつを使って意見を伝えることができます。
このバグは重要なので、修正すべきである
このバグは重要ではないので、クローズすべきである
このバグの重要度は不明なので、チームとしてさらに議論と調査が必要である
バグに対するコンセンサスが取れれば、それに従ってチケットが更新されます。
InfoQ: どのような課題に直面して、どう対処しましたか？
Walsh: 最も大きな問題は、まず最初に他のチームの賛同を得ることでした。zero-bugポリシは、従来のサポート手法からあまりにも大きくかけ離れているので、懐疑的な見方をする人は確かにいたのです！これに対抗するために、1か月間トライする試験という位置付けにして、"バグ修正時間"や顧客満足度といったメトリクスを監視することにしました。うまくいかなければ、いつでも以前のアプローチに戻ることができる、という訳です。この方法は、他の人たちに参加してもらう上で、非常に役に立ちました。
幸運なことに、試験を開始すると、短期間のうちに肯定的な結果をたくさん得ることができました。それによってチーム全体がzero-bugポリシの強力な支持者となってくれたため、すぐに試験状態から脱却し、日常的なチームプロセスの一部にすることができたのです。それ以来、プロセスの採用と洗練を続けています。例えば、プロセスをロールアウトした直後に、連絡を受けたバグの処理手順を変更する必要が生じたため、スクラムからかんばんへの変更を行っています。その後も、機能開発、運用上のメンテナンス、バグ修正のバランスを改善するために、プロセスの微修正を行いました。
InfoQ: バグを修正しないと判断した場合、ユーザにはそれをどのように説明しているのでしょうか？
Walsh: トリアージプロセスの間は、特定のバグに投票したすべてのチームメンバが、その理由をコメントとして必ず説明するようにしています。チームがバグフィックスを回避した理由について詳しく説明する必要があるため、このようにしているのです。サポート作業表の担当者がこれをサポートチケットに追加し、担当するサポートエージェントがそれをユーザに伝える、という手順です。
InfoQ: どのようなことを学びましたか？
Walsh: おもに２つのことを学びました。ひとつは、ユーザに対して誠実かつ率直であれば、例えバグを修正しなくても、100回中99回は理解し納得してくれる、ということです。
ふたつめは、"事実を恐れず、ありのままに言うこと！"です。私たちにはどうやら、バグを修正する必要のある重大なものだと考えがちな傾向があるようなのです。これは特に、オープンしているバグの数がそれ程多くない場合に当てはまります。私たちは時として、"修正するべき"ではなく、"修正できる"という理由で、バグを修正対象として取り上げることがあります。これは結果として、価値の低い仕事をすることになると同時に、バグを修正するかどうかの判断が、バグ自体の重要性ではなく、いつ報告されたかという点に強く関わるようになるのです。このアドバイスに従うのは難しいかも知れません。未解決のバグが他にないのにバグの修正を拒否するというのは、変な話のように思われるからです。しかし、何事もそうであるように、時間と経験があれば簡単に対処できるということに、私たちのチームは気付いたのです。