バグ追跡システムのライフサイクルを再考する：オープンソースソフトウェアの育て方（1/3 ページ）

バグ追跡システムは、はじまりと終わりの状態があるすべてのもの、存在している間に情報が発生するすべてのものを追跡するためによく使われます。本稿では、バグの追跡にかんするライフサイクル、そして、それをつかさどるソフトウェアのさまざまな側面を考えます。

[Karl Fogel， ]

バグ追跡システム

　バグ追跡が扱う範囲は多岐にわたります。この連載ではバグ追跡のさまざまな側面を議論しています。ここではバグ追跡システムをセットアップすることと、その作業にかんする技術的な考察に集中します。その話題に入る前に、バグ追跡の方針にかんする質問から始めましょう。具体的にどの情報をバグ追跡システムに保存すべきなのでしょうか？

　バグ追跡システムは、誤解を招きやすい用語です。バグ追跡システムは、新しい機能要望や、一度限りのタスク、送られてきたパッチ――はじまりと終わりの状態があるすべてのもの、存在している間に情報が発生するすべてのものを追跡するためによく使われます。このため、バグ追跡システムは、問題追跡システム、不具合追跡システム、影響追跡システム、要望追跡システム、チケットシステムなどとも呼ばれています。バグ追跡システムのソフトウェアの一覧は、付録B.フリーなバグ追跡システムを参照してください。

　本稿では“バグ追跡システム”という用語を、バグを追跡するソフトウェアを指すものとします。なぜなら、ほとんどの人がバグ追跡システムと呼んでいるからです。しかし、バグ追跡システムのデータベースに登録される個々のアイテムを指すものとして、問題という用語を使います。これによってユーザーが遭遇するソフトウェアの変な振る舞い（つまりバグです）と、バグの発見、診断、解決の記録を区別できるからです。ほとんどの問題は実際に起こったバグにかんするものですが、ほかのタスクにかんすることでも問題という用語が使えることを覚えておいてください。

　問題の典型的なライフサイクルは次のようなものです。

1. 誰かが問題をバグデータベースに記録します。この記録には、問題の要点、問題の説明（もしあれば、問題を再現させるための手順も。ユーザーに優れたバグ報告をさせる方法については、章8.ボランティアの管理のすべてのユーザーの協力を得るために項を参照してください）。バグ追跡システムが求めているそのほかの情報がすべて含まれています。問題を報告した人は、プロジェクトについてまったく知らないかもしれません――ユーザーのコミュニティーと開発者たちから、同じくらいの割合でバグ報告や機能要望があがってきます。

　いったん問題が報告されると、その問題は保留中の状態にあるといいます。なぜなら、それに対して何らアクションが取られていないからです。システムによっては、未確認とか未着手といったラベルを付与するものもあります。まだ誰もこの問題を担当していません。システムによっては、担当が決まっていないことを表すためにダミーの担当者を割り当てるものもあります。この時点では、問題は一時的な領域に置かれています。つまり、システムに記録されてはいるが、プロジェクトがまだ関心を持っていないということです。

2. 誰かほかの人が問題を読み、コメントをつけます。おそらく問題を報告した人に、不明な点について説明を求めるでしょう。

3. 問題はやがて再現済みという状態になります。これは問題のライフサイクルの中で最も重要かもしれません。これは、まだ解決されたわけではないが、報告した人以外の誰かが問題を再現でき、この問題が本物だと証明したことを指します。そして同じくらい重要なことですが、報告した人が本物のバグを報告することで、プロジェクトに貢献したと確認することでもあります。

4. そして診断済みという状態になります。問題の原因が特定され、可能なら解決に必要な労力が見積もられます。これらのことは必ず追跡システムに記録しましょう。原因を調べた人が突然しばらくプロジェクトを離れなければならない（これはボランティアの開発者にはよくあることです）場合に、誰かが穴を埋められるようにしておくべきだからです。

　この段階か、もう1つ前の段階で、開発者が問題を“自分が解決することにして”、自分自身を担当者にするするかもしれません。（担当者を決める手続きをさらに詳細に調べるには章8.ボランティアの管理の作業依頼と担当者の決定を明確に区別する項を参照してください）この段階で、問題に優先度も割り当てられるかもしれません。例えば、問題がとても深刻なので解決は次のリリースに回すべき場合、その事実は早い段階で確認する必要があります。よって、追跡システムはそれを記録する何らかの方法を備えるべきということになります。

5. 問題をいつ解決するかという予定が立てられます。予定を決めるということは、いつまでに直すという日程を決めることとは限りません。将来のどのリリース（次のバージョンとは限りません）で直すかを決めるだけのこともありますし、特定のリリースで直すと決めない場合もあります。バグが素早く直せる場合には、予定を立てないこともあります。

6. 問題が解決されます（タスクが終了したり、パッチが適用されたりとか、そういったものです）。行った変更は、問題の処理が済んだり、解決済みとマークされた後に、コメントとして記録するようにしましょう。

　問題のライフサイクルには共通のバリエーションが幾つかあります。問題によっては、バグではなくユーザー側が誤解していたという理由ですぐに処理済みとされることがあります。プロジェクトが多くのユーザーを獲得するにつれ、バグではない問題が報告される回数も増えていき、開発者は次第にぶっきらぼうな返事をして問題を処理済みとするようになります。こういう風潮にならないよう努力しましょう。ぶっきらぼうに問題を処理済みにしてもいいことは何もありません。バグではない問題を報告したユーザーは、以前報告された問題には何の責任もないのですから。それに報告される問題が統計的にどういった傾向にあるかは、開発者のみ分かることで、ユーザーには分からないことです（後半のバグ追跡システムをあらかじめフィルタする項で、バグではない問題の数を減らすテクニックについて見ていきます）。

　また、異なったユーザーが繰り返し同じような誤解をする場合は、誤解を生む部分を再設計する必要があるのかもしれません。この手のパターンはバグデータベースを監視する問題管理システムがあれば簡単に見つかります。章8.ボランティアの管理の、バグマネージャ項を参照してください。