はじめに

BTS（バグ・トラッキング・システム）は，その名の通りバグ（不具合）修正を管理するために作られたシステムです。

近年，開発の現場では欠かせない重要なツールとなりつつあります。BTSはバグの状態や誰が担当者かを記録し，処理の流れを管理してくれます。BTSはWeb上で動作するものが主流ですが，ローカルネットワーク内で使うタイプのものもあります。BTSの知名度は比較的高いといえますが，その一方で，セキュリティ上の懸念や既存の会社文化が妨げとなって，うまく導入できないという話も時折耳にします。

本連載ではBTSの選定・導入方法などの解説を主眼として，基礎からさまざまなTipsまで取り上げてみたいと思います。

BTSのないシステム開発は…

あなたがBTSを使っていない受託開発会社のテスト責任者だったとしましょう。開発が終盤になり成果物がその姿を現し始めると，往々にして数多くのバグが顕在化してきます。納期に余裕のない案件で，十分なデバッグが行えないまま顧客を交えての修正大会に突入した場合，どんなことが起こるでしょうか？

入り乱れるバグ報告

受け入れテストで品質不足が露呈，その翌日から「こちらで見つけたバグを送ります」と顧客からメールでリストが届くようになります，あなたはそれを自社のバグリストに逐一マージするでしょう。

その後遅々としてデバッグは進まず，さらに3日ほど経ったころ，「作業は進んでいますか？上司に報告しますので，こちらから報告したどのバグが直ったか，毎日レポートを送ってください」と言われてしまいます。慌ててバグリスト項目に目印を追加，それから毎日集計のためだけに数時間を消費するようになるでしょう。

見えないデバッグ進捗

さらに顧客から「デバッグが進まないのでこちらでテスト人員を確保しました」と連絡がきます。そして翌日から送られてくるバグレポートは開発側で既知のものばかり。手元のバグリストを渡して，同じものは送らないでくれ，と申し入れると「現在直ったかどうかわからないので重複していても送ります。そちらで調整してください」と言い返されてしまいます。

人間BTSの誕生

こうなっては，あなたの仕事のほとんどの時間はバグリスト管理に奪われてしまいます。

なんとも溜息の出る話ですが，これらはBTSを導入していれば簡単に避けることができるトラブルばかりです。

Excelでの手作業から抜け出そう

BTSが導入されていない環境では，多くの場合，Excelのような表計算ソフトでバグのリストを作っていると思います。集計などはマクロを組んで処理しているといった話もよく耳にします。ごく単純な案件であれば，MLのみ，紙に手書きということもあるかもしれません。バグが2桁程度であれば，整理係を一人置いて頑張れば何とかこなせるでしょうが，数百件以上となってくると，もう人力では限界が生じてきます。

また，Excelなどでは複数の人間が一度に編集作業を行うことはできませんので，チームが大きくなればなるほど待ち時間が増え，編集が面倒になってきます。

こういった開発方法は非効率な部分が多いと言えるでしょう。