TVerのWeb内製化 - 開発スピードと品質を両立させるまでの道のり

by TVer Inc.

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

©2025 TVer INC. tver.jp の技術スタック・言語・FW：Next.js, React, TypeScript ・ライブラリ：CSS Modules, SWR, Biome, OpenAPI ・テスト：Vitest, Playwright, Storybook ・ホスティング： Amazon S3, Amazon CloudFront ・開発管理ツール：Github, Github Project, Github Actions ・ドキュメント：Figma, Miro, Confluence, Google Docs ・コミュニケーション：Slack, Google Meet ・AIツール：Claude Code Max 20x, Gemini, GitHub Copilot ● 技術スタックとしてはNext.jsやTypeScriptなどシンプルでモダンな技術を採用 ● S3に静的アセットを配置して、CloudFrontで配信。レンダリング方式はCSR ● OVP（Online Video Platform）プレーヤーとして STREAKSを使用 9

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

©2025 TVer INC. 18 2023.08 QA内製チームの立ち上げ 2023.10 iOS内製開発チームの立ち上げ、 Android開発の完全内製化が完了 2024.03 Webフロントエンド内製開発チームの立ち上げ 2024.04 iOS開発の完全内製化が完了 2024.10 QA、Webフロントエンド開発部の完全内製化が完了フロントエンド開発部発足、 Android内製開発チームの立ち上げ 2023.04

Slide 19

Slide 19 text

https://findy-code.io/media/articles/tver-frontend 19

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

©2025 TVer INC. デザインシステムがなく CSSも整理されていない ● 個別にコンポーネントのCSSが設定されている ● カラートークンはあるがちゃんと整理していない ● カラートークン以外の共通CSSが定義されていない ● 汎用コンポーネントと個別コンポーネントが混在しているケースがある ● アクセシビリティを考慮していないこれらの課題により、コンポーネントの仕様とデザインの一貫性が低下し、結果的に全体的な品質が低下している 28 洗い出した課題がいっぱい。。。シンプルなコンポーネントはずのにCSSが多くて重複の定義も存在されているコンポーネントの例適用されているCSS スペーシングがベタ打ちボタンのカラートークンになっている

Slide 29

Slide 29 text

©2025 TVer INC. APIデータの定義がバラバラ ● APIの型定義がなく、フロントエンドで定義されているAPIデータが実際のAPIと合っているかどうかが分かりにくい ● APIデータを取得するためのfetch関数が別リポジトリで管理していてメインテナンスが大変この結果、APIの仕様が分かりにくくなり、実装スピードの低下やメンテナンスの負担に繋がっている 29 洗い出した課題がいっぱい。。。型定義がないAPIデータのfetch関数が別リポジトリで管理されていて、同時にデプロイしないとアプリ側とずれる可能性がある ↓

Slide 30

Slide 30 text

©2025 TVer INC. 自動テストと検証環境が整備されていない ● デプロイできる環境が少ないため、共通開発環境へマージしないと検証できない ● Storybookとそのホスティング環境がないため、コンポーネントのUI検証が手間 ● コンポーネントテストとユニットテストが少ない ● UIとデータ取得のロジックが混在していてテストが難しい ● モックデータを生成する仕組みがなく手書きで書いている ● E2Eテストがなく、QAチームの手動テスト工数が高い ↓ 手動検証に手間がかかり、品質も保証できていない 30 洗い出した課題がいっぱい。。。

Slide 31

Slide 31 text

©2025 TVer INC. 課題が尽きない ● 動画プレイヤーの改善 ● ESLintとPrettierが設定されているがルールが整理されていない ● コードのスタイルガイドがなくファイル毎に書き方が変わるため、理解に時間がかかる ● エラーログとパフォーマンスの監視（New Relic） ● SEOがバックエンドで管理されていてカスタマイズが難しい ● 画像が圧縮されていない ● 内部リンクのhrefがベタ打ちになっている 31 洗い出した課題がいっぱい。。。とりあえず解決策を見にいこう！これ以外にも課題がまだあるが。。。

Slide 32

Slide 32 text

Slide 33

Slide 33 text

©2025 TVer INC. ヘッドレスUIライブラリの検討汎用コンポーネントを改修する前に下記を検討した ● TVerは自社製デザインになっているため、フルパッケージのUIフレームワークが合っていない ● アクセシビリティを向上したいが実装に高い工数が掛かるのを避けたい ● 必要なコンポーネントが用意されていて、ドキュメントも分かりやすいこと上記を踏まえてRadix Primitivesを選定 https://www.radix-ui.com/primitives 33 デザインシステムとStorybookの導入

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

©2025 TVer INC. 生成ツールの導入 ● SVGRでSVGファイルからアイコンを簡単に Reactコンポーネントへ変換できるようにする https://react-svgr.com/ ● pathpidaでNext.jsのpagesディレクトリからタイプセーフのURLを生成できるようにする https://github.com/aspida/pathpida ● OpenAPI TypeScriptでデータスキーマ、fetchと SWRをアプリのリポジトリ内で生成する https://openapi-ts.dev/ 40 生成ツールとAIの活用 Pathpidaの例データスキーマの例

Slide 41

Slide 41 text

©2025 TVer INC. AIでモックデータと MSWハンドラーの実装 ● テスト環境を改善するためにMSW（Mock Service Worker）を導入 ● Claude CodeのCustom Slash Commandで、OpenAPI のスキーマからMSWのHandlerを自動生成 ● Mockデータ生成の際のデータソースとして master.mdを用意し、実際に存在する開発環境のデータを参照するように整備 41 生成ツールとAIの活用 Claude Codeのプロンプト生成されたHandler

Slide 42

Slide 42 text

©2025 TVer INC. ● 別リポジトリで管理しているOpenAPIスキーマを取得し、GitHub Actionsで型の生成 + SWRを生成する ● Claude Code ActionsでOpenAPIの型を参照し、 MSWのHandler生成と、型エラーの修正を自動化 ● 最終的にPRが生成され、レビューを通して問題なければマージ GitHubワークフローで生成フローを完結させる 42 生成ツールとAIの活用ワークフローを実行する PRが作成される OpenAPIスキーマを取得する AIによるMSWのハンドラー生成 & 型修正

Slide 43

Slide 43 text

43 OpenAPIの型生成 Claude Code ActionによるMSW生成と型修正

Slide 44

Slide 44 text

©2025 TVer INC. AIで生成されたモックデータと MSWハンドラーの活用開始とその結果 ● APIがまだ実装されていない状態でもMSWが返すモックデータを参照して実装を開始することができ、開発スピードが向上 ● StorybookにAPI取得含めてストーリーの作成ができるようになり、実際のユーザーに近い環境での検証をコンポーネントに対して実施可能に ● Storybookの生成に関しても、Claude Codeの Custom Slash Commandを使用し、標準化された Storyの生成を可能に 44 生成ツールとAIの活用

Slide 45

Slide 45 text

Slide 46

Slide 46 text

©2025 TVer INC. 46 ● VOD配信（見逃し配信）のOVPをSTREAKSに移行 ○ 元々リアルタイム配信で使用していたPLAY社のSTREAKSをVODにも採用 ○ VODとリアルタイム配信で同じOVPを使用することで、開発スピードが向上や管理コストが削減。移行時にシーク時のサムネイル機能や画質向上のなども追加 ● 広告リクエストの単体テストの実施 ○ 広告ターゲティングに必要な情報を広告サーバーに渡して、広告を再生するための VMAP/VASTを受け取るが、その際に渡すパラメーターにテストが書かれていなかった ○ そのため、ヒューマンエラーが発生しうる可能性があったので、単体テストを実装し、未然に不具合を防ぐ仕組みを構築 ● プレーヤーに必要なアセットロードの並列化によるパフォーマンス改善 ○ プレーヤーを再生するには、IMASDKやプレーヤーのSDK、その他様々なアセットが必要だが、それらが直列で読み込まれていた ○ 並列で読み込ませてプレーヤー構築までの速度を改善（約1s）動画プレーヤーの改善

Slide 47

Slide 47 text

Slide 48

Slide 48 text

©2025 TVer INC. ● PR毎にプレビュー環境をデプロイする仕組みをS3 + CloudFrontで構築し、レビュー時の検証を容易に ● コードスタイルガイドを書いてルールを明確にしながらAI（Copilot, Gemini Code Assist）に単純なレビューを任せる ● QAエンジニアが、QA項目に沿ったテストケースを元にPlaywrightでE2Eテストを実装 ● ESLintとPrettierをBiomeに統一し、実行速度の向上。pre-commit時に実行し、事前に検証可能に ● 画像サイズを圧縮できるCDNへ移行（ダウンロードサイズを50%以上削減） ● Feature-Sliced DesignとPresentational・Containerコンポーネントのパターンにリファクタリングし、コードの責務を明確に 48 その他の解決策

Slide 49

Slide 49 text

Slide 50

Slide 50 text

©2025 TVer INC. ● 画面の一貫性とバグの発生率の改善で品質を向上できた ● コードがより疎結合で拡張性が高くなり、開発スピードを向上できた ● 生成ツールとAIで手間な作業削減し、ユーザー価値に貢献する開発に集中可能に 50 今まで導入した解決策の結果レビュー依頼から初レビューまでの平均時間初コミットからPRオープンまでの平均時間 Findy Teamsで計測しているリードタイムが改善傾向に 🎉