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