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