オープンソースBTSはソフトウェア開発のベストプラクティス

ソフトウェア開発は3つのモードがあると思う。
最初は新規開発モード。
そしてソフトウェア開発の中で最も難しく、最もプロジェクトマネジメント能力を要求されるバグ管理モード。
最後は、運用保守モード。

BTS（バグ追跡システム）は、主にバグ管理モードで使われる。
つまり、各開発者のプログラムを繋ぎ合わせて正常に動かす結合テスト。
あるいは、色んなブラウザに対応しているか、とか、高負荷なアクセスに耐えれるか、などのようなシステムテスト。

BTSとは、そこで上がったバグを収集し、修正し、検証する一連の作業をフレームワーク化したもの。
主にWebシステムで作られている。

このBTSについて再考してみる。

【1】BTSに至るまでの歴史

一昔前。
結合テスト以降のバグ修正は、Excelベースだった。

バグを見つけた人が、Excelのバグ報告票に起票する。
そのExcelを修正担当者に渡し、修正してもらう。
修正後、修正担当者が、バグ報告票をテスト担当者に渡す。
テスト担当者は修正した機能を検証し、OKなら、プロジェクトリーダーへ報告して、報告票をCloseする。

業務プロセスをIT化するのがシステム屋の仕事なのに、自分たちのシステム開発は、余りにも手作業の部分が多かったし、今もそんな状況の開発チームは多くないだろうか？

このバグ修正のワークフローが、ソフトウェア開発で最も難しいのは何故か？
二つあると思う。

一つは、Excelベースなので、同時に複数人の書き込みができない。
バグ報告票は、作業状態によって、修正担当者・テスト担当者・プロジェクトリーダーなど複数人が触る。
システム開発で最も忙しい工程なので、Excelを握ったままの人がいると、はかどらなくなる。

もう一つは、プロジェクトリーダーが作業状態や優先順位を把握しづらいこと。
バグ報告票は複数人が触るので、今誰がバグ報告票を握っているのか、その作業状態を把握するのが最も大事。

でも、たくさんのバグが上がってきたら、どれが最優先に修正すべきか、そして、誰がバグを修正して検証すべきか、という素早い決断をいつもプロジェクトリーダーは迫られる。
その時にExcelベースだと、今どこまで進捗が進んで、後どれくらい残っているのか、そしていつ終えることができるのか、を見極めるのが難しい。

そこで、自社独自の開発プロセスを持つ大手SIerは、普通、独自のBTSを持っている。
ExcelベースをWeb化して、それなりに運用している。

しかし、この独自のBTSも良し悪しがある。
一つは、社外で利用する時に困ること。
最近は、請負開発で分散開発していたり、オフショア開発で海外で作っていたりすると、バグ情報を共有できない。

また、プログラマにとっては、独自のBTSの使い方に慣れないのも困る所。
大手SIer独自の開発プロセスに特化しすぎな部分があるからだ。

【2】BTSのワークフロー

ここでBTSのワークフローをおさらいしてみる。
このフェーズの作業フローは、Wikipediaで下記で明確に書かれている。

【Open】バグの報告：
テスト担当者はバグを発見するとバグ管理システムにアクセスしてバグの報告を行う。報告の完了時にはバグの状態は「Open」となり、すべての開発者にメールで通知される。
↓
【Assigned】担当者を決定：
管理担当者はバグ情報を確認し、適切な修正担当者を割り当てる。修正担当者が割り当てられるとバグの状態は「Assigned」となり、修正担当者にメールで通知される。
↓
【Resolved】バグの修正：
修正担当者は、バグを修正したら解決方法等を追記し、バグの状態を「Resolved」とする。修正の報告はテスト担当者にメールで通知される。
↓
【Verified】修正の確認：
テスト担当者は再テストを行い、修正が完了していることを確認した上で、バグの状態を「Verified」とする。
↓
【Closed】修正の完了：
管理担当者は「Verified」となっているバグに対して内容を確認し、状態を「Closed」に変更する。

ここで大事なのは、テスト担当者・修正担当者・管理担当者という3つの異なる担当者が関わり、5つの作業状態が変化すること。

RedmineやTracのチケットをバグ報告票と見なせば、BTS自体は非常に使いやすいToDo用のワークフローシステムだと言える。

そして、このワークフローは実は、ソフトウェア開発のフレームワークとして、一般化できる。

【3】BTSはソフトウェア開発のベストプラクティスを抽象化したフレームワーク

つまり、BTSは下記3パターンの作業フローに使える。

１・バグ管理ならBTS。
２・日々の運用保守や、開発時の様々な雑用のタスク管理なら、プロジェクト管理。
３・お客様から上がってきた仕様追加や仕様変更なら、要求管理。

だからこそ、オープンソースのBTSは数多いし、あちこちで使われている。
有名なBTSなら、Bugzilla、Mantis辺りだろうか？

Excelや独自のBTSよりも、オープンソースのBTSを使った方が効率が良いと思う。
理由は、多種多様なプログラマがBTSを使いこなし、カスタマイズして進化させてきたから、業界標準に従っている面があること、そして、ソフトウェア開発のベストプラクティスが含まれているからだ。

【4】Remineは単なるBTS以上のソフトウェア開発のインフラだ

ここで、Redmineを見ると、色んなパラメータをカスタマイズできる。
例えば、ステータスは上記5個のステータスそのものがデフォルト設定されていて、更に追加・修正もできる。
ユーザの権限も、増やすことができる。

更に、ワークフローと言う項目があり、そこでは、「バグ」「機能」「サポート」のチケットの種類に応じて、上記のステータスを一部だけ抜き出して選択することができる。

つまり、Redmineでは、担当者の権限と作業状態を作業フローの種類に従って選択・抽出できるのだ！
更に、Redmineでは、複数プロジェクトも管理できる。

だからこそ、新規開発モード・バグ修正モード・運用保守モードをそれぞれのプロジェクトで作っておき、それぞれの作業フローに従って、担当者の権限と作業状態をカスタマイズすればいい。

特に、運用保守フェーズでは、緊急のバグ修正時のソースと、工数をきちんと確保して仕様追加したソースを使い分けなければいけない。
この時に、リリース用モジュールがデグレしたり、新機能が混じったりしまいがちなので、細心の注意が必要になる。
普通は、Subversionでブランチを切って別管理するのが普通だろう。

ここで、Redmineで複数のプロジェクトに分けて、それぞれのSVNリポジトリを紐づけることができる。
そうすれば、運用保守モードのチケットと、新規開発モードのチケットを区別して、仕様からチケットを経由してソースコードまで、一貫してトレースできる。

Redmineで複数プロジェクトを管理できる利点が今まで良く分からなかったが、上記のことをやってようやく分かった。

ソフトウェア開発が難しい理由は、似たような3つのモードの作業フローを意識して切り替えながら、ソース管理もやっていく所にあるのだろう。