昨日は、ぶりおくんの「Node.jsとViteのバージョンアップに挑戦して遭遇した強敵」でした！
こんにちは、んだ(@ndasan55)です。
普段は、ユーザー要望対応、運用保守、プロダクトのデータ基盤まわりを触ったりしています！九州からフルリモートで働いています。
今回は 「チームの開発スピード向上＆NewRelicを導入したので、リリース体制を再設計しているぞ」 というテーマで、お話ししていきます！
本記事の前提
弊社ではチームごとにリリース体制や運用が異なります。 この記事は、私たちが所属するチームで実際に取り組んだ内容をもとにしています！
見直し前のリリース体制について
さて、今回の記事は「リリース体制の再設計」というテーマですが、まずは、今回の見直し以前、私たちのチームのリリース体制がどうなっていたかをお話ししていきます！
見直し前のリリース体制は、大きく分けると以下の2種類 に分かれていました。
- ユーザー影響が大きい「大規模リリース」
- 運用保守・既存機能のアップデート「日常リリース」
ユーザー影響が大きい「大規模リリース」
ユーザーの業務フローが変わるような大きな機能追加や仕様変更については、
- 影響範囲を事前に整理し、リリース前後で確認を行う
- PdM、エンジニア、カスタマーサポートが複数名で立ち会い
という、比較的手厚い体制で対応していました。
運用保守・既存機能のアップデート
一方で、既存機能の改善や軽微な仕様変更など、日常的なリリースについては PdM がプロジェクトごとに状況を把握し、リリース判断を行う という体制でした。
普段のリリースは基本的に、
- PdM が全体状況を把握し
- PdM がリリース可否の判断を行い
- その判断のもとでリリースを実施する
という形で進めており、 日常的なリリースは PdM が管理・判断する一元管理型の体制 になっていました。
今回、お話ししていくのは、「運用保守・既存機能のアップデート」などの日常的なリリースの方です。
なぜ、リリース体制の見直しが必要になったのか
見直し前のリリース体制は、今年の夏頃までは、大きな問題なく機能していました。
チーム内のプロジェクト数もそこまで多くなく、PdM が全体を把握しながらリリース判断を行う体制でも、十分に回せていたという背景があります。
一方で、その後いくつかの変化が重なっていきます。
プロジェクト数の増加
チーム内で並行して進むプロジェクトが増え、リリース対象となるチケットやアイテムの数も徐々に増えていきました。
「リリースできる状態のもの」は増えている一方で、どれを、いつ出すかの調整にかかるコストが目立ち始めます。
開発・テストまでのスピード向上
もう一つの大きな変化が、コーディングエージェントの活用によって、
- 実装
- テスト
- リリース可能な状態
まで到達するスピードが、チーム全体で明らかに上がってきたことです。
結果として、
- チケットはどんどん「出せる状態」になる
- しかし、リリース判断や調整が追いつかない
- リリース待ちにアイテムが積み上がっていく
といった状況が生まれました。
リリース自体は可能だが、リリース“するための調整”に時間がかかるという状態になりつつありました。
この変化を受けて、開発スピードやPJの増加に見合ったリリース体制への再設計 が必要だと考えるようになりました。
見直しフェーズ：何を課題と捉え、どう変えたか
ここからは、 「そもそも何が問題だったのか」→「何をしたのか」 の順で、今回の見直し内容を整理します。
開発・テストまでのスピードが上がり、「リリースできる状態のアイテム」が増えてきた中で、 私たちは、リリースに至るまでの体制や流れを見直しました。
ポイントは、
- 誰が・どこで・何を判断しているのか、どこで調整や待ちが発生しているのか
- 安心、安全にリリースを担保するにはどうしたらいいか
- 人に依存している部分を、どこまで仕組みにできるのか
という点です。
以下では、今回見直した内容を 「そもそも何が問題だったのか」→「何をしたのか」 の順で整理します。
取り組んだのは以下の３点です
- プロジェクト横断でリリースアイテムを可視化した
- New Relic を軸にリリース後の確認を整理した
- エンジニア主体で回せるリリースフローにした
施策1｜プロジェクト横断でリリースアイテムを可視化
Before
これまで、リリース待ちのアイテムはプロジェクト単位では把握できているものの、
- チーム全体として、今どれだけリリース待ちがあるのか
- どのアイテムを、いつ出そうとしているのか
といった PJ横断の視点 では見えづらい状態でした。
その結果、
- 調整や判断が特定の人に集中する
- 「今どれを優先すべきか」を都度すり合わせる必要がある
という状況が生まれていました。
After
Asana を活用し、PJ横断でリリースアイテムを一覧できる状態 を作りました。
これにより、
- 現在リリース待ちのアイテムが何か
- どれを、どの順番でリリースする予定なのか
を、チーム内の誰でも把握できるようになりました。
施策2｜New Relic を軸にリリース後の確認を再設計
New Relicを導入したことも要因として、とても大きいです。
New Relicの具体的な導入の背景や検討プロセスについては、こちらの記事にまとまっていますので、気になる方はぜひ、こちらも読んでみてください
Before
リリース後の確認は、人の目による確認など「ひと」に依存する部分が多く、
- どこまで見れば安心と言えるのか
- 誰が見ても同じ判断ができるのか
が分かりづらい状態でした。
After
New Relic を軸に、
- 全体の異変監視
- Critical User Journey（CUJ）の確認
を整理しました。
ダッシュボードを通じて、 「主要な機能が壊れていないか」を 誰でも同じ観点で確認できる 状態を作っています。
施策3｜エンジニア主体で回せるリリースフロー
今回の見直しの中で、 最もリリース頻度の向上に効いたのが、この取り組みでした。
リリースアイテムをチケットとして可視化し、 リリース後は New Relic で状態をモニタリングできるようになったことで、 「安心して出せる」状態がチーム全体で共有されました。
この安心感を土台に、 エンジニア主体でリリースを回せるフローを整えたことが、 リリース頻度を大きく押し上げる結果につながっています。
Before
これまでの体制では、
- リリース判断や作業が特定の役割・人に寄りやすい
- 手順や判断ポイントが暗黙知になっている部分がある
- その人が不在だと進みにくい
といった構造がありました。
開発スピードが上がるにつれ、 この属人性がリリース時の調整コストとして表に出てきました。
After
リリース前・リリース後のフローを整理し、 どのタイミングで、何を確認し、どこまでできていればリリースしてよいのか を明確化しました。
あわせて、
- リリース前にやること
- リリース作業時の手順
- リリース後に確認する観点
を揃え、特定の人に依存せず、エンジニアであれば誰でも・いつでも対応できる 形にしています。
これにより、
「誰かがいないとリリースできない」状態を減らし、
チームとして継続的に回せるリリースフローに近づいています。
新体制での運用：嬉しい変化
今回のリリース体制の見直しは、 リリース頻度を上げることを前提に設計した取り組みでした。
その結果として、 リリースの頻度やタイミングに、明確な変化が現れています。
これまで、リリースは 週に1回程度 が基本でしたが、 現在では 週に最低でも3〜5回、 多いときにはそれ以上の頻度でリリースできるようになっています。
嬉しい変化①：リリースできる「時間帯」が広がった
以前は、
- リリース後の影響が読みにくい
- 異変に気づくまでに時間がかかる
といった理由から、 影響が比較的少ないと考えられる 夜間にリリースを寄せる ことが多くありました。
現在は、New Relic によるモニタリングを前提にすることで、
- どの時間帯に異変が起きやすいか
- どの時間帯であれば比較的安全にリリースできるか
を、感覚ではなく データとして把握 できるようになっています。
その結果、
- リリースの時間帯を選べるようになり
- 日中を含め、1日に複数回リリースする という判断が現実的になってきました。
嬉しい変化②：「自信を持って出せる」リリースへ
リリース頻度が上がったこと自体も変化ですが、 それ以上に大きいのは、
New Relic によって、リリース後の状態を自分たちで把握できるようになったことです。
- 出したあとに、ちゃんと見れている
- 何かあればすぐに気づける
- 問題がなければ「問題ない」と言える
この状態があることで、「とりあえず夜に出す」ではなく自信を持って、出せるタイミングでリリースする という判断ができるようになってきています。
嬉しい変化③：思わぬ嬉しい効果
また、今回の取り組みを進める中で、 もう一つ、想定していなかった嬉しい変化がありました。
それは、 リリース頻度が増え、リリースに立ち会う機会が増えたことで、 エンジニア同士のコミュニケーションが自然と増えたことです。
リリース後のモニタリングを行う時間は、
- 仕事の話をしながら状況を確認したり
- 実装の意図や背景を共有したり
- 時には趣味の話やちょっとした雑談をしたり
といった、 以前は意図的に作らないとなかなか生まれなかった ゆるいコミュニケーションの場 になってきました。
リリース体制の見直しは、 単にスピードや安全性を高めるだけでなく、 チームのコミュニケーションにも良い影響を与えてくれました。
今、抱えている課題
一方で、今回の見直しによって新たに見えてきた課題もあります。
リリース頻度が上がったことで、 リリースに立ち会う回数も自然と増えました。
これは、
- 状況をリアルタイムで把握できる
- チーム内のコミュニケーションが増える
といったポジティブな側面がある一方で、 立ち会いそのものがコストになり始めている という側面もあります。
どこまでを人がやり、どこからを自動化するか
現在は、
- モニタリングをしながら状況を確認する
- 何かあればすぐに気づける
という安心感を重視していますが、 この状態をそのままスケールさせるのは難しいと感じています。
今後は、
- 人が立ち会うことで得られる価値（判断・会話・気づき）
- 自動化しても問題ない確認やチェック
を切り分けながら、 コミュニケーションの場としての良さは残しつつ、 立ち会いコストを下げる設計 をしていく必要があります。
これから
リリース体制の再設計は、 一度作って終わりではなく、 開発スピードやチームの状態に合わせて 更新し続けるもの だと考えています。
今回の取り組みで得られた手応えをベースに、 次は「より少ないコストで、同じ安心を得る」方向へ 進めていきたいと思います！！
SEN Advent Calendar 2025 17日目となる明日はmocoさんです。どうぞお楽しみに！
