バグ管理の現状

システム開発を行う場合には、他の記事に記載されているような、さまざまなテストを実施して、システムが期待された機能通りに動作しているか確認する必要があります。

残念ながら、予定されたすべてのテストで、システムが常に期待通りに動作していることは稀ではないでしょうか。多くの場合、期待値とは異なる出力をシステムが返すことがあるかと思います。このような現象を一般的にはバグとか不具合、あるいは欠陥と呼んで、それぞれの事象を何らかの形で管理しているのではないでしょうか？

本記事では、一般的に用いられることが多いバグという用語で統一して扱いますが、JSTQBでは、フォールト（バグ、欠陥）、故障、インシデント（不具合、障害）は、それぞれ定義がされており、別々の意味を持っています。詳細については、「JSTQB Foundation」に記載されていますので、そちらをご参照ください。

ここでNPO法人ソフトウエアテスト振興協会のツールワーキンググループにて、配布されている以下の資料から図表を抜粋してみます。

「テストツールまるわかりガイド（入門編）」

（http://aster.or.jp/business/testtool_wg/pdf/Testtool_beginningGuide_Version1.0.0.pdf)

このグラフは、JaSST’12 Tokyo 「テストツールの処方箋」セッションにて会場で行ったアンケート結果をもとに作成されています。

この図を見てもわかるように、バグの管理（図では、インシデント管理）については、他のテスト関連ツールに比べて、みなさんが高い意識を持たれて、実際の開発で管理を行っていることがよくわかります。

では、みなさんのプロジェクトでバグの管理はどういう形式で行っているのでしょうか。おそらく、次にあげるいずれかの例で管理されていると思われます。

1. １枚のバグ管理票（紙ベース、電子ファイルベース）に起票したうえで、台帳をつけている。
2. エクセルなどの表計算ソフトを使って、１バグ１行の形で一覧できる形に管理している。
3. 何らかのバグ管理ツール（商用、無償、自作を問わず）を使って管理している。

最近では紙ベースで管理することは少なくなりました。とは言え、開発標準が全社的に定義されているような比較的に歴史のある会社では、電子ファイルベースで管理するケースがまだ多く見られるのではないでしょうか。

そして、多くの方が２番のエクセルといった表計算ソフトを利用して管理しているのではないでしょうか。あるいは、３番のように専用のツールを導入しているかもしれません。

では、バグの管理は、上記のような方法を使ってデータベース化し、記録することで終わりとしてよいのでしょうか。通常、発見されたバグは解決が確認されるまでの間、何らかの形で状況の変化とともにデータを更新しているはずです。そこで次に、このバグを管理することについて考えてみましょう。

BTSとは？

現在、バグを管理するためのツールは、有償、無償など多数存在しています。それぞれツールを表わす用語も多数ありますが、本記事では、それらをBTS（Bug Tracking System）として扱います。（たとえば、Issue Tracking Systemと呼ぶ場合もあります。また、Ticket駆動開発で使うシステムなども、ある種のＢＴＳとして使うことができます。）

エクセルなどを使った場合、バグ情報を登録するだけでなく、バグの対応状況の変化に応じてステータスの変更を行っているかと思います。したがって、広義の意味では、これらエクセルで作られた表もBTSであることには間違いありません。

しかし、確かにバグを管理する側面ではエクセルなどであっても必要条件を満たしているかもしれませんが、それで本当にBTSと呼ばれるツールの条件を十分に満たしていると言えるでしょうか。

エクセルなどの単一のファイルで管理されている場合、誰か一人がファイルを開いていると、他の人が編集できず更新作業が止まってしまうことがあります。あるいは、一欠陥、一行のような管理の場合、スクリーンショットやログファイルが添付できない場合もあります。（専用にフォルダを作って入れる場合が大半だと思いますが）

一般的にBTSと言われるツールでは、エクセルで作った単純な表とは違いさまざまなバグに関する情報を持っているだけではなく、これらの添付ファイルを管理する標準機能が付いています。それだけではなく、ワークフローや通知機能、構成管理ツールやテスト管理ツールとのインターフェースなどの機能も持っています。もちろん、ツールによって保有する機能やその実装レベルには違いがあります。しかし、ワークフロー機能と通知機能を有することがBTSの十分条件の一つだと定義付けられています。

一般的な開発組織の場合、発見されたバグは、解決されるまでいくつかの状態を持つことになります。組織によって、それらの管理レベルは異なると思いますが、極端に単純化して分けると以下の状態が存在に分けられます。

1. 発見された状態のバグ
2. 対応中のバグ
3. テスト中のバグ
4. 解決したバグ

これは、本当に極端に単純化した管理レベルの例であり、通常のBTSを使用した場合には、標準状態でも、もっと多くの状態と、それを実現するワークフローを持っています。

バグの管理をどの程度細かく行い、ワークフロー化するかは、導入を考えている組織や開発プロジェクトの規模や成熟度、開発するシステムの状況などによって変化するものと考えられます。

必要以上に細かく管理すると、余分な管理コストが増えるのでおすすめ出来かねますが、さすがに上記の４レベルだけだと雑すぎることは理解していただけると思います。

開発組織として、バグを管理するのに必要なワークフローを実現しバグの管理の負担を軽減して、かつ現状把握が容易な状態（見える化）に持っていくのがBTSの役割です。これは、単なるエクセルを使った表だけでは困難な機能です。

BTSの導入にあたって

繰り返しになりますが、BTSを導入する際には、自分たちの開発プロセスにおけるバグの管理レベルにカスタマイズで対応できるBTSを選定する必要があります。これは、どのようなツールを導入する場合でもいえる普遍的なことです。また、過度のカスタマイズは、ツールのバージョンアップ時に弊害となる可能性が出てきますので、そのあたりの加減も考慮する必要があります。

現在、一般に使われているBTSのほとんどが簡単な設定で、一般的な組織で必要とするようなバグ管理のワークフローには対応できています。どのBTSを選んでも標準状態で、上記の４ステップ以上のワークフローを実装していますし、もしかすると、自分達の組織では不釣り合いなくらい重厚なワークフローが標準テンプレートになっている場合もあります。

また、最近のBTSであれば、適切なサーバーに標準設定でインストールするのは、ほとんどワンクリックで行える簡単な作業になってきています。そして、そのまま標準的な設定で利用するのであれば、利用ユーザの登録や、必須項目、選択項目についての設定を行うだけで、すぐにも使い始めることができます。

しかし、たとえ標準設定であっても、自分たちの組織の中でBTSを正しく運用していくには、なぜそのワークフローがあるかについてちゃんと説明したルールが必要です。このルールを組織に属する各自が理解していないと、だんだん使われなくなったり、いびつなローカルルールができたり、別途エクセルで管理する二重帳簿的な状況も発生しかねません。

では、どのようにBTSを導入すればよいのでしょうか？

最近では、書籍で解説されているような著名なBTSも多数存在します。しかし、本を読んで理解した気になっても、実際に他の人に説明して組織に導入し定着させるのは大変な作業になります。

一番良いのは、すでにBTSを開発プロセスの中で使っている知り合い方に話を伺うことでしょう。できれば、異なるBTSを使われている別々の方からの話が良いでしょう。とくに、導入時のトラブルとか、運用して行く上での問題点や注意点などのネガティブな部分を聞ける人が一番良いと思います。書籍ではそういったネガティブな部分が省略されている場合があるからです。その話の中に、自分たちの組織に導入する知見とツール選定のためのヒントが隠されていると思います。その知見をもとに、実際にいくつかのツールを触ってみて、自分たちの組織へ適応した時のワークフローを検討してみるといいでしょう。ツールにも得手、不得手が存在しますし、何らかの割り切りが必要なケースもあります。それを事前に確認することが何より大事です。

それでは、BTSを導入し運用する上で考えなければならないポイントをいくつかあげてみましょう。当然と言えば当然ですが、ワークフローを持つシステムを導入する上で、考慮するべき点は、やはりBTS導入でも考慮する必要があります。

1. バグの入力ができるだけ負担にならないこと。
2. テスターが考える重要度と、プロジェクトとして求める優先度は異なることがある。
3. バグを対処するエンジニアへの割り振りの方法を自分たちの組織に最適化する。
4. 特定の人がボトルネックにならないようにする、あるいは、ボトルネックが発生した場合には、それが認識できるようにする。
5. 現在、誰がボールを持っているかが明確になるようにする。
6. バグのクローズを承認できるのは誰かを明確にする。
7. マネージメント層が、現状を簡単に把握できるようにする。

BTS特有という意味では、発生したバグの重要度、優先度の判断と、対応者への割り振りが重要になります。

もちろん、バグの発生件数に対して、解析担当者の能力が十分あれば、多くのバグが未解決で残ることはないかと思いますが、そんな幸運なプロジェクトを経験するのはごく稀なことです。一般的には、解析能力を上回るバグが発生して、発散しそうになるバグを抑えるために四苦八苦しているのが現状だと思います。また、特定の解析者に負荷が集中するケースもあります。これらの見える化によって、的確に把握し、最適化を行っていくことが必要であり、それを実現するためのツールがBTSになります。

ここで問題となるのが、バグの重要度や優先度の判断です。ツールによっては、これらを細かく定義されている場合もありますが、細かく定義すればするほど判断する手間が増えますし、判断基準が難しくなります。たとえば、５段階に重要度が分かれていた場合に、５番目と４番目の重要度の違いは何で区別するのがよいのでしょうか。

それらを踏まえて、最近では、医療の現場で使われる「トリアージ」の考えを導入することによって、単なる重要度判断ではなく、優先度を明確にするケースも出てきています。（この考え方はバグの管理だけに限った事ではありませんが。）

「トリアージ（Triage）は、人材・資源の制約の著しい災害医療において、最善の救命効果を得るために、多数の傷病者を重症度と緊急性によって分別し、治療の優先度を決定すること。特記すべきとして、優先度決定であって、重症度・緊急度決定ではない。」（Wikipediaからの引用）

さらに重要なのは、導入したルールを組織として守っていくことです。ルールを守るというのは、ルールを変えないという意味ではありません。状況の変化によってルールを変える必要は出てくると思いますが、「なぜそのルールが必要か？」を最初に明確にしておくことで、状況の変化によって前提条件が変わった場合に、ルールを変えやすくなります。

一つの事例ですが、あるデスマーチになりかけていた（なっていた？）プロジェクトの立て直しのお手伝いをしたことがあります。その時には、本当にいろいろなことを改善しました。その一つにBTSの導入がありました。混乱して管理不全に陥っていた現場にBTSを導入し、バグ管理のための本当にシンプルなワークフローを定義し、それらをプロジェクトメンバーに落とし込んだのです。そして、人材育成の意味も含めて、若いエンジニアを張り付けて、バグの可視化とルールからの逸脱の監視を行わせました。それと同時に定義したワークフローと運用ルールについては、別途品質保証部門の方に正式にレビューしていただき、了解を得ることも行いました。

ここでポイントの一つは、あえて人材育成も兼ねて若いエンジニアに逸脱の監視を行わせたことです。経験のあるエンジニアより、学校を出てすぐの若いエンジニアのほうが指示されたルールを厳格に守ることに集中します。もちろん、逸脱の検出はできても、それを先輩方に注意するということは難しいので、その部分については、私が担当してプロジェクト管理の立場から指摘をし、改善させていただきました。このチェック機構によって、組織としてルールを守る風土ができてきました。

後日、品質保証部門の方から、このプロジェクトの後継プロジェクトでは、ルールが根付いており、バグが常に見える状態で管理されているので安心してみていられるとお言葉をいただいたことが記憶に残っています。

最後に、BTSの導入運用で重要なのは、検出されたバグの一件一件を確実にワークフローに乗せて解決まで管理することを組織的に行い定着させることです。ツール標準のテンプレートのワークフローを無理やり自分たちの組織に導入する必要はありませんが、テンプレートには、そのツールにおけるある種の理想のワークフローが定義付けられています。自分たちの組織に当てはめてみて、合わないところだけを修正することで、十分実用に耐えるワークフローができると思います。

そして、忘れてはならないのは、BTSを導入するだけで劇的にバグが減り、システムの品質が向上するわけではありません。あくまでもBTSは、バグの管理の支援を行ってくれるだけです。組織の中に定着させて上手に使いこなすためには、ルール作りやTipsの共有が必要なのは他のツールと違いはありません。

参考資料

日本で著名BTSとして使えるオープンソースツールの例（アルファベット順）

• Bugzilla(http://www.bugzilla.org/)
• Mantis(http://www.mantisbt.org/)
• Redmine(http://redmine.jp/)
• Trac(http://trac.edgewall.org/)