これは Kyash Advent Calendar 2024 の2日目の記事です、こんにちは あるいは こんばんは。Kyashでエンジニアリングマネージャーをしている 牧山（@_rmakiyama）です。
さて、昨年に続きですが、私は3つあるKyashのValue（行動指針）の中でも『動いて風を知る』がとても好きです。社内でもよく会話やSlackのemojiで飛び交うValueでもあり、自然とみんなの行動や意思決定に表れているなと感じています。
プロダクト開発チームでも、このValueを体現するように、初夏からリリーストレインを導入しました。少しずつですが開発にリズムが出てきたように感じています。 今回は、リリーストレインを導入するに至った背景と現在地について紹介します。
課題
2024年の始め、プロダクト開発チームは3つのチーム（現在は2つ）に分かれていました。チームによって責務とする領域やそれぞれの施策内容、開発の進め方が異なっており、それぞれのタイミングでリリーススケジュールを組んでいました。
これにより、下記のような課題を抱えていました。
- リリースタイミングが被りそうなときのスケジュール調整が頻繁
- QAのテスト設計から実施までのアサインが大変
- 次にリリースされるものを開発チーム全体で把握しにくい
特にスケジュールの調整コストは高く、リリースに向けたブランチ戦略 / QA / リリース作業も煩雑化していました。 また、QAチームのリソースは限られており、ある機能を優先させるために他の機能のテスト設計が遅れることもあり、複数のチームで並列して開発を進めていても、デリバリーが直列に近い状態となる時期もありました。
リリーストレインという選択肢
これらの課題を解決するための1つの選択肢として、リリーストレインの導入を進めました。 リリーストレイン自体の概要や目的などはここでは割愛します。捉え方は一つではないですが、特にSAFe（Scaled Agile Framework）のアジャイルリリーストレインの考えを参考にしています。
Kyashとしてのリリーストレインの目的は下記の2点に定めました。
- 複数チーム間のリリース前の調整 / コミュニケーションコストを減らす
- アジリティ高くプロダクトの価値をデリバリーしフィードバックサイクルを早める
導入にあたって大事にしたことは、『リリーストレインを忠実に守ること』が目的にならないようにすることです。ここが抜けてしまうと、「トレインに乗りそびれたら2週間後（次のトレイン）になることで価値提供が遅れてしまうのではないか」という逆行した感覚に陥ってしまう懸念があったため、それ自体が目的にならないことを強く意識していました。
ここの認識がずれないよう、エンジニアだけでことを始めるのではなく、PdMやQAチームと今の課題やリリーストレインの目的の認識合わせも行っています。
これにより、いくつかの懸念は出てきたものの、「うし、やってみっか」という温度感に揃えてからのスタートを切ることが出来ました、懸念についても、実際にトライしてみないと実態がわからないよねというものも多く、ここが事前にすり合ったのも良かった点です。
最初に行ったトレインの設計
リリースサイクルを2週間と定め、下記のプロセスで実施を開始しました。
- 1週目
- 月曜: POがトレイン乗車判断をする
- 水曜: QA用アプリ配布
- 木曜: 機能テスト開始
- 2週目
- 翌週月曜日にリリース 🚀
- POが次のトレインのリリース判断（1週目に戻る）
簡単な概略としては図のようなイメージです。
Kyashは事業の性質上、機能によっては仕様承認やリリース承認といった、いくつかのプロセスが用意されています。トレインとしてもリリースプロセス全体に合わせて設計することも考えましたが、まずはシンプルな形でスタートして、必要に応じてプロセスを追加することにしました。
探索と適応
やってみなければうまくいくかわからないという不確実性を許容してスタートしたリリーストレインですが、やっていくなかでいくつかの課題を見つけることが出来ました。
その中でも、組織の変更に伴い責務とする領域やそれぞれの施策内容、開発の進め方の違いが顕著になったことが運用するうえで大きな阻害要素でした。
そこでチーム間で話し合い、下記のような決定をしました。
現在のトレインの設計
今では下記のようなプロセスとなっています。
- 1週目
- 各事業部開発
- 事業部ごとに機能テストを開始
- 2週目
- 翌週月曜日にリリース 🚀
- （1週目に戻る）
最初とさほど変わっていないようにも見えますが、各チームがより自律して動けるように余白を増やすことで、スケジュールによる価値提供の損失を防ぎやすくなりました。
リリーストレインで得たもの
だいたい半年ほど変化を加えながら運用してきましたが、動いて風を知るという意味でもよいスタートが切れたのではないかと感じています。チームとしても下記のような効果を実感しています。
- 定期的・継続的にユーザーに価値を届けられている
- 時間以外の観点のトレードオフが議論されやすくなった
- 開発にリズムが生まれる
リリーストレインから得たものではありませんが、少しずつリリーストレインに対する改善も職種問わず起きるようになっています。 直近だと、リリースのたびにSlackで作成しているリリースチャンネルに、Zapierを使って最初にすべきことを自動で投稿するようPdMがシュッと作ってくれて、確認漏れを防ぐことに一役買っています。
最初の課題感にあった、コミュニケーションコストですが、リグレッションテストの開始タイミングのすり合わせなどは引き続きあるものの、開始以前よりは認知不可含めだいぶ改善されています。
おわりに
リリーストレインも走り始めたばかりで、まだまだ伸びしろがあると感じています。なんとなく効果を感じているものの、数値的な効果検証などは取れていないため、せっかくだし取りたいよねという話も出ていたりします。
また、リリーストレインはすべてのチーム・すべてのフェーズに適合するような手段ではありません。今のKyashの開発チームには、一定の効果が得られていますが、組織やフェーズが変わったときに同じように効果が出るとは限りません。
我々が求めているのはリリーストレイン自体ではなく、プロダクトの価値をユーザーに早く届けることであるという視点で、引き続き改善を続けていこうと思っています。
今回はリリーストレインの取り組みについて簡単に紹介しました。この他にも、ユーザーに爆速で価値提供できるようにまだまだトライしていきたいことばかりです！
これからMobile / Serverside / SRE / Data のポジションをオープンします。もしリリーストレインなどの取り組みについてもっと聞きたい、他にどんな課題を持っているのか聞きたい、ちょっとでも興味がある、そんな人は、面識あるなしにかかわらずせび気軽にお話しましょう！記事の内容にかかわらず、モバイルチームの話も大歓迎です！
Kyashで一緒に、新しいお金の文化を創りましょう🙌🏻
