GNATS、BugzillaそしてRedmine

IT開発の現場ではバグ対応が避けられません。受け付けたバグ報告や、対応しているバグや完了した件などを個人的なメモに留めていると、小規模な開発では何とかなっても、関係者が増えてきた場合に対応できなくなります。また個人で対応できていたとしても、何らかの事情で担当できない状況に追い込まれた場合、それを他の人が引き継ぐのは至難の業です。

そこで「Bug Tracking System (BTS)」というものが生まれました。これが「バグ（不具合、障害、問題点）」だけを対象とするのではなく、さらに進化し、開発の中で生じてくる様々なアイディアを含めて運用できるようにするため「Issue Tracking System (ITS)」と呼ばれたりもします。

OSSで提供されているBTSもありますし、商用製品もあります。OSSと製品のいずれが優れているのかは直ちには判断できません。OSSは信用できず商用製品でなければ責任の所在が曖昧になると考えている人もいるでしょうし、製品に比べればOSSの方が利用者が多いから仮に問題があったとしても修正が迅速であるはずだと主張する人もいます。一般論としてはどちらもその通りですが、具体的に個別のBTSについて見ていくと、それぞれの事情があるとして言えないでしょう。

いろいろな主張があるとしても、試しに利用してみるためにはOSSの方が手っ取り早いのは確かです。いろいろありすぎて選択に迷いますが、著名なのは古くからある「GNATS」とか、最近では「Bugzilla」や「Redmine」です。

GNATSはGNUの開発したBTSで、FreeBSDやNetBSDなどがバグ報告を受け付けるために利用されています。バグを報告は「Problem Report」と呼ばれ、一つの報告に対してPR番号が付けられます。その問題の管理はPR番号で行われることになります。

BugzillaはFirefoxでお馴染みのMozilla Fundationが開発し、Redhatなどが利用しているようです。

Redmineは市販の参考書が多く出版されており、利用者コミュニティが活発であることが窺えます。GNATSではPRで管理していたようなことを、Redmineでは「チケット」と呼んでいるようです。

BTSの範疇に含まれるものは数多く、どれを利用すれば良いのか迷ってしまいます。注意しておきたいことは、各々はBTSには違いないとしても、その具体的な実現方法は様々であるので、出来ること出来ないことは個々に異なるということです。何かを選べば、他を選んだなら出来たであろうことが、出来なくなる可能性は高いと思います。妙な例えになりますが、MS-DOS上でC言語を利用しようとして、Lattice-Cを選ぶか、MS-Cにするか、それともTurbo-Cにするかという判断とは違うのです。

いずれのBTSであれITSであれ、ひとつの問題や要望に対する一連の情報を整合性を保って管理するという趣旨は同じですが、そのための実現方法は大きく違います。 その用語も個々に違います。もちろん同じような用語が多いのですが、全く同じである保証はないし、用語の意味を膨らませていたりすることもあります。

このような状況では、自分の要求に即したBTSやITSを選択するには、全てを使ってみるしかありません。インストールマニアでもなければ、そんなことをしている余裕は普通は無いでしょう。機能の詳細に踏み込まずとも、大雑把に比較して対象を数個に絞り込むことは可能だと思います。しかし使ってみないと分からないことも多いので、結局は何かを選択して利用してみることになるでしょう。

選択するためのひとつの考え方は「有名なものを選ぶ」ということです。市販されている書籍が多いとか、Webなどで情報が見つかりやすいとか、または身近で利用されているというような事です。そのような理由で選ばれたものは、機能的に最高レベルではないかもしれません。「有名なものを選ぶ」という判断基準は、「最高レベルを選ぶ」という基準とは両立しないのです。これまた変な例えですが、CP/MやMS-DOSが広く使われていた時代に、OS-9の方が技術的に優れているという主張がありました。これは確かにその通りだと思いますが、OS-9が広く利用されるようにはなりませんでした。

何を選んだとしても、実際に使い始めてみると、期待していたようなことができない可能性があります。その期待が、無いものねだりなのかもしれませんし、もしかすると何かのバグかもしれません。そこで選択しなかった方を調べてみたら、そちらでは出来ることが分かったとしましょう。そこでツールを乗り換えるのも方法のひとつではあります。ですが乗り換えたところで、次にまた別の壁にぶつかったら、また乗り換えるつもりでしょうか。その調子で乗り換えていたら、何時になったら本来の目的である「バグ管理（または要望管理）」ができるようになるのでしょう。

これは、一度決めたら決して乗り換えてはいけないという主張をしているのではありません。そうかといって、気軽に乗り換えることを勧めている訳ではありません。ツールの選択に限らず、「選択」と「決断」は難しい判断です。いずれにしても、何をするにも「自覚的であれ」というのは真理かもしれません。