前回からかなり間が空いてしまいましたが、さて今回は実際の運用に関してです。

普通のBTS運用

まず影舞による一般的な運用から。

一般的な運用ではバグレポートは以下の流れを順にたどります。

新規	ポストされたばかりのレポート
受付済	担当者がアサインされた状態
修正済	担当者が修正済みの状態
完了	確認等を経て完了した状態

バグを発見した人がBTSにバグレポートをポストし、開発側がその対応に担当者をアサインします。

アサインされた担当者はバグを修正し、修正が完了したら確認等を経て完了をレポートします。

「バグトラッキングシステム」という名前そのままのシンプルな運用ですね。

影舞以外のBTSでもここらへんは基本的に同じであるかと思います。

ついでにポストやリプライの内容がメンバー全員にメールで飛ぶようにしたり、RSSで購読できるようにするのも一般的ですかね。

FFの場合

私たちもとりあえず上記のような運用からスタートして、その後走りながら試行錯誤を重ねていきました。

その結果、現在では以下のような流れでバグを処理しています。

新規	ポストされたばかりのレポート
受付	技術チームが問題を確認した状態
実行中	担当者がタスクとしてコミットした状態
実行済	担当者が作業を完了して確認者に確認を依頼した状態
リリース待ち	確認者が修正内容を確認してリリースを待っている状態
完了	修正がリリースされ、確認者が本番環境で再度修正内容を確認した状態

担当者に関しては一方的なアサインはせずに、担当者自らがコミットして作業を開始するようになっています。

担当者は作業を開始したらステータスを実行中にして自分が取り組んでいることをアピールします。

修正作業が終わるとレポートのステータスは実行済みとなり、担当以外の他のメンバー（確認者）に修正の確認依頼がかかります。

確認者は修正内容の確認を行い、問題がなければリリース待ちとします。

リリース待ちのものは本番にリリースされたタイミングで、再び確認者が確認を行い、本番環境でも問題がなければ完了とします。

確認の手間が二度にわたっていてめんどくさいと思われるかもしれませんが、品質の維持や修正の抜けによる手戻りが発生することを考えればコスト的には高くないと考えています。

BTS人形

さてところで上記のように作業からリリースまでの間に以上のフローを定めたのはいいのですが、実際には実行済み状態で放置されるレポートが多数発生。

修正のリリースに支障をきたすという事態がしばしば起こるようになりました。

そこでその状況を打開すべく登場したのが次のBTS人形です。

確認を依頼する際、これ見よがしに確認者の机の目立つところやキーボードの上に置くのが正しい使い方です。

彼らのおかげで確認忘れがほぼなくなり、修正作業からリリースまでの流れがスムーズになりました。

ただしごくたまに誰かの机の上に定住してしまっている人形もいたりするので、そうならないようにたまにチェックをいれる必要はありそうです。

アグレッシブなBTS運用

FFでは機能追加や改良に関する要望や提案などもBTSで管理しています。

すべての要望はまずBTSに登録されて検討されます。

BTSのこうした使い道に関しては Bugzillaのドキュメントにも見られるように、 BTS運用の第二のステップとしては割と普通のことなのかなと思います。

この流れが更に発展していくと、Tracなどに見られるようなプロジェクト管理ツールへの統合や進化の方向へ向かっていくみたいですね。

とはいえあんまり複雑にしても

現在のFFのBTSを見ると、他にもいろんな項目がオプションとして追加されています。

バグや要望のレポートをより効率よくかつシステマチックに処理しようとした努力の跡です。

でも実際はちょっとの間使われただけで、それらの項目は今は使われなくなってしまいました。

複雑なものや面倒なものはそれを利用するモチベーションが切れると使われなくなるのが常です。

ツールの助けがあるとはいえ、運用をシンプルにしていくことはやはり大切なのでありますね。

まとめ

というわけで以上がFFのBTS運用のお話でした。

日々試行錯誤しつつ運用しているので、常に変わる可能性はありますが、現時点ではこんなかんじです。

また何か大きな変化や思いついたことがあれば第三弾を書くかもしれませんが、とりあえず今回のところはこれにて。

ではでは。