Kyashモバイルチームのトランクベース開発への歩み

これは Kyash Advent Calendar 2023 の12日目の記事です、こんにちは あるいは こんばんは。KyashでAndroidエンジニアをしている 牧山（@_rmakiyama）です。

さて、突然ですが、私は3つあるKyashのValue（行動指針）の中でも『動いて風を知る』がとても好きです。社内でもよく会話やSlackのemojiで飛び交うValueでもあり、自然とみんなの行動や意思決定に表れているなと感じています。

Kyashのモバイルチームでも、このValueを体現するように、ここ1年ほどかけてトランクベース開発の導入を進めており、最近ではだいぶ板についてきました。 今回は、トランクベース開発を導入するに至った背景と、どのように導入していったかについてフォーカスして紹介します。

なぜトランクベース開発なのか

これまでモバイルチームではフィーチャーブランチ開発をベースにしていました。
チームの人数が増えるに従い、改善を含め複数のプロジェクトが動き、複数のフィーチャーブランチを伴った開発となりました。
これにより下記のような問題が起こりました。

  • 開発後半でコンフリクトの解消に工数が割かれる
  • プロジェクト間の変更の影響を把握しにくい
  • 巨大なフィーチャーブランチは精神衛生上よろしくない

また、Kyashのモバイルアプリは、昨年からKotlin Multiplatform（以下KMP）を導入しています。途中から導入したこともあり、現在はiOS / Android / KMPとそれぞれGitHubのリポジトリがわかれています。
そのため、KMPリポジトリのリリース管理やバージョニングについても煩雑さが増していました。

このような課題もあり、モバイルチームでは、Four Keysで有名なソフトウェア開発チームのパフォーマンスを示す指標を参考に、『mainブランチ/フィーチャーブランチへのmergeを日平均1回以上/1人』という目標を年始に立てていました。（このときはまだフィーチャーブランチ運用だった。）これはFour KeysにおけるEliteの基準です。

課題感とモバイルチームが目指す先に合致したのが、トランクベース開発だったわけです。

どのように進めたのか

いきなり「トランクベース開発をしましょう！」と言っても認識が合うわけではなく混乱を生むだけです。そこで、下記のステップを踏んで導入を進めました。

  • 課題の認識を合わせる
  • トランクベース開発についての認識を合わせる
  • フィーチャーフラグの認識を合わせ導入をする

それぞれのステップでやったことを詳しく紹介していきます。

課題の認識を合わせる

トランクベース開発という解決策に至る前に、まずはチームで課題や解決の方向性について同期的なミーティングの場で話しました。Kyashのモバイルチームは週にいくつかの定例があります。
何度か話をしたあと、改めてチームの認識を揃えるために、GitHubのIssues上で「なぜやるのか」「なにをやるのか」「どのようにやるのか」というドキュメントを作りました。
実際のIssueがこちらになります。

基本的な方向性については話し合いでまとまっており、ここではいくつかのケースにおける懸念や進め方について話をまとめ、この方向性で進めていこうという合意を行いました。

このIssueでは、トランクベース開発におけるリスクについても認識を合わせています。
例えば、トランクベース開発では、フィーチャーフラグなどを使って開発中のコードもmainブランチ（トランク）にマージしていきます。この性質上、アプリのバイナリ解析などで未公開の機能やリソースなどが完全ではないにしても閲覧できる状態となってしまいます。
このリスクに対してKyashでは、プロダクト開発チーム全体で認識合わせを行い、外部のステークホルダーが関わるプロジェクトの場合などは実装に入る前に開発の進め方を話し合い、フィーチャーブランチを用いる選択肢も取れるようにしています。

もしトランクベース開発をこれから導入していこうと考えている場合は、ここについても認識合わせと合意をとるとよいでしょう。

トランクベース開発についての認識を合わせる

今このブログ記事を読んでくださっている全員がトランクベース開発について把握しているわけではないと思いますが、ここではトランクベース開発についての説明は割愛します。
同様にチームメンバー全員がトランクベース開発について把握しているわけではもちろんありません。開発をスムーズに進めるに当たって、認識を合わせることはとても重要です。説明を割愛するわけにはいきません。

そこで、モバイルチームにおけるトランクベース開発についてのドキュメントをまとめ、全員の認識が揃うようにしました。

トランクベース開発を厳密に守ることが目的ではなく、あくまでもKyashのモバイルチームの開発フローに合わせたドキュメントとしています。

フィーチャーフラグの認識を合わせ導入をする

課題とトランクベース開発の認識が合ったので、あとは実践です。しかし、1つ解決すべきことが残っていました。

現在のKyashでは、いわゆるリリーストレインを採用しておらず、複数のチームがそれぞれのタイミングでリリーススケジュールを組んでいます。今の状態でトランクベース開発を導入すると下記の問題が出てしまうことが明らかでした。

  • あるチームのリリースタイミングで別チームの開発中のコードが含まれてしまう
  • mainブランチがデプロイ可能（リリース可能）な状態になっていない

これらの問題を解決するためにも、フィーチャーフラグの導入は必須でした。

フィーチャーフラグと一口に言っても、用途や実装方法はさまざまです。これについても認識を合わせることから始めました。

このドキュメントでは、Feature Toggles (aka Feature Flags)に触れ、フィーチャーフラグが大きく4つのカテゴリに分かれること、生存期間と変化の度合いで性質が分かれることを説明しています。これは下記の図を見ると分かりやすいです。

出典: Feature Toggles (aka Feature Flags)

モバイルの日々の開発においても、フィーチャーフラグとして利用したケースは様々あります。それをすべて考慮に入れて実装に落とし込むと、アジリティが失われてしまう懸念がありました。
そこで、このドキュメントを通してトランクベース開発をスムーズにするために最も必要なのは『リリース前の機能をユーザーから使えないように制御する』ことであるという認識合わせをし、『リリースフラグ』の役割にフォーカスした実装・利用していくことに決めました。

導入してみて

トランクベース開発を導入してからは、フィーチャーブランチを用いた開発で起きていたような大きなコンフリクトの解消などの煩雑さが大幅に削減されました。

一方で、リリースフラグを利用する前提の開発となるため、リリース前の機能は既存のアプリに影響がないように作る必要がある、という新たに考慮する必要があることも増えています。これはフィーチャーブランチを用いた開発による課題とのトレードオフです。
リリースフラグ導入の最初の時期は、考慮漏れが発生してリリース前に調整するケースもありました。最近ではリリースフラグをどのように仕込む必要があるかを開発初期にチームで話すなどの工夫でだいぶスムーズな開発ができています。

実際に導入して運用を始めてから約半年経っていて、チームの中でも、トランクベース開発がフィットしているという実感があります。
トランクベースに合わせたCI等の最適化や、ペアプロなどのプラクティスの実践など、できることはまだまだあります。さらなる高みを目指して、One Teamで改善を進めていこうと考えています。

おわりに

今回は、モバイルチームがどのように改善を進めているかという裏側を実際のドキュメントと一緒に紹介しました。

トランクベース開発はゴールではありません。目指すところはサービスの価値提供のパフォーマンスを最大限に高めることです。
これからも、今が最適と考えず、会社の成長や組織やチームの変化に合わせて継続的に改善をしていきます。

参考