ソフトウェア開発やシステム開発で作成されるプログラムは、ほとんどの場合人によって開発される。 そのため、プログラム内にはバグと呼ばれるプログラム上の間違い、不具合が必ずあり、バグのない
プログラムを作成することはほとんど不可能と考えられている。(バグとは)
開発者はプログラム作成において、バグを取り除く作業に多くの時間が費やされることになるが、 そのデバッグ工程で大活躍しているツールとバグ管理方法について紹介したいと思う。
ソフトウェア企業で障害管理表、バグ管理表といえば MS Excel や MS Word で管理している企業は多いと思う。 実際に過去自分が関わったプロジェクトでは Excel が多く利用されていた。
弊社でのバグ管理方法は、Trac といわれるバグトラッキングシステム(Bug Tracking System/BTS) を利用して管理している。 ほとんどすべてのプロジェクトでバグトラッキングシステムを利用しているが運用するためには最低限のルールが必要になる。ルールを守って、だれでも簡単に運用できるようにしなければ、チーム内でうまく利用されない。
これから導入を検討されている方の参考になればと思う。
基本の考え方
- プロジェクトスタートと同時に開発用の BTS を準備
- プロジェクト内で発生するバグ・課題は必ず BTS に登録すること
- 「BTS に登録されないバグや課題は対応しない」など、徹底させるためのルールをはじめに説明
運用方法
- すぐやる / 都度やる
バグや課題は見つけたときにすぐ登録、「あとで」は忘れるもと。導入後でデータ登録 が一番めんどうだが、メリットを考えるとちょっとの努力を惜しまずにやる。
- 各プロジェクトの管理責任者を決める
BTSの導入後、チケットの乱発、処理されないチケット、担当のいないチケットがいつ までも残ることがあるので、管理責任者を用意する方がうまくいく。
- バグ・課題のクローズはチケット作成 バグ・課題(チケット)をクローズする権限は、発行者、各プロジェクトの管理責任者、品質保証のメンバー
チケット運用イメージ(ワークフロー)
BTS のワークフロー
開発サポートツールをうまく導入するために、できるだけシンプルなルールだけを決めて運用してきたつもり。 開発者ならだれでも使えるだろう Excel や Word ほど学習コストは下げられないが、一度利用しはじめたら そのメリットから開発には必須のツールになる。
まだ導入していないソフトウェア開発者の人は、ぜひ導入を検討してもらえれば幸いである。