TOPシステム開発> 第2回:開発チームにおけるバグの扱い方 (1/3)

バグ管理再考のススメ - TFSの場合

バグ管理再考のススメ - TFSの場合

第2回:開発チームにおけるバグの扱い方

著者:マイクロソフト 長沢 智治

公開日:2008/03/11(火)

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

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

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

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

図1:実装作業中の作業とバグの登録の整理
(画像をクリックすると別ウィンドウに拡大図を表示します)

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

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

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

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

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


1   2  3  次のページ


マイクロソフト株式会社 長沢 智治
著者プロフィール
マイクロソフト株式会社  長沢 智治
ソフトウェア開発業務改善のプリンシパル コンサルタントやソリューション アーキテクトとして多くの多種多様なソフトウェア開発の現場のお手伝いを経験。2007年1月よりマイクロソフトのエバンジェリストとして、特にチーム開発の訴求を行うべく活動中。
ブログ「長沢智治のライフサイクルブログ」
http://blogs.msdn.com/tomohn


INDEX
第2回:開発チームにおけるバグの扱い方
バグとして認識するタイミング
  開発ライフサイクルとバグの意思決定
  MSFにおけるトリアージ