リリースサイクルを3ヶ月毎から毎日に短縮
株式会社シャペロンでエンジニアをしている野田です。
弊社では長らく3ヶ月ごとにリリースを行っていましたが、2024年8月からは毎日リリースを実施するようになりました。今回はその取り組みについてご紹介します。
なぜ毎日リリースしたいのか
まずは、3ヶ月毎リリースのメリットについてです。
影響の確認がしやすい：変更がユーザーや周辺システムにどの程度影響を与えるかが不透明なため、リリース前にユーザー企業の担当者に確認をお願いしていました。高頻度になると負担が大きく、3ヶ月ごとのリリースが適していました。
品質の確保：リリースまでの期間をかけて、品質向上に取り組んだり、リリース前に手動で網羅的にテストを実施できました。
しかし、メンバーの成長や自動テストの充実に伴い、これらのメリットは小さくなり、3ヶ月のリードタイムによるデメリットが目立つようになりました。具体的な問題点は以下の通りです。
フィードバックが得られない：リリースが遅れることで、ユーザーからのフィードバックが得られず、間違った方向に開発が進んだり、開発が停滞することがありました。
状況の変化に対応できない：顧客の要望に応えて機能を追加しても、3ヶ月後には状況が変わり、十分に活用されないことがありました。
変更のコストが大きい：一度に大量の変更をリリースするため、テストやリリース作業のコストが増大していました。
どうやってリリースサイクルを短縮したか
リリースサイクル短縮に際して、「具体的にどう変わるのかイメージできない」という声が開発部門内で多く聞かれました。そこで、次のステップで進めました。
1. 理想のリリースフローを定義
まず、バリューストリームマッピングを行い、リリースまでのプロセスとそのボトルネックを可視化しました。これにより、以下のプロセスがボトルネックであることを特定しました。
リリース前にユーザー企業の担当者が影響を確認する。
リリース前に手動で網羅的なテストを行う。
次に、これらのボトルネックを取り除いた理想のリリースフローを定義しました。
2. 運用の見直し
ユーザー企業の担当者による事前確認をなくすためには、互換性のない変更に対応する猶予期間が必要です。そのため、本番環境にデプロイしつつも、特定の環境やユーザーにのみリリースする仕組みを構築しました。これを実現するために、Feature Togglesを導入しました。Feature Togglesの詳細については、別の記事で詳しくご紹介します。
3. 開発プロセスの見直し
手動での網羅的なテストをやめても、品質が低下しないようにする必要があります。そこで、品質目標の再定義と自動テストの拡充に取り組みました。特にE2Eテストの自動化はリリースサイクルの短縮に大きく貢献しました。詳細は以下の記事をご覧ください。
得られた効果
ユーザーへの素早い価値提供
リリースまでのリードタイムを短縮できたことで、ユーザーに素早く価値を届けられるようになりました。現在、複数のプロダクトが並行して開発されていますが、リリースサイクル短縮はPMF（Product-Market Fit）達成に大きく貢献しています。
品質の安定
一度にリリースする変更量が減ったことで、リリース判定やリリース作業が簡単になりました。運用を開始して2ヶ月が経過しましたが、発生したバグは数名のユーザーに影響のあった軽微なもの1件のみでした。これはリリースサイクル短縮前と同等以下の件数です。
生産性の向上
予想外の効果として、リファクタリングが以前よりも積極的に行われるようになりました。3ヶ月という締め切りに追われず、少しずつデプロイできることで、規模の大きなリファクタリングにも取り組みやすくなったことが要因だと思います。機能追加や改善の数も増えており、生産性が向上しました。
おわりに
シャペロンでは、社内外のステークホルダーと協力し、プロダクトや開発プロセスの改善を日々行っています。現在、さらに品質と開発効率を向上させるため、APM（Application Performance Monitoring）によるモニタリング強化やリリースの自動化も検討しています。
弊社にご興味をお持ちいただけましたら、ぜひ「Entrance Book」もご覧ください。
この記事が気に入ったらサポートをしてみませんか？