Jira

「担当者が曖昧で同じ修正が二重に走った」「変更の経緯が追えず、なぜこのコードになったか誰も説明できない」――ソフトウェア開発の現場でよく聞く悩みです。こうした課題を仕組みで解消するアプローチが、チケット駆動開発（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人日です。これより大きいと進捗が見えにくくなり、細かすぎるとチケット管理自体がオーバーヘッドになります。 チケットには以下の情報を含めます。 項目 記載内容の例 タイトル 「ログイン画面にバリデーション追加」のように動作を明示 説明 完了条件（Acceptance Criteria）を箇条書きで記述 優先度 High / Medium / Low 担当者 実装者を明確に指定 見積もり ストーリーポイントまたは時間 マイルストーン 紐づくリリースバージョンやスプリント ステップ2：チケットを着手する 担当者はチケットのステータスを「進行中」に変更してから作業を開始します。作業前のステータス変更が重要で、チーム全体にリアルタイムで「誰が何に取り組んでいるか」が可視化されます。 ステップ3：コードを変更しコミットする 実装が完了したら、コミットメッセージにチケット番号を記載してバージョン管理システムにプッシュします。多くのBTS/ITSはコミットフックやWebhookで連携でき、コミットメッセージからチケットへの自動リンクが可能です。 git commit -m "refs #1234 ログインバリデーションを追加" ステップ4：レビュー・テストを経てチケットをクローズする プルリクエストのレビューとテストが完了したら、チケットのステータスを「完了」に変更します。この時点でチケットのライフサイクルが終了し、作業実績として記録に残ります。 メリットとデメリット TiDDの利点 作業の可視化とトレーサビリティ チケットボードを見れば、未着手・進行中・完了の件数が一目で把握できます。「コードの変更理由」がチケット経由でいつでも辿れるため、半年後に別の担当者が修正する際にも背景情報を確認できます。 属人化の防止 口頭での依頼や個人のメモ帳による管理と異なり、チケットはチーム全員がアクセスできる共有情報です。担当者が休暇や異動で不在になっても、チケットの内容を見れば作業を引き継げます。 データに基づく改善 チケットの完了数・リードタイム・バグ発生率などのメトリクスを蓄積すると、チームのベロシティ把握やプロセス改善に活用できます。 変更管理への対応力 仕様変更や追加要望が発生した場合、新しいチケットとして登録するだけで管理対象に組み込めます。Excel管理のように「どのシートのどの行を更新すべきか」で迷う必要がありません。 ...