あなたのチームはバグ管理をどのようなルールの下、運用しているのでしょうか。それは正しく運用されておりソフトウェアの品質(信頼性向上)に役立っていると思いますか。

障害対応やバグ対応とは「バグが発生したら、開発者が修正、その後にテスターがテストする」を繰り返すだけの作業であり、大規模な専用ツールを導入して管理するほどでも無いと考えてる人がいるかもしれません。また、表計算ソフトで管理しており、一覧性と使い慣れた操作性がベストと思っている人もいると思います。

バグ管理はワークフローと管理すべきことを理解している担当者がチームにいれば、高度なツールを使う必要はありません。表計算ソフトやメモ帳でも十分管理することが出来ます。

どのようなツールをつかって管理するにしても万能な解決方法は無く、ルール化・教育がとても重要だと考えています。

サイクロンというプロジェクト管理・課題管理システム開発会社という立ち位置からBTS(バグ管理システム)またはバグを管理するために重要なことを考えてみます。

バグ管理で重要なこと

重要なことは2点あります。 1つ目は、「バグの発生日」「発見者」「事象」「再現方法」「対応者」「対応内容」「テスト結果」があとで追跡可能な状態であること。2つめは「バグ対応に伴う、ソースコードの変更、改修内容、改修理由」がログに残っていること。 です。

1つ目はどこのプロジェクトでも管理している内容で当たり前と思われる項目ばかりです。これらの情報はバグの発見者が記録しておくことが望ましいし、そうあるべきです。（バグの報告にもスキルが必要になります。）

バグ報告のスキル…起こった事実を正確に書くこと。

バグ報告を受け取る開発者にとって正確で十分な内容のバグ報告があれば解決は心配ありません。バグで一番時間がかかる部分（工数を消費し、見積が難しい)は原因の特定なのです。

「動作しません」 「動作がおかしくなりました」

このようなバグ報告を見ることがありますが、開発者は何がおきたか分かりません。意味の無い報告はやめるようにしたいものです。報告する方も読む方も時間の無駄になってしまいます。

2つめはソースコード管理システム、Git, Subversion, Mercurial, CVS を利用するだけです。 多くの開発チームでは何かしらのバージョン管理システムを導入されていると思います。コミットするときのほんの少しの時間、あなたが行った変更内容をコメントに残してください。ただそれだけです。 このちょっとした手間をかけるだけでリポジトリを共有・参照する他のメンバーにとって価値ある情報を提供することになります。

最後に開発現場でバグを管理するために必要な項目を補足します。

• 起票日 : 障害を発見した日を入力する
• 起票者 : 障害を発見した人の名前を入力する
• 区分 : バグか課題か要望なのか･･･を決める
• 状態 : バグが発生した後、現在の状態「未着手」「完了」「対応なし」などを管理するための場所
• 内容 : バグの再現方法や発生状況をわかりやすく書く場所
• 担当(チーム、人）: だれが担当するのか名前を入力する
• 回答日/対応日 : バグに対して回答した日を入力する
• 対応内容 : 対応した内容を出来るだけ分かりやすく入力する

  あなたのプロジェクトチームがすばらしい製品をリリースするために開発工程の改善につながれば幸いです。