ワークフロー管理の厳密性と作業スピードは反比例する

ソフトウエア開発において、例えば要件定義、基本設計などの作業を進めていくにあたって個々の作業をどう管理するかというのは重要な問題です。担当者が基本設計書を作成したら誰がレビューして承認するのか？といった個々のタスクの流れをどう管理していくかというのは大規模になればなるほど厳密にやる必要があります。

TracやRedmineのような近代的なBTSでは個々のタスクを可視化したのがチケットであり、個々のタスクの流れを可視化したのがワークフローと言えます。

Tracはチケットという概念を作ることによりバグ票を抽象化し、バグ以外の作業も扱えるようにしました。またSVNのような構成管理ツールとチケットを連動させることによりチケット駆動開発を可能にしました。

Tracのワークフローは以下のようになります。

new（新規） → assigned（アサイン済み） → accepted（受け入れ済み） → closed（クローズ）

このワークフローではいわゆるレビュー待ちのようなステータスがありません。このこととワークフローのカスタマイズが難しいことからTracのワークフローが貧弱であると言われることが多いです。

Tracの後発のRedmineのワークフローは以下のようになります。

New（新規） → Assigned（担当） → Resolved（解決） → Closed（終了）

担当者が解決にしたらリーダが終了にするといった運用になるでしょう。またRedmineの場合はワークフローのカスタマイズがGUIのマトリックスでできるので比較的容易にできるようです。

確かに大規模なプロジェクトではチケットが担当者の一存で勝手にクローズされてはマズいでしょう。一方でワークフローを厳密に管理するにはコストもかかります。チームが慣れてないとかなり難しいと思います。定期的にチケットの棚卸しをしないとレビュー待ちのチケットだらけになる可能性が高いです。

またチケットのdoneの定義をある程度はっきりしておかないといつまでたってもクローズできなくなります。チケットというバグよりも抽象度が高いものにしたためdoneの定義があいまいになりがちです。

バグだとdoneの定義がはっきりしているのでチケットとしてはやりやすいです。設計書作成とか環境構築ぐらいならまだいいですが、〜の整理とかモヤモヤしそうなやつがチケットになるとすぐ宙に浮きます。そういう意味では結合テスト以降のバグ管理にのみチケットを使うというはありだと考えています。

Mantisはこのバグ管理に特化したBTSです。TracやRedmineと違ってWikiやリポジトリブラウザはありません。

Mantisのワークフローは以下のようになります。大規模だとこれぐらいの管理が必要かもしれません。

new（新規） → feedback（要追加情報） → acknowledged（内容確認済） → confirmed（再現済） → assigned（担当者決定） → resolved（解決済） → closed（完了）

一人プロジェクトの場合はチケットのステータスはnewとcloseがあれば十分です。俺が仕様状態なので自分の判断でクローズでいい。たとえwontfixでもwステータスがいっぱいあったら返って面倒。なので一人プロジェクトが多かった僕にとってはTracのワークフローが弱いというはあまりぴんとこなかったりします。

こういうケースでは当たり前ですが作業スピードは速いです。ワークフローをルーズに管理すればスピードは速くなります。ただ小規模なら向いていても、あるとき大規模になった瞬間にこの運用だと回らなくなる可能性があります。大規模になったら作業スピードは犠牲にしてワークフロー管理を厳密にする必要があるでしょう。ただ厳密にするというのはチェックリストを増やすということではありません。スケールするためにはPM、リーダ層が意識をあわせてトップダウンでチケット運用しないと難しいでしょう。