Excelまたは紙によるバグ管理の実態
ここで、まず11月に行った読者アンケートの結果をみてみよう。この読者アンケートでは、実際に読者の方々がどのような手法またはソフトウェアを活用してバグ管理を行っているかと、今後何を使ってみたいか／どのような管理手法に興味があるか、について聞いている。
結果として、まず現在利用している手法としてExcelが約37%、続いて紙が約21%と、約半数を占めている。これに対して今後使ってみたい手法ではそれぞれが約2%ずつとなり、数値が激減していることが見て取れる。
なお、今後使ってみたい手法の中でもっとも多いものが、Bugzillaで約23%、ScarabとVisual Studio 2005 Team Foundation Serverがそれぞれ約10%となっている。「圧倒的な人気」が存在しない状況をみると、バグ管理システムの導入に関しては今まさに模索している最中といえるのではないだろうか。
「Trac徹底活用！」の「第1回：なぜバグ管理システムを使うのか？」で解説している通り、開発／テスト中に発見されたバグに関して、発生した日時や内容、発見者、修正担当者、修正履歴、重要度、現在の進行状況などの項目について、管理する必要がある。
さらに、発見から修正までの間、誰がそのバグに対して責任を持ち、修正までを行うかといったタスク管理も重要となる。
読者アンケート結果
もちろんExcelや紙ベースでも、きちんとした運用ルールが制定されていれば、BTSに負けないタスク管理ができるかもしれない。しかし「とりあえず記録しておこう」であったり「一応管理らしきものをしておこう」という程度での運用だとしたら、バグによる問題が発生した際に、原因を究明することは困難だ。
そして、多くの読者が今後使ってみたい手法として、Excelおよび紙ベースでのバグ管理をあげていない状況を鑑みると、この手法について不満を持っている読者が多いと推測できる。
特に、大規模かつ多人数でのプロジェクトでは、アナログまたはアナログ的な手法となるExcel／紙ベースでの運用は、管理面での漏れや不具合が多く発生し、バグの効率的な修正／管理は難しい。
前述した通り、匿名を条件に質問に答えてくれた技術者は「弊社では個々のプロジェクトごとに、Excelのシートを使って管理してますから」とコメントしている。この言葉の裏には、Excelベースでの管理には限界があると考えており、その現状を公表することに抵抗を感じる、といった意味が含まれていると考えられる。
実際に、別の技術者からは「紙ベースでのバグ管理を行っているが、正しく運用されているとは言いがたく、必要な修正が行われずに作業が進み、最終的に手戻りが発生するケースもある」という意見も聞かれた。
あくまでも推測ではあるが、このような「バグ管理が確実に行われているとはいいがたい」という状況から、明確な返答がいただけないのではないかと考えている。ではなぜ、現状に不満を持ちながらも従来の手法を使い続けているのだろうか。 
次のページ
