チケット駆動開発（TiDD）とは？基本原則から現代の運用・AI活用まで徹底解説

「担当者が曖昧で同じ修正が二重に走った」「変更の経緯が追えず、なぜこのコードになったか誰も説明できない」――ソフトウェア開発の現場でよく聞く悩みです。こうした課題を仕組みで解消するアプローチが、チケット駆動開発（TiDD: Ticket-Driven Development） です。

チケット駆動開発は、すべての作業を「チケット」として登録し、チケット単位で進捗を管理する開発手法です。2007年頃に日本の開発コミュニティから生まれ、アジャイルにもウォーターフォールにも適用できる柔軟さから、国内外のチームに広く浸透しました。

近年は「チケット駆動開発は古い」という声も聞かれますが、AIコーディングエージェントの台頭により「チケット＝プロンプト」として再評価される動きもあります。基本原則から現代の運用テクニックまで、実務で役立つ知識を体系的に整理しました。

チケット駆動開発の定義と歴史

チケット駆動開発（TiDD）は、ソフトウェア開発におけるすべてのタスク・不具合・改善要望をBTS/ITS（バグ管理システム／課題管理システム）のチケットとして登録し、チケット単位で作業を進める開発スタイルです。

誕生の背景

TiDDは2007年頃、国内のオープンソース開発コミュニティで提唱されました。Redmine や Trac といったオープンソースのBTSが普及し始めた時期に、バグ管理だけでなく開発タスク全般をチケットで管理する実践が自然発生的に広がったのが起源です。2008年のKOF（関西オープンフォーラム）での発表を皮切りに、国内のアジャイル開発コミュニティで体系化が進みました。

2012年には小川明彦氏・阪井誠氏の共著『チケット駆動開発』（翔泳社）が出版され、手法としての理論的基盤が確立されています。

基本ルール：No Ticket, No Commit!

TiDDを支える最も重要な原則が 「No Ticket, No Commit!」 です。チケットに紐づかないコード変更を一切許容しないというルールであり、コミットメッセージには必ずチケット番号を含めます。

このルールにより、「いつ・誰が・なぜ・何を変更したか」というトレーサビリティが自動的に確保されます。バージョン管理システムのコミットログとチケットの相互参照が可能になるため、後から変更理由を追跡する工数が大幅に減ります。

チケット駆動開発の基本フロー

TiDDの開発サイクルは、以下の4ステップで構成されます。

ステップ1：要件をチケットに分割する

プロジェクトの要件やユーザーストーリーを、実装可能な粒度のタスクに分解し、それぞれをチケットとして登録します。TiDD提唱者が推奨する粒度は1〜5人日です。これより大きいと進捗が見えにくくなり、細かすぎるとチケット管理自体がオーバーヘッドになります。

チケットには以下の情報を含めます。

ステップ2：チケットを着手する

担当者はチケットのステータスを「進行中」に変更してから作業を開始します。作業前のステータス変更が重要で、チーム全体にリアルタイムで「誰が何に取り組んでいるか」が可視化されます。

ステップ3：コードを変更しコミットする

実装が完了したら、コミットメッセージにチケット番号を記載してバージョン管理システムにプッシュします。多くのBTS/ITSはコミットフックやWebhookで連携でき、コミットメッセージからチケットへの自動リンクが可能です。

git commit -m "refs #1234 ログインバリデーションを追加"

ステップ4：レビュー・テストを経てチケットをクローズする

プルリクエストのレビューとテストが完了したら、チケットのステータスを「完了」に変更します。この時点でチケットのライフサイクルが終了し、作業実績として記録に残ります。

メリットとデメリット

TiDDの利点

作業の可視化とトレーサビリティ チケットボードを見れば、未着手・進行中・完了の件数が一目で把握できます。「コードの変更理由」がチケット経由でいつでも辿れるため、半年後に別の担当者が修正する際にも背景情報を確認できます。

属人化の防止 口頭での依頼や個人のメモ帳による管理と異なり、チケットはチーム全員がアクセスできる共有情報です。担当者が休暇や異動で不在になっても、チケットの内容を見れば作業を引き継げます。

データに基づく改善 チケットの完了数・リードタイム・バグ発生率などのメトリクスを蓄積すると、チームのベロシティ把握やプロセス改善に活用できます。

変更管理への対応力 仕様変更や追加要望が発生した場合、新しいチケットとして登録するだけで管理対象に組み込めます。Excel管理のように「どのシートのどの行を更新すべきか」で迷う必要がありません。

TiDDの課題と注意点

運用コストの発生 チケットの起票・ステータス更新・クローズの手間が一定量発生します。小規模チーム（2〜3人）で短期の開発を行う場合、管理工数が開発工数を圧迫するケースがあります。

マイクロマネジメント化のリスク 管理者がWBS（Work Breakdown Structure）の全項目をチケットとして事前に切り出し、開発者に割り当てるだけの運用になると、TiDDは「監視ツール」と化します。TiDD提唱者の一人であるakipii氏も、2025年のnote記事で「チケット駆動開発がマイクロマネジメントのツールになってしまっている」現場の問題を指摘しています。本来は開発者自身がタスクを分解・登録することで、自律的な開発リズムを生むのがTiDDの趣旨です。

チケットの形骸化 「とりあえず起票するが、更新されない」「完了してもクローズされない」状態が続くと、チケットボードの信頼性が失われます。定期的なチケット棚卸し（後述）が欠かせません。

スケーリングの困難さ 少人数チームで始まったTiDDの運用ルールを、数十〜百名規模の組織にそのまま適用すると、チケット数の爆発的増加により管理が破綻しやすくなります。大規模な場合はLeSS・SAFeなどのスケーリングフレームワークと組み合わせるか、「Redmineポリス」のような運用管理者を設ける必要があります。

主要ツールの機能比較

TiDDに利用できるITS/プロジェクト管理ツールを比較します。

選定のポイント:

• 既にGitHubを使っている: GitHub Issues + GitHub Projects が最もシームレス。Issues機能はパブリック・プライベートリポジトリともに無料で利用でき、コミットとのリンクが自然に行えます。保護ブランチやコードオーナーなどの高度な機能が必要な場合はTeamプラン（$4/user/月）を検討します
• 日本語での運用を重視する: Backlog は日本製のため、UIからサポートまですべて日本語で完結します
• 大規模チームでアジャイルを実践する: Jira はスクラムボード・ベロシティチャート・バーンダウンチャートなど、アジャイルメトリクスの計測機能が充実しています
• セルフホストでコスト最小化: Redmine はOSSで無料。社内サーバに構築すれば外部サービスへのデータ送信を避けられます

アジャイル・ウォーターフォールとの連携パターン

TiDDは特定の開発プロセスに依存しない手法のため、アジャイルにもウォーターフォールにも組み合わせが可能です。

スクラムとの併用

スクラムでは、スプリントバックログのアイテムをチケットとして管理します。

スプリント完了時に未完了チケットを次スプリントへ繰り越す運用ルールを設けておくと、残作業の管理が明確になります。

カンバンとの併用

カンバン方式では、チケットをカンバンボード上のレーン（ToDo → In Progress → Review → Done）で管理します。WIP（Work In Progress）制限を設けて同時進行チケット数を抑えることで、マルチタスクによる効率低下を防ぎます。

ウォーターフォールでの活用

ウォーターフォール型のプロジェクトでも、各工程（要件定義・設計・実装・テスト）のタスクをチケットとして管理できます。ガントチャートとチケットを連動させれば、Excelで管理していた進捗表をITS上に統合でき、情報の一元化が実現します。

TiDD提唱者は、ウォーターフォールとアジャイルの中間に位置する「適応型ウォーターフォール」という概念も提唱しており、TiDDを導入することで硬直的なWF型開発にも段階的な改善サイクルを組み込めるとしています。

「チケット駆動開発は古い」のか？現代における再評価

「チケット駆動開発 古い」というキーワードで検索する人は少なくありません。2007年の提唱から約19年が経過し、ツールや開発スタイルが大きく変化したことがその背景にあります。

「古い」と感じられる理由

• Redmine / Tracの時代感: TiDDの初期はRedmineやTracが主流だったため、これらのUIイメージと結びつきやすい
• チケット起票の手間: 現代のチャットベース開発（Slack/Teamsでの口頭合意）と比べると、チケット起票が「重い」と感じられる
• AIコーディングの台頭: GitHub CopilotやCursorなどのAIツールが実装を高速化する中、チケット管理の工程が相対的にボトルネックに見える

AI時代の新しい価値：Ticket = Prompt

しかし、AIコーディングエージェントの普及により、チケット駆動開発の価値は再定義されつつあります。

2025年にUbie社のPHRチームが実践した事例では、Jiraチケットの内容をそのままAIエージェント（Cursor + MCP連携）へのプロンプトとして活用し、人間がコードを書かずにAPIを開発・リリースしました。この「Ticket = Prompt」というアプローチでは、従来TiDDが重視してきた「完了条件を明確に記述したチケット」が、AIへの的確な指示書としてそのまま機能します。

チケットに以下の情報が整理されていれば、AIエージェントは高い精度でコードを生成できます。

• 実装対象のエンドポイント仕様（入出力の型定義）
• 前提となるドメインモデルの構造
• テストケースの期待値
• 既存コードベースとの整合性に関する制約

TiDDの「チケットを丁寧に書く」という習慣は、AI時代においてむしろ開発速度を加速させる基盤になっています。

CI/CDとの自動化連携

現代のTiDDでは、チケット管理ツールとCI/CDパイプラインの連携が容易になりました。

• GitHub Issues + GitHub Actions: チケットのラベル変更をトリガーにワークフローを起動
• Jira + Bitbucket Pipelines: チケットステータスの自動遷移（PRマージ → チケットクローズ）
• Backlog + Webhook: チケット更新をSlackやTeamsに自動通知

手動でステータスを更新する手間が自動化により大幅に削減され、「運用コストが高い」という従来のデメリットが軽減されています。

導入を成功させる実践パターンとアンチパターン

成功パターン

小規模なパイロットプロジェクトで始める 全社一斉導入ではなく、5人以下のチームで1つのプロジェクトから試行します。運用ルールの策定・修正サイクルを短く回し、自チームに合ったテンプレートやワークフローを確立してから横展開します。

チケット棚卸しを定期実施する 週1回または隔週で、全チケットの状態を確認する棚卸しミーティングを設けます。長期間更新のないチケットは「保留」「氷漬け（Icebox）」ステータスに移動するか、不要なら削除します。チケットボードの信頼性を維持するための最も効果的な施策です。

チケットのテンプレートを整備する バグ報告・機能追加・技術的負債など、種別ごとにテンプレートを用意します。起票者が記入すべき情報（再現手順、期待結果、完了条件など）を明示することで、チケットの品質を一定水準に保てます。

ペア作業でチケット品質を向上させる チケットのコメント欄を使って、コードの書き手と読み手が役割を交代しながら品質を高める手法です。たとえば、実装者がプルリクエストを提出し、レビュアーが指摘事項をチケットに記録、実装者が修正して再レビューを依頼する――この一連のやり取りがチケット上に蓄積されるため、第三者が後から経緯を把握しやすくなります。

よくあるアンチパターン

まとめ

チケット駆動開発（TiDD）は、「No Ticket, No Commit!」を原則に、すべての作業をチケットで管理するシンプルかつ強力な開発手法です。2007年に日本で提唱されて以降、アジャイル・ウォーターフォール問わず幅広い現場で活用されてきました。

主なポイントを整理します。

• 基本フロー: 要件分割 → チケット起票 → 実装・コミット → レビュー・クローズの4ステップ
• ツール選定: GitHub Issues・Jira・Redmine・Backlog・Linearなど、チーム規模と既存環境に合わせて選択
• アジャイルとの親和性: スクラムのスプリントバックログ、カンバンのWIP制限とシームレスに統合可能
• AI時代の新価値: 詳細に記述されたチケットはAIコーディングエージェントへの指示書（プロンプト）として直接活用でき、開発速度を加速させる
• 失敗を防ぐ鍵: 定期棚卸し・テンプレート整備・粒度統一の3点を守ることで形骸化を回避

「チケット駆動開発は古い」という声がある一方で、CI/CDパイプラインとの自動連携やAIエージェントとの組み合わせにより、その実用的価値はむしろ高まっています。まずは小規模なプロジェクトで「No Ticket, No Commit!」を試してみることが、チーム改善の第一歩になるはずです。