はじめに
BTS(バグ・トラッキング・システム)は、その名の通りバグ(不具合)修正を管理するために作られたシステムです。
近年、開発の現場では欠かせない重要なツールとなりつつあります。BTSはバグの状態や誰が担当者かを記録し、処理の流れを管理してくれます。BTSはWeb上で動作するものが主流ですが、ローカルネットワーク内で使うタイプのものもあります。BTSの知名度は比較的高いといえますが、その一方で、セキュリティ上の懸念や既存の会社文化が妨げとなって、うまく導入できないという話も時折耳にします。
本連載ではBTSの選定・導入方法などの解説を主眼として、基礎からさまざまなTipsまで取り上げてみたいと思います。
BTSのないシステム開発は…
あなたがBTSを使っていない受託開発会社のテスト責任者だったとしましょう。開発が終盤になり成果物がその姿を現し始めると、往々にして数多くのバグが顕在化してきます。納期に余裕のない案件で、十分なデバッグが行えないまま顧客を交えての修正大会に突入した場合、どんなことが起こるでしょうか?
入り乱れるバグ報告
受け入れテストで品質不足が露呈、その翌日から「こちらで見つけたバグを送ります」と顧客からメールでリストが届くようになります、あなたはそれを自社のバグリストに逐一マージするでしょう。
その後遅々としてデバッグは進まず、さらに3日ほど経ったころ、「作業は進んでいますか?上司に報告しますので、こちらから報告したどのバグが直ったか、毎日レポートを送ってください」と言われてしまいます。慌ててバグリスト項目に目印を追加、それから毎日集計のためだけに数時間を消費するようになるでしょう。
見えないデバッグ進捗
さらに顧客から「デバッグが進まないのでこちらでテスト人員を確保しました」と連絡がきます。そして翌日から送られてくるバグレポートは開発側で既知のものばかり。手元のバグリストを渡して、同じものは送らないでくれ、と申し入れると「現在直ったかどうかわからないので重複していても送ります。そちらで調整してください」と言い返されてしまいます。
人間BTSの誕生
こうなっては、あなたの仕事のほとんどの時間はバグリスト管理に奪われてしまいます。
なんとも溜息の出る話ですが、これらはBTSを導入していれば簡単に避けることができるトラブルばかりです。
Excelでの手作業から抜け出そう
BTSが導入されていない環境では、多くの場合、Excelのような表計算ソフトでバグのリストを作っていると思います。集計などはマクロを組んで処理しているといった話もよく耳にします。ごく単純な案件であれば、MLのみ、紙に手書きということもあるかもしれません。バグが2桁程度であれば、整理係を一人置いて頑張れば何とかこなせるでしょうが、数百件以上となってくると、もう人力では限界が生じてきます。
また、Excelなどでは複数の人間が一度に編集作業を行うことはできませんので、チームが大きくなればなるほど待ち時間が増え、編集が面倒になってきます。
こういった開発方法は非効率な部分が多いと言えるでしょう。
BTS導入のメリット
BTSを導入するメリットを具体的に挙げてみましょう。
ユーザの権限管理ができる
多くのBTSではアカウントごとに閲覧や書き込みの権限を設定することができ、最終確認は特定のアカウントに限るなど、大人数の開発でも混乱を防ぐことができるようになっています。
ワークフローの明確化
そのバグを受け持っているのは誰か、どんな状態にあるかを管理すると共に、「バグの一生」とでもいうべき処理の流れを制御します。
代表的な流れは図2のようになります。
報告されたバグはNew(新規)から始まって、Assigned(割り当て済み)→Resolved(処理済み)→Verified(確認済み)→Closed(解決済み)と流れて完了します。差し戻しが発生すると、Reopend(再開)となります。
報告フォーマットの統一
紙媒体や表計算ソフトでは空欄での入力を防ぐことができず、情報の収集に支障を来たすことがあります。BTSを使って必須項目を設けておけば、より確実にインシデントを収集できます。
集計レポートの作成
BTSによっては、バグ除去率をグラフで表現するなど、綺麗なレポート出力ができるものもあります。きちんとしたレポートは見た目の安心感がありますので、顧客とのやり取りに一役買ってくれるでしょう。
リアルタイムに情報共有可能
複数人で同時に作業可能ですので、バグの報告も即座に共有可能です。ほとんどのBTSがメールでの通知もサポートしています。
バグ処理履歴の記録が可能
どのような処理を行ったか時系列で記録してくれますので、処理履歴の追跡が容易です。表計算ソフトではただ上書きするだけになりがちで、過去の経緯まで振り返ることができません。
さまざまな付加機能
BTSによってはバグ管理のみならず、テストケース管理ソフトと連携したり、wikiやバージョン管理ソフトと合体したものもあります。これらが開発スタイルと合致すれば、非常に便利なツールとなります。
どうでしょう、非常に魅力的かと思います。
これらのメリットを前述のBTSのない開発エピソードに当てはめてみましょう。
顧客側にもBTSを使ってもらい、バグリストを入力してもらえば、受付やマージの手間は発生しません。アカウント管理をしていますので、顧客は自分の報告したバグだけを絞り込んで閲覧することが、いつでも簡単にできます。いちいち報告する必要は生じません。バグを検索すればそれが報告済みでないか、次のビルドで修正されるのかどうかをすぐ調べることも可能です。
デモを触ってみよう
このように、とても導入効果の高いBTSですが、初めての方は何をするのかピンとこないかもしれません。そういう場合はデモを触ってみるのが一番です。
数あるBTSのひとつ、MANTISのデモを見てみましょう。
「新しいユーザーの作成」からアカウントを作成して、「登録」から作業割り当て、解決済みまでチケットを動かしてみましょう。また、バグ一覧の絞込みや検索も試してみてください。
最初は取っ付きにくく感じるかもしれませんが、日本語化されているBTSであれば、慣れるまでにそれほど時間はかからないと思います。
まとめ
今回はBTSの概要とその魅力に触れてみました。次回以降は、開発スタイルに合わせたBTSの選定・設置についてお話したいと思います。