複数人で複数の機能を並行開発していると、どうしてもブランチが乱立する。
本来であれば、親となるブランチ（develop等）から定期的に差分をPullして同期を取りながら進めればいいだけの話だ。しかし、現実のプロジェクトではメンバー間で同期を忘れることが多々ある。結果として差分が肥大化し、いざ合流させようとした時に凄まじいコンフリクトが発生する。
コンフリクトの解消だけで丸1日潰れてしまった経験はないだろうか。
我々のチームでもこの問題に直面した。「いち早く機能を提供してスピードを上げる」ことを課題の1つに掲げているにも関わらず、単なるマージ作業に1日を使うのはあまりにもったいない。さらに、管理側としても複数に散らばったブランチの進捗をいちいち確認して回るのは手間になってきていた。
そこで行き着いた結論がトランクベース開発（Trunk-Based Development）への移行だ。
「常に最新の状態が合流しているブランチが、最も検証されている正しい状態である」のだから、全員でそれ（トランク）を直接触るのが一番理にかなっている。
（図：従来の「完成するまでマージしない」運用と異なり、トランクベース開発では未完成でも小刻みにマージして差分を小さく保つ）
移行を支えた「3つの現実的な割り切り」
とはいえ、未完成のコードをガンガン共有ブランチに流し込めば、通常はカオスになる。
我々のチームでは、これを実現するために以下の3つの「割り切り」と「工夫」を行っている。
1. 自作テーブルによる「機能タブ単位」のフラグ管理
未完成の機能を本番や検証環境から隠すため、フィーチャーフラグ（機能フラグ）を導入した。
私の場合、自作のフラグ管理テーブルを構築し、細かなロジックの分岐ではなく「機能タブ単位」といった大きめの粒度で「見せる・見せない」を制御している。
これならコードが無闇に複雑化することもなく、「特定の権限を持つユーザーのみ」といった段階的リリースも容易になり、未完成コードをマージする安全性が担保される。
※フィーチャーフラグの具体的な運用術については、別記事（AI開発のスピードを止めない。フィーチャーフラグの実践的な運用術）で詳しく解説している。
2. DBスキーマ変更の「先行マージ」
これまでは、新規テーブルや列の追加は「機能がマージされるタイミング」に合わせる必要があり、コードの状況とDBの要・不要を常に神経質に追わなければならなかった。
今は、DBのテーブル追加なども気にせず、先に作成してトランクへマージしてしまっている。
「実際に使わなければ後で消せばいい」という身軽さを手に入れたことで、DBのバージョン管理で悩む不毛な時間が消滅した。
3. 非同期の「細かいコードレビュー」の廃止
短いサイクルで頻繁にマージを行うため、従来のような「PRを出して、非同期で他の人がレビューして、承認されてからマージ」というフローを真面目にやると、レビュー待ちの渋滞が起きて開発が完全にストップする。
また、年齢や経験年数が異なるメンバー間での非同期レビューは、言い方や指摘のニュアンスに気を遣う「コミュニケーションコスト」が非常に高かった。
我々はこの問題を「非同期での細かいレビューを捨てる」ことで解決した。
代わりに、機能が出来上がったタイミングで作成者に直接デモをしてもらい、動作と仕様を確認するフローに切り替えることで、人間関係の摩擦を減らしつつスピードを維持している。
AI時代における「人間」のボトルネック化を防ぐ
なぜここまでしてトランクベース開発に振り切り、開発効率を優先するのか。
最大の理由は、AIを活用することで、コードや機能を作成するスピードがかつてないほどに上がっているからだ。
AIが爆速でコードを吐き出しているのに、ブランチのマージ作業、コンフリクトの解消、DBのバージョンのすり合わせ、そして非同期のコードレビューといった「人間の手作業や確認プロセス」がボトルネックになっていては意味がない。
迅速に機能をユーザーに届けるためには、人間がボトルネックになる部分を極限まで少なくし、管理コストを減らす必要がある。全員が同じブランチを向いていれば、「どのDBのバージョンが今正しいのか」といった不毛な確認作業も消滅する。
おわりに
もちろん、この運用を続けていけば別の問題が出てくるだろう。
しかし、その時はその時に対応を考えればいい。今は何よりも「開発効率」と「提供スピード」を優先している。
きれいなブランチ戦略や緻密なレビュープロセスを守るために1日を無駄にするくらいなら、少しコードが汚くなろうが、全員で一本の太いトランクにマージし続ける泥臭い開発の方が、今の時代には合っていると感じている。
コメント