PR単位の開発環境構築自動化によるWEBフロントエンド開発の生産性向上

みなさん、こんにちは!TVer SREチーム DevOps Unitの鈴木です!

TVerでは採用に非常に力を入れており、おかげさまで社員数が右肩上がりに増え続けています。 note.com

TVerでは、WEB、iOS/Androidアプリ、Fire TV Stickなどといった多様な端末でサービスを提供しており、それぞれに専門の開発チームが存在しています。 組織拡大に伴い、それぞれのチームで複数の新規機能開発や改善プロジェクトが同時に推進されるようになりました。

しかしながら、この急速な組織拡大に伴い開発環境の不足がボトルネックとなり、開発生産性向上を阻むという課題が浮き彫りになりました。

開発組織全体の生産性向上は、私たちSREチームの重要なミッションの一つです。

本記事では、この多岐にわたる開発チームの中でも、WEBフロントエンドチームが抱えていた「開発環境の課題」に焦点を当て、PR単位での自動開発環境構築というアプローチが、どのような効果をもたらしたのか紹介します。

なお、本記事は以下の記事から着想を得たものであり、@dtaniwaki さんにこの場を借りてお礼申し上げます。

techblog.jmdc.co.jp

1. 開発環境の課題

WEBフロントエンドチームでは、組織の拡大と並行して進むプロジェクトの増加に伴い、いくつかのボトルネックが顕在化していました。

開発環境利用における待機時間の発生

これまで、利用できる開発環境の数が限られていたため、複数の開発メンバー間で開発環境の利用が集中し、使いたい時に使えないという状況が常態化していました。これにより、自身のコードのテストや機能の確認を行う際に、不要な待機時間が生じていました。

レビュープロセスの遅延

PRのレビューにおいては、実際に動く開発環境での確認が必須です。 しかし、開発者だけでなくPdM(プロダクトマネージャー)やQAチームのメンバーも動作確認を行うため、開発環境を占有する時間が長くなりがちでした。 結果として、開発環境の待機時間が発生し、レビュープロセス全体が滞る主要な原因となっていました。

構築・運用コストの高さ

従来の開発環境はバックエンドアプリケーション、データベース、外部サービスなど全ての機能を含むフルパッケージ構成でした。 この構成では構築・維持にコストがかかるため、需要に応じて柔軟に開発環境を増やすことができませんでした。

データの不整合

フルパッケージ構成の開発環境はそれぞれの開発環境でデータベースが独立しているため、参照できるデータが開発環境ごとに異なるという課題がありました。 これにより、フロントエンド開発者が特定のUI/UXやユースケースを検証したい際に、必要なテストデータが存在しないケースが頻発し、検証作業に支障をきたしていました。

2. 課題解決のためのアーキテクチャ

前述の課題解消にあたり、PR単位でWEBフロントエンド開発環境を自動で構築できる仕組みを用意しました。 アーキテクチャとしてはCloudFrontとS3を利用した非常にシンプルな構成になっております。

今回のアーキテクチャの特徴は以下になります。

  • CloudFront FunctionにてサブドメインのPR番号を取得し、PR番号に応じたパスに書き換える
  • ワイルドカードドメインで任意のPR番号で対象PRの画面を確認できるように
  • PRにdeploy-prラベルの付与をトリガーにS3のPR番号フォルダ配下に自動デプロイ
  • バックエンドはテストデータが充実した既存の開発環境を参照

新しく上記リソースをCDKで用意するだけだったため、少ない工数ですぐに構築することができました。

3. PR単位の開発環境構築がもたらした効果

今回の対応で以下の効果をもたらしました。

課題の解消

開発環境利用における待機時間の解消

新しい仕組みでは、PRに特定のラベルを付与するたびに、専用の開発環境がゼロから自動で構築されます。 これにより、誰もが「確認したい」と思ったその瞬間に、自身の変更が反映された独立した開発環境を利用できるようになりました。

レビュープロセスの効率化

PR単位でユニークなURLが発行されるため、開発者、PdM、QAメンバーは、確認したい時に、確認したいPRの開発環境へ直接アクセスし、独立して動作確認を行えるようになりました。 GitHub Actionsによる開発環境の自動作成は、構築時間を大幅に短縮し、すぐに検証を開始できるため、レビュープロセス全体が飛躍的に効率化されました。

構築・運用コストの最適化

従来のフルパッケージ構成の開発環境ではなく、WEBフロントエンド用開発環境のみを必要な時に即時かつ自動で構築できるようになったため、インフラの構築・維持にかかるコストを大幅に削減できました。

テストデータ不整合の解消

PR単位の開発環境はテストデータが充実しているバックエンド開発環境に接続するようにしました。 これにより、実施したいテストを確実に行えるようになり、検証の品質が向上しました。

データで見る開発生産性の向上

今回、PR単位の開発環境構築を自動化したことで、WEBフロントエンドチームの開発生産性がどのように向上したのかを、開発組織の生産性分析ツールであるFindy Team+のデータで見てみましょう。 この仕組みを本格的に導入した2025/06以降、PR作成数や開発者数に変化がない中で、開発フローにおける複数の重要な指標で顕著な改善が見られました。

変更のリードタイム

変更のリードタイムは約80%(前月比)ほど減少しました。 これは、コードの変更(コミット)してからmainブランチにマージされるまでの、開発サイクル全体のスピードが大幅に向上したと読み取れます。

PRオープンからレビューまでの平均時間

PRオープンからレビューまでの時間は約40%(前月比)ほど減少しました。 PRが作成されてから、レビュアー(開発者、PdM、QA)がレビューを開始するまでの時間が短縮され、開発環境の待機時間が解消されレビューに着手しやすくなったことを表しています。

もちろん、これらの数値改善は「PR単位の開発環境構築自動化」のみが要因ではありません。 開発チーム全体の継続的な努力や改善活動も大きく寄与していることを認識しております。

しかし、WEBフロントエンドチームから「従来の開発フローにはもう戻れない」という嬉しい声をいただいており、今回の対応が開発生産性向上に貢献できたと思っております。

4. まとめ

今回はWEBフロントエンド環境構築の自動化によってWEBフロントエンドチームの開発生産性が向上した話を紹介させていただきました。

SREチームでは組織全体の開発生産性向上をするためにまだまだたくさん解消しなくてはいけない課題が存在するため、興味がある方は以下からのご応募お待ちしております。

herp.careers