ブログ

どのプロジェクトでも新機能の追加や変更を行うし、バグの修正もあるだろう。必然的に以下の質問があがることだろう。 「バグ修正のスケジュールはどうやってたてれば良いのか？」

考慮すべきこと

経済価値の最適化

最適化されたスケジューリングのアプローチは経済価値に基づいているべきである。すなわち何を行えば、行ったことから得られる価値が最大化されるかということだ。

バグが見つかることは単なる症状である

最初にバグをみつけたとき、多くの場合単に背後にある根本原因から生まれた症状のみを見つけているだろう。背後にある欠陥はさらなる未発見のバグを引き起こしたり、新しいバグを生み出すことになるだろう。

予測可能性

バグは他の種類の作業に比べると予測しにくい。というのも、多くの努力が、何故その問題が起こっているのかを探索する箇所にあるからだ。

解決案

バグを常に最優先にする

常にバグを真っ先に直すことはとてもシンプルなアプローチだ。しかし、これは経済価値最適化のアプローチではない。 例えば、滅多に使われない機能のバグ修正ととてもよく使われる機能への機能追加を比較すると良い。 ただ、既存バグがたくさん存在するレガシーシステムにとっては、このアプローチは、まずは「既存バグは最優先にする」ようにしない限りはうまくいかないだろう

バグは単に他の作業と比較して優先順位付けする

新たな機能を追加するよりもバグ修正の方が価値があるのであれば最初にそれをやるし、そうでなければやらない。 このアプローチでのよくある問題は、修正されていないバグの影響度を特に複雑なシステムにおいて、過小に見積もってしまうことである。

バグの修正を他の変更と関連付けて行う

この戦略は既存のバグがたくさんある場合によく見られる戦略である。より価値のある修正は変更が行われている箇所にあり、漸進的な「バグ修正税」も機能追加と同時にテストを行うことで負担にならないようになる、という考え方だ。

バグ修正の担当者を別に用意する

何人かの人をバグの調査と修正の専任として確保しておく。ローテーション制かもしれない。この予め確保されたメンバーの人数はバグ修正と新機能追加の価値の差をどれくらいに置いているかを反映している。

私の一般論的な回答

まだ状況が悪化していない環境下では、まずは積極的にバグの修正を進め、その後状況に応じて他の作業と優先順位付けをする方向に進めるだろう。バグの数をとても少なく保つことは必要な努力の予測性を高めることに非常に役にたつだろう。

一方で既存のバグがたくさん存在しているレガシーな環境下では、変更した箇所に関連するバグを直すというアプローチと他の作業とバグ修正を比較して優先順位をつけるアプローチを併用するだろう。 チームが十分に大きいのであれば、根本原因分析をしてバグ修正を進める人を交代で用意するということもするだろう。