[#TiDD] チケット駆動開発のはじまり #devsumi

チケット駆動開発は、

• タスクをチケットで管理する
• 構成管理上の更新をする際はチケットと連動する(構成管理と障害管理の連携)

というものです。

チケットは障害管理票に当たるものですが、これはかなり昔から障害以外の記述が行われていました。私の知る限り1992年に生まれたオープンソースBTSであるGNATSはバグの管理だけでなく、ユーザとのコミュニケーションが目的であり、2003年に使った時にはすでにBugとFeatureが標準の分類にありました。

2番目の構成管理と障害管理は、たぶん1980年代から行われていました。構成管理では、ベースラインを決めて、そこからの変更の管理をしていたからです。障害は障害票で管理されて連番が降られますから、ベースラインからの変更理由として障害票の番号を書くことは自然だからです。

このように、チケット駆動開発の基本的なルールはすでに20世紀から実施されてきたと思われることです。しかし、それは一般の開発現場のためでなく、オープンソースの開発であり、管理のためでした。これらはツールで自動化されることなく、別々に行われました。これがチケット駆動開発と大きく違うところです。

チケット駆動開発はtracから始まりました。tracは障害管理ツールの一つですが、以下のような特徴がありました。

• チケットの種類に「タスク」が始めからあった
• 構成管理ツールと簡単に連携できた
• Wikiが組み込まれており、その記法としてチケット番号やチェンジセットへのリンクがあった

このように、オープンソースでなく一般の開発が考慮され、管理者でなく開発者を意識したつくりになっていたのです。tracを知った開発者たちは現場で活用し、Shibuya.tracなどで、多くの情報交換が行われました。

その当時に有名だったのは、masuidriveさんで、チケットでプロジェクト管理することを提唱されていました。そのような中で、まちゅさんがチケット駆動開発を提唱されました(このころのことはtogetterチケット駆動開発のはじまりをご覧ください)。

まちゅさんは上述の基本ルールを、現場の実体験を通じて提案されました。これが、XPJUG関西の人たちの目に留まり、略称がTiDDとなり、アジャイルに関する議論が行われ、あきぴーさんを通じて私も参加するようになりました(アジャイルに関してはまちゅさんもコメントされています)。

そうこうする間に、tracを参考に開発されたRedmineが注目を集めるようになり、あきぴーさんと史上初のチケット駆動開発の本を書くことになったのです。

謝辞：

上に挙げさせていただいたmasuidriveさん、まちゅさん、XPJUG関西のみなさん、あきぴーさん、に感謝します。また、この記事を書くに当たってTwitterでかぬさんに色々と教えていただきました。感謝いたします。そして、かぬさんへの質問のきっかけになったのは、デブサミ2011の講演中のつぶやきでした。これは会場のアンテナ設置がなければ、そのきっかけを失っていたでしょう。スタッフのみなさん、ソフトバンクのみなさんに感謝いたします。