AIツールを使い始めてコードを書く速度は上がりました。それにもかかわらず、「ブランチのマージ」や「コンフリクトの解消」に時間を取られ、結局リリースが進まない状態になっていました。
そこで、トランクベース開発とフィーチャーフラグを組み合わせました。今は検証環境へ1日10回以上デプロイしています。
長く残るブランチをやめ、未完成の機能はフラグで隠す
私の開発では、細かくブランチを分けるGitFlowに近い運用をやめました。
未完成の機能もメインラインに取り込み、「フィーチャーフラグ」で画面や機能を隠してデプロイする形です。マージ作業が減り、実際の環境で確認するまでの時間も短くなりました。
コードを書くより、ブランチの管理に時間を取られていた
現在、社内システムの開発を行っています。
最初は「機能ごとにブランチを切って、完成したらマージする」という、GitFlowに近いオーソドックスな運用でうまくいっていました。
しかし、追加機能が増え、並行開発が進むにつれて課題がいくつも出てきました。
「この機能はまだリリースできない」「検証環境の空き待ち」といった理由で、リリース待ちのブランチが乱立。いざマージしようとすると、「何と何をマージしていいのか分からない」「巨大なコンフリクトが発生する」というマージ地獄に陥ってしまった。
さらに拍車をかけたのが、AIによる開発アシストです。
AIを使えば、一気にそれっぽい画面やロジックが実装できます。それなのに、テストやブラッシュアップのたびにブランチを切り、OKが出た分だけ別ブランチとマージする。コードを書く時間以上にGitの管理作業へ時間を奪われるのが非常にストレスでした。
また、チーム内のコードレビューやマージ時のコミュニケーションコストも大きな負担でした。特に経験年数や年齢が高いメンバーからの発言・言い方に対して気を使う場面が多く、そのフォローや発言内容の訂正など、本質的な開発以外の部分でひたすら消耗していました。
未完成の機能をマージするため、フラグで画面を隠した
みんなブランチを切ってマージを頑張るのが当たり前だと思っていましたが、調べていくうちに「フィーチャーフラグ（Feature Flag）」を知りました。
そして、その流れで辿り着いたのが「トランクベース開発」です。
寿命の長いフィーチャーブランチを持たず、細かい単位で頻繁にメインブランチ（トランク）へマージしていく手法です。
最初は「機能が未完成なのにマージして大丈夫なのか？」と直感に反しましたが、それを可能にするのがフィーチャーフラグでした。
コードはマージしますが、ユーザーに見える画面や機能はフラグで制御して隠しておきます。私の場合、自作のフラグ管理テーブルを構築し、機能タブ単位で「見せる・見せない」を制御しています。「特定の権限を持つユーザーのみ」や「全体の何%のユーザーにだけ表示する」といった段階的なリリースも実現しており、これがマージの安全性を担保してくれています。
これにより、マージの頻度を上げつつ、本番や検証環境への影響を分離して開発を進められるようになりました。
検証環境へ1日10回以上デプロイできるようになった
現在は、マイグレーション用の共有ブランチをトランクに見立て、そこにガンガン機能追加をプッシュしています。
導入後、次のように変わりました。
1. プッシュ・マージ回数の増加とレビューの軽量化
チーム内でのプッシュやマージの回数が増えました。
フィーチャーフラグで未完成の機能は制御されているため、壊すことを恐れずに好きなだけコードを弄れます。細かい単位でマージされるため、以前のような巨大なコンフリクトに悩まされることがなくなりました。
さらに、一度の変更量が小さくなったことでコードレビューの負担も減り、前述した人間関係のコミュニケーションコストも和らぎました。
2. DBのスキーマ変更も先行して実施可能に
これまでは、新規テーブルや列の追加は「機能がマージされるタイミング」で合わせて作業する必要があり、コードの状況とDBの要・不要を常に神経質に追わなければなりませんでした。
今は、DBのテーブル追加なども気にせず先に作成してマージしてしまいます。実際に使わなければ後で消せばいい、という身軽さを手に入れました。
3. デプロイの高速化とフィードバックループ
デプロイ作業をコマンド実行できるように整備したこともあり、マージしてテスト・デバッグで問題がなければ即座にデプロイしています。
結果として、検証環境だけで言えば「1日に10回以上」デプロイできるようになりました。実環境で動かして実際に触ってもらえるため、手戻りも少なく、シンプルに開発体験が良くなりました。
次はマイグレーション用ブランチもなくしたい
日に何回もデプロイしたい私には、トランクベース開発とフィーチャーフラグの組み合わせが合っていました。
現在の運用はマイグレーション用ブランチで非常にうまくいっていますが、次なる課題はこれを develop や Main ブランチでも完全に実現することです。
ゆくゆくはマイグレーションブランチ自体を廃止し、develop ブランチに新機能も保守も集約して複数の検証環境へ反映する。Main に取り込んだら本番へデプロイする。そこまで単純にしたいです。
長期ブランチをやめる判断に至った背景と、運用を変えて分かったトレードオフは、なぜトランクベース開発へ移行したのかに続けて書いています。
確認した情報
確認日: 2026年9月26日
- Trunk Based Development: Feature flags：変更の統合と機能の公開を分ける考え方
掲載図は本文の当時の検証環境への運用です。自作テーブル、共有ブランチ、デプロイ頻度は私の体験であり、上の資料の実績ではありません。
コメント