ここまで標準的なBTSの取り扱いについてご案内してきましたが，既存のBTSを使わずに自前で用意したり，類似の別のシステムを導入するという選択肢もあります。BTSの導入を検討するとき，これらの選択肢の存在も無視できないものですので，これらについても触れてみたいと思います。また，他の開発アプリケーションとの連携についてもご紹介したいと思います。

BTSを内製する場合の注意

既存のBTSが業務にうまくマッチしないと判断した場合や，カスタマイズの知識が無い場合，過去の経緯により不具合リストの機能を拡張して使用している場合など，内製のBTSを使うケースも見られます。割合的にも結構多いようで，BTSを使っている組織のうちおよそ2割くらいあるようです。

ここでは内製BTSでありがちな問題点を挙げてみたいと思います。

細かい部分の完成度が低くなる

内製BTSは業務に特化して作られるので，項目の設定などは思う通りできているものですが，ページ遷移の具合やリストの見やすさ，検索機能などの細かい部分で詰めが甘くなり，使い勝手の悪いものが多いように思います。

本筋の開発の傍らでBTSの開発に割り当てられる時間は少ないでしょうから，重要でない部分は自ずと中途半端なままになってしまいます。しかし，毎日使用するツールとしてはまさにそうした使い勝手の部分が大事で，ほんの少し表示が見づらかったり，確認ダイアログが多すぎたりするだけで，使いにくいものができあがってしまいます。

独特のバグ処理文化になる

BTSに詳しくない人がBTSを内製すると，往々にして奇妙なシステムができあがります。既存のBTSは長い間人々に使用されており，細部までいろいろ考えて作られているので，それを導入することで，これまで培われてきたノウハウや文化を取り入れることができますが，安易な内製BTSにはそれがありません。用語の定義が最も混乱しがちな部分で，世間に通用しないローカルな文化を作り上げてしまう危険があります。

社内用なのだから社内の人間にわかれば良いとされがちですが，新人への教育コストも余計にかかりますし，何らメリットはありません。

要求の変化を考慮する

内製は既存のものを使うのに比べて準備に時間も手間も掛かります。作っていくうちに業務で要求されることが変わってしまう可能性もありますので，せっかく作ったのに短い期間しか使わなかった，などという事態も考えられます。業務の先を見据えて本当に内製が必要かどうか計画を練る必要があります。

軽い気持ちで内製したものの状況が変わって陳腐化してしまい，しかし開発コストをかけてしまったゆえに捨てるに捨てられなくなる，というのが最悪のパターンだと思います。