BTSはバグを管理するための道具ですが，チケットの処理記録を振り返ることで，プロジェクトやチームの状態を知ることができます。

普段から作業記録を残すように運用しておけば，BTSを業務改善の道具としても役立てることができます。

BTSに溜まったデータからわかること

BTSのチケットには作成日時，処理日時，処理方法などが記録されているため，処理にかかった時間や処理方法の偏りを調べることで，プロジェクトやチームの状態を読み取ることが可能です。考え方としては，Webのアクセス解析の仕組みなどに似ているかも知れません。

マネージャ視点での読み取り

では，まずマネジメントを行う立場の方にとって役に立ちそうなポイントを述べてみます。

報告されるバグの数が少なく，処理がRESOLVEDになることが多い

開発者によるテストのみで検証が十分にされていないか，テスターがいる場合は慎重なテスターがテストしているときこの状態になります。顕在化するバグの数が少ないからといって品質が良いとは限りません。

報告されるバグの数が収束し，RESOLVED以外の結果が目立つ

デバッグは最終段階を迎えています。もしもまだ納期前ならば，それなりに上手く行ったプロジェクトでしょう。ただし，派遣会社から調達した経験の浅いテスターをアサインしたなら話は別です。

NEWからRESOLVEDになるまでの平均時間が長い

バグが報告されてから修正されるまでの時間が長いなら，プログラマが不足気味ではないか検討してみる必要があります。また，チケットの粒度が問題で処理しにくい状態になっている可能性も考えられます。

REOPENDになる割合が増加している

検証に回ったものが頻繁に差し戻されるのは，何かしらバランスの悪い状態であることを示しています。また，新しいメンバーが追加されたときなどこの割合は自然に増加します。そのときはプロダクトに慣れて理解が深まれば減っていくのですが，理由なく増えているならば，プログラマのモチベーションやチームワークが悪化していないか気をつけた方が良いでしょう。

INVALID，DUPLICATEの割合が多い

未熟なマネージャが犯しやすいありがちなミスの1つに，最終段階で素人テスターを大量投入してデバッグしようとする行為があります。どこも人手不足ですから，急に借り出せる人材イコール他で不必要な人材ということです。無駄なチケットを処理するために貴重な時間が失われ，泥沼になるのはよくあることです。気をつけましょう。

NEWからFEEDBACKになるケースが多い

BTSへ不具合を報告する際は，再現手順などが正確に伝わるよう気をつけなくてはいけません。FEEDBACKは不慣れなテスターがいる場合など基本的に情報が足りないときのステータスですが，プログラマとテスターのコミュニケーションが取れているかも問題になっていることがあります。コミュニケーションさえ円滑に取れていれば多少のことは直接話し合えば済むはずですが，敵対関係になっていると問題が生じます。プログラマのモチベーションが低く，なかなか修正したがらないケースもありえます。

SUSPENDEDが全体の1/4以上ある・SUSPENDEDになったままの期間が長い

保留というステータスは必要不可欠ですが，使い過ぎは感心できません。本来，先方の連絡待ちになっている場合などに使うべきですが，面倒なチケットを退避しておくために，何かと理由をつけて保留されることもあります。あまり多くなっている場合は原因を取り除く必要があります。

ASSIGNEDへのチェンジ回数が多い

バグ修正がたらいまわしになっていませんか？

デスマーチに耐えかねたプログラマが続々雲隠れして，急遽採用した新人に全てを託したりしませんでしたか？

テスター視点での読み取り

テスターも単純にバグを報告するだけでなく，BTSの状態に気を配り己の仕事の糧にすべきです。周りに配慮して動けるテスターは，チームから信頼されるでしょう。

WONTFIXが目立つ場合

的外れな不具合報告であればINVALIDになるのでわかりやすいですが，不具合報告として有効なものの，処理されないのがWONTFIXです。修正可能な問題でもプロダクトへの要求の範疇から外れる問題は修正されません。

どちらにしろ結果には繋がらないチケットになりますので，プロダクトへの要求がどんなものか配慮して現実的な問題点を見つけ出すことに目を向けるよう心がけましょう。

NOT FIXABLEが目立つ場合

本来根源的な問題により修正できない時のステータスですが，開発陣の技術レベルによっては違う意味で使われているかもしれません。

もちろん元の報告が非現実的な場合も考えられますので，注意しましょう。

間違った読み取り方

間違った読み取り方をすると，役に立たなかったり，逆に有害なことも多々ありえます。やるべきではないことも触れておきましょう。

ASSIGNEDからRESOLVEDへ移行する時間を気にする

修正にかかる人的コストを計算しようとするとき，この時間を集計して個人や組織の能力の判断基準にしたくなると思いますが，それは間違っていることが多いといえます。これはチケットによりバラツキが大きい数字なので，ほとんど参考になりません。

バグの報告数が少ないのを気にし過ぎる。

バグ出しのために発見バグ数のノルマを設けてしまったりすると，無駄なチケットが増えます。自然な状態を観測することが有益です。

RESOLVEDからCLOSEになる時間を気にし過ぎる。

修正されたものはすぐ片付けてしまいたいものですから，スムーズにCLOSEされることを気にするかもしれません。しかし中には検証の難しいバグもあります。そして，ここで確認されたものは以後監視されないわけですから，慌てさせてチェックの手を抜くべきではありません。

「バグを3つ直すと1つバグが生まれる」という諺もあります。

BTSのデータを人事評価に使ってはならない

このように，BTSからいろいろなことがわかります。しかもこれらは数値として取ることができますので，これを人事評価に使いたいと思われるかもしれません。

しかし，データを人事評価に反映させるとなるとメンバーがそれを意識するので，不自然な運用がなされる可能性が生じます。BTSのデータを分析する際は，結果を業務改善の為にのみ用いるよう経営者に約束を取り付けておくべきです。

まとめ

今回はBTSを運用して得られるデータの読み取りと利用法についてご案内しました。BTSは導入しただけでも効果のあるものですが，データの分析を行って業務改善にも役立ててください。

次回は，この連載のまとめとして，ここまでに盛り込めなかったさまざまなお話をしたいと思います。