トランクベース開発を推進した結果、チームの生産性と開発者体験が向上した話
はじめに
こんにちは、ワンキャリアでバックエンドエンジニアをしている田中（@kakke18_perry）です。
昨年、ワンキャリアはファインディ株式会社が主催する「Findy Team+ Award 2022」において「向上率部門」を受賞しました。以前のテックブログでは、私たちが生産性を向上させるために行った取り組みを紹介しました。今回は、具体的な生産性向上の施策として、私が所属しているチームで実施したトランクベース開発について紹介しようと思います。
git-flow（GitHub Flow）の課題
ワンキャリアの開発組織において、ほとんどのチームは、ブランチ戦略としてgit-flow（もしくはGitHub Flow）を採用しています。具体的には、以下のような流れです。
ブランチを作成
そのブランチで作業（新機能開発やバグ修正）
作業後にmainブランチにプルリクエスト（以下、PR）を提出
コードレビューとレビュー修正を経てマージ
しかし、このブランチ戦略ではいくつかの問題が発生しました。例えば、PRが長時間オープンな状態であると、mainブランチとの差異が大きくなり、マージの際に複雑なコンフリクトが発生する可能性があります。また、仕様変更や設計方針変更により大きな手戻りとなる可能性もあります。つまり、フィードバックループが長くなるという課題が生じていました。
トランクベース開発とは
このような課題を解決するために、トランクベース開発を導入することにしました。
トランクベース開発は、Google Cloudの記事によれば、以下のように説明されています。
それぞれのデベロッパーが自分の作業を小さなバッチに分割し、その作業を 1 日に少なくとも 1 回（場合によっては数回）トランクにマージします。このアプローチの主な違いはスコープです。通常、機能ブランチには複数のデベロッパーが関与し、作業が終わるまでに数日から数週間かかります。対照的に、トランクベース開発のブランチは数時間以内で終わり、多くのデベロッパーが個々の変更を頻繁にトランクにマージします。
要するに、「PRの生存期間を1、2日間程度に短縮し、できるだけはやくメインブランチにマージする」ことを目指す手法です。
トランクベース開発推進の取り組み
トランクベース開発を推進するために、具体的にチームとしてやったことをまとめていきます。
PRに関するルール策定
PRの生存期間を1、2日間程度にするために、以下のようなルールを決めました。
1つのPRの差分は100行以内に収まるようにする（ただし、自動生成ファイルなどは除く）
コードレビューは非同期ではなく、同期で行うこと（自分の実装よりコードレビューを最優先にする）
GitHubとSlackを連携させ、通知が来るようにすること
100行という数字に意味は特になく、とにかく変更行数を少なくしようとしていました。時には10行以内のPRもあったりします。変更行数が減ることで、コードレビュー負荷も下がりました。GitHubのSlackAppの通知設定をONにすることで、自分が出したPRにコメントがついた時や自分がレビュワーにアサインされた時にすぐに対応できるようにしています。
モブプログラミング
毎日13:30からチームメンバーとモブプログラミングをしています。集まった後は基本的に各自の作業に取り組み、相談や質問がある時に議論するという形をとっています。コードレビューも基本的にはこの場で行っています。
モブプログラミングをすることにより、「これどっちで書いた方が良いかな？」といった細かい改善も全員で議論し決定することができています。コードベースや仕様について誰か一人が詳しいという状態にならないようにできていると思います。
CI/CD改善
コードレビューを同期的に行う上で一番困ったことが、CIが遅いことでした。詳細は省略しますが、速度改善を行うことで、PRがapproveされた後すぐにマージできるようになり、それに伴い開発スピードも向上しました。また、CDの改善も行い、プロダクトマネージャーやデザイナーにも早く確認してもらえるようになりました。
トランクベース開発を推進した結果
2023年3月から私たちのチームが始動しました。2023年4月から本格的に開発がスタートし、それに伴ってトランクベース開発を始めました（当時は3人のチーム）。
現期間に2023年4月に設定した（前期間は2023年3月）Findy Team+のチーム詳細スタッツは以下のようになっています。
トランクベース開発を行うことで、コードレビュー待ちの時間が大幅に短縮され、結果的にPR作成数を増やすことができました。また、PRがサクサクマージできるので開発者としてとても気持ちよく実装することができています。
開発者が気持ちいいというのは他のチームメンバーからも上がっていて、目に見える数値よりも価値ある改善であることを実感することができました。レビュー待ちの間に別のタスクをこなすという状況も少なくなったため、コンテキストスイッチが減り、このような感想を抱くことになったのかなと思います。
今後の展望
私たちが開発している機能はまだ本番環境にリリースされていないものです。なので、最悪mainブランチにバグが入り込んでいても問題ないのですが、本番環境にリリースされてからはそういうわけにもいきません。本番環境にリリースされてからもトランクベース開発を推進できるように、さらにCI/CD改善や監視整備をやっていく必要があると考えています。また、他プロダクトにもトランクベース開発を導入してもらえるように日々改善を続けていこうと思います。
最後に
ワンキャリアでは現状に満足せず常に改善を進めていける人を求めています！本記事を読んで少しでもご興味持っていただけた方は、ぜひご連絡ください！
▼カジュアル面談を希望の方はこちら
▼エンジニア求人票
この記事が気に入ったらサポートをしてみませんか？