初めてのアジャイル開発で、Gitブランチ戦略を改善した話

はじめに

こんにちは！
jinjerプロダクト開発部SEの関根です。
2025年の3月に入社し、ジンジャー人事評価のバックエンドエンジニアを担当しています。

今回は私が初めてアジャイル開発をやってみて気づいた課題と、どう改善をしていったかをお話ししたいと思います！

なぜ今、ブランチ戦略を見直す必要があったのか

開発規模が拡大し、複数のリリースサイクルが並行するようになると、標準的なGit-flowだけでは運用の維持が少しずつ難しくなってくる場面があります。

私たちのチームでも、以前はプルリクエストの差分が不必要に増えてしまったり、競合が発生するたびに作業ブランチを切り直したりといった「地味に面倒な作業」が頻発していました。

本記事では、こうした日々の開発のストレスを減らし、運用の透明性を高めるために導入した 「sprintブランチ」 と 「開発環境の増設」 について紹介します。

なお、本記事の運用は、以下のような規模感のチームで特に効果を感じています。

• チーム構成：バックエンド 4名程度 / フロントエンド 4名程度
• 開発体制：2スプリント以上の並行開発が発生
• リリース頻度：月2回程度

以前の運用における課題

これまでは staging ブランチを起点に feature ブランチを作成し、検証後に staging へ戻す運用を行っていました。しかし、並行開発が増えるにつれ、以下のような問題が顕在化しました。

• リリース対象管理の複雑化
  staging に「次のスプリントで出すもの」と「その先に向けた検証」が混ざり、リリース直前に不要なコミットを revert したり、必要なものだけを cherry-pick したりする手作業が発生していました。
• 頻発するコンフリクト
  中長期案件の大きな修正が短期の修正と干渉し、作業ブランチを頻繁に作り直す必要がありました。
• 作業精度の低下
  複雑なマージや cherry-pick はヒューマンエラーを誘発しやすく、デグレードを引き起こす要因となっていました。

改善後のブランチ構成と役割

これらの問題を解決するため、ブランチの役割を「リリース時期」と「検証の目的」に基づいて再定義しました。

主要ブランチの役割

• master: 本番環境。リリース済みコードを管理。
• staging: 本番直前の検証用。リリース確定分のみを反映。
• sprintXX: リリース対象ブランチ。そのスプリントでリリースするものだけを格納。
• develop: スプリント内の機能確認用。
• develop2 (追加の開発環境): 中長期開発・実験用。メインの検証フローから切り離した隔離環境。

開発フローの使い分け

スプリント内に収まる短期開発は sprintXX を基点とし、スプリントをまたぐ中長期開発は master から専用の機能ブランチを切り、検証には増設した 「もう一つの開発環境（develop2）」 を使用するルールを徹底しました。

改善後のブランチ運用イメージ

これにより、リリース間近のブランチを汚すことなく、並行して安全に開発を進めることが可能になりました。

コンフリクトの減少と、チームによる解消プロセス

今回の変更後、メンバーの体感として最も効果があったのは 「コンフリクトの頻度が大幅に減ったこと」 です。

コンフリクトが起きにくくなった理由

その最大の理由は、短期と長期のコードを物理的に環境ごとに分離した点にあります。
開発の途中でブランチ同士が交わらなくなったことで、
不要なコンフリクトが発生しにくい構造になりました。

コンフリクト解消のルール化

それでも発生する共通部分のコンフリクトに対しては、 「開発者全員で音声チャットを繋ぎ、その場で解消する」 という運用を取り入れました。

一人の担当者が推測でマージするのではなく、変更の意図を知るメンバーが対話しながら進めることで、マージ作業の心理的負担とミスが解消されました。

開発環境を増設するという選択肢

もちろん、環境をもう一つ用意すればその分のインフラコストはかかってしまいます。
しかし、以下のような兆候が見え始めたら、増設を検討する価値は十分にあると感じています。

• 中長期案件が常時2本以上走るようになった
• masterからの乖離期間が1ヶ月を超える大きな機能開発がある
• リリース判定の前に、不要なコードを抜くためのcherry-pick作業が頻発している

「環境を増やす」という提案はハードルが高く感じるかもしれませんが、作業の詰まりによる工数ロスや、リリース不備のリスクを解消する手段として、非常に有効な投資です。

まとめ

今回の取り組みを通して、Gitブランチ戦略は単なる「コード管理のルール」ではなく、「チームの意思決定をいかに安全にリリースまで流すか」という設計そのものだと感じました。

「日々の開発で感じるちょっとした面倒くささ」を仕組みで解消していくことで、以前よりも格段に見通しの良い開発ができるようになったと思います。

最後に - チームでより良い開発環境を作っていきたい -

今回の改善では、私自身が課題を感じて提案を行い、ベースとなる仕組みを作成しました。ですが、すべての運用を独断で決めたわけではありません。

実際のルールや運用の細かい部分については、チーム全体でも話し合い、意見を出し合うことで、より現場に即した良い形に落とし込むことができました。

jinjerには、入社したばかりのメンバーであっても 課題に感じたことをすぐに改善へと移せる土壌 と、それを チーム全員で助け合いながら形にする風土 があります。

現在、jinjerでは 日本一の開発組織 を目指していける仲間を探しています。
「課題を解決し成長したい」「チームで協力して開発したい」 という想いをお持ちの方、ぜひ私たちと一緒に日本一を目指しませんか？

少しでも興味を持っていただけたのであれば、ぜひ採用サイトや募集要項を覗いてみてください！