チケット駆動開発（TiDD、Ticket Driven Development）は、開発作業をすべてチケット（Issue）として起票し、チケットを起点にコミット・レビュー・リリースを進める運用手法です。2007年ごろの日本のSubversion・Trac利用の現場から生まれ、Redmine・GitHub・Jiraのいずれでも実践できます。この記事では定義と発祥、守るべきルール、ツール別の設定、AIコーディングエージェントに任せる場合の前提までを整理します。
まとめ：チケット駆動開発の要点
TiDDは「タスク管理ツールを導入すること」ではなく、作業の記録を成果物の変更履歴に結びつけることが本体です。中核ルールはチケットのないコミットを禁じる「No Ticket, No Commit」で、これを守ると各変更の理由がチケットに残り、リリース後の追跡ができるようになります。ツール側は、Redmineなら参照キーワード（既定はrefs, references, IssueID）と修正キーワード（既定はfixes, closes）、GitHubならcloses #123形式のclosing keywords、Jiraならスマートコミットが、この結びつけを自動化します。ただし自動クローズはRedmineでは既定のステータスが未設定のため、設定しない限り動きません。
導入の失敗は、ルールを形式的に運用して「コミット直前に作った後付けチケット」が並ぶ状態に陥ることです。チケットの粒度と棚卸しの頻度をあわせて決めないと、記録は増えても追跡には使えません。導入時は、作業前の起票、変更履歴との紐づけ、棚卸しを一組で設計します。
チケット駆動開発（TiDD）の定義と2007年の発祥
TiDDは、機能追加も不具合修正も調査依頼もすべてチケットとして登録し、そのチケットIDを軸に作業とコミットを紐づける進め方を指します。日本で生まれた手法で、Wikipedia日本語版は「チケット駆動開発が提案された2007年ころはソフトウェア開発環境が充実し、Subversion、trac、ウィキを活用したプロジェクト運営が注目されていた」と記述しています。
時系列は、TiDDの普及を担った小川明彦・阪井誠がSPI Japan 2010で発表した資料に明記されています。資料は「チケット駆動開発(TiDD)の歴史」として2007年のまちゅ氏によるITpro Challengeライトニングトーク「もうひとつのTDD」を起点に置き、2008年にXPJUG関西のビジネスモデリング研究会からTiDD勉強会が発足したと記録しています。両名はその後、2010年10月に『Redmineによるタスクマネジメント実践技法』（翔泳社、ISBN 978-4-7981-2162-8）、2012年8月に『チケット駆動開発』（翔泳社、ISBN 978-4-7981-2506-0）を刊行しました。前者の副題は「チケット駆動開発+テスト工程管理のAtoZ No Ticket! No Commit!」で、ルール名が書名の一部になっています。
同じ資料はTiDDが生まれた背景を「細かく大量の作業、変化への対応が必要となり、プロセスの即時性・効率化が求められた」と説明しています。この出発点はいまも運用設計に効きます。TiDDは大規模な設計を管理するための枠組みではなく、件数の多い小さな変更を取りこぼさないための仕組みです。
「駆動開発」という呼称の範囲とTDD・BDDとの違い
「〇〇駆動開発」は、開発の進行を何が起動するかを示す言い方です。TDDとは？テスト駆動開発の基本サイクルと導入判断を実装者向けに解説で扱うテスト駆動開発は、テストコードを先に書いて実装を導くコードの書き方の手法です。BDDとは？振る舞い駆動開発の仕組みとTDDとの違い・導入判断を実装者向けに解説の振る舞い駆動開発は、振る舞いの具体例を通じた要件の共通理解や受け入れテストまで含む手法です。
これに対してTiDDが規定するのは作業の受け渡しと記録で、コードの書き方には踏み込みません。層が違うため、TiDDとTDDは排他ではなく併用できます。実際にはチケットに受け入れ基準を書き、その基準をテストコードに落とす形で組み合わせるのが自然です。TiDDとTDDは略称が似ていますが、テスト駆動開発を探している場合は上記のTDD記事が該当します。
チケット・Issue・作業項目の呼び分け
呼び方はツールごとに違い、同じものを指します。Redmineは「チケット（Issue）」、GitHubは「Issue」、Jiraは以前の「課題」から「作業項目（work item）」へ表記が変わりました。Jiraの使い方と基本機能｜作業項目・エピック・ボードを実務目線で解説で扱うエピックやストーリーは、作業項目の種別を分けたものです。
混乱しやすいのは、サポート窓口の問い合わせ管理も「チケット」と呼ばれる点です。TiDDのチケットは、作業内容と経過を記録し、関連する変更履歴を紐づける管理単位を指し、顧客対応用とは目的や閲覧権限を区別し、修正依頼と開発チケットの対応関係を残します。
運用ルールの中核：No Ticket, No Commit と7つのプラクティス
最も知られたルールが「チケットなしのコミットは禁止（No Ticket, No Commit!）」です。Wikipedia日本語版はこのルールの効果を「開発メンバーの仕事が把握しやすくなるだけでなく、成果物の更新が必ずチケットと関連付くので変更理由が明確になる」と説明しています。Atlassianが公開しているTiDDの解説記事では、これを含む7つのプラクティスが整理されています。
| プラクティス | 内容 | 主な効果 |
|---|---|---|
| No Ticket, No Commit | チケット番号のないコミットを禁止 | 変更理由の追跡 |
| No Ticket, No Work | チケットのない作業を行わない | 作業量の可視化 |
| Iteration is Version | 反復をリリースバージョンに対応させる | リリース範囲の確定 |
| チケットは製品に従う | チケットを製品単位で管理 | 対象の取り違え防止 |
| Divide and Conquer | タスクをチケットで分割 | 並行作業の分担 |
| チケットの棚卸し | 滞留チケットを定期的に処理 | 台帳の信頼性維持 |
| Pair Work | 1チケットを2人以上で連携 | 属人化の抑制 |
7つを同時に入れる必要はありません。先に効くのは上2つとチケットの棚卸しで、残りはリリース運用や体制が固まってから足しても遅くはありません。逆に、棚卸しを省くと、対応方針が不明な古いチケットが蓄積し、残件数が判断材料として使えなくなります。
No Ticket, No Commitは宣言だけでは守られません。TiDDの出発点となったTracの公式Wikiは、この点について「With additional logic in the commit hooks it is possible to reject the commit if no ticket number is supplied.」と述べ、コミットフックに判定を足してチケット番号のないコミットを拒否できると説明しています。ルールを機械側で強制するか、しないかが、運用が続くかどうかの分かれ目になります。
コミットとチケットを紐づけるツール設定
ルールを人の注意力に頼ると守られません。主要ツールはコミットメッセージからチケットを参照・クローズする機能を持っているので、参照の自動化は記録漏れを減らします。自動クローズを使うかは、レビューやリリースの完了条件に合わせて決めます。
Redmineの参照キーワードと自動クローズ設定
Redmineは管理画面のリポジトリ設定でキーワードを定義します。公式ガイドによれば既定値は、参照用がrefs, references, IssueID、修正用がfixes, closesです。コミットメッセージは次のように書きます。
git commit -m "This commit refs #1, #2 and fixes #3"対象リポジトリをRedmineに登録し、変更履歴を取り込むと、チケット1番と2番が紐づき、3番が修正対象として解釈されます。キーワードの後ろではチケットIDを空白・カンマ・&で区切れます。注意が必要なのは自動クローズで、公式ガイドは「There’s no default status defined for fixed issue. You’ll have to specify it if you want to enable auto closure of issues.」と明記しています。修正キーワードだけ設定しても、適用するステータスを指定しなければチケットは閉じません。キーワードを使わずメッセージ中のIDをすべて拾いたい場合は、参照キーワード欄に*を1文字だけ入れます。なお最新リリースは7.0.1で、2026年8月26日に6.1.4・6.0.11とあわせて公開されています。
GitHubのclosing keywordsとIssue起点のブランチ作成
GitHubはプルリクエストの本文またはコミットメッセージに書いたキーワードでIssueを閉じます。使えるのはclose、closes、closed、fix、fixes、fixed、resolve、resolves、resolvedの9語です。
Fixes #100
Fixes octo-org/octo-repo#1001行目が同一リポジトリ、2行目が別リポジトリのIssueを指す書き方で、公式ドキュメントは別リポジトリの構文をKEYWORD OWNER/REPOSITORY#ISSUE-NUMBERと定義しています。閉じるタイミングにも条件があり、「When you merge a linked pull request into the default branch of a repository, its linked issue is automatically closed.」とあるとおりデフォルトブランチへマージされたときだけ自動クローズされます。開発ブランチへのマージで閉じない場合は、まずマージ先がデフォルトブランチかを確認します。Issue画面のDevelopmentから作業ブランチを作れば、起票からブランチ、プルリクエストまでが1本の線でつながります。
Jiraのスマートコミット3コマンドと前提条件
Jiraはスマートコミットで、コメント追加（#comment）、作業時間の記録（#time）、ワークフロー遷移の3種類を扱えます。遷移だけは書き方が違い、公式ドキュメントは構文を<ISSUE_KEY> #<transition_name>と定義しています。#transitionという固定語ではなく、そのワークフローで実行できる遷移名をそのまま書きます（例はJRA-090 #close）。
JRA-123 #comment レビュー指摘を反映 #time 2h #in-progress公式ドキュメントは「A Smart Commit command must not span more than one line」として、1つのコマンドを改行でまたげないと定めています。複数コマンドを同じ行に並べるのは可能です。対応する連携先はBitbucket Cloud・GitHub・Fisheye・Crucibleで、先にJiraとリポジトリ側を接続しておく必要があります。もう1つの前提が本人特定で、コミッターのメールアドレスがJiraユーザーの中でちょうど1件だけ一致する必要があります。複数ユーザーに一致した場合や権限が足りない場合、スマートコミットは失敗しますが、コミット自体は成功して作業項目に表示されます。失敗時はJiraがメール通知を送るため、気づかないまま進むことは通常ありません。ただし例外が2つあり、通知先のアドレスを特定できない場合と、必須フィールドが設定されている状態で遷移コマンドを使った場合は、公式ドキュメントが「silently fail」と記すとおり無通知で失敗します。
チケットの粒度と状態設計
1チケットを切る単位の判断基準
粒度の基準は、レビューできる単位に揃えることです。実務的には「1人が1日以内で終わり、1本のプルリクエストで説明が完結する」あたりが扱いやすい範囲になります。これより大きいと進捗が「作業中」のまま動かず、小さすぎると起票と棚卸しの手間が実装時間を超えます。
分割の判断で迷ったら、受け入れ基準を書いてみて独立して実装・レビュー・完了判定できる作業が含まれているかを確認してください。含まれていれば、その境界で分割します。GitHubで親子構造にする場合は上限があり、公式ドキュメントは「You can add up to 100 sub-issues per parent issue and create up to eight levels of nested sub-issues.」として、1つの親Issueにつきサブイシュー100件、入れ子は8階層までと定めています。この上限に達した場合は、親Issueが表す範囲と階層構造を見直します。件数だけで分割の適否は判断できません。要件とチケットと成果物の対応関係をどこまで残すかは、ITのトレーサビリティとは？要件から設計・実装・テストを紐付ける実装手順の考え方が判断材料になります。
ステータス設計と棚卸しの頻度
ステータスは増やすほど記入漏れが起きます。開始時の一案は、未着手・作業中・レビュー中・完了の4段階です。Redmineなら、各ステータス間の遷移をロールとトラッカーに応じて設定し、保留や承認待ちを区別する必要が生じたら状態を追加します。レビューで修正が必要になったら「作業中」に戻し、修正後に再び「レビュー中」へ進めます。差し戻し理由はチケットに記録します。
棚卸しは、反復（スプリント）の区切りに合わせて実施します。点検するのは残件数ではなく最終更新日が古い順のチケットです。1か月以上動いていないチケットは、閉じるか、対応しない理由を書いて別の扱いにするかを決めます。この判断を先送りすると、次の反復で同じチケットを再び読み返すコストが発生し続けます。
AIコーディングエージェントによるTiDDの作業委任と実行条件
IssueアサインからPRレビュー依頼までの流れ
チケットが機械可読な作業指示になっていることは、AIコーディングエージェントを入れる前提条件でもあります。GitHubの公式ドキュメントは「You can ask Copilot to start working on an issue by assigning the issue to Copilot. Copilot will start working on the task, raise a pull request, then request a review from you when it’s finished.」と説明しており、Issueの担当者にCopilotを指定すると、作業からプルリクエスト作成、レビュー依頼までが自動で進みます。GitHubは2025年9月25日のchangelogでこのエージェントを全有料Copilot契約者向けに一般提供したと発表し、タスクを委任すると「Copilot will open a draft pull request and work in the background」と説明しています。2026年9月時点でも対象はPro・Pro+・Business・Enterpriseを含む全有料プランです。
担当者指定の画面にはOptional promptの入力欄があり、コーディング規約やテスト要件などの制約をここで補えます。ただし現行ドキュメントはIssueを割り当てる導線について「This feature is in public preview and subject to change.」と注記しているため、この入口を正式な運用手順として固定するのは時期尚早です。
この流れ自体はTiDDの構造を変えません。チケットが起点で、成果物がプルリクエストで、人がレビューして閉じるという順序は同じです。変わるのは実装を書く担当者だけで、チケットの記述品質がそのまま出力品質になる点はむしろ強まります。開発サイクル全体をAI前提で組み替える議論はAI-DLC（AI駆動開発ライフサイクル）とは？仕組み・Bolt・導入事例を解説で扱っています。
CIとリポジトリルールで詰まる箇所
導入時に最初につまずくのがCIです。GitHubの公式ドキュメントは「By default, GitHub Actions workflows will not run automatically when Copilot pushes changes to a pull request.」と述べています。理由も併記されていて、ワークフローが秘密情報にアクセスできる特権を持つためです。既定設定では、プルリクエスト側のGitHub Actionsワークフローを実行するためにApprove and run workflowsによる承認が必要です。エージェント自身の作業環境でのテスト実行とは別の制御です。.github/workflows/配下の変更提案には特に注意するよう促されています。
もう1つはリポジトリのルール設定で、「a rule that only allows specific commit authors can prevent Copilot cloud agent from creating or updating pull requests」とあるように、コミット作成者を限定するルールセットやブランチ保護があるとエージェントの利用自体がブロックされます。コミット作成者を限定している組織では、既存ルールとエージェントの互換性確認が必要になるため、権限設計の見直しが導入作業の中心になります。
チケット駆動開発が機能しない場面
TiDDを入れないほうがよい場面は実在します。第一に、調査やPoCのように着手前に完了条件を書けない作業です。完了条件を書かずに起票すると「調査する」という中身のないチケットが残り、棚卸しのたびに判断を保留する対象が増えます。チケット化するなら、時間枠と確認したい問い、結果の記録先を完了条件として先に書いてください。それを書けないなら起票を見送り、時間枠だけ決めて結果を文書に残すほうが実態に合います。
第二に、1人から2人で短期間に作る試作です。紐づけの設定と起票の手間が、得られる追跡性を上回ります。第三に、No Ticket, No Commitだけを先に強制した場合です。コミット直前に空のチケットを作る運用が定着し、チケットは増えるのに変更理由は書かれないという、導入前より状況が悪い状態になります。ルールを入れる順序としては、チケットに受け入れ基準を書く習慣を先に作り、紐づけの強制は後に回してください。
なお、チケットの数や消化率を個人の評価指標に使うのも避けたほうが無難です。粒度を細かく切るほど数字が伸びるため、台帳が評価対策で歪みます。
よくある質問
チケット駆動開発とJiraの関係は？
JiraはTiDDを実践するためのツールの1つで、手法とツールは別物です。TiDDは2007年ごろのSubversionとTracの環境で生まれた運用手法であり、Jira・Redmine・GitHub Issuesのいずれでも実践できます。Jiraを選ぶ場合は、スマートコミットの3コマンドとワークフロー設定がTiDDの紐づけ部分を担います。
チケット管理のデメリットは？
起票と更新の手間が作業時間に上乗せされること、そして滞留チケットを放置すると台帳が信用できなくなることの2点が主です。粒度を細かくするほど管理コストが増えるため、レビュー単位に揃える判断が必要になります。短期の試作では、起票の手間と追跡の必要性を比べて決めます。調査作業は、時間枠と結果の記録先を完了条件にすれば管理できます。
開発におけるチケットとは？
機能追加・不具合修正・調査依頼などの作業を1件ずつ登録した記録で、担当者・状態・期限・受け入れ基準を持ちます。Redmineではチケット、GitHubではIssue、Jiraでは作業項目と呼ばれますが、指す対象は同じです。サポート窓口の問い合わせ管理も同じ言葉を使うため、目的や閲覧権限を区別し、開発作業との対応関係を残します。
駆動開発とはどういう意味ですか？
開発の進行を何が起動するかを示す呼び方です。テスト駆動開発はテストコードが、振る舞い駆動開発は振る舞いの記述が実装を導きます。チケット駆動開発はチケットが作業の起点になるという意味で、コードの書き方には踏み込まないため、テスト駆動開発と併用できます。
AIエージェントにIssueを任せる場合、チケットの書き方は変わりますか？
変える必要があるのは具体度です。背景・完了条件・触ってよいファイル範囲を本文に書いておくと、担当者指定時のOptional prompt欄で補う量が減ります。加えて、GitHubの既定ではエージェントのプッシュでワークフローが自動実行されないため、レビュー担当がApprove and run workflowsを押す手順を運用に組み込んでおく必要があります。
