はじめに
はじめまして、みらい翻訳のプラットフォーム開発部のcidです。
みらい翻訳に来て4年目になりますが、TECH BLOG初投稿になります。「cidはTECH BLOG書かないんだっけ？」という勝手な(本当に勝手な)プレッシャーを感じ、重たい筆を取りました。
最近、自チームでは「リリーストレイン」という考え方を取り入れてみましたので、紹介します。
リリーストレインとはなにか？
システム開発におけるリリースを、電車のように定期化してしまう考え方です。
機能の完成は待たず、その日が来たら絶対にリリースします。
...え、これだけ？
はい、これだけです。
終
制作・著作
━━━━━
みらい
あ、ブラウザバックはお待ちください！！ たったこれだけなのに、チームとしては良いことが多数あったんです。すごくないですか？というお話になります。
なぜリリーストレインなのか？
そもそも、自チームではFour Keysという指標を計測、改善していくことで、エリートDevOpsチームになることを目指しています。
Four Keysはソフトウェア開発のパフォーマンス指標です。
エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud 公式ブログ
すごく簡単に言うと、「早くリリースできて、障害を起こさない、起きても復旧が早いチームがつよい」ということです。
ただ、このような目標を立てていながら、少し前までは「機能ができたら出す」というよくあるリリースをしていました。
こうなると、リリーススピードはなかなか上がっていきません。実態として...
- 開発の1stコミット〜リリースまでの日数
- 機能A: 約150日
- 機能B: 約90日
という開発もあり、「相対的に見ると、ここの機能はリリースが遅かったね」なんて話題が出ていました。
そこで、「リリーストレインを導入すれば、無理やり早くなるんじゃないか？」という少し強引とも取れるやり方を試してみることになりました。
リリーストレインはいいぞ
「ひとまず、2週間に1回の頻度で絶対リリースしてみるか」という運用をし始めると、課題が多数出てきます。そしてそれに伴う改善も当然、多数行われました。
リリース作業のコモデティ化
頻繁に、そして定期的にリリースを行うので、リリース作業自体の改善が行われました。
例えば...
- リリースノートとか手順とか書くのめんどくさい！
- ドキュメントがテンプレート化されました
- AIを使って補佐されるようにしました
- テスト/QAがめんどくさい！
- 自動テストツールを徹底的に使うようになりました
という営みがあり、誰でも簡単にリリースができるようになりました。
OSS ver UP の定期化
せっかく定期リリースするんだから、ということでOSS ver UPは必ず行うようになりました。
大量のOSSを使っているので、2週間経ってver UPされないものはありません。これにより...
- いきなり大量のOSSがバージョンアップされて大丈夫？！といったリスクが減りました
- OSSバージョンアップ -> テスト -> 開発環境デプロイ まで自動化されました
価値提供の分割
機能が開発途中であっても、
「次のリリースで、出せるものないかな？」
「せっかくリリースするんだから、ここまで出せないかな？」
といった提案が出るようになりました。
実際に、「画面は間に合ってないけど、APIサービスとしては出そう」といったリリースがありました。
... というように、「リリースを定刻化するだけで、とにかく色々なことが改善されている！」と運用から半年経って気づきました。
が、当然辛い事も出てきます。
リリーストレインはいいことばかりではないぞ
まだ完成してないけどデプロイしたい！
「まだ完成はしてないけど、コードリポジトリ運用上デプロイだけしておきたい」みたいなシチュエーションがありました。
ブランチを分けるか？という話もありましたが、フィーチャーフラグを活用するようになりました。
フィーチャーフラグの解説は、以下の記事を参照してください。
これにより、ブランチ管理が複雑化することはなくなり、おまけにシステムの障害耐性も向上しています。
....しかし、プロダクトコードは複雑性が上がってしまっているという事実はあります。なんとか複雑にならないように努めていますが、ここは今後の課題になっていきそうです。
機能開発の実装スピードが落ちていないか？
開発作業の合間にリリースが挟まるので、「ある機能完成までの実装スピード」という観点で見ると、やはり落ちることになります。
ただ、「価値提供」という面で見ると、スピードはあがっているように思います。
- 機能リリース後に重大なフィールドバグが見つかり、切り戻した
- 開発している間にユーザが興味を失った(別のシステム使うわ！...など)
一部でも機能をリリースしていくことで、このようなリスクと、それに支払うコストが低減されているのではないか、と考えています。
一方、ここはビジネス側の方針に応じてバランスを取るべきで、プロダクトのオーナーと認識をあわせることが重要かとも思っています。
リリーストレインを始める前に
いいことが多そうなリリーストレインですが、ある程度効率化されているけど、更に良くしたい！といった場合に有効な考え方ではないか、と考えています。
スコープの調整が効く開発であること
「この日までに、この機能がすべてリリースされていること」が絶対条件の開発では、そこに向けて資源を集中すべきかと思います。
リリースやテストがある程度効率化/自動化できていること
例えば、リリースに厳格な審査や承認が必要だったり、リグレッションテストが手動だったりして、リリース作業そのものが重たい場合はやめましょう。
まずは、リリース作業を軽くできないかを検討すべきかと思います
依存関係が明確なシステムであること
A機能のリリースに、BシステムとCシステムの改修が必須で、それぞれが別チームが管理している場合などはやめましょう。
まずは、システムを疎結合にすべきかと思います。
まとめ
自チームにおいて、「リリースをもっと早くできないか」という課題を解決するために、リリーストレインの考え方を取り入れてみました。
結果として様々な改善が実施され、「リリース作業の効率化」「リリースリスク低減」「価値提供の加速」に繋がったと感じています。
究極的には1日1回リリース！というところまで行けないかと個人的には思っていますので、今後も改善を続けていきます。
We are hiring!
みらい翻訳では、私たちと一緒に翻訳・AIエージェントプロダクトの開発を進めていただけるエンジニアを募集しています!ご興味のある方は、ぜひ下記リンクよりご応募・お問い合わせをお待ちしております。
