TiDD：チケット駆動開発

「チケット駆動開発」という言葉を聞かれたことがあるでしょうか？
テスト駆動開発と似ているこの言葉は、最近、アジャイルに興味を持つ人たちの間で注目されています。今回は、この「チケット駆動開発」について書いてみたいと思います。

１．チケット駆動開発の始まり

「チケット駆動開発」は、TracやRedmineなどのBTS(Bug Tracking System：障害管理ツールなどとも呼ばれる)の利用から始まりました。まちゅさんが、たくさんの小さな修正を加えるシステムを開発されている中で、BTSのチケット(障害票)を用いて開発プロセスを改善されたことに始まります。

まちゅさんは「チケット無しでのコミット禁止」とすることで、全てのコード修正をチケットで管理できるようにされました(参考文献1：チケット駆動開発 … ITpro Challenge のライトニングトーク (4))。

まちゅさんによると必ずチケットを発行するというルールによって、2つのメリットが生まれるそうです(参考文献2：チケット駆動開発 (TiDD) とアジャイル開発)。

(1)開発メンバの仕事が把握しやすくなる

(2)ソースコードのコミット単位が明確になる (目的が異なる修正を同時に加えない)

２．アジャイル開発への適用

まちゅさんの講演を受けて、XPJUG関西の人たちが、TiDDがアジャイル開発に向いていることに気付きました。まちゅさんは「もう一つのTDD」と呼ばれていましたが、テスト駆動開発と区別するためにえと～さんが「TiDD」と名づけられました。

そして、あきぴーさんを始めとして、実際の開発現場でTiDDが実践されました。XP(Extreme Programming)のタスクカードをBTSのチケットに置き換えることで、XPを以下のように改善できました。

(1)タスクボードが必要ないので、職場の環境に関係なく多くの作業を管理できた

TiDDによるアジャイル開発では、XPのタスクカードをチケットに置き換えます。このことで、タスクボードと呼ばれる掲示板が不要になり、XPの実施が容易になりました。また、タスクボードを用いると、その大きさによって貼ることが可能なタスクカードの数が制限されますが、そのような制限がなくなりました。

(2)個人毎の作業管理が容易になった

タスクカードはToDo、Doing、Doneという3つの状態で管理されますが、それぞれのタスクの担当を容易に識別できません。タスクカードをオンライン化することで、個人ごとの担当作業を容易に抜き出すことが可能になりました。

(3)複雑な構成管理作業が抜けなく行えるようになった

XPでは繰り返し開発を行いながら複数回リリースするので、リリース後のソースコードと開発中のソースコードを同時に構成管理する必要があります。BTSのワークフロー機能を使うことで、作業の抜けをなくすことができました。

３．TiDDの二つの側面

このようなチケット駆動開発には、ツールの新しい利用方法という側面と、プロセスの改善という二つの側面があります。

３．１ ajaxのようなもの？

「TiDDはajaxのようなもの」と言われることがあります。昔からある機能ですが、考え方と使い方を少し変えるだけで世界が大きく変わる、という意味だと思います。TiDDではBTSのチケットを用いますが、それは障害を記録するものと言うよりは作業の管理単位になっています。

大昔に読んだマイヤースの本に機能とは何かについて書かれていました。時計の機能は現在の時刻を示すものですが、ユーザによっては１と３の間の数字を知るということもひとつの機能になると書かれていました。もちろんこれは本来の機能ではありませんが、TiDDとBTSの関係に似ています。

具体的にはBTSの状態管理、ワークフロー管理、構成管理ツールとの連携、といった機能を、作業管理のために用いています。そのように書くと、「BTSでなくても良いの？」とか「BTSがなくてもよいのか？」という疑問が出ると思います。実はそうなんです。

３．２ アジャイル開発のプロセス改善

まちゅさんによると、そもそもTiDDはBTSを「みんなで使うToDoリスト」として使う開発法です。だとすると、ToDoリストがあればBTSはなくても良いはずです。いやいや、ワークフローの管理が必要だと言われるかもしれませんね。それなら、ToDoリストに判子欄を設けてはいかがでしょうか(そういえば、昔の障害票には判子欄のあるものがありました。順に押印していくことで、ワークフローを管理していたのですね)。あとは個人毎の作業管理が必要ですね。ToDoリストを色分けして、担当者がわかるようにすれば、すこしは便利かもしれません。

そんな風に考えると、チケット駆動開発はいったい何だろうと思われるでしょう。誤解を恐れずに書くと、TiDDはプロセス改善の手法です。

まちゅさんはたくさんの小さな修正を加えるシステム開発をうまく行いたかった。たまたまそこにBTSがあって、便利に使えたということでしょう。あきぴーさんは、アジャイル開発をうまく行いたかった。そこにBTSがあってTiDDを実践すると、いままでうまくいかなかったアジャイル開発がうまくいった。そういうことなのだと思います。

つまり、プロセスを改善する道具を探したら、そこにBTSがあったということなのだと思います。

４．チケット駆動開発はエンジニアリングの基本

巷では月着陸40周年と騒がれていますね。このアポロ計画が成功したのはWBS(Work Breakdown Structure)があったからだといわれています。かつてない巨大なシステムを構築するには作業を抜けなく行う必要があるので、WBSは非常に有効なツールだったと思います。

XPJUG関西の集まりで、チケット駆動開発をどこまで抽象化できるかを議論していたとき、ある方が「チケットは忘備録」と言われました。この言葉を聞いて、その程度のものかと正直思いましたが、じつはこれがチケットの本質だと思います。小さな作業がたくさんあるプロジェクトにおいて、作業を抜けなくきちんとやることは、とても大事なことなのです。

アポロ計画ほどの巨大なシステムでなくても、作業を細分化していけばその数は膨大なものになります。それをきちんと抜けなく、定められた手順でやる、それはとても大切なことです。

そのためには、(1)どのような作業があるかプロジェクト内で共有・確認し、(2)開発者が担当作業を把握し、(3)決められた手続きに沿って抜けなく作業する、ということが支援されなくてはならないのです。チケット駆動開発は、それを支援しています。まさに「エンジニアリングの基本」を支援しているのです。

５．まとめ：チケット駆動開発の魅力

「チケット駆動開発」は、アジャイル開発(を中心とした)プロセス改善手法です。もちろんBTSがあれば便利に使えますが、ツールが無くてもプロセスを改善することができるはずです。

このように書いていて、かつてオブジェクト指向分析がブームのころに話題になったOMT(リンク先はWikipedia)の本を思い出しました。この本の後半には、オブジェクト指向でない言語でのオブジェクト指向開発の方法が書かれていました。オブジェクト指向分析は、言語に関係なくのメリットがあるということなのでしょう。実際、この本に励まされて実践された方もたくさんおられるのでしょう。でも、環境の整ったオブジェクト指向言語の方がはやったように思います。

チケット駆動開発もたぶんそうです。便利なタスクカードや「チケット駆動開発環境」というものがあれば、それがブームになるかもしれません。でも、それ以前に良くできたBTSがあったのです。最近のBTSは高機能化が進んでいて、チケットの状態管理、検索、グラフ化、ワークフロー管理、などなど、様々なことができます。その機能はチケット駆動開発に十分なものでした。

そんなチケット駆動開発は現場で生まれました。研究所で生まれたなら、たいそうな概念があって、見た目重視の専用ツールがあったでしょう。でもチケット駆動開発は違います。解決したい問題が先にあり、目の前にあったBTSを使ってやってみたらうまくいった。

その概念もあまり固まっていませんでした。私がここに書いていることも人によっては「ちがう！」と言われるかもしれません。でも、実践したらうまくいった。それが「チケット駆動開発」なのです。

「チケット駆動開発」を育てたのは、技術に対して貪欲で、意欲的な人たちです。いまやアジャイル開発も普通のことになりましたが、数年前までは目新しい概念でした。どの程度役に立つのか、あまりわからない状態でしたが、現場に問題を抱えていた技術者たちはアジャイラーになりました。そして進んで実践し、問題にぶつかり、チケット駆動開発を見出したのです。

私が「チケット駆動開発」に魅力を感じるのは、そんな技術を実践する人たちが育てているからかも知れません。オブジェクト指向も、アジャイル開発も、そんな人たちが育てたから、良いものになりました。きっと「チケット駆動開発」も良いものに育っていくだろうと思っています。