昨年末以来ご無沙汰しています、Rettyアプリチームの今泉@imaizumeです。来月のtry! swift tokyoに約5年ぶりの参加でワクワクしております、会場でお見かけした方はぜひよろしくお願いします!
今回は、RettyのiOS/Androidアプリにおけるリリースサイクルについてのお話です。
Rettyは開発手法にスクラム(LeSS)を採用しており、アプリも含めた全チームが共通のバックログを基に1週間スプリントで開発サイクルを回しています。そしてiOS/Androidのリリースは、スプリントに合わせる形で原則毎週行っていますが、カジュアル面談などで
- アプリの毎週リリースは大変なのでは?
- アプリは2週間に1度の方が良いのではないか?
といったご意見・ご質問をいただくことがあります。
アプリのリリースサイクルを2週間に1回(あるいはそれ以上)にしているチームもあると思いますし、運用に関する前提条件や制約は各社異なるとは思いますが、今回はRettyがなぜ毎週リリースを採用しているのかや、運用の負荷を減らす取り組みについて紹介してみたいと思います。
直近のリリース実績
| OS \ 期間 | 2024/10-12 | 2025/01-03 | 2025/04-06 | 2025/07-09 |
|---|---|---|---|---|
| iOS | 11 | 13 | 11 | 13 |
| Android | 10 | 12 | 11 | 12 |
こちらの表は、直近1年間の四半期ごとのiOS/Androidアプリのリリース回数を示したものです。四半期を4週 * 3ヶ月 = 12週として換算すると、概ね毎週達成できており、週1回以上を達成している期もあることがわかります。
毎週リリースをする理由
ここで先に本題である「なぜ毎週リリースをするのか」という疑問についてお答えします。
その目的は「小さく高頻度なリリースにより、施策の洗練と価値検証機会の増加を図る」というもので、チーム全体がこの認識を共有しているからです。
現在のRettyはまだまだ発展途上にあり、毎週新施策や改善を通じてユーザーさんに新しい価値提供を試みています。狙い通り価値が届いているケースもありますが思ったほど効果が得られないケースもあるため、その場合は機動的に方針転換をしていく必要があります。
このため同じ期間内においてリリース回数=PDCAサイクルは多ければ多いほどよく、そのために検証に必要な最小限度の仕様へとブラッシュアップせざるを得ないようになっていきます。1週間というスプリント・リリースサイクルを軸に考えることで、不要な作り込みを防いだり代替手段を検討するといった動きがPdMやデザイナーだけでなくエンジニアにもクセがつきます。
例えばRettyアプリでは、最近検索結果に特定の検索条件に絞ったタブを表示させる機能「スマートタブ」が追加されました。この施策を開始した当初、スマートタブが本当に使われるのかどうか確証が得られず、また従来の検索ロジックとは異なる形に拡張が必要であったため、アプリ・バックエンド・データの各レイヤーで大規模な修正をすると数スプリントが必要と思われました。
しかしチームで協議した結果、まずはスマートタブの価値検証の観点で既存の仕組みを使った最小限の仕様とすることで1~2スプリントでのリリースが可能と判明し、仕様を簡素化させ短期間でリリースすることができました。その後結果として多くのユーザーさんに使われることがわかったことから、改めてスマートタブの理想的な仕様を考え、より良い形で再設計しつつ運用することができるようになりました。
もちろん状況や内容によっては、2スプリント以上にわたる開発・リリースをせざるを得ない場面もありますが、原則的にはこれを避けるような方針がチーム全体に共有されているわけです。
つまり、短期的視点では「リリース回数が多くて大変」に見えるこの運用も、長期的に見れば「無駄な開発をしない」という点で大域最適解につながっていると考えており、これがアプリを週1リリースとしている理由になります。 (なおこの方針はアプリに限らずWeb等でも同じ)
毎週リリースにおいて重要なポイント
この運用については、ほかにおさえるべきポイントがあるので紹介します。
毎週リリースは原則でありルールではない
リリース実績のところで平均リリース回数が週1回を下回っているように、状況によってはリリースをSKIPする場合もあります。原則は先程も述べたように「小さく高頻度にリリース」ですが、内容や状況によっては2週以上かかることもあります。つまり毎週リリースは「原則」あり「ルール」ではありません。
また週をまたぐような比較的規模の大きいリリースでもFeature Flagのような仕組みを使い、リリース可能な状態を維持しつつ影響なく他の差分をリリースような手段も採用しています。
作業者・チーム負担を減らす
毎週リリースの負荷についても、可能な限り定型化・自動化をすることで減らしています。リリースするにあたり、まずはリリースバージョンを作成・配信しますが、iOS/AndroidともCIによるWFを組んでおり、自動的にブランチを作成・マージ後自動的に配信を行う仕組みがあります。この中で
- GitHub Actionsを使って
release/vX.Y.Zブランチを作成する - releaseブランチ作成時、前回との差分からマージされたPRの一覧がコメントされる
masterマージ後にTestflight/Firebase App Distributionでの配信が開始
というSTEPが組まれており、ブランチを作成・マージするまでにもほとんど人間の手を介在することはありません。
参考: https://engineer.retty.me/entry/2022/08/12/182957
配信が完了したら、Slack WFを使ってQAとリリースノート(文言)作成の依頼を行います。リリース文言については、こちらの記事で紹介したようにSlack WFを経由して担当のプランナー及びCSチームが主体となって決めることとなっており、ここでもエンジニアが行う作業はほとんどありません。
参考: https://engineer.retty.me/entry/2024/12/07/090000
そして最終的に必要なすべての情報が揃った段階で、エンジニアがダブルチェックで申請を行います。翌週に行われるリリースでも定時にリマインダーが設定されており、あとはエンジニアがボタンを押すだけですので、1名あたりの毎週の作業時間としては15分もかかりません。
リリースされる内容の管理
このフローに落ち着くまでにあった課題の1つが「今週リリースされる内容」の管理方法でした。
以前は担当プランナーやCSが取りまとめていましたが、彼らはPull Requestのマージ状況までは把握できないため、次のリリースに含まれる内容を正確に把握できず、ユーザーさんに影響がある差分が気付かないうちにリリースされるという事態もたびたび発生していました。
この反省から対策を協議した結果、リードエンジニアである私がリリース内容を管理し指定の場所に記載するルールとなりました。これにより、最新のコードの状態を把握したうえでリリースの予定を一元的に管理し、お知らせ配信やリリース文言決定といった必要な対応をミスなく行えるようになりました。
現在は都合により私が担当者となっているのですが、手順化されているのでエンジニアなら誰でも担当することができます。
効果測定の準備
毎週リリースの目的が高速な価値検証である以上、リリースした機能の効果検証をする体制が整っていることも必要です。
この責務は担当するプランナーが担っており、リリース作業の開始時に内容を予告することで効果測定の準備できているかどうかの確認にもなっています。ときにはリリース後に効果の話題が上がらないとエンジニアからプランナーに問い合わせたり、必要であればエンジニア側で確認を行う場合もあります。
また各施策効果の共有は、毎週のスプリントレビューやエンジニア・プランナー・デザイナーが集まる週次の定例で共有され、全員で結果の解釈や次の打ち手出しを行っています。
QA体制・不具合への対応
スピードを重視するからと言って安全性度外視というわけではありません。Rettyアプリはリリース時にQA担当者が品質確認作業を行う運用を取っており、定型の重要項目に加えて新たにリリースされる内容についてもここで再確認してもらっています。幸いRettyにはQA担当者がいるため、重大な問題が含まれていてもかなりの確率で申請前に発見することができています。
また万が一リリース後に問題がおきた場合にもすぐに対処し解消できるようにしておく必要があります。アプリであればクラッシュ率の増加やユーザーさんからの問い合わせという形で現れますが、我々のチームでは朝会でクラッシュ率の確認を行っており、問題報告用のSlackチャンネルで動きがあれば、すぐに関係者と修正・ロールバックの判断を行う体制を構築しています。
リリースに対する価値観の共有
最後に「小さく高頻度なリリースを重視する」という価値観をエンジニアだけでなくチーム全体が共有していることも大事なポイントだと思います。リリースはエンジニア・プランナー・CSといった複数のメンバーが関わる作業ですので、一部の人に過剰に負荷が寄ってしまったりメリットが享受できていないと感じることがあれば成立しません。
我々は毎週のスプリントレビューで成果物があると盛り上がりますし、社内のメンバーからフィードバックを得る機会も増えることが良いという認識を持っています。またリリースは学びと軌道修正の機会でもあるので、変化や積み上げを実感するという意味でも、これを上回るような問題が発生しない限りにおいては毎週リリース適切というような判断をしています。
まとめ
今回はRettyアプリチームが行っている毎週リリースの運用について紹介しました
- 週1リリースの負荷は現状1人1回15分以下
- 小さく高頻度でリリースすることのメリットをチーム・組織が享受できている実感がある
- 手順は極力定型・簡素化し、ナレッジはチームで共有
- リリースの内容管理・効果測定・QAといった体制を整え、問題が起きてもすぐに対応できるようにしておくことも必要
紹介した内容はあくまで現状のRettyアプリチームにおけるものであり、今後変更される可能性はありますが、みなさんのアプリのリリース運用における1つの参考となれば幸いです。 みなさんもぜひRettyのiOSアプリまたはAndroidアプリをダウンロードしていただき、毎週のアップデートをお楽しみください!
最後に、現在Rettyでは一緒にAndroidアプリを創っていく仲間を募集しています。 Meetyのほか、個人のSNSにDM等でカジュアル面談のご依頼など受け付けていますので、ご興味ある方まずは気軽にお話しましょう!
