ソフトウェア開発の必須アイテム、BTSを使ってみよう

第2回BTSの選定と導入作業

システム開発にもさまざまありますが、BTSにもさまざまな種類があり、想定した開発内容に合致するよう考えて作られています。ですからBTSの導入に当たっては、組織にピッタリ合うBTSを選定することが重要です。選定を誤って無駄な作業手順が発生したり、不要な項目を抱えながら使わざるをえなくなると、使用感が悪いように感じてしまい、せっかくのツール導入に逆風が吹くことになります。

また、今まで慣れていた開発フローを変更することになるわけですから、導入の流れも慎重に計画すべきです。

選定時に着目すべきこと

まずは、どのBTSを導入にするか目星を付けましょう。デモ版を触ったり解説を読んだりして吟味することになりますが、その際気をつけるべきポイントを列挙します。

処理フロー・設定項目は希望通りか
項目は加減できるケースが多いですが、処理フローはほぼ決め打ちなので、開発スタイルに合うか検討しておきましょう。
権限管理を適切に行えるか
プロジェクトに関わる人が増えてくると権限管理が必要になります。役割分担(ロール)を適切に設定できるか見ておきましょう。
複数プロジェクトを扱えるか
対応していないBTSでは、プロジェクトごとにインストールしなくてはなりません。
レポートの出力形式
レポート出力が充実していると、顧客への報告が楽になります。
データインポート、エクスポートの対応状況
定期的にバックアップを取る必要がありますし、何らかの都合でBTSを引越しするかもしれません。
インストールは容易か?
BTSは準備が面倒というイメージがありますが、導入を楽にするためにパッケージ化されているものもありますので、探してみると良いでしょう。
日本語のヘルプ・インストールマニュアルがあるか?
当然ですが、日本語対応しているものでなくては使えません。ドキュメントが日本語化されているようでしたら本体も対応済みと考えられます。
馴染みのある言語で書かれているか?
機能を拡張したり、不具合を修正したりすることになるかもしれません。
データを使いまわせるか
乗り換えを意識して他のBTSがデータのインポートを受け付けているケースがあります。 実際に使ってみてどうも合わないと思ったとき、途中で乗り換えることができます。
高機能過ぎないか
要求を満たす限り、最初に使うBTSはシンプルなほうがよいです。
見易さ・デザイン
毎日使うツールですから、見た目の印象も考慮にいれてよいと思います。テンプレートを編集可能なBTSもあります。

メジャーなBTSとその特徴

以下に比較的メジャーなBTSと特徴をご紹介します。

Webベースのもの

Bugzilla
当初はNetscapeの社内で使われていたものが、1998年8月にオープンソース化されたものです。歴史が古く利用実績が多いBTSです。Perlで実装されています。
図1 Bugzillaの画面
図1 Bugzillaの画面
MANTIS
一般に人気のあるBTSで、Kenzaburo Ito氏によって開発されたWebベースのオープンソースのBTSです。PHPで実装されています。
Trac
エンジニア寄りの人に好評なBTSで、バージョン管理システムやwikiと合体したプロジェクト管理システムというべきものです。Pythonにより実装されています。日本では、Windows上へ楽に導入できるTrac Lightningも提供されています。
RedMine
Tracに似た機能を持つオープンソースのプロジェクト管理ソフトウェアです。Ruby on Railsで記述されています。Railsの流行と共に人気が高まっています。

Webサーバ不要のもの

GNATS
旧式ながらWeb、Emacs、メールなど、多様なインターフェースを持つBTSで、Linux上で動作します。
GNATSをメールインターフェースで使った例として、apache.orgでの使用例があります。
Papilio
Eclipseのプラグインとして提供され、Webサーバ不要のBTSです。他の端末と同期して動きます。
図2 Papilioの画面
図2 Papilioの画面

導入にあたって確認しておくこと

BTSの目星がついたら、導入手順の検討に入ります。

推進担当者を決める
下調べや、設置、教育などにそれなりのコストがかかります。日々忙しい業務の片手間でやるのは厳しいので、担当者を決めて作業時間を割り振るべきです。
設置場所の確保
まずはサーバなど物理面の手配です。軽量なBTSであれば、低スペックの余っているPCでもいいでしょう。
セキュリティポリシーに抵触しないか運用形態を確認する
重要な情報を取り扱いますから、社内からのアクセスに限るなど、セキュリティを考慮しなくてはいけません。どのように運用するかを確認しましょう。
導入時期・案件
ちょうどテストフェーズの案件があるから、と慣れないものをいきなり導入すると失敗の元です。小さめの新規案件から試してみましょう。
導入のメリットを周知しておく
会社の文化としてBTSが定着するまで時間がかかります。なんとなく導入するのではなく目的を明確にして乗り切りましょう。メンバーの同意を取り付けておくのもお忘れなく。

導入の落とし穴

さて、一通り導入のポイントをご案内してきましたが、意外なことで導入に失敗するケースもあります。気をつけなくてはいけないことは何でしょうか?

変化を好まない管理職やスタッフの反対に遭うケース

主に導入のメリットが浸透しておらず、トップダウンでなく現場のエンジニアから導入を進めている場合、ちょっと触ってみて理解できないと投げ出されてしまうことがあります。便利そうなので使ってみようと思うんですが~というノリだけでBTS導入を始めると、危険かもしれません。

訓練コストの不足による混乱

慣れないうちはチケットを一枚書き上げるのも一苦労です。今まで通りメールで送るのが楽なんだけど、入力しておいてくれない?ともなりかねません。入力項目の取り扱いルールも、共通認識ができあがるまでは混乱しがちです。慣れないうちは仕様に詳しい人間が積極的にバックアップするようにしましょう。

まとめ

今回はBTSの選定と導入のコツについてご案内しました。導入で一番重要なのは、推進担当者の熱意かもしれません。ぜひ導入を成功させてBTSを使いこなし、あなたのチームをレベルアップさせてください。

次回からは、代表的なBTSについて、それぞれの特徴・設置手順などをご案内したいと思います。

おすすめ記事

記事・ニュース一覧