バグトラッキングシステムとは
バグトラッキングシステムとは、日本語で言うと障害管理システムのことです。Bug Tracking Systemの頭を取って通称BTSとも呼ばれています。テストなどで発見された障害（バグ）を登録し、それが修正されて完了するまでを追跡（トラッキング）するためのシステムです。
図１：バグトラッキングシステム（BTS）の役割
バグトラッキングシステムのメリット
バグトラッキングシステムを使えば、障害を一元管理して、プロジェクトメンバーで共有し、きちんと修正されるまでを見届けることができます。さすがに今どきバグトラッキングシステムを使わずにシステム開発している現場はないと思いますが、もし、Excelなどで障害管理しているようでしたら、下記の比較表で効率の違いを確かめてください。
バグトラッキングシステムは、障害管理のための専用システムなので、バグ情報の共有や検索が簡単にできます。画像ファイルなどの添付もできますし、バグ曲線グラフ表示やバグ情報の分析も備わっています。メール配信と連動させることもでき、ユーザビリティもExcelに比べて格段にいいので、効率よくバグ管理できるのです。
| BTS | Excel | |
|---|---|---|
| バグ情報の共有 | システムにログインすれば権限に応じて情報共有。同時書込みも可能 | ファイル形式なので共有しにくい。また、一度に書き込みもしにくい。 |
| バグ情報の検索 | 自分が対応しなければならない障害やキーワード検索など、さまざまな検索が可能。 | フィルタなどの機能を駆使することになるが、検索しにくい。 |
| ファイルの添付 | バグを示すスクリーン画像の添付などが簡単に行える。 | 画像ファイルの添付ができず、紐付けがやりにくい |
| バグの分析 | バグ曲線のグラフ表示、どのようなバグが多いかなどの分析も可能 | 分析するには、自身でグラフ機能などを使って作りこむ必要あり |
| メールやチャット配信 | バグ登録により、修正担当者にメールやチャットを飛ばすなどの自動処理が可能 | 担当者に手書きでメールを書いて送信しなければならない |
| ユーザビリティ | 日付カレンダー、プルダウン、デフォルトセットなど使いやすい | 所詮Excelなので入力しにくい。 |
表１：バグトラッキングシステム（BTS）とExcelの主な違い
バグ管理のワークフロー
Excelなどでは、バグをただ登録して修正したらクローズするというシンプルな管理になりますが、バグトラッキングシステムはバグの発生からクローズまでの”バグの一生”を役割分担と処理フローできめ細かく管理できます。図2のBTSのワークフローを元に説明しましょう。
①バグの報告（登録）
バグらしきものを見つけた人（もしくはその報告を受けて代理で登録する人）は、バグ情報を登録します。このとき、後続の人が分かりやすいように画面のキャプチャーを添付したり、緊急度や障害分類（どんな種類の障害だったかを分析できるもの）を付けます。
②バグの認定
報告された事象は、必ずしもバグとは限りません。勘違いであったり、要望であったり、再現できなかったりすることもあります。そのため、いきなり対応者（バグ修正する人）に指示を送る前に内容を確認して対応すべきかどうかを判定します。対応すべきと判断した場合は、対応方針と対応希望者を指定しますが、俗に言う「これは仕様です」などの対応しないものはそのままクローズします。
③バグの対応
対応者は、バグの原因を調べて、その内容に応じてプログラムの改修や仕様書の修正を行います。このとき、原因分類（どんな原因だったかを分析できるもの）を付けるとともに、修正にかかった工数を記録して、後で障害対応コストを算出できるようにします。
④対応の確認
バグの修正対応が終わったら、確認者は正常に動作するかどうかを確認し、ＯＫであればクローズします。ＮＧの場合は、どこが問題なのかコメントを加えて対応者にやり直しを指示します。対応者は修正した上で新たに原因分類と工数を追加してもう一度確認してもらいます。
図２：バグトラッキングシステム（BTS）のワークフロー
バグトラッキングシステムの機能
BTSは、OSS（オープンソースソフトウェア）のものがたくさん出回っています。RedmineやTrac、Mantisなど実績の豊富なものも多いので、これまでBTSを使ってなかったとしたら、ぜひ、利用することをお勧めします。
これらのソフトはチケット駆動開発（Ticket Driven Development：TDD）と呼ばれる管理手法で、「バグの登録＝チケットの発行」としてそのチケットを持ち回り、適切に処理されてクローズするまでをトラッキングする仕組みを持っています。
OSSのメリットは何と言ってもただで使えることですが、自分好みにカスタマイズできる点も意欲のある人には魅力です。ただし、BTSをどのように使いこなすと効率的に障害管理できるかを理解してないと中途半端なまま使う恐れもあります。
当社は統合型プロジェクト管理システム（OBPM）を使っているため、上記のような単独のBTSではなく総合的なプロジェクト管理の１機能としてBTS（障害管理機能）が備わっています。単なるバグ管理で閉じていないので、プロジェクトの健康状態を総合的に判断することができます。また、Easy to Useを重視して誰でも事前設定の必要なくそのまま使えます。当社の持つバグ管理のノウハウをもとに、登録する項目やワークフローをテンプレート化して提供しています。 OBPMの画面をもとにBTSに備わるべき機能を説明しましょう。
(1)障害登録画面（画面1）
画面１：OBPMの障害登録画面
BTSの多くが汎用性を重視して、その分複雑になっているのに対し、OBPMは専用システムなので、シンプルに効率良くバグトラッキングを行えるようにしています。
①ワークフロー
画面1のように、１つの画面内にワークフローの役割に応じた登録蘭を用意し、どのような状態なのかが一目で把握できるようにしています。
②ファイル添付
画面キャプチャーなどのエビデンスを複数枚ファイル添付できます。
③分類付け
重要度や緊急度、対策難易度などの重みづけのほか、障害分類（どのような障害だったか）や原因分類（なにが原因だったか）など分析に必要な項目を付加できます。
④日付管理
発生日、登録日、認定日、対応日、確認日など、フローの各段階に応じた日付を登録して管理します。また、対応期限を入れると、緊急度を日付で示すことができます。
⑤関連障害/関連質問
１つの障害に関連して複数の障害を登録したり、質問を受けたら実はそれが障害だったというケースに対応できるように、関連障害や関連質問も管理できます。また、同じようなバグをいくつも登録する必要がある場合も多いので、コピー機能も用意しています。
⑥通知
図2のワークフローにおける”次の人”へ通知メールが飛ぶようにします。OBPMの場合は、画面２のような「メール配信設定」機能により、障害情報パラメータをメール件名や文章に入れたメールが自動で飛ぶように設定できます。ただし、テスト期間中はいちいちメールが来ると面倒なので「使用」チェックボックスをオフとし、保守などのフェーズに入ったときに使うなどの使い分けをすることが多いようです。
画面２：メール配信設定
(2)障害一覧画面（画面３）
画面３：OBPMの障害一覧画面
登録された障害は画面３のように検索＆一覧表示されます。この画面を例に検索のポイントを説明しましょう。
⑦対応状況の検索
ワークフローでは、処理と処理の間の”残”を管理します。図３の例では、認定待ち、対応待ち、確認待ち、完了という４つの対応状況がありますので、画面２のようにそれらの対応状況ごとを検索できるようにします。
⑧自分のチケットの検索
「自分が登録したバグがどのように処理されているか」「自分が対応しなければならない対応待ちバグは」「自分が確認しなければならない対応済のバグは」など、自分に関係するチケットを一覧表示できるようにします。画面３では、担当者欄に自分を入れて、報告者、認定者、対応希望者、対応者、確認者という５つの役割で自分の関わるチケットを検索できるようにしています。
この時、自分に回ってきたチケットだけでなく、自分が回したチケットも検索できるようにして顛末を確認できるようにしましょう。
⑨対応期限や分類による検索
障害登録時に「対応期限」を登録してあれば、最優先のチケットから処理できます。また、「要望（バグじゃない）」、「課題（対応は見送る）」、「再現しない」などの対応区分や「プログラミングミス」、「仕様書記述ミス」、「仕様が間違い」などの原因分類でも検索できると便利です。
⑩キーワードや機能で検索
規模の大きなシステムでは障害登録数が1万件を超えることもあります。登録数が多いと後で特定の機能の障害だけ見たいという場合に探すのが大変なので、任意のキーワード検索できる必要があります。また、「受注入力画面」に関する障害というように、特定の機能（OBPMでは明細）で絞り込めるようにしましょう。
⑪工程による検索
ウォーターフォールでは単体テスト、結合テスト、総合テストなどの工程で障害が発見されて登録されます。本来は上流工程で発生したバグが全部クローズされてから次工程に進むべきですが、現実にはバグが残ったまま次工程に突入したり、期間が重なって並行で進むこともあります。そのため、どの工程で発生した障害なのかを検索できる必要があります（これはアジャイル開発でも同じです）。
⑫ソート
任意の項目でソートできるようにしましょう。「発生日」順はもちろんですが、「緊急度」や「重要度」などでソートすると優先順位の高いものから対応することができます。OBPMの場合は、表の上部タイトル部分をクリックすることで昇順・降順という順番にソートできます。
BTSの利用シーン
要件定義や設計工程などの上流工程では”バグ”と呼ばずに”課題”として登録して管理するので、BTS（Bug Tracking System）ではなくITS（Issue Trackng System）と呼ばれています。どちらもチケット駆動で処理するので一緒にしていることが多いですが、課題は顧客と共有することも多いのでOBPMではBTSとは別に専用の「課題管理機能」を用意しています。
また、BTSに障害を登録してクローズまでを追跡するのは、通常の開発フェーズ（プロジェクト期間内）と稼働後の保守フェーズがあります。前述のように保守フェーズではメールで自動通知するとか、かかった対応工数をより厳密に管理するなど運用方法が少し変わります。
図３：バグトラッキングシステム（BTS）の利用シーン
BTSを使いこなすコツ
BTSを使いこなすコツは「Simple is best」です。BTSを準備する側はQC（品質管理）リテラシーも高く、つい、あれこれ欲張ってしまうのですが、使うのは普通のエンジニアたちです。大勢の人たちが使いますし、必死にバグと戦っているさなかに登録・利用するわけなので、できるだけシンプルにしてあげてください。
なお、BTSには、バグ曲線を表示するなどのグラフ機能や障害を分析して品質改善につなげるなどの分析機能もあります。これらについては次回に詳しく説明します。
（株式会社システムインテグレータ 梅田弘之）
