バグとして認識するタイミング

前回説明した通り、バグ1つとっても関係者は数多くいる。開発チームにおいてもバグと関わるメンバーは開発者だけではない。プロジェクト管理者やテスト担当者など、多くのメンバーがバグと関わっているのだ。しかしながら、開発のライフサイクルの中における彼らのバグに対する価値観やバグと付き合うタイミングは、ロールによってだいぶ異なっている。

プロジェクト管理者やその機能を担当するリード開発者は、バグの報告を受けた後、あるタイミングでその報告がバグであるか、またはバグではなく仕様通りなのか、使用者の今後のシステムへの要望なのかを識別する必要がある。さらにバグとして識別されたものをどのリリースに向けて、どのタイミングで誰に駆除させるのかを検討する必要もある。すなわち、彼らはバグがバグとして開発チームが認識する前のかなりの早い段階で、バグを扱う必要があるのだ。

それに対して、開発者やテスト担当者はバグの可能性があるものを発見し、さらにバグの駆除の決定後に、バグをバグとして認識することになる。たとえ、開発途中に開発者が何らかのバグ（正確にはバグの候補）を発見したとしても、その場で他者の意見を聞かずにバグを駆除してしまうことは必ずしも適切でない場合が多い。テスト中においてもテスト担当者が発見したバグ（正確にはこれもバグの候補）も同様に、発見した時点では、まだ駆除すべき対象にはなってはいないということになる。

実装作業中におけるバグの駆除は問題か

しかし、開発者が実装作業中にバグを発見した場合に、それを駆除できないことは「生産性の阻害になるのではないか？」と疑問に思われるだろう。ここにはある一定のルールが必要になる。

例えば、その開発者が担当している機能の実装作業中に、その開発者が作成または変更しているソースコードにバグを発見した場合は、それを駆除する。これは発見した時点において即、駆除すべきと言えるだろう。その時点で駆除を見逃すことは、品質の劣化を招くだけではなく、生産性の阻害にもなり得るからである。

しかし、現在の実装作業に起因しない、他者が作成したソースコード中のバグは、慎重に扱わなければならない。なぜならば、その場で発見し駆除したとしても、そのバグを同じタイミングで別の開発者が駆除している可能性もあるからだ。また、実はバグではなく、その1人の開発者の思い違いであるかもしれない。さらに言えば、仕様に矛盾があり、他の機能からすると適切だが、特定の機能からみるとバグに見えるだけかもしれない。

このように考えると実装作業中におけるバグは、ソースコードを結合（共有）するまでは、各自担当する実装部分については各自で駆除するのが効率的であることがわかる。また、一度ソースコードを結合（共有）した部分に対しては、開発者が個人で判断するのは好ましくなく、バグとして報告し、判断を仰いだ後に駆除するのが良い方法であることがわかる。そこで活用するのがバグ管理システムだ。 次のページ