トランクベース開発

状況: 従業員60名のBtoB SaaS企業、エンジニア18名。Gitflow運用でfeatureブランチの平均寿命が12日。マージコンフリクトの解消に週あたりチーム合計15時間を消費。リリースは月1回。

移行ステップ:

1. フィーチャーフラグ基盤（LaunchDarkly）を導入
2. 「ダッシュボード刷新」をフィーチャーフラグ付きで開発
3. 日々のPR: 「新しいグラフコンポーネントの追加」（フラグOFFでmainにマージ）
4. 翌日のPR: 「データ取得APIの追加」（フラグOFFでmainにマージ）
5. 全パーツが揃ったら、フィーチャーフラグをONにして公開

コンフリクト解消に費やす時間、週15時間→0.5時間。ブランチ寿命を12日から0.8日に縮めただけでこの差がつく。リリース頻度も月1回から日次に変わった。

状況: MAU 500万人のWebサービス。エンジニア100名、15チーム。各チームが独自のfeatureブランチを持ち、「インテグレーション地獄」（全チームのブランチをマージする週末作業）が常態化。リリースは隔週。

導入の3段階:

• Phase 1: CIパイプラインを強化（テスト実行時間を45分→8分に短縮）
• Phase 2: フィーチャーフラグ運用ルールを標準化
• Phase 3: 全チームのブランチ寿命を段階的に短縮（2週間→3日→1日）

リリース起因障害、月8件→2.1件。問題検知まで3日→35分。100人規模でもトランクベース開発は機能する——ただしCI/CDの高速化とフィーチャーフラグの標準化が前提。

状況: 従業員35名の地方SIer。受託開発でクライアント向けの業務システムを構築。エンジニア10名がGitflowで運用していたが、develop→main のマージで毎回半日〜1日のコンフリクト解消作業が発生。納品スケジュールが常にギリギリ。

段階的導入:

• まずブランチ寿命を「1週間→3日」に短縮（フィーチャーフラグなし）
• 3日以上かかるタスクは設計段階で分割する習慣を定着
• CI（GitHub Actions）を導入し、PR時の自動テストを必須化

納品遅延率40%→8%。フィーチャーフラグなしでも、ブランチ寿命を短縮するだけでこの改善が得られた。副産物として「タスクを小さく分割する」習慣がチーム全体の設計力を底上げしている。