チケット駆動開発 (ticket-driven development; TiDD) とは、プログラム開発手法の一種で、作業をタスクに分割しBTS（Bug Tracking System／バグ管理システム）のチケットに割り当てて管理を行う開発スタイル。細かな修正作業の多い従来開発の中で生まれたが、アジャイル開発との親和性が高いことから、エクストリーム・プログラミングをはじめとするアジャイル開発でも実践されている。
はじまり チケット駆動開発が提案された2007年ころはソフトウェア開発環境が充実し、Subversion、trac、ウィキを活用したプロジェクト運営が注目されていた。そのような中で、たくさんの細かな修正を効率よく行う方法として「チケット駆動開発」が現場から生まれた。
チケット駆動開発は、まちゅ氏のITpro Challenge のライトニングトーク「もうひとつのTDD開発」の中で発表された。この中で、チケット駆動開発はBTS（バグ管理システム）のひとつであるtracのチケットを以下のように用いるとした。
チケットをプロジェクトの情報の中心とする チケットによる作業の割り振りと進捗管理 チケットなしのコミットは禁止とする
その後、Shibuya.tracではtracユーザによる実践が、TiDD関西勉強会、XPJUG関西ではアジャイル開発での実践が行われるなど、多くの実践が行われるようになった。
大阪中央公会堂で行われたTiDD関西勉強会にて、「TDDと同じ略称だと紛らわしいので、TiDDにしよう」で決まった。iが小文字なのは、おしゃれだからである。
ルール 上述のようにチケット駆動開発はBTSを中心にツールを統合し、チケットで作業の管理と見える化を実現するものである。チケット駆動開発を実践する上でのルールは基本的に1つである。
チケットなしのコミットは禁止（No Ticket, No Commit!）
個人的な管理ではなく、構成管理上のコミットをしないということである。このルールによって開発メンバーの仕事が把握しやすくなるだけでなく、成果物の更新が必ずチケットと関連付くので変更理由が明確になる、というチケット駆動開発のメリットが生まれる。
開発サイクル チケット駆動開発では、概ね次のようなPDCAサイクルを繰り返して開発が行われる。 大まかなリリース計画を作る。 仕事を細かいタスクに分割し、タスクを書き出す。(チケットの発行) イテレーション単位でタスクをまとめて、イテレーション計画を作る。 タスクを一つ選び、実装する。 差分をコミットし、完了する。(チケットのクローズ) イテレーションに紐づくタスクがすべて終了ステータスになるとリリースする。 リリース後、開発チームで作業をふりかえる。 次のイテレーション計画へ顧客の要望やふりかえりの内容を反映する。
利点 チケット駆動開発には、次のような利点があるとされる。 いつでも誰でもチケットを参照できるので、コミュニケーションを取りやすくなる。 突発的なタスクの変更があっても、チケットの属性変更が簡単なので変化に対応しやすい。 イテレーションの作業量を一定にすることにより、開発のリズムが生まれる。 チケットをイテレーション単位に管理するため、頻繁なリリースも可能になる。 チケットをソースコードや要件、テストケースと結びつけられるので、相互に追跡可能になる。 チケット管理のワークフローは、バグ管理だけでなく、ソフトウェアの新規開発や要件管理にも応用できる。
脚注
外部リンク・参考文献
Shibuya.trac: https://osdn.net/projects/shibuya-trac/wiki/FrontPage XPJUG関西(チケット駆動開発研究): http://www.xpjug.jp/cgi-bin/main_wiki/wiki.cgi?page=%A5%C1%A5%B1%A5%C3%A5%C8%B6%EE%C6%B0%B3%AB%C8%AF%B8%A6%B5%E6 小川, 阪井: Redmineによるタスクマネジメント実践技法, 翔泳社, 2011.
関連項目 アジャイルソフトウェア開発 エクストリーム・プログラミング テスト駆動開発