ここまで標準的なBTSの取り扱いについてご案内してきましたが、
BTSを内製する場合の注意
既存のBTSが業務にうまくマッチしないと判断した場合や、
ここでは内製BTSでありがちな問題点を挙げてみたいと思います。
- 細かい部分の完成度が低くなる
- 内製BTSは業務に特化して作られるので、
項目の設定などは思う通りできているものですが、 ページ遷移の具合やリストの見やすさ、 検索機能などの細かい部分で詰めが甘くなり、 使い勝手の悪いものが多いように思います。 - 本筋の開発の傍らでBTSの開発に割り当てられる時間は少ないでしょうから、
重要でない部分は自ずと中途半端なままになってしまいます。しかし、 毎日使用するツールとしてはまさにそうした使い勝手の部分が大事で、 ほんの少し表示が見づらかったり、 確認ダイアログが多すぎたりするだけで、 使いにくいものができあがってしまいます。 - 独特のバグ処理文化になる
- BTSに詳しくない人がBTSを内製すると、
往々にして奇妙なシステムができあがります。既存のBTSは長い間人々に使用されており、 細部までいろいろ考えて作られているので、 それを導入することで、 これまで培われてきたノウハウや文化を取り入れることができますが、 安易な内製BTSにはそれがありません。用語の定義が最も混乱しがちな部分で、 世間に通用しないローカルな文化を作り上げてしまう危険があります。 - 社内用なのだから社内の人間にわかれば良いとされがちですが、
新人への教育コストも余計にかかりますし、 何らメリットはありません。 - 要求の変化を考慮する
- 内製は既存のものを使うのに比べて準備に時間も手間も掛かります。作っていくうちに業務で要求されることが変わってしまう可能性もありますので、
せっかく作ったのに短い期間しか使わなかった、 などという事態も考えられます。業務の先を見据えて本当に内製が必要かどうか計画を練る必要があります。 - 軽い気持ちで内製したものの状況が変わって陳腐化してしまい、
しかし開発コストをかけてしまったゆえに捨てるに捨てられなくなる、 というのが最悪のパターンだと思います。
BTSに類似するシステム
ITS（Issue Tracking System）
BTSに近い使い方が出来るものにITSがあります。
BTS中心に開発を行うようになると、
導入に当たっては、
代表的なITSにはscarabなどがあります。
プロジェクト管理ツール
プロジェクト管理ツールは、
いくつかの機能の集合体で、
前述のITSと同じようにバグ処理にフォーカスしたものではないので、
他のアプリケーションとの連携
テスト管理システムとの連携
テスト管理システム
BTSは顕在化した不具合を管理しますが、
多くのBTSと連携できるフリーのテスト管理システムにTestLinkなどがあります。
- TestLink.
JP - TEF有志によるTestLink日本語化プロジェクト
SCM（ソフトウェア構成管理）との連携
ソフトウェア構成管理でよく利用されるSubversionには、
終わりに
BTSについて選定から運用まで一通りご案内してきましたが、
この連載が皆さんのBTS導入の一助になれば幸いです。