チケット駆動開発はツールによる改善か、プロセスによる改善なのか

チケット駆動開発を実践してプロジェクトが大きく改善された事実を話して、一番気になる質問がある。
「チケット駆動開発を運用したプロジェクトはツールで改善されたのですか？　それともプロセスで改善したのですか？」

質問の意図は、チケット駆動開発の話を聞くとBTSやらバージョン管理やらツールの使い方の話が多い。
そのプロセス改善はツールに依存しすぎではないか？
ツール無しの開発プロセスにできるのか？
チケット駆動開発は、BTSがなければ運用できないのか？
と。

この質問は今の僕が抱える問題点の一つを持っている。
それについては後でまとめる。

【1】チケット駆動開発の定義の一つは、BTSチケットをXPのタスクカードのように使うことだ。
すなわち、障害だけでなく要望なども取り扱う。

この方法は、Issue Trackingとも呼ばれている。
つまり、障害修正のワークフローをSW開発における全ての作業の管理に拡張しようとすることだ。

SW開発の作業は、バグ修正というプログラミングだけではない。
ビルド環境を作ったり、リリース作業、テストデータの流し込みもある。
仕様変更によって設計書を直し、ソース修正もする。
お客から電話やメールで依頼される調査もある。
現場リーダーならば、スケジュールを作ったり、上司や顧客へ報告書を作ることもある。

それら全ての作業をチケットに登録して、進捗や作業状態をチケットで追跡していく。

すると、このようなプロジェクト管理は、BTS無しでも、PostItのようなカードでも運用可能だろうと推測できる。
実際、XPの計画ゲームを第三者が見ると、チケット駆動開発と何ら変わることはない。

でも、さかばさんによると、チケット駆動開発をアナログでやりたければ、PostItに判子の欄やチェック欄を追加すればいいでしょ、と。

例えば、チェック欄は、その作業のワークフローにおけるステータスが完了したかどうかに使う。
判子の欄は、その作業のステータスが完了した場合、現場リーダーやテスト担当者がレビューしたり検証して、承認したら判子を押す。

つまり、PostItにワークフロー管理機能を追加した点がチケット駆動開発が強調した点の一つ。
しかし、アナログのPostItは管理が面倒だ。
ホワイトボードや模造紙で、かんばんの上にPostItを貼り付けるのがPFのプラクティスの一つでもあるが、PostItは紛失しやすい。
また、集計しにくい。

マネジメントという作業の基本スキルは、予定と実績の比較にある。
PostItによるアジャイルな運用は、実績管理しかできない。
この点がBTSを使う利点の一つ。

現場で開発者の感想を聞くと、チケット駆動開発を自分のToDo管理に使っているようだ。
例えば、日々のタスク管理をCheckPadやRememberTheMilkのようにWeb上で行う感覚。

このやり方を推し進めると、チケットでリスク管理や課題管理も自然に行うようになる。

例えば、開発者がリファクタリングすべき作業ではないか、と気になった箇所は、優先順位の低いチケットとして登録しておく。
このチケットはすぐに作業する必要はないが、このチケットに絡む作業が発生した場合、その時点で作業の一部として取り込む運用もできる。

管理者としては、このチケットは将来のリスクの一つ。
3人日と見積もったチケットが実は5人日もかかってしまった理由の殆どは、リファクタリングの作業工数をあらかじめ見積もりできていなかったからだ。

この運用を始めて、開発者は積極的に、ソースで不安な所、コーディングルールに則っていない所をチケットに登録してくれるようになった。

あるいは、設計書に従って実装して、設計時の仕様漏れや仕様の不明点を質問が出た場合、課題としてチケットへ登録する。
このチケットは、障害修正と異なり、設計者や顧客へ問合せを行うワークフローで管理する。
つまり、このワークフローは変更管理、あるいは、インシデント管理の一部なのだ。

このチケット管理がおそらくIssue Trackingの発端ではないかと推測される。
課題のチケットは、上手に運用しなければ、単なる質問に過ぎなかったのに、仕様漏れとしてテスト工程で工数が大きくかかってしまう危険がある。

だから、チケットで質問と回答を履歴として残し、テスト工程や運用保守で追跡できるように記録しておく。

【2】チケット駆動開発の定義によれば、チケットとソース管理の連携というもう一つの特徴がある。
これこそが、従来のアジャイル開発のタスク管理になかったもの。

この運用ルールに開発者が慣れてしまうと、チケット無しでソースをコミットするのが不安で仕方なくなる。
チケット無しのソース修正をしてしまうと、変更理由が後で自分でも分からなくなるからだ。
特に、昨今のSW開発は開発者の出入りが激しいため、去ってしまった開発者のパッチの修正意図はすぐに分からなくなる。

これは後々の変更管理で大きくリスクとして響く点の一つ。
ソフトウェアは常に手入れしなければ、雑草が生えた公園のように、すぐにエントロピーが増大して品質が劣化していく。

【3】チケット駆動開発はウォーターフォール型開発でも運用できるだろうと思う。
しかし、アジャイル開発のプロジェクト管理に特化できる点が大きな特徴だと思っている。

現場で、Redmineにおける開発者の使い方を見ると、最初はチケット一覧で自分の担当チケットだけフィルタリングして、ToDo管理している。
しかし、僕が朝会などでRedmineのロードマップ画面を見ながら説明するうちに、開発者も自然にロードマップ画面を中心に見てくれるようになった。

理由は、自分のタスク状況だけでなく、チームの進捗がRedmineのロードマップ画面で一目で分かるからだ。
やっぱり、自分の作業、自分の役割がプロジェクトでどんな役割を担っているか、を開発者も知りたいらしい。

Redmineと比較して、Tracのロードマップは機能が貧弱だ。
終了チケットの進捗率しか表示してくれない。

ロードマップこそがアジャイル開発の肝だ。
ロードマップでプロジェクトの進捗、更にはプロジェクトのゴールが見えるし、そして、マイルストーンをXPのイテレーションとして運用すれば、自然にアジャイル開発になる。

Redmineでは自然にアジャイル開発できたのに、過去の僕が、Tracではチケットを乱発したり放置されがちに運用してしまったのは、Tracのロードマップやバージョン、マイルストーンを上手に運用できなかったのが理由だと思っている。

だから、Tracを運用して一番不満な点、そしてTracの最大の弱点の一つは、ロードマップ機能だと思っている。

逆に言えば、Redmineのチケット管理をアジャイル開発のプロジェクト管理に応用できた経験のおかげで、TracやMantisでも、チケット駆動開発できるようになった。

つまり、チケット駆動開発は、Redmineでなければできないわけではない。
数少ない経験から、BTSならば何でも可能だという気がしている。

【4】実際の現場で運用して、今はツールとセットでプロセス改善している、と回答せざるを得ない。
でも、RUPやCMMIのように、管理者からプロセスを開発者へ押し付けて、上からプロセス改善するよりも、ツールを使っていたら自然にプロジェクトの生産性がアップしていた、という方が、現場では使いやすい。

XPやアジャイル開発のように、チケット駆動開発も下からプロジェクトを改善していくのだ。