トランクベース開発とは何か：mainに毎日コミットする手法
要約
全員がmainに毎日コミットし、長期ブランチを持たない。フィーチャーフラグで未完成の機能をユーザーから隠し、コードベースを常にリリース可能な状態に保つ開発手法。Googleは35,000人の開発者でこれを実践しており、2021年DORAレポートでもエリートチームとの相関が確認されている。
トランクベース開発とは、チーム全員が「トランク」と呼ばれる単一の共有ブランチ（通常はmain）に、少なくとも1日1回コードをコミットする開発手法だ。長期的なフィーチャーブランチは存在しない。「hotfix-v2-backup-final」が3週間も放置されることもない。短命なブランチは数時間で生まれて消え、コードベースは常にリリース可能な状態を保つ。Googleは35,000人もの開発者をこの手法で動かしている。仕組みと使いどころ、そして向かない場面を順番に解説する。
「final_v2_FINAL_これを使え.xlsx」問題 -- コード版
共有フォルダを開いたとき、report_v1.xlsx、report_v2_FINAL.xlsx、そしてreport_USE_THIS_ONE_greg_edits.xlsxが並んでいた経験はないだろうか。それがまさに、トランクベース開発が解決しようとしている問題だ。
コードベースでも同じことが起きる。あるチームメンバーが第1週にフィーチャーブランチを切る。他のメンバーはmainに向けて出荷し続ける。3週間後、そのブランチはmainから数十コミット遅れている。マージは週末プロジェクトと化し、誰も喜んで担当しない。コンフリクトが積み重なる。コードを書いた本人ですら、なぜその半分が存在するのかを忘れている。これが「マージ地獄」だ。
最も広く教えられる代替手法であるGitflowは、フィーチャー、リリース、ホットフィックスに分かれた正式な構造でこの問題を解こうとする。紙の上では整然として見える。現実には、ブランチは共有ドライブのスプレッドシートと同じように増殖し、「インテグレーションデー」は「インテグレーション週間」になる。
トランクベース開発はその逆の立場を取る。インテグレーションの負債を積み上げるのをやめて、今日mainにコミットするのだ。
全員がmainにコミット。毎日。それがすべてのモデルだ
核心的なルールはシンプルだ。全開発者が少なくとも24時間ごとに共有トランクに変更をプッシュする。「まだ終わっていないから」という例外はない。今ある状態をコミットし、それがビルドを壊さないことを確認する。
これは恐ろしく聞こえるかもしれないが、安全にする仕組みが存在する。
短命なブランチ：ブランチを使うことはできる。ただし、数時間で完結させる。2日以上生き続けるブランチは調査すべき警告サインだ。
コミットごとの自動テスト：CIパイプラインが即座にテストスイートを実行する。何かが壊れても、スプリント終了時ではなく数分以内に分かる。
フィーチャーフラグ：未完成の機能はトグルの裏に隠れたまま、リリース準備が整うまでユーザーには見えない。本番コードに入っていても、だ。
その結果は「常にリリース可能なコードベース」だ。「フィーチャーブランチをマージしてQAを1週間回してからリリース可能」ではなく、必要があれば今すぐリリースできる状態。それがこの手法の根本的な約束だ。
短命なブランチは時間で測る -- 週単位ではなく、時間単位で
トランクベース開発では、ブランチを使うことが禁止されているわけではない。長期ブランチが禁止されているのだ。
朝9時に開いて午前中作業し、昼食後にコードレビューを受け、夕方5時前にmainへマージするブランチ。それが理想的な形だ。チームメートがレビューできるほどの大きさで、1回読めば内容が把握できる。コンフリクトがあっても数分で解決できる。
一方、1人の開発者が認証システム全体を3週間かけて孤独に構築するようなブランチは問題だ。マージの時が来ると、チームはコンフリクトの解決に機能の構築より長い時間を費やすことになる。
多くのTBDチームが実用的な閾値として使うのは2日間だ。2日以内にマージされなければ、何かを変える必要がある。フィーチャーが大きすぎるので分割するか、部分的な作業を安全に届けるためにフィーチャーフラグを使うかのどちらかだ。
仕事を小さな単位に分解することが、トランクベース開発が実際に鍛える核心的な規律だ。「ダッシュボード全体を構築する」ではなく、「データレイヤーを追加する」「最初のグラフを追加する」「フィルターを配線する」という順番でトランクへ届ける。各ピースは独立してテストされ、リリースされる。完全な機能は複数のコミットにわたって段階的に現れる。
これは遅く聞こえるかもしれない。実際には速い。なぜなら、コンテキストがまだ新鮮で表面積がまだ小さいうちに問題を見つけるからだ。
フィーチャーフラグ：未完成のまま本番に届けるための仕組み
フィーチャーフラグ（フィーチャートグルとも呼ばれる）は、1つの短命ブランチで機能を完成できない場合にトランクベース開発を実用的にする仕組みだ。
考え方はシンプルだ。新しい機能を、特定のフラグがオンのときだけ動作する条件分岐でラップする。
if (featureFlags.newReportingDashboard) {
renderNewDashboard();
} else {
renderOldDashboard();
}新しいコードは本番にデプロイされる。ただし、トグルを切り替えるまでユーザーには実行されない。つまり：
開発者は誰にも影響を与えずに作業中のコードをトランクにコミットできる
QAは特定のユーザーや環境でフラグを有効にして本番でテストできる
リリースはデプロイイベントではなく設定変更になる
何か壊れても、ロールバックやホットフィックスブランチなしにフラグをオフにすればいい
フィーチャーフラグのインフラは、起動時にチェックするシンプルな環境変数から、専用のフィーチャーフラグプラットフォームまで多様だ。始めたばかりのチームなら、設定ファイルや環境変数で十分だ。重要なのはツールの複雑さではなく、この機能を持つことだ。
トランクベース開発が向かない場面
直接言っておく価値がある。トランクベース開発は普遍的に優れているわけではない。特定のコンテキストに合う手法だ。
CI/CDパイプラインが整っていない場合はスキップ。コミットごとの自動テストなしのTBDは、ブランチ戦略ではなく、急速に問題が積み上がるコードベースだ。テストインフラが整ってから初めてブランチモデルが機能する。
チームが本質的に頻繁にコミットできない場合。タイムゾーンをまたいで非同期で働く分散チームや、散発的なバッチで提出するオープンソースプロジェクトは、毎日のコミットリズムに苦労するだろう。
必須のリリースウィンドウがある規制環境の場合。一部の業界では外部の承認、長いQAサイクル、リリースブランチ単位の正式な監査証跡が必要だ。Gitflowの構造化されたリリースブランチはそのようなワークフローに合う。
チームの規律がまだ整っていない場合。TBDでは、mainへのすべてのコミットがテストを通過するか、失敗したら即座に修正されることが前提だ。チームが壊れたビルドを許容するなら、共有トランクは全員の共有問題になる。
Gitflowは、四半期リリーススケジュールのチーム、別々のスクワッドが複数の並行フィーチャーを開発する状況、またはブランチレベルの分離が必要なコンプライアンス要件がある場合には合理的な選択だ。問題はどちらが原則として勝るかではなく、どちらが正直に合っているかだ。
GitflowからTBDへの移行：混乱なしに進む方法
チームがGitflowを使っていてTBDを試したい場合、移行はハードカットオーバーである必要はない。
最初に行うのは、新しい長期ブランチの作成を停止することだ。決定後に始まるフィーチャーは短命なブランチを使う。すでに長期ブランチで進行中のフィーチャーは旧モデルで完成させる。2つのアプローチが一時的に共存する。
未完成の作業をトランクにコミットする前に、フィーチャーフラグを整備する必要がある。基本的なフィーチャーフラグシステムを設定することが、他のすべての前提条件だ。それなしでは、TBDは未完成のUIを本番ユーザーに届けることを意味する。
次に、mainブランチにCIを強制適用する。自動テストがすべてのプッシュで実行され、失敗したテストはマージをブロックし、通過しなければマージできない。これは交渉できない部分だ。
最後に、2日ルールを明示的に定義する。2日以上古いブランチは、どうするかについての会話のきっかけとなる。フィーチャーを小さく分割するか、フラグを追加するか、すでに完成している部分をリリースするかを決める。プルリクエストのプロセスでこれを可視化させる。
多くのチームが直面する不快な調整点がある。「部分的に完成している」状態をコミットとして有効だと認めることだ。ただし、フラグの裏に隠れていて既存のテストを壊していないことが前提だ。
DORAレポートが示す開発速度の実態
DevOps Research and Assessment（DORA）レポートは、ソフトウェア開発チームのプラクティスに関する最も大規模な実証的研究に近いものだ。2021年のDORAレポートによると、エリート級のパフォーマンスチームは下位パフォーマーと比べて、トランクベース開発を採用している可能性が2.3倍高い。
DORAフレームワークのエリートパフォーマーは1日に複数回デプロイし、コミットから本番までのリードタイムは週単位ではなく時間単位で測られる。TBDはそうした成果と一貫して相関している。
重要な注意点がある。相関は因果ではない。高パフォーマーチームがTBDを採用するのは、すでに根底にある規律に投資してきたからだ。自動テスト、堅固なCI/CDインフラ、小さく焦点を絞った変更を書くエンジニア。それらの基盤が先にある。TBDはそのコンテキストに合うブランチモデルであって、それを生み出すものではない。
Biscuitはこれをすぐに理解する。優れたレトリーバーは3つのボールを同時に運ぼうとしない。1コミット、1レビュー、1マージ。Good boy。
TBDに切り替える価値はあるか
チームがスプリントのかなりの時間をマージコンフリクトに費やし、「フィーチャーブランチが準備できていないから」という理由でリリースを遅延させ、誰も何のために存在するか覚えていないほど古いブランチを抱えているなら、トランクベース開発は真剣に評価する価値がある。
毎日のコミットリズムは要求が高い。フィーチャーフラグのインフラはセットアップが必要だ。文化的なシフトには数週間かかる。しかし結果は本物だ。常にリリース可能なコードベース、ファイル単位ではなく行単位で測られるマージコンフリクト、危機ではなく日常業務としてのリリース。それはチームの働き方における意味のある改善だ。
小さく始めよう。1チーム、1スプリント、すべてのプッシュで動くCI、フィーチャーフラグの整備。4週間で何が変わるか確かめてみよう。