民放各局が制作した動画コンテンツを無料で視聴できる民放公式テレビ配信サービス「TVer」は、iPhoneやAndroidなどのスマートフォン・タブレット、コネクテッドTV(テレビアプリ)、そしてWebと複数のプラットフォーム向けにサービスを提供してきました。サービス開始以来ユーザー数を順調に拡大し、2025年4月時点でアプリの累計ダウンロード数は8,500万件を超えるに至っています[1]。
このサービスをさらにブラッシュアップし続けるため、TVerのフロントエンド開発チームでは2022年4月の大型リニューアルを機に開発パートナーへの開発委託から内製化への移行を進めてきました。その決断の背景と効果について、同社のサービスプロダクト本部に所属する吉田紳一郎さんと永井洸気さんにお話を聞きました。
地上波と同じように、コンテンツを落とさず届ける
― TVerにおける、お二人の役割をお聞かせください。
永井 2024年3月に入社し、TVerサービス(tver.jp)のWebフロントエンドエンジニアをしています。
吉田 私は2023年4月に入社して、現在はiOS、Android、Web、そして新規コネクテッドTVデバイスといったフロントエンド開発チーム全体のマネジメントをしています。
― TVerというサービスの特徴はどんなところにありますか。
吉田 TVerは、地上波で届けられている放送局のコンテンツをインターネットのチャネルを用いて見てもらうサービスです。地上波の放送では「落ちる」ということはまずありません。インターネット上でも同じサービスレベルをしっかり実現したいという思いで取り組んでいます。
地上波のビジネスモデルと同様に、TVerはユーザーに広告を見てもらうことで収入を得ていますから、広告を届ける仕組みもしっかり作っています。広告も地上波と同レベルの質が要求され、放送と同じ基準の業態審査・素材審査が行われています[2]。
また、重要インフラの一つとして、地震などの自然災害が発生した際でもTVerを通して情報を届ける役割も目指しています。2024年1月に能登半島地震が発生した際はニュース速報の配信を行いました。また、同年10⽉に「24時間ニュースライブ」の配信を開始して、報道・情報コンテンツの配信を強化しました。そういった意味で、一般的なWebサービスよりも重大な使命を担っているという思いでサービスを開発しています。
― アプリのダウンロード数も閲覧数も順調に増加している中で開発の難しさはありますか。
吉田 主にインフラ側の課題になりますが、TVerでは地上波で放送していたスポーツ中継などの続きをリアルタイムで配信することがあります。そんなときには急激にユーザーが増え、スパイクが発生(アクセス数や処理負荷などが一時的に急上昇)して、平常時を想定したサーバー数や運用体制ではさばけないことがあります。
このような場合に備えてフロントエンド側でも、関係するステークホルダーとすりあわせをしながら、キャッシュできるデータはキャッシュしておいたり、無駄なリクエストを減らしたりといった調整を行いながら運用しています。いかに安定して運用するかは大変なポイントの一つですね。
TVerの大きな特徴は、テレビ業界の多くのステークホルダーが関わっていることです。TVerはtoCサービスでもありますが、放送局や広告会社、広告クライアントに向けたtoBのプラットフォームでもあります。UIの改修にせよ、データ構造の変更にせよ、toCとtoBの両面から検討しています。
― TVerの開発体制はどのようになっているのでしょう。
吉田 TVerのエンジニアが関わる部門としては広告事業、放送局向けシステム、そしてユーザー向けのプロダクトという三つの本部があります。私たちはそのうちユーザー向けのプロダクトを開発するサービスプロダクト本部に所属しています[3]。
サービスプロダクト本部のエンジニア部門はさらに、バックエンドとフロントエンドの部署に分かれ、フロントエンドの中にiOSチーム、Androidチーム、tver.jpのWebチーム、コネクテッドTVチームがあり、それぞれ6〜10名程度となっています。 こうしたOSごとの縦軸のチームに加え、アクセシビリティ向上といったミッションごとに横軸でのチームも組織されており、マトリックス組織的な要素もあります。
技術的負債が蓄積したアプリではフルリアーキテクチャを実施
― そもそもTVerが内製化に舵を切ることにした理由を教えてください。
吉田 2022年4月の大型リニューアル[4]の時点で、バックエンドの開発はTVer Technologiesの吸収を機に内製化していた一方、フロントエンドの開発は開発パートナーに発注する体制でした。その開発会社もとてもよく対応してくださっていましたが、TVerが次のフェーズを目指し、開発のスピード感や品質を高めるには、中にエンジニアを抱えて内製化していく方がいいだろうという判断を下しました。
リニューアルの際にはスケジュールが決まっていたこともあり、開発スピードを優先した結果、コードの品質を犠牲にした部分がありました。そのため、技術的負債が一定程度たまってしまっていたのも事実です。
また、リニューアル後にはいくつかの施策を予定していたものの、想定どおりの開発スピードが出せないという課題もありました。コミュニケーションの面では、受発注の関係性があると、同じ会社内にチームがある場合に比べて密度が相対的に薄まってしまうところがあり、そうしたボトルネックを解消したいという意図もありました。
さらに、動画配信サービスが数多く存在する中で「TVerの優位性をどれだけ維持できるか」と考えると、開発のスピードを加速させる必要があると判断しました。
そしてもう一つ、TVerが動画配信サービスにおける社会インフラを目指していく中で、外部に頼る体制では社内にナレッジが蓄積しにくいという課題も認識していました。
― フロントエンドはいつ頃から内製化を進めていったのですか。
永井 2023年4月にフロントエンド開発の部署が立ち上がり、まずはAndroidから内製化を始めました。その後iOS、Webという流れで、約半年ごとの期間をおいて徐々に進めていきました。
吉田 iOSとAndroidのソースコードは、Webに比べて技術的負債が大きかったため、完全にリアーキテクチャをする方針でアプリの再構築を進めています。
負債の具体的な内容は、例えば、何重にもネストされている分岐文があったり、並列処理で書かれているのに実行順序に依存しているロジックがあったりと、初歩的なところから複雑なものまで「あるある」の課題がいくつも存在していました。統一的なアーキテクチャを取り入れようとしたが、担当者によって実装が異なっている部分がありソースコードの統一性も保たれていなかったため、現状のソースコードをベースに拡張していくよりも、フルリアーキテクチャをして作り直す方針を採用したわけです。
― リアーキテクチャはどう進めましたか。
吉田 方向性を検討する際に、iOSならばSwiftUIやTCAのような、今後メジャーになり得るであろうフレームワークを取り入れたり、パッケージマネージャーを用いてマルチモジュール化をしたりすることで疎結合となる構成を目指しました。フィーチャーフラグなどの仕組みも導入し、リリース時のリスクに対する柔軟性も持たせています。また、デザインシステムを構築してUIパーツをコンポーネント化することで汎用性を高め、再利用できる設計にしていきました。
― 課題だったことは何でしょうか。
吉田 iOSアプリとAndroidアプリでは、単体テストもほとんどない状態で、どこかを修正すると「なんでこんなところが壊れるんだろう」ということも起こっていました。ですからリアーキテクチャに合わせてしっかり単体テストやUIテストも整備し、高い品質を維持できる環境づくりを目指しています。
1年半ほどかけて少しずつ作り直してきましたが、いきなり全面的に切り替えるビッグバンリリースはリスクが高いと判断し、マルチモジュール化して少しずつ入れ替えを進めています。2025年1月にリアーキテクチャしたモジュールの一部を無事リリースできており、今後も1年程度の期間をかけて完了させる予定です。
▶ 月間4.5億回再生を超える大規模サービス TVer iOSアプリのリアーキテクチャ戦略 - iOSDC2024 - Speaker Deck
Webフロント内製化は「将来的な拡張」にフォーカス
― Webフロントエンドは、iOSやAndroidに比べるとそこまで複雑ではなかったのでしょうか。
永井 そうですね。負の部分をなくすというよりも、今のものをより良い形にして、今後もコードの品質を保ちながら拡張していくところに目を向けて改善していきました。
― 内製化に伴って、技術スタックはどのように変化しましたか。
永井 フレームワークにはNext.jsを用い、言語はTypeScript、スタイリングはCSS Modulesという大枠は変わっていません。ただリンターのESLintやフォーマッターのPrettierをBiomeへ変えたり、テストでもChromaticを利用してVisual Regression Testing(VRT)[5]を導入した他、ディレクトリ構成をFeature-Sliced Design(FSD)[6]に変更したりと、細かな部分でいろいろと手を加えました。
また、以前はフロントエンドを担当する開発パートナーとバックエンドの内製チームとの間に“落ちている課題”を拾うことがあまりできていませんでした。バックエンドのエンジニアがドキュメントにまとめたAPIスキーマ情報を開発パートナーに展開する際、仕様の認識齟齬や必要なfieldがフロントエンドで記載できていないミスなども発生していました。内製化後は、バックエンドエンジニアがOpenAPIで書いたAPIスキーマ情報を、Webフロントエンド側でTypeScriptの型に変換して落とし込むように自動化し、食い違いを減らしています。
― 先行して内製化を進めた二つのチームから参考にした部分はありましたか。
永井 「開発パートナーからの引き継ぎ後、どういったところが暗黙知になりがちか」「どんな部分をドキュメントとして残しておいてもらうのがいいか」といった、落とし穴になりがちな部分をヒアリングしたことがとても役立ちました。
コードやコミットメッセージにチケットを紐付けたり、関連する仕様へのリンクを張っていただいたりして、開発パートナーには大変丁寧に引き継ぎをしていただきました。コードに記載のコメントやチケットリンク先を見ただけでキャッチアップできるような形にしていただいたため、ポイント、ポイントで疑問を抱くことはあまりありませんでしたね。
― 引き継ぎのほかには、どんな点に苦労しましたか。
永井 実は、ドメイン知識の把握は想像以上に大変でした。TVer特有の業務フローはもちろん、放送業界の構造や用語といったビジネスドメイン、さらに動画プレーヤーの内部構造や外部システムとの連携などの技術的ドメインまで、疑問点は尽きません。正直、網羅的かつ体系的なドメイン知識の習得には、まだまだキャッチアップが必要だと実感しています。
社内のドキュメントをきちんと読んで、必要に応じて関係者と話して疑問点の解消に努めています。また、月に一回開催される社内の勉強会「TVer Tech Talk」でも、広告配信に関する技術をはじめ、いろいろなノウハウが共有されるため、そういった機会も活用して日々キャッチアップしています。
― Webフロントエンドチームのビルディングはどのように行ったのでしょう。
永井 2024年10月の時点で3名体制になったのですが、メンバーそれぞれのバックグラウンドが異なるため、価値観にはどうしても違いがあります。Webフロントエンドチームとして一つの目標の下で開発できるよう、毎日の朝会でカンバン形式を用い、今悩んでいることや課題をざっくばらんに起票し、話していきました。最初の頃はお互いのことをよく知らない状態だったので、朝会冒頭に5分から10分ほど雑談の時間を設け、チームとしての雰囲気を醸成していきました。
― 「Lean Coffee」のような形式を採用していたのですね。具体的にはどういった話が出たのですか。
永井 「lintのルールとしてこんなものを導入したい」といった小さなことから、テストの方針やディレクトリ構成といった大きな議題に至るまで起票して議論し、後者については何回もミーティングを重ねて認識をそろえていきました。以前はなかったコーディング規約も整備し、朝会で話し合いながら徐々に増やしています。決まった内容はドキュメントとして残し、新たに加わってくるメンバーにも見てもらうようにしています。
― テストに関しては何かこだわりがあったのでしょうか。
永井 「そもそもなぜテストを書く必要があるのか、書くとしてもどの粒度でやるのか」というのは、チームによってばらつきが生じがちです。そういった部分をきちんと整理し、Webフロントエンドチームとして「テストには価値がある」という認識を持った上で、テストの粒度をそろえていくことは大事だと思っています。
現在ではさらにメンバーが増え、業務委託も含め6名体制で開発を進めています。先ほどTVerのフロントエンド開発チームは、技術軸とミッション軸という二つの軸でクロスファンクションのような形になっているとお話ししました。それを意識し、ミッション軸で分かれたときにチームをリードできる人材の採用を重点的に進め、幸運なことに、一緒に改善していきたいと思える仲間を増やすことができました。
― 内製化の前後で、何か変化は感じていますか。
永井 月に1回くらいのスパンでリリースを行っていますが、内製化を機に、一度のリリース期間の中に含まれるチケット数が約2倍に増えています。本格的に指標を計測していくのはこれからですが、開発スピードやソフトウェア品質を計測するサービスを導入し、開発生産性を向上できるように土台を整えました。
吉田 目標としては月に2回くらいのペースでリリースしたいと考えているのですが……。大型のライブ配信を控えているタイミングなどはリスクも高いので、リリース頻度は流動的になってしまっているのが実情です。
内製チームで臨んだ「OVP」切り替えで開発しやすさを実感
― 内製化後に新機能の追加も行ったのでしょうか。
吉田 TVerのコア機能で、エンコード処理などを担うOnline Video Platform(OVP)を切り替えました。 TVerサービスの主要機能であるVOD配信(見逃し配信)について、開発スピードの向上やコストを抑えた画質向上などを目的に、VOD配信のOVPをリアルタイム配信でも採用していたPLAY社の「STREAKS」に切り替えることにしました。PLAY社とはリアルタイム配信向けSDKをともに開発した実績があり、フットワーク軽く動いていけることもわかっていたので、将来を見据えてもその方がいいと判断しました。フロントエンド開発チームだけでなく、バックエンドやデザイナー、QAなど、多くのチームが関わり、2024年3月頃からプロジェクトを始め、今年の2月にリリースしました。
― 1年ほどかかったのですね。
吉田 実際の開発期間に加え時間をかけたのは、放送局をはじめとするビジネスサイドとの調整ですね。動画配信機能の根幹であるOVPの切り替えをTVerサービスの停止なしで確実に行うために、二つのOVPを並行運用するための検討や、コンテンツを入稿するシステムを持つ放送局技術担当との調整に十分な時間をかけました。
永井 社内からも放送局からも、「OVPの切り替えによって何が変わるのか」、「事故なくリリースできるのか」と心配する声を多くいただきました。ですので、関係者と定期的に情報連携を行ったほか、リリース前の検証においても、本番同等の環境を用意してしっかり確認してもらった上で進めていきました。 特に慎重を期したのはバックエンド側で、切り替えも一度にすべて行うのではなく、切り戻しできるような体制を整えた上で、新旧のシステムを並行して動かし、問題なく動くことを少しずつ確かめながら、密に連携しながら切り替えていきました。
― フロントエンド側ではどんな部分を開発したのですか。
永井 プレイヤーの構築だけでなく、広告配信の制御やログ送信などを実装しました。ユーザー体験を変えないことを前提に、シークバーサムネイル(動画の再生バーを動かしたときに表示される、再生位置に対応したプレビュー画像)や画質向上なども追加しています。
― シークバーサムネイルとはどのような仕組みなのでしょう。
永井 1枚の画像に対して20枚以上のサムネイルが敷き詰められている形になっています。このサムネイルを1枚1枚リクエストで取るのではなく、タイミングに応じてどのサムネイルを切り取るかという細かな制御が必要だったので、実装は難しかったですね。
― ほかに大変だったところはありましたか。
永井 いちばん気を遣ったのは、これまで使ってきたOVPでできていた機能が、リグレッションを起こすことなく新たなOVPでも実装できるかという仕様の整理の方です。ドキュメントの確認やコミュニケーションを綿密にやりました。
― OVP切り替えで内製化しておいて良かったな、と感じたことはありますか。
永井 内製化したことで、開発自体はとてもやりやすくなりました。OVPの変更に当たっては、以前であればTVerとOVPサービス提供者、そして開発パートナーの三者でやりとりを行う必要がありました。それがTVerとOVPサービス提供者の二者で済むようになり、調整やコミュニケーションがスピーディに行えるようになったと感じています。
またWebだけでなくiOS、AndroidやQAなどの各チームが内製化されていたため、社内の一度のミーティングで仕様を伝えて確認するだけで済み、デバイス間の認識の齟齬や仕様の不一致も少なくなったと思っています。
吉田 開発をパートナー会社へ発注する場合だと、要件をしっかり固めてから実装してもらい、検品し、その後「やはりこうしたい」という変更が発生するとまた最初からやり直して……というリレーを何度も調整する必要がありました。内製チームであれば、ある程度不確定要素が含まれる状況でも実装を始められますし、その都度仕様変更に柔軟に対応できます。そういった意味で、かなりスピード感を持って対応できたように思います。
内製化の次は「一人一人の生産性を高める」
― 最後に今後の取り組みについて聞かせてください。
永井 チームづくりについては一区切り付いたので、今後は、プロダクトの品質や生産性の向上を進め、ちゃんと「内製にして良かったね」と思ってもらえるように改善していきたいです。
吉田 TVerは今後、サービス規模をさらに拡大し、「日本人の誰もが広く使うサービス」になっていきたいと考えています。それを達成するためには、単純に人員を増やすという戦略もあるでしょうが、人が増えればその分、逆にコミュニケーションコストがかかるといった問題も出てきます。
内製化し、チームのベースができたことを踏まえ、この先は一人一人の生産性をいっそう高め、ビジネスサイドの要求に迅速に応え、ユーザーにさらなる価値を提供できるようにしていきたいと考えています。その手段としては、生成AIなどの新しい道具も積極的に導入していきたいですね。
冒頭でお伝えしたように、TVerは動画配信サービスにおける社会インフラとしての役割も目指していきます。ですので、コンテンツの品質、広告の品質はもちろん、プロダクトの品質もしっかり担保し、ユーザーの方に「TVerって、安心・安全に見れるよね」と思われるサービスにしていきたいと思います。
取材・構成:高橋 睦美
編集・制作:はてな編集部
-
参照 株式会社TVer「累計アプリダウンロード数8,500万ダウンロードを突破」 ↩
-
参照 Screens「成長加速のTVer、取締役が語る広告価値アップの背景 〜Interop Tokyo 2024 レポート」 ↩
-
参照 株式会社TVer採用サイト「エンジニア組織の全体像」 ↩
-
参照 Screens「TVerが大幅リニューアル!「TVer ID」によるデバイス連携やリアルタイム配信に対応」 ↩
-
UIの見た目に意図しない変化がないかを画像で比較して検出するテスト手法 ↩
-
機能(Feature)単位でアプリケーションを構造化する設計手法 ↩