ゼロバグポリシ(zero bug policy)を採用すると、バグの優先順位付けが容易になり、チームの可視性とバグへの対応性を向上することができる。ただし、過激な変革なので、意思決定とバグの修正時間に関して、自分自身の状況に合わせることが必要だ。
DashlaneのシニアQAマネージャであるSimone Colosimo氏は、Agile Testing Days 2021で、ゼロバグポリシを採用した自身の経験について講演した。
氏らのバグ処理戦略が目指したのは、次のような目標だ。
当時の私たちは、外部からも内部的にも認められるような品質低下に直面していたため、バグへの対処方法を変えなくてはならないと考えていました。そこでパラダイムを変えて、品質とカスタマをプロダクトの中核に置き直し、バグのバックログに対するコントロールを取り戻すため、バグを処理する新たな方法を導入することにしたのです。
ゼロバグポリシを使うことでバグの分類は、バグか、バグでないかという2者択一になる。Colosimo氏の言うように、"存在を許容できるならば、それはバグではなく改善"なのだ。このポリシの下で、問題がバグであると考えられた時には、今後の開発や改善よりも高い優先度が与えられる。
ゼロバグポリシのアプローチは、当時の氏らの状況に対しては厳格すぎたようだ。特に、優先順位付けとバグ修正時間に関して、それまでの慣行に比べて非常に厳しい変更であったため、チームから大きな反発を受けることになった、とColosimo氏は述べている。そのため氏らは、意思決定とバグ処理にゼロバグポリシを採用することにした。
新たなバグがオープンされると、チームのプロダクトオーナがそれを修正するべきか、クローズするべきかを判断します。
修正が必要という結論になった新しいバグは、オープンしてから30日以内に修正しなくてはなりません。一部のバグについては30日以降に修正される場合を認めますが、それは例外であって、規則ではありません。
ゼロバグポリシの採用は、次のような結果をもたらした。
優先順位付けの容易化:
- 対象の数が少なくなったため、優先順位付けを以前より簡単に、より効果的に行えるようになった。これにより、重要な問題を見逃すリスクを一定以下に保ちながら、最も重要なことに取り組んでいるという確証を持つことができる。
チームの可視性とバグへの対応性の向上:
- バックログにバグが山積みになっていると、バグ修正に対する感覚が鈍くなり、チームのモラルを低下させることになる。新たなバグの発生が気にならなくなるのだ。
- 発生したバグにすぐ対処すれば、チームのバグに対する態度は改まり、品質に対するプライド意識が生まれる。自分たちの努力が、プロダクトの品質に直結するからだ。
ゼロバグポリシの適用について、Simone Colosimo氏に聞いた。
InfoQ: 一般的な企業は、バックログのバグをどのように管理しているのでしょうか？そのアプローチには、どのようなデメリットがあるのでしょう？
Simone Colosimo: 品質が最優先事項ではなく、新機能の提供が急がれているような場合には、優先的でないバグは後回しにされて、バックログに蓄積していくことが多いのです。このような状況では、これらのバグ修正に時間が費やされることはほとんどありません。
こうしてできたバグの蓄積を削減するために、一般的に行われる方法が"春の大掃除"です。すなわち、QAが主体となってセッションを開き、バグの再現性を確認した上で、古い情報や修正済のバグはクローズし、有効であれば優先順位付けを行う、という方法です。
このアプローチはおもに2つの結果をもたらします。まず、新たなバグ発生に対する感受性が低くなり、バグレポートの価値を認めなくなります。次に、何年にもわたってバグが蓄積するため、"大掃除"がますます苦痛なものになるのです。
InfoQ: Dashlaneでゼロバグポリシを採用したのはなぜですか？
Colosimo: 私たちのモットーは、"正直であれ、責任を全うせよ"というものです。
バグに対しても、私たちは正直でありたいのです — バグが修正すべき重要なものならば、修正しましょう。そうでなければ、先送りするのではなく、クローズしてしまった方がよいのです。バグが修正されるべきかどうかという判断が求められることで、意思決定者の説明責任も高くなります。
私たちは、ループを閉じなくてはなりませんでした。プロダクトオーナ(意思決定者)は自身の判断を、バグの最初の報告者と、さらにはチームとも共有する必要があります。自身の判断について説明し、判断の背景にある論理を正当化しなくてはなりません。
報告者の視点からはさらに明確です — 問題を修正しない理由の説明を受けるか、合理的な時間内に修正されるか、どちらかになるのです。
InfoQ: 採用の結果と、それによるメリットはどのようなものでしたか？
Colosimo: 優先順位付けが簡単になったことと、チームの可視性と対応力が向上したこと以外にも、いくつかのメリットがありました。
報告者の満足度の向上
- 反応がよくなり、コミュニケーションが向上しました。
技術的負債の低減
- バグ修正に何か月も待たせることによって、その間、現状での我慢をステークホルダに強いたり、コードが変更されて他の部分に影響を与えるリスクが増えたりすることは、もはやなくなりました。
- バックログのサイズが80パーセント減少しました。
- 平均すると、バグは1スプリント(14カレンダ日)で修正されています。まだパーフェクトではなく、現在でも30日ポリシを破るようなバグがいくつかありますが、品質に関するコミットメントを遵守するよう、チームは一生懸命努力しています。
結果は前向きで期待の持てるものなので、さらに努力して新たなレベルを達成したいと思います。
InfoQ: どのようなことを学びましたか？
Colosimo: 新しいバグ処理戦略に関する社内の議論は情熱的で、激しく、有益なものでした。私自身は、提案を作成し完成させるには、エンジニアリングの内外において、ステークホルダの関与が重要である、ということを学びました。すべてのフィードバックを取り入れられた訳ではありませんが、誠実なコミュニケーションは、次のステップに進む上で不可欠なものです。それと同時に、経営層の関与とサポートも重要な側面です — 経営陣が変革をサポートしてくれなければ、実現はとても難しいものになるでしょう。
最後に重要なのは、中核的なチームメンバを支援することが、変革を成功させる決め手になった、ということです。彼らは自律的なので、適切なツールを提供すると同時に、日々の作業の戦略を適応して"生きる"よう、彼らをトレーニングしなくてはなりません。
InfoQ: ゼロバグポリシを採用しようという企業に対して、何かアドバイスはありますか？
Colosimo: プロセスを根本から変えることを恐れないでください。バックログにバグが積み上げられているにも関わらず、そのコントロールを取り戻すための活動がほとんど行われていないようであれば、今こそ行動の時です。
それと同時に、コンテキストアセスメントを注意深く行わなくてはなりません。例えば、あなたがポリシをそのまま適用しようとした、としましょう。この場合、ターゲットを見失って、コブラ効果(cobra effect) — 行動が裏目に出て、当初の意図に反する、望ましくない結果につながる — を起こす可能性があります —
私たちは、ゼロバグポリシに手を加えた上で採用しました。変更が大規模かつ永続的な影響を与えると思われたためと、変更に対する抵抗を抑制するためです。私たちのケースでは、意思決定者の役割をプロダクトオーナに担わせたのですが、場合によっては技術的リーダ、プロジェクトに責任を持つQAがその役割になるかも知れません。あるいは、私たちのようなポリシの変更を行う必要はないかも知れません。すべては状況次第です。