チケット駆動開発 (ticket-driven development; TiDD) とは、プログラム開発手法の一種で、作業をタスクに分割しBTS（Bug Tracking System／バグ管理システム）のチケットに割り当てて管理を行う開発スタイル[1]。細かな修正作業の多い従来開発の中で生まれたが、アジャイル開発との親和性が高い[2]ことから、エクストリーム・プログラミングをはじめとするアジャイル開発でも実践されている。 チケット駆動開発が提案された2007年ころはソフトウェア開発環境が充実し、Subversion、trac、ウィキを活用したプロジェクト運営が注目されていた[3]。そのような中で、たくさんの細かな修正を効率よく行う方法として「チケット駆動開発」が現場から生まれた。 チケット駆動開発は、まちゅ氏のITpro Challenge のライトニングトーク「もうひとつのTDD開発」の中で発表された。この中で、チケット駆動開発はBTS（バグ管理システム）のひとつであるtracのチケットを以下のように用いるとした[4]。 その後、Shibuya.tracではtracユーザによる実践が、TiDD関西勉強会、XPJUG関西ではアジャイル開発での実践が行われるなど、多くの実践が行われるようになった。 大阪中央公会堂で行われたTiDD関西勉強会にて、「TDDと同じ略称だと紛らわしいので、TiDDにしよう」で決まった。iが小文字なのは、おしゃれだからである。 上述のようにチケット駆動開発はBTSを中心にツールを統合し、チケットで作業の管理と見える化を実現するものである。チケット駆動開発を実践する上でのルールは基本的に1つである。 個人的な管理ではなく、構成管理上のコミットをしないということである。このルールによって開発メンバーの仕事が把握しやすくなるだけでなく、成果物の更新が必ずチケットと関連付くので変更理由が明確になる、というチケット駆動開発のメリットが生まれる。 この節は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方）
はじまり
チケットをプロジェクトの情報の中心とする
チケットによる作業の割り振りと進捗管理
チケットなしのコミットは禁止とする
ルール
チケットなしのコミットは禁止（No Ticket, No Commit!）
開発サイクル.mw-parser-output .ambox{border:1px solid #a2a9b1;border-left:10px solid #36c;background-color:#fbfbfb;box-sizing:border-box}.mw-parser-output .ambox+link+.ambox,.mw-parser-output .ambox+link+style+.ambox,.mw-parser-output .ambox+link+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+style+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+link+.ambox{margin-top:-1px}html body.mediawiki .mw-parser-output .ambox.mbox-small-left{margin:4px 1em 4px 0;overflow:hidden;width:238px;border-collapse:collapse;font-size:88%;line-height:1.25em}.mw-parser-output .ambox-speedy{border-left:10px solid #b32424;background-color:#fee7e6}.mw-parser-output .ambox-delete{border-left:10px solid #b32424}.mw-parser-output .ambox-content{border-left:10px solid #f28500}.mw-parser-output .ambox-style{border-left:10px solid #fc3}.mw-parser-output .ambox-move{border-left:10px solid #9932cc}.mw-parser-output .ambox-protection{border-left:10px solid #a2a9b1}.mw-parser-output .ambox .mbox-text{border:none;padding:0.25em 0.5em;width:100%;font-size:90%}.mw-parser-output .ambox .mbox-image{border:none;padding:2px 0 2px 0.5em;text-align:center}.mw-parser-output .ambox .mbox-imageright{border:none;padding:2px 0.5em 2px 0;text-align:center}.mw-parser-output .ambox .mbox-empty-cell{border:none;padding:0;width:1px}.mw-parser-output .ambox .mbox-image-div{width:52px}html.client-js body.skin-minerva .mw-parser-output .mbox-text-span{margin-left:23px!important}@media(min-width:720px){.mw-parser-output .ambox{margin:0 10%}}
出典検索?: "チケット駆動開発"
チケット駆動開発では、概ね次のようなPDCAサイクルを繰り返して開発が行われる。 この節は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方）
大まかなリリース計画を作る。
仕事を細かいタスクに分割し、タスクを書き出す。(チケットの発行)
イテレーション単位でタスクをまとめて、イテレーション計画を作る。
タスクを一つ選び、実装する。
差分をコミットし、完了する。(チケットのクローズ)
イテレーションに紐づくタスクがすべて終了ステータスになるとリリースする。
リリース後、開発チームで作業をふりかえる。
次のイテレーション計画へ顧客の要望やふりかえりの内容を反映する。
利点
出典検索?: "チケット駆動開発"
いつでも誰でもチケットを参照できるので、コミュニケーションを取りやすくなる。
突発的なタスクの変更があっても、チケットの属性変更が簡単なので変化に対応しやすい。
イテレーションの作業量を一定にすることにより、開発のリズムが生まれる。
チケットをイテレーション単位に管理するため、頻繁なリリースも可能になる。
チケットをソースコードや要件、テストケースと結びつけられるので、相互に追跡可能になる。
チケット管理のワークフローは、バグ管理だけでなく、ソフトウェアの新規開発や要件管理にも応用できる。
脚注^ masuidrive (2007年12月20日). “ ⇒[Think IT 第3回：チケットドリブン開発でバグ削減！ (1/3)]”. 2008年6月8日閲覧。
^ まちゅ (2009年3月1日). “ ⇒チケット駆動開発 (TiDD) とアジャイル開発”. 2011年5月1日閲覧。
^ 角田直行 (2007年8月30日). “ ⇒濃縮還元オレンジニュース：Subversion，Trac，Wikiを徹底活用した「masuidrive的プロジェクトの方針」”. 2011年5月1日閲覧。
^ まちゅ (2007年9月7日). “ ⇒チケット駆動開発 … ITpro Challenge のライトニングトーク (4)”. 2011年5月1日閲覧。