アジャイル

リリース直前にバグが大量発覚し、修正に追われる。仕様変更のたびにデグレードが発生し、影響範囲の調査だけで何時間も消える。こうした問題の根本原因は、コードの正しさを継続的に保証する仕組みが欠けている点にあります。 テスト駆動開発（TDD: Test-Driven Development）は、まずテストを書き、そのテストを通す実装を後から追加する開発手法です。Kent Beckが2002年の著書『Test-Driven Development: By Example』で体系化しました。単なる「テストを先に書く」技法ではなく、テストを軸にソフトウェアの設計を段階的に育てる開発プロセス全体を指します。 テスト駆動開発（TDD）の定義 ─ 通常のテストとの根本的な違い 一般的なソフトウェア開発では、実装を完了した後にテストを書きます。TDDはこの順序を逆転させ、実装前にテストを書くことで、コードの品質と設計を同時に改善します。 通常のテストが「すでに書いたコードが動くか確認する行為」であるのに対し、TDDのテストは「これから書くコードがどう振る舞うべきか定義する行為」です。この違いにより、TDDでは次の効果が生まれます。 コードを書く前に仕様が明確になる テストが常に存在するため、変更時の安全網として機能する テスト可能な設計を自然と選択するようになる Red-Green-Refactorの3ステップ ─ コード例で理解するTDDサイクル TDDの中核は、Red → Green → Refactorの3ステップを繰り返すサイクルです。1サイクルは数分から十数分が目安で、短く回すほど手戻りが少なくなります。 Step 1: Red ─ 失敗するテストから始める 実装したい振る舞いをテストコードとして記述します。この時点では対応する実装がないため、テストは必ず失敗（Red）します。 Python（pytest）の場合： # test_tax.py from tax_calculator import calculate_tax_inclusive def test_税込価格を正しく計算できる(): assert calculate_tax_inclusive(1000, 0.10) == 1100 TypeScript（Vitest）の場合： // tax.test.ts import { calculateTaxInclusive } from './taxCalculator'; test('税込価格を正しく計算できる', () => { expect(calculateTaxInclusive(1000, 0.10)).toBe(1100); }); この段階ではモジュール自体が存在しないため、インポートエラーでテストが失敗します。これが正常な状態です。 Step 2: Green ─ テストをパスする最小コードを書く テストを通すために必要な最小限の実装を書きます。コードの美しさや効率は気にせず、テストが通ることだけに集中します。 Python： # tax_calculator.py def calculate_tax_inclusive(price: int, tax_rate: float) -> int: return int(price * (1 + tax_rate)) TypeScript： // taxCalculator.ts export function calculateTaxInclusive(price: number, taxRate: number): number { return Math.floor(price * (1 + taxRate)); } テストを実行すると、Green（成功）に変わります。 Step 3: Refactor ─ テストを維持しながらコードを改善する テストがGreenの状態を保ちながら、コードの重複排除、命名の改善、構造の整理を行います。テストが通り続ける限り、リファクタリングは安全です。 ...

「担当者が曖昧で同じ修正が二重に走った」「変更の経緯が追えず、なぜこのコードになったか誰も説明できない」――ソフトウェア開発の現場でよく聞く悩みです。こうした課題を仕組みで解消するアプローチが、チケット駆動開発（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管理のように「どのシートのどの行を更新すべきか」で迷う必要がありません。 ...