開発プロセス・方法論

トランクベース開発

（とらんくべーすかいはつ／Trunk-Based Development）

一言でいうと

短命のブランチだけを使い、主幹へ頻繁に統合し続けるブランチ戦略です。自動テストが整っていない状態では成立しません。

実践自体は継続的インテグレーションの初期から存在しますが、この名前で体系的に整理されたのは2010年代後半です。解説サイトが公開され、Martin Fowlerも継続的インテグレーションの記事の中で、この実践がトランクベース開発と呼ばれる場合があることに触れています。

国内の求人票で明示する企業はいまも多くありません。ブランチ戦略の名前として、GitFlowとの対比で語られることが多い語です。

統合の衝突そのものはCI/CDのページで扱っています。この戦略に固有なのは、衝突を減らす手段として分岐の寿命だけに賭ける点です。解決の作業自体が新しい欠陥を生むため、衝突を上手に解くより、起こさない側に寄せます。

1日から数日で主幹（開発の中心になる1本のブランチ）に統合する運用を前提に置きます。分岐が短ければ、他の変更との差が育つ前に解消できます。

作業単位を小さく分け、短命のブランチで作業して主幹へ統合します。未完成の機能を含んだまま統合する場合は、機能フラグで実行時に切り替えられるようにします。

主幹は常に動く状態を保ちます。統合のたびに自動テストが走る仕組みが前提で、これがない状態でこの戦略を採ると、主幹が壊れたまま気づかれない時間が生まれます。

CI/CDの整備が一定の水準にあることを示します。ブランチ戦略を明示している求人は、開発の進め方を設計している組織である可能性が高くなります。

この語を経歴に書く候補者はまだ少なく、要件に入れると対象が消えます。

自社側では、主幹へ統合するまでの平均的な期間を確認します。1日から3日を前提に置く戦略なので、1週間を超えているなら名前だけの運用です。候補者には、未完成の機能をどう扱っていたかを聞きます。機能フラグの管理そのものは人事では良し悪しを判断できないため、現場が同席する場の質問にしてください。