バグのライフサイクルを管理する仕組みがバグトラッキングシステムの特徴の1つである。
簡単に言うと、「バグの発生～調査～対策～確認」のバグ1件毎にステータスを管理する仕組みのことである。
なぜ、バグのステータスを管理必要があるか、というとExcelをつかったバグ管理を実践してみるとわかると思う。
こちらの記事(「とりあえずバグ管理」のための Excel テンプレート)
でバグ管理に必要な項目をリストアップしたが、バグの「状態」をもう少し運用に沿った仕組みで管理したくなる。
Excelを使ってバグ管理の運用をしていくと以下のような課題が挙がると考えられる。
- いつ、だれが、どのような対応をしたのか?わかりにくい
- 対応履歴の管理が出来ない
- 状態の変更履歴（どのようなフローを経由してきたか）がわからない
- Excelファイルをメール添付してやりとりするため、最新がどれかわからない
- 複数の版にわかれたファイルをマージしなければいけない
- YYYYMMDD_○○○.xls という管理になってしまう
など、Excelではバグ管理できないわけではないが、開発者にとっては運用するだけでストレスを感じてしまう場合が多い。
弊社ではバグトラッキングシステムを利用しているが、これは開発者にストレスをかけないために導入したという経緯があるためである。
これまでの経験上、Excelで運用していくと破綻してしまう場合があるので、バグトラッキングシステムはソフトウェア開発では必須のツールになっている。
バグトラッキングシステムの中で最も必要な機能が「状態（ステータス）」とワークフローである。 以前にブログで紹介した、「ソフトウェア開発:バグ管理方法の紹介」で簡単にワークフローについてイメージ図を紹介したが、バグのフローとは
- 1. バグの発生(発見者)
- 2. 担当者への振り分け
- 3. 担当者の対応
- 4. バグの完了確認(対応済みかどうか)
- 5. バグの完了
である。 ソフトウェア開発の現場では、バグの数も半端な数ではなく大量に発生する。それらバグ1つ1つのワークフローをきちんと管理できる仕組みがバグトラッキングシステムの大きなメリットであると考えている。
会社やプロジェクトによって、ワークフローはもっと複雑になっていると思うが、
基本的には
[発生->割当->対応中->確認待ち->完了] [ ->対応なし ]
が管理できれば十分である。
今回はバグの場合のワークフローについて書いたが、機能追加の要望、タスクなども同様にワークフローを決めて運用することでソフトウェア開発の効率は格段に上がると思う。
OpenGrooveの社内検索システム : zeera document search
