バグトラッキングシステム（BTS）とは

バグトラッキングシステム（BTS）とは

多い少ないといった違いはあれども、どのようなソフトウェアにも、必ずバグは潜んでいます。そして、どれだけ入念にテストを行ったとしても、リリースされるプログラムから潜在的なバグを完全に取り除くことは困難です。そのため、バグに対しては「発見できたバグについては修正を行うが、それ以外は見つけ次第対処する」という、対処療法的なアプローチを取らざるを得ないのが現実です。

ユーザーへの影響を考慮すると、発見されたバグは、可能な限り速やかに修正することが望ましいと言えます。しかし、単に速く作業をすればそれでよいというものではありません。バグをきちんと管理せず、目についたバグを場当たり的に修正していると、せっかくの修正がリリースから漏れてしまったり、そもそも修正作業に担当者がアサインされないまま、バグが宙に浮いてしまうような事態にもなりかねません。

そのため、発見されたバグは、きちんと管理・追跡することが大切です。この「発見されたバグを登録し、修正をリリースするまでの作業状況を追跡するツール」をバグトラッキングシステム（BTS：Bug Tracking System）と呼びます。

オンプレミスにおける可用性

何らかのリストを記録・管理するには、Excelのようなスプレッドシートを利用するケースが多いのではないでしょうか。バグに関しても、バグトラッキングシステムの登場以前は、Excelなどを利用してバグの管理をすることがよくありました。現在でも、Excelを利用して管理をしているという方もいらっしゃるのではないかと思います。

Excelは普段から使い慣れている人も多く、リストをシンプルに管理できるため、導入しやすいツールであることは事実です。しかし、Excelは汎用的な表に過ぎないため、バグの現在の状態ややり取りの経緯など、必ずしもバグに関連する情報をすべて記録できるとは限りません。場合によっては、別のツールを併用して補足情報を管理するなど、余計な手間がかかる可能性も十分考えられます。また、Excelはあくまで個人のPC上で動作し、ファイル単位でデータを管理するアプリケーションです。そのため、作業者がそれぞれ別のバージョンのコピーを持ってしまい、古いファイルで新しいファイルを上書きしてしまったり、変更が衝突したりといったトラブルが起きやすい問題もあります。

バグの管理をExcelで行うというのは、例えるならソースコードの管理にバージョン管理システムを使わず、日付ごとにフォルダをコピーして、変更を管理したつもりになっているようなものです。そう考えると、Excelによるバグ管理がどれだけ不完全で、かつ簡単に破綻してしまうかが理解できるのではないでしょうか。

BTSとExcelの特徴の違いを簡単にまとめると、以下の表のようになります。

バグ修正のステップ

組織や開発体制ごとに多少の違いはありますが、バグの発見から修正までは、概ね以下のようなステップを踏んで行われます。これらの状態と作業内容を、常に最新の状態を保ち、かつ整合性のある状態でExcelに記録するのは、相当困難な作業であるのが解るのではないでしょうか。

しかし、BTSを利用すれば、起票されたバグ情報を複数人で共有したり、現在の修正の状況を確認したり、過去のバグ情報を参照したりといったことが、容易に可能になるのです。

起票

バグ修正は、開発者によるテストやユーザーからの報告などによって、バグが発見される所から始まります。

発見されたバグは、バグの内容、発生した環境の情報、再現条件といった情報とともにBTSに登録されます。これを「バグを起票する」や「バグをオープンする」などとも呼びます。起票されたばかりのバグには、「新規」という状態が設定されます。

バグの確認

開発者によって、起票されたバグが本当にバグであるのかの確認が行われます。ユーザーからはバグのように見えたものが、実はバグではなかったというケースもよくあります。例えば、プログラム自体の不具合ではなく、動作する環境に起因する問題やそもそも発見者の勘違いであったといったケースです。

本当にバグであることが確認できたなら、バグの状態が「確認済み」に設定され、次のステップに進みます。もし、バグでないと判断された場合は、状態が「無効なバグ」に設定され、修正作業はキャンセルされます。

バグのトリアージ

バグの存在が確認されたからといって、必ずしもすぐに修正が行われるとは限りません。実際に修正作業に着手する前にどのくらいの優先度で行うのか、そもそもそのバグは本当に修正する必要があるのかといった判断が行われます。

セキュリティに関するバグであれば、ほかのバグに割り込む形で、優先的に修正するといった判断が行われることもあるでしょう。軽微なバグであれば、修正はするものの優先度は低く設定され、次のバージョンのリリースまでに修正できていればよいということもあります。さらに、ほとんどのユーザーに影響しないような軽微なバグの場合は、リリース作業による副作用の方が大きいと判断し、修正しないという結論に至ることも珍しくありません。

こうした優先度付けを「バグのトリアージ」と呼びます。トリアージが済んだバグには「緊急」「高」「中」「低」といった優先度が設定されます。

バグの修正

トリアージされた優先度やリリーススケジュールに従って、実際にコードの修正作業とテストが行われます。バグの状態は「作業中」となります。

修正のリリース

バグが修正されたコードを、実際にリリースします。

リリースをもって、BTS上のバグの状態が「完了」や「リリース済み」に変更され、修正作業は完了となります。このように、起票された1つのバグ修正が完了することを「バグのクローズ」とも呼びます。

代表的なバグトラッキングシステム

BTSにもさまざまな実装が存在します。BTSはその名の通り、バグを追跡するのが目的のシステムですが、本当にバグの追跡だけを目的としたシステムはむしろ稀だと言えるでしょう。多くのBTSは、チケット管理システム、タスク管理システム、Wikiなどのドキュメント管理システムなどの機能を統合的に提供しています。

有名なオープンソースのBTSとしては、「Bugzilla」「Redmine」「Trac」などが存在します。また、バグの修正はコードの修正と概ねイコールのため、ソースコードホスティングシステムの一環として、BTSの機能が提供されていることも一般的です。例えば、GitHubにはIssueと呼ばれる機能があり、GitHub上で行うバグ修正やタスクを管理できるようになっています。

DevOps実現に重要なバグトラッキングシステム

現在のITシステムは、激しく変化する市場の要求に対して、迅速に対応することが求められています。こうした高速な開発サイクルを実現するために注目されている開発手法がDevOps（デブオプス）です。

DevOpsとは、開発（Development）と運用（Operations）を組み合わせた造語です。簡単に言えば、「開発担当と運用担当が緊密に連携して、柔軟かつスピーディーにシステム開発を行う手法」のことを指します。そして、BTSはDevOpsのライフサイクルを円滑に回すための重要なツールの1つと位置づけられています。

その理由としては、DevOpsでは高速な開発を実現する一環として、CIによるテストの自動化を行うのが一般的となっています。CIではコードに変更が加えられると、都度自動的にテストが行われます。これにより、追加した新機能にバグがあった場合や既存のコードに悪影響があったような場合にすぐ気が付くことができるわけです。

ですが、バグはきちんと修正をリリースしてはじめて解決するものです。どれだけ早期に発見できても発見しただけで放置しているのであれば意味がありません。特に大規模で複雑なシステムでは、バグの数も種類も非常に多くなる傾向にあります。こうしたバグのすべてを人力で管理するのは現実的に不可能でしょう。そのためにも、発見したバグをきちんと追跡し、修正のリリースまでを管理するBTSは、現代的な開発において必要不可欠と言えます。

なお、DevOpsの詳細につきましては、「DevOpsとは？概要やアジャイル開発との違い、メリットなどを解説します」の記事やニフクラ/FJcloud-Vが提供するeBook「これから始める DevOps導入ガイド」をご覧ください。