BTSの選定とセットアップが終了したら、いよいよ本格運用の準備に取り掛かることになります。慣れない方はここまででも相当神経を擦り減らせたことかと思いますが、せっかく始めたBTSの導入です、まず行うべき作業をしっかり押さえておきましょう。

最初にやること

MLの準備

チケット全体の動きをメールで流したい場合は、BTS専用のMLを作ってそこに送ると便利です。BTS自体の機能でもいいのですが、より柔軟に運用できます。

プロジェクトの作成

最初にやることはプロジェクトの作成です（BTSによってはインストール時に作成します⁠）⁠。管理者やMLのメールアドレス等を入力することになりますので、前もって準備しておきましょう。

項目のカスタマイズ

プロジェクトの性質により、足りない項目があれば追加しましょう。あまり神経質になる必要はありませんが、明らかに余計な項目があれば消しておくのも良いでしょう。実際の運用上、コンポーネントの項目は担当者別と同じような意味を持ちますので（主にそのコンポーネントの担当が修正も行うので⁠）⁠、体制に合わせて分割しておくと後々便利です。

メンバーの追加

プロジェクトにアサインされているメンバーを登録します。役割に合わせて権限を設定しておきましょう。

このときサブ管理者を任命してメンバーの追加登録を代行して貰えるようにしておくと便利です。

BTSのURLをすぐわかるようにしておく

運用開始のときにBTSのURLをメールでメンバーに通知するわけですが、メールは後々埋もれてしまい見失いがちですから、会社のWikiや社内ホームページのわかりやすいところにリンクを貼っておきましょう。

テスト用チケットを流す

準備が整ったらメンバーにBTSを触ってもらいます。このときただ触っておくように連絡するより、テスト用のチケットを作って各メンバーにアサインしてあげると良いでしょう。アカウント設定のチェックにもなります。

約束事を決める

ただ漫然とBTSを使い始めると、いろいろな混乱が起こります。操作に慣れなくてはいけないことに意識が向きがちですが、BTSの概念に対する認識のズレも問題になりやすい所です。複数人で共有するものですから、細かく認識を合わせておく必要があるでしょう。

処理フローを決める

チケット処理の流れについて、誰がどんな役目を果たすか決めておく必要があります。大まかには以下のような流れになりますが、細かいバリエーションがつけられます。

社内プロジェクトの場合

• チケットの割り当てはメンバーで調整してよいか、プロジェクトマネージャのみに限るか？
• 重要度、優先度の変更はメンバーも調整してよいか、プロジェクトマネージャのみに限るか？
• 修正の確認は起票したテスト担当者かプロジェクトマネージャに限るか？
• クローズできるのはプロジェクトマネージャのみに限るか？

などを決めていくと良いでしょう。

受託開発の場合

受託開発であれば、クライアントが自分でチケットを立てられるようにしておくと、苦情整理の手間が少なくなって便利です。

チケットの確認やクローズの権限をクライアントのアカウントに付与する形もよくあります。クライアントにとって不必要な部分は閲覧のみできるようにしておきましょう。いずれにせよ、上手く情報を公開することで秘密主義よりもフレンドリーにバグ修正を進められるでしょう。

処理ルールを決める

メンバーはアサインされたチケットを優先度に従って処理することになりますが、

• コメントをどの程度書くか？（最低限、後から見直してもわかるくらい書くのがオススメです）
• 「緊急」のものは原則当日中に処理するか？

など、具体的な運用ルールについて話し合っておくべきでしょう。

認識のズレやすい点について

処理方法（結果）

一番ズレやすいのが、closeのときに選択する処理方法（結果）の選別かと思います。

処理方法は大体以下の通りです。

NOT FIXABLE	解決方法が見つからないので修正不可能
INVALID	この問題はバグではない
WONTFIX	修正しない
DUPLICATE	他のチケットと重複している
WORKSFORME	'Works for me.'「私の所では動作した」のことで、問題を再現できなかった場合に使います。

特定の処理方法（VERIFIED、DUPLICATE以外）は判断しにくいものですので、マネージャが判断すること決めるとブレがなくなるかもしれません。そんな細かいところまで気にしなくても、いずれにせよ問題は解決したのだから処理方法などどうでもいいと感じるかもしれませんが、正確に記録しておくと後で統計を取り利用することができます。

BTSの使われ方やプロジェクトの状態を示すデータが取れますので、特に専門のQAの方はここをきちんと整理しておくと良いでしょう。

重要度と優先度

明確に区別しにくいのが重要度と優先度です。ほとんどの場合重要であれば優先度も高いので、軽い使い方であれば片方あれば十分かもしれません。一致しない例としては、サーバを乗り換えた時の旧HDDのデータ削除などですと重要度は高く優先度は低いでしょう。クライアントの要望はすぐ修正するように、軽微な改修でも優先度を上げておく、などの使い方が一般的でしょうか。

心理的な障壁を取り去ろう

BTSを使うとき、最初はなにやら野暮ったく面倒そうな印象を受けるものです。そういった心理的な障壁を解消するポイントがいくつかあります。BTSをメンバーに見せる前に一呼吸置いてカスタマイズしておくといいでしょう。

プロジェクトのロゴマークを入れる

多くのBTSでロゴマークの設定ができます。ぜひプロジェクトのロゴに入れ替えましょう。親近感がわくとともに、複数プロジェクトを取り扱っている場合取り違えにくくなります。

背景を入れ替える/CSSを設定する

配色をコーポレートカラーなどにすれば、違和感を感じさせずに導入できるでしょう。

一言メッセージを設定する

Bugzillaでは、ヘッダに一言メッセージをランダムに表示できるようになっています。労わりのメッセージやジョークを入れてみましょう

まとめ

今回は運用の開始時に行うべきことをご案内しました。物事は最初が肝心とも申しますので、しっかり準備して良いスタートを切ってください。次回は、日々の運用のコツについてお話したいと思います。