バグ追跡 が扱う範囲は多岐にわたります。 この本ではバグ追跡についての様々な側面を議論しています。 ここでは バグ追跡システムをセットアップすることと、 その作業に関する技術的な考察に集中しようと思います。 その話題に入る前に、バグ追跡の方針に関する質問から始めましょう。 具体的にどの情報をバグ追跡システムに保存すべきなのでしょうか?
バグ追跡システム は、誤解を招きやすい用語です。 バグ追跡システムは、新しい機能要望や、一度限りのタスク、 送られてきたパッチ — はじまりと終わりの状態があるすべてのもの、 存在している間に情報が発生するすべてのものを追跡するためによく使われます。 このため、バグ追跡システムは、 問題追跡システム、 不具合追跡システム、 影響追跡システム、 要望追跡システム、 チケットシステム などとも呼ばれています。 バグ追跡システムのソフトウェアの一覧は、付録C フリーなバグ追跡システム を参照してください。
この本では "バグ追跡システム" という用語を、 バグを追跡するソフトウェアを指すものとします。 なぜなら、殆どの人がバグ追跡システムと呼んでいるからです。 しかし、バグ追跡システムのデータベースに登録される個々のアイテムを指すものとして、 問題 という用語を使います。 これによってユーザーが遭遇するソフトウェアの変な振る舞い（つまり、バグです）と、 バグの発見、診断、解決の 記録 を区別できるからです。 殆どの問題は実際に起こったバグに関するものですが、 他のタスクに関することでも問題という用語が使えるということを覚えておいてください。
問題の典型的なライフサイクルは次のようなものです。
誰かが問題をバグデータベースに記録します。 この記録には、問題の要点、問題の説明(もしあれば、 問題を再現させるための手順も。 ユーザーに優れたバグ報告をさせる方法については、 8章ボランティアの管理 の 「すべてのユーザーの協力を得るために」 を参照してください) 、バグ追跡システムが求めているその他の情報が全て含まれています。 問題を報告した人は、プロジェクトについて全く知らないかもしれません。— ユーザーのコミュニティーと開発者達から、同じくらいの割合でバグ報告や機能要望があがってきます。
いったん問題が報告されると、その問題は 保留中 の状態にあるといいます。 なぜなら、それに対して何らアクションがとられていないからです。 システムによっては、 未確認 とか 未着手 といったラベルを付与するものもあります。 まだ誰もこの問題を担当していません。システムによっては、 担当が決まっていないことを表すためにダミーの担当者を割り当てるものもあります。 この時点では、問題は一時的な領域に置かれています。つまり、 システムに記録されてはいるが、プロジェクトがまだ関心を持っていないということです。
誰か他の人が問題を読み、コメントを付けます。 おそらく問題を報告した人に、不明な点について説明を求めるでしょう。
問題はやがて 再現済み という状態になります。 これは問題のライフサイクルの中で最も重要かもしれません。これは、 まだ解決されたわけではないが、 報告した人以外の誰かが問題を再現でき、 この問題が本物だと証明したことをいいます。 そして同じくらい重要なことですが、 報告した人が本物のバグを報告することで、 プロジェクトに貢献したと確認することでもあります。
そして 診断済み という状態になります。 問題の原因が特定され、可能なら解決に必要な労力が見積もられます。 これらのことは必ず追跡システムに記録するようにしましょう。 原因を調べた人が突然しばらくプロジェクトを離れなければならない（これはボランティアの開発者にはよくあることです）場合に、 誰かが穴を埋められるようにしておくべきだからです。
この段階か、もうひとつ前の段階で、 開発者が問題を "自分が解決することにして"、 自分自身を 担当者にする するかもしれません。 (担当者を決める手続きをさらに詳細に調べるには 8章ボランティアの管理 の 、 「作業依頼と担当者の決定を明確に区別する」 を参照してください) この段階で、問題に優先度 も割り当てられるかもしれません。 たとえば、問題がとても深刻なので解決は次のリリースにまわすべき場合、 その事実は早い段階で確認する必要があります。 よって、追跡システムはそれを記録する何らかの方法を備えるべきということになります。
問題をいつ解決するかという予定が立てられます。 予定を決めるということは、 いつまでに直すという日程を決めることとは限りません。 将来のどのリリース（次のバージョンとは限りません）で直すかを決めるだけのこともありますし、 特定のリリースで直すと決めない場合もあります。 バグが素早く直せる場合には、予定を立てないこともあります。
問題が解決されます。（タスクが終了したり、 パッチが適用されたりとか、そういったものです） 行った変更は、問題の 処理が済んだ り、 解決済み とマークされたあとに、 コメントとして記録するようにしましょう。
問題のライフサイクルには共通のバリエーションがいくつかあります。 問題によっては、バグではなくユーザー側が誤解していたという理由ですぐに処理済みとされることがあります。 プロジェクトが多くのユーザーを獲得するにつれ、 バグではない問題が報告される回数も増えていき、 開発者は次第にぶっきらぼうな返事をして問題を処理済みとするようになります。 こういう風潮にならないよう努力しましょう。 ぶっきらぼうに問題を処理済みにしてもいいことは何もありません。 バグではない問題を報告したユーザ－は、以前報告された問題には何の責任もないのですから。 それに報告される問題が統計的にどういった傾向にあるかは、 開発者のみわかることで、ユーザーにはわからないことです。 (この章の後半の 「バグ追跡システムをあらかじめフィルタする」 で、 バグではない問題の数を減らすテクニックについて見ていきます) また、異なったユーザーが繰り返し同じような誤解をする場合は、 誤解を生む部分を再設計する必要があるということかもしれません。 この手のパターンはバグデータベースを監視する問題管理システムがあれば簡単に見つかります。 8章ボランティアの管理 の、 「バグマネージャー」 を参照してください。
別のバリエーションとして、 1. のすぐ後で問題が 重複している として処理済みにされる場合があります。 重複した問題は、プロジェクトが既に認識している問題を誰かがまた報告すると発生します。 重複した状態は 保留中 の問題で発生するとは限りません。 解決したあとで再び報告される(この状態を リグレッション（回帰） と呼びます)こともあります。 こういう場合は、重複の元となった問題を 再度保留中の状態にして、 重複した問題は処理済みにしてしまうのが普通は望ましいでしょう。 バグ追跡システムは、 問題を再現する情報ははじめに報告された問題で見られるように（逆も同様）、 問題同士の関連を追跡しているはずです。
開発者が問題を処理済みにする3つ目のバリエーションは、 問題を解決したと思い込んで処理済みにするパターンです。 これは結局、問題を報告した人がそれを拒んで再度保留中にする結果になります。 これは開発者が単にバグを再現するのに必要な環境にアクセスできないか、 問題を再現する手順に正確に従ってテストをしなかったために発生します。
これらのバリエーションのほかにも、 バグ追跡システムによって細かい部分が変わる場合はありますが、 基本的なパターンは同じです。 問題のライフサイクルそのものもオープンソースソフトウェアに特有のものではありませんが、 オープンソースプロジェクトのバグ追跡システムの使い方に影響を与えています。
1. が暗に示すとおり、 バグ追跡システムはメーリングリストやウェブページと同様プロジェクトの顔です。 誰でも問題を報告し、調べることができますし、現在保留中とされている問題の一覧を見ることができます。 よって、報告されている問題の進捗を何人の人が知りたがっているのかが、 開発者にはわからないということになります。 問題が解決される割合は開発者コミュニティーの規模やスキルに左右されますが、 プロジェクトは少なくとも問題が報告されたらすぐにそれを認識しようとすべきです。 たとえ問題が解決されずにしばらく残り続けても、 開発者が返答すると、問題を報告した人は引き続き参加したいと考えます。 なぜなら、自分がやったことが認められたと感じるからです。(問題を報告することは、 たとえば電子メールを送ること以上に労力がいることを思い出してください) それ以上に、問題をいったん開発者が見れば、 報告された問題の他の事例に注意を払ったり、他の開発者と話し合える、などの意味で、 プロジェクトが問題を認識したことになります。
適切なタイミングで問題に応答するには、次の二つが必要です。
バグ追跡システムをメーリングリストと接続しなければいけません。 これは、問題を報告することを含めた、問題の状態を変更するあらゆる行動が、 メールで投稿されるようにするためです。 このメーリングリストは通常使う開発用のものとは違うのが普通です。 なぜなら、開発者全員が自動送信されるバグ報告メールを受け取りたいとは限らないからです。 しかし、(コミットメールと同様に) Reply-to ヘッダは開発用のメーリングリストのアドレスに設定しておきましょう。
問題を報告するときの記入フォームは、 報告する人の電子メールアドレスの欄にフォーカスを当てておくべきです。 (しかし、匿名で報告したいと思う人もいるので、 電子メールアドレスを 必須 にすべきではありません。 匿名の重要性については、 この章の後半にある 「匿名性とプロジェクト参加」 を参照してください。
バグ追跡システムがディスカッションフォーラムにならないようにしましょう。 バグ追跡システムに人間が顔を出し続けることは大事ですが、 それがリアルタイムに議論するのに適しているわけではありません。 バグ追跡システムは、起こった事実や他の議論に対する参照、 メーリングリストで起きた議論をまとめるアーカイバと考えるようにしましょう。
こうした区別をするのはふたつの理由があります。 ひとつめは、バグ追跡システムがメーリングリストに比べて（ついでにいうと、リアルタイムに会話ができるチャットシステムと比べても）使いにくいからです。 これはバグ追跡システムのインターフェイス設計が悪いからではなく、 単にメーリングリストやチャットシステムが、連続していない状態、つまり自由に流れていく議論を取り込めるように設計されているからです。 ふたつめは、ある議論に参加している人が、 バグ追跡システムを見ているとは限らないからです。 よい問題管理のやり方(8章ボランティアの管理 の、 「技術的な作業だけでなく管理作業もみんなで」 を参照してください)は、 開発者全員に起こっている問題全部を追いかけさせるのではなく、 適切な人の注意をひくようにすることです。 6章コミュニケーション の 「バグ追跡システムでは議論しない」では、 適切なフォーラム以外に偶然議論が波及しないようにする方法や、 バグ追跡システムに議論を持ち込まないようにする方法を見ていきます。
バグ追跡システムによっては、メーリングリストをモニタし、 既知の問題に関する電子メールを全て自動的に記録するものがあります。 通常、こうしたシステムはメールの件名の行にある問題の番号を、 特別な文字列として認識することでこれを行います。 開発者達は、バグ追跡システムの注意を引くために、 電子メールにこうした文字列を含めることができるようになります。 バグ追跡システムに電子メール全体を記録させてもいいですし、 (よりよいのは)通常のメーリングリストのアーカイブにあるメールへのリンクを記録させてもよいでしょう。 どちらの方法でも、これはとても役に立つ機能です。 あなたが使っているバグ追跡システムにこの機能があるなら、 それを有効にして人々が利用するように知らせておきましょう。
ほとんどのバグ追跡システムは結局同じ課題に悩まされます。 バグを報告した経験が少なかったり、 肝心な部分を知らない善意のユーザーが、 既に報告されている問題やバグではない問題を大量に報告してくるのです。 この傾向に対処するはじめのステップとして、 バグ追跡システムのトップページに目立つように注意書きを置いておく方法があります。 そこで本当にバグかどうかを区別する方法や、 既に報告されている問題かどうかを検索する方法、 そして最後に、本当に新規のバグであった場合に効果的に報告する方法を説明しておくのです。
こうすることでしばらくは報告されてくる問題のノイズは下げられますが、 ユーザーが増えてくるにつれてこの課題は結局再燃します。 このことでユーザーを責めることはできません。 ひとりひとりのユーザーはただプロジェクトをよくするために貢献しようとしているだけですし、 たとえ彼らのバグ報告がはじめは役に立たなかったとしても、 あなたは彼らにひき続きプロジェクトに参加してもらって、 将来はよりよいバグ報告をして欲しいと思うでしょう。 しばらくの間は、バグ追跡システムに自由にバグを報告させ続ける必要があります。
この課題を避けるために何より実行すべきことがふたつあります。 バグではない問題や、 重複したバグ報告を報告されたらすぐに 処理済みとマークできる十分な知識がある人にバグ報告システムを見張ってもらうこと。 そしてバグ報告システムにバグを報告する前に、 他の人とバグかどうかを確認するようユーザーに求める（または強く勧める）ことです。
はじめのテクニックはあらゆるところで使われているようです。 巨大なバグデータベースを持つ（たとえば http://bugs.debian.org/ にある Debian のバグ追跡システムは、執筆時点で 315,929個 のバグ情報があります）プロジェクトでも、バグが報告されるたびに 誰かが 見張るようにシステムを改造しています。 問題のカテゴリによって見張る人は違うかもしれません。 たとえばDebianプロジェクトはソフトウェアパッケージの集合体なので、 自動的にそれぞれの問題を適切なパッケージメンテナーに転送しています。 もちろん、ユーザーがときどき問題のカテゴリを誤解することもありえます。 そういう場合は、そのバグははじめは間違った人に転送されるので、 転送された人が再度転送し直さなければなりません。 しかし重要なのは、その負担が共有されているということです — ユーザーがバグを報告するときに正しいか間違っているかを推測しようがすまいが、 報告されたバグを見張る役目は多かれ少なかれ開発者に分散されています。 よって問題が報告されるたびに、適切なタイミングで応答できるのです。
ふたつめのテクニックは広く使われているわけではありませんが、 これはおそらく自動化が難しいからでしょう。 アイディアの要点は、新しく報告されてくる問題をデータベースに登録する前に、 "仲間を" 巻き込むことです。 ユーザーが問題を見つけたと思ったときは、 メーリングリストかIRCで説明するように求めます。 そうすることで、誰かが本当にバグかどうかを確認するのです。 別の人の目に早めに晒すことで、たくさんの間違った報告を避けることができます。 別の人がその振る舞いはバグではないとわかったり、 最近のリリースで解決済みだとわかる場合があります。 または、別の人が以前報告された問題から報告されるバグの兆候に精通しているので、 古い問題であるとユーザーに指摘することで重複した報告を防ぐことができる場合もあります。 "既に報告された問題かどうかをバグ追跡システムで検索したかい?" とユーザーに聞くだけで十分なこともあります。 多くの人はそんなことを考えてもいませんが、 誰かがそうすることを 期待している とわかれば、 喜んで検索するものです。
仲間を巻き込む仕組みはバグデータベースをきれいにしてくれますが、 欠点もいくつかあります。 多くの人が、新しくバグを報告するときに仲間を見つけなさいという指示を見ないか、 軽視するかして、結局ひとりでバグ報告をしてしまうことです。 よって、ボランティアにはやはりバグデータベースを見張ってもらう必要があります。 さらに、ほとんどの新しい報告者はバグデータベースを維持するのがどれだけ難しいかを知らないので、 ガイドラインを無視しているからといって厳しく注意するのはフェアではありません。 よってボランティアは、 誰にも見てもらっていないバグ報告を報告者にどう差し戻すのかについては、 用心深く、なおかつ慎重でなければなりません。 これは、問題をフィルタする仕組みを理解する人々を増やせるように、 ゆくゆくは仲間を巻き込んでバグ報告をしてもらうことが目的です。 誰にも見てもらっていないバグ報告を見つけたら、 とるべき理想的な対処のステップは次のようなものです。
すぐにバグ報告に応答し、 ユーザーがバグ報告をしてくれたことに丁寧にお礼を言います。 しかし、バグかどうかを誰かに見てもらうガイドラインがあることを指摘します。（これはもちろん、ウェブサイトに目立つように投稿すべきです）
報告された問題が明らかに正しいもので重複していない場合は、 とりあえずそれを受け入れて通常のライフサイクルを開始します。 結局、報告した人はバグかどうかを誰かに見てもらうべきだと言われているので、 正しいバグ報告を処理済みにするまで労力を無駄にする点はありません。
そうでない場合、つまり報告された明らかに正しくない場合は処理済みとマークしましょう。 しかし、報告した人には誰かにバグであるかを確認した上で報告したのなら、再度保留中にして欲しいと伝えます。 この場合、報告した人は確認をとったスレッドへの参照（e.g. メーリングリストアーカイブへのURLなど）を掲載するはずです。
この方法はいずれバグ追跡システムの S/N比を改善してくれるでしょう。 しかし、間違ったバグ報告は決してなくならないことを覚えておいてください。 間違ったバグ報告を根絶する唯一の方法は、 開発者以外の人にはバグ追跡システムを使わせないことです — しかし、この方法でよい結果が出ることはほとんどありません。 間違ったバグ報告を取り除くことがプロジェクトのルーチンワークであることを受け入れ、 できるだけ多くの人達の助けを得ようとした方がよいでしょう。
8章ボランティアの管理 の 「バグマネージャー」 も参照してください。