なぜBTSによるバグ管理が進まないのか
従来のExcelや紙ベースでのバグ管理手法を使い続ける理由としては、表2のようなものがあるだろう。この構図は、これまでThink ITで取り上げてきたグループウェアやSNSなど、社内の情報共有を進める上での問題点と非常によく似ている。
実際の導入についてある程度の強制力を持って導入を進めるべきだが、導入が目的になり、実際の運用で問題がでてしまっては仕方がない。そのバランスこそが重要だといえる。
この点については、火曜日の連載「バグ管理のノウハウ」の「第1回：バグはなくならない？」で触れているので、ぜひ参考にしていただきたい。
一方で「バグの管理が不十分である」という状況が、開発者に対して大きな負担となっていることも見逃せない。まず最初にコードを記述する時点で、正確なコード／バグのないコードを求められる。もちろん1つの方法論として有用ではあるが、そこに負担が集中してしまうとプロジェクト全体をみた場合には「プログラマ頼み」という属人的な対応が迫られてしまう。
「スタープログラマの存在」がプロジェクトの牽引となるケースもあるのだが、それをすべてに適応するのは無理難題である。バグは必ず発生するもの、という観点に立ち、いかにプロジェクト全体でバグを減らしていくかが重要だ。
- プロジェクトリーダーごとに個別の手法を採用している
- すでにExcelのシートがあり、それで運用すると決まっている
- 次々にプロジェクトが舞い込み、BTSを導入するタイミングがない
- どのBTSを選んでよいかわからない
- BTSを覚えるために時間を割けない
表2：BTSに切り替えられない理由
Excelや紙ベースでのバグ管理を考えた場合、1つのファイルや1つの書面に状況が記録されていることが望ましい。複数箇所に記述する場合、記載の漏れやコピーのし忘れといった問題が発生するからだ。最終的に「どのファイルが正しいのか」という状況になり、その確認に時間を割く必要がでてしまう。
これでは「バグを効率的に減らす」という目的に対して、逆行しているといわざるを得ない。また、集中的に管理できたとしても、そのファイル／書面にアクセスするための時間的コストもばかにならない。
BTSの導入による恩恵は、ただ単にバグ管理を効率化するだけではない。最終的に製品の品質が向上し、それはユーザの利益にもつながってくるのだ。特に、大規模かつ、さまざまな使われ方が予想される「家電」の開発現場では、バグ管理の効率化によるメリットは計り知れないだろう。
一般的なシステム開発については、BTSをはじめとしたバグ管理のノウハウの公開や共有が進んでいる。ぜひ家電の分野においても同様の取り組みが行われ、よりよい製品作りが行われることを期待したい。 
タイトルへ戻る
