サービスプロダクト本部技術統括（TVerサービス開発部門内のVPoEみたいなポジション）兼バックエンド部部長の脇阪(@tohae)です。 この記事はTVerアドベントカレンダー 2024 25日目の記事です。24日目の記事はSREチームの鈴木さんの「AWS re:Invent 2024に1人で参加してきました」でした
今年の1月からEMとして入社し、約1年間開発組織の拡大や開発生産性の向上のためにいろいろな取組みを行ってきました。 本記事では約1年前のTVerのエンジニア組織がどのような課題を抱えていて、それに対してどのような手を打ってきたかというところをまとめます。
続きを読むこの記事は、TVerアドベントカレンダー23日目の記事です。
22日目の記事は@a-matsuoka-tverさんの「大規模サービスを支える小さな開発組織のプロダクトマネジメントチャレンジしたこと」でした。
皆さん、こんにちは、コネクテッドTV（以下CTV）に関するビジネス領域を担当している井出と申します。 業務内容としては、毎度説明に迷うのですが、 すごくシンプルにいうと業務内容としては、TVer（特にCTV)を商材とした営業です。 TVerに関わる全ての人が作り上げているTVerをよりパートナー様にとって価値を感じてもらえるよう、 日々TVerの市場における価値向上に努めています。
去年書いた記事はこちらです。
そもそも、CTVってなんやねんという方向けに補足させていただくと、
CTVとは、テレビ自体がインターネットに接続されているスマートテレビはもちろん、 Fire TV、Chromecastなどのストリーミングメディアプレイヤー、 PlayStationやXboxなどのゲーム機、プロジェクター、セットトップボックスなどの外部機器を接続している場合のテレビも含んでいるものを指します。 （※TVerはゲーム機にはまだ対応しておりません、ごめんなさい！） 自分の家のテレビや、モニターがインターネット接続に対応していない場合も、外部機器を接続することで、コネクテッドTVとして、動画サービスなどのエンタメを堪能することができます。
去年はCTVの概要から、TVerにおけるCTVの位置付けなどについてお話ししました。
今回は、その続き及びCTVにまつわる世界の流れなどについて書いていきたいと思います。
具体的には、
について書いていきます。
TVは市場としても拡大しており、 下記の記事では、
近年、動画ストリーミングや見逃し配信の視聴者数の増加に伴って、CTVの普及が進んでいます。テレビ端末のネット結線率は、2015年に東京50Km圏の24.5%でしたが、2021年には半数の50%を突破。2023年には59.6%まで上昇しています。2015年からの9年で2.4倍増と、着実に増加していることが分かります。
「コネクテッドTV（CTV）とは？」今さら聞けない！基本の『キ』｜VR Digest plus メディアとビジネスのミライを見つめる。 | ビデオリサーチ
と書かれている通りに、約60%がインターネットに接続されたテレビ、つまりCTVとなっています。
普及が進んでいるアメリカにおいては、
Leichtman Research Groupの調査によると、米国のTV世帯の87%がなんらかのCTVデバイスを少なくとも1台所有していることが明らかになっています。この数字は、2020年の80%、2017年の69%、2012年の38%から劇的に増加している状況です。
と実に、90%近くがCTVとなっているようです。急速に伸びている背景には、NetflixなどのVODサービスの普及の影響が強いとは思いますが、 アメリカの潮流は少し先の日本と考えられますので、日本も近い将来こういった流れになると考えられます。
サイバーエージェント社の調査によると、動画広告の市場は、2024年には7,209億円の市場規模になる見込みで、
「コネクテッドテレビ向け動画広告需要は昨年対比137.0％となる740億円と、市場全体の成長をけん引する高い成長を遂げています。」
とのことで、急成長を遂げていることがわかります。
サイバーエージェント、2023年国内動画広告の市場調査を発表 | 株式会社サイバーエージェント
アメリカにおいても、状況は変わらず、伸びていますが、CTV広告を取り巻くプレイヤーに変化がみられています。 従来CTV広告は、主にメディアや、広告代理店が販売していたものでしたが、 昨今では、小売企業、つまり、リテール企業が参入しています。
日本でいうリテールメディアというと店頭にあるデジタルサイネージなどを思い浮かべると思いますが、 アメリカでは少々状況が違います。
アメリカで、リテールメディアというと、店舗での広告はもちろん、検索広告、ECサイト上での広告など全てを含みます。
ここで、急速に広告ビジネスを伸ばしているウォルマートの例をご紹介したいと思います。
大手スーパーチェーンであるウォルマートは、自社の購買データとマッチさせ、広告を表示させるビジネスを展開してきました。
ここにさらなるビジネス展開として、テレビメーカーのVIZIOを買収しました。
なぜ、テレビメーカーを買収したかですが、プライベートブランドでの販売の拡充ではなく、 CTV広告を自社で売りたいという意図があるようです。
対象となるのはVIZIOのTVを所有しているユーザーであり、 広告バイヤーに対してはウォルマートのデータとVISIOのデータを組み合わせて分析し、より精度の高いターゲット広告を売ることができます。
例えばテレビでセサミストリートを見始めて、ウォルマートのECでは子供服やおむつを買い始めた人がいた場合、 ウォルマートは、ウォルマートのECや、VIZIOの双方のデータを合わせて分析しながら、 その特定ユーザーに対して、セサミストリートが好きな子供がいるユーザーとして、 ターゲットを絞った広告を双方で配信できるようになるため、広告主としてはより効率の良い配信ができるようになります。
ウォルマートのように、買収までいかないまでも、自社で持っているデータを活用し、 アメリカのリテール企業は、自社広告だけでなく、 他社広告であるCTV広告を販売することで広告ビジネスを急速に成長させています。
この背景には、3rdPartyのCookie規制も強く影響を与えており、 1stPartyでデータを持っているリテール企業が強みを活かしているというところがあるようです。
日本においては、まだまだ店舗が強いリテール企業が多く、ECサイトの広告ビジネスまで手を回せていない印象がありますが、 アメリカの例を参考に今後増えていくかもしれません。
リテールメディアの事例については、下記で詳しく解説されているようですので、気になる方はご覧ください。
余談ですが、セブン-イレブン・ジャパンの方がリテールメディアについて語られている記事もありました。 リテールメディアについて気になる方はご覧になってみてください。
スマートフォン/タブレット、PC Webサイトに加えてCTVが登場しましたが、 スクリーンを持つデバイスは他にもあります。
例えば、EchoShowなどのモニター付きのAIスピーカー、コネクテッドカー、VRグラスなどが挙げられます。
AIスピーカーにはすでに一部端末で、TVerは対応しており、EchoShowでTVerをご覧いただけます。 ぜひ、キッチンや、寝室などAIスピーカーを置いている場所で、ご活用ください！
車載については、世界の車がインターネットに接続されるようになり、コネクテッドカーと言われるようにもなりました。 当初は、カーナビや車のOSなどの車の機能に関するアップデートなどに用途は限られていましたが、 5Gの登場で、高速化が始まり、車内でのVOD視聴ができるようになりました。
韓国企業であるLGも運転席のモニターはもちろん、後部座席でのエンタメ体験ができるソリューションを出す予定です。 Press Release | LG's Advanced Automotive Content Platform Features in Kia's Newest Electric Vehicle
後部座席は第二のリビングのようにくつろぐためにはエンタメは欠かせない存在になってきそうです。
VRグラスについても、メタ社の「Meta Quest」シリーズや、ByteDance社の「Pico」シリーズ、ソニー社の「PlayStationVR」シリーズに 加え、2024年は、Apple社が満を持して投入したVisionProなどもあり、 各デバイスでエンタメを楽しめます。
苦戦しているイメージのVRですが、2024年は上向くことが予想されているようです。 世界AR/VRヘッドセット市場、2023年第2四半期は44.6％減--2024年に上向き46.8％増へ - CNET Japan
スマートテレビで9社、ストリーミングメディアプレイヤーで2社、プロジェクターで3社、セットトップボックスで3社 が去年執筆時の対応状況でしたが、 現在では、ニトリ様販売のAndroidTV、MAXZEN(マクスゼン）、スカパー!＋ネットスティックが加わり、20メーカーへの対応ができております。
スカパー!＋ネットスティックにはTVerボタンも搭載されています。
この記事をご覧になっている方々のお持ちのデバイスももしかしたら、対応しているかもしれません。 ぜひ、TVerをCTVデバイスでお楽しみください！
今では、リリース当初1.9%ほどだったデバイス別再生割合は、2023年1月には、31%達し、
2024年10月には、36.9%と20倍以上に成長しました。
TVerを使う3人に1人以上は、CTVを利用して、視聴しているということになります。
また、再生数も、
パリ2024オリンピック™や、ドラマのヒットを追い風に、1.5億回を突破しました。
私は、冒頭触れた通り、TVerでCTVのマーケティング領域に限らず、 BizDevをメインに担当しています。 具体的には、 * 各メーカー様とアライアンスの調整 * CTV領域の外部へのマーケティング活動全般 * 社内のCTV関連部署との連携
などを行なっております。
マーケティング面での効果最大化、効果検証（CTVの出稿はまだまだ未成熟で計測できないことも多いので、試行錯誤しています）などの 挑戦はもちろん、CTVにまつわる全ての部署、プロジェクトとの連動性を持って、 TVerのCTVグロースのために日々社内外の皆さんにお力を借りて奮闘しています。
最後に去年書いたことを改めて記したいと思います。
自分自身の思いとして、 自分の仕事を通して、エンドユーザーに、 感動体験を届けることを仕事の軸にしています。 TVerでもたくさんの感動をユーザーに届けられるよう仕事に取り組んでいます。 UIUXの改善、リモコンボタンからのダイレクト起動、作品との出会い、など TVerのCTV体験を今よりもよく、 そして、テレビを解放するために、日々邁進してまいります。 ぜひ、CTVの領域にも注目してみてください！
ちなみに採用も頑張っています、ご興味ある方はぜひ！ カジュアル面談しましょう！ herp.careers
以上です。長々と稚拙な文章にお付き合いいただきありがとうございました。 また、別の話題でどこかで書いてみたいと思います。 引き続き、TVerを宜しくお願いします！
明日は @ayt_szkさんの「AWS re:Invent 2024に1人で参加してきました」です。お楽しみに！！！
この記事はTVerアドベントカレンダー2024 20日目の記事です。 19日目の記事は @0906koki さんの TVerのWeb フロントチーム内製化への道のりとこれから でした。
こんにちは。TVerでiOSエンジニアをしている 小森 @mathtanguu です。
今回は少し間が空いてしまいましたがiOSDC Japan 2024で登壇した話と結果その後どのような反響があったのかを記事にしたいと思います。
以前の参加レポートで弊社EMの高橋が記事にしてくれたように、今年のiOSDC Japan2024のスポンサーセッションにて、「月間4.5億回再生を超える大規模サービスTVer iOSアプリのリアーキテクチャ戦略」という内容で登壇しました！
初めてのiOSDC Japan登壇かつリアーキテクチャという擦られまくっている内容で皆さんに受け入れてもらえるのか正直不安はありましたが、多くの方々にセッションを聞いていただけただけでなく、
Ask The Speakerにも沢山の方々が来てくださり、リファクタリングやリアーキテクチャの向き合い方について同じ課題感を持っている方々と
ディスカッションできとても有意義な時間を過ごせました。
来てくださった方々ありがとうございました。
詳細な登壇内容については是非、動画やスライドを参照していただければと思います！！
TVerではカンファレンススポンサーなどを含む技術広報の活動は採用活動の一環として行っており、結果候補者の方々の興味・認知を獲得できたのかという観点も重要になってきます。
直接的な興味・認知を効果検証するのは難しいのですが、iOSDC登壇前後のカジュアル面談数をみてみると、明らかにiOSDCが開催された2024年8月直後に大きな反響があったことがわかります。
iOSDCを聞いてカジュアル面談に応募してくださった方もいましたし、元々スカウトを送っていた方がiOSDCの登壇を聞いて再度メッセージを送ってきてくれるパターンもありました。
また、カジュアル面談の短い時間では伝えきれなかったリアーキテクチャの詳細な取り組みもiOSDCでの発表やその資料を元に詳細日お伝えしやすくなったことで、候補者の方がTVer入社後の働くイメージを持ちやすくなり、応募により繋がりやすくなったのではないかと考えています。
その結果、採用にも繋げることができて私しかいなかったiOSエンジニアが
なんと来年の1月から2名増える予定になりました！！！
このように一定採用活動への効果が出たと考えておりますので、引き続きカンファレンスや技術イベントなどの登壇を通してTVerのiOS開発の現状を皆さんにお伝えできるような機会を増やしていきたいと思います。
明日は @yoshi001201 の 「PdMとして持ちたい「施策を出す前に考える心のチェックリスト」 です。ご期待ください！
TVer で Web フロントエンドエンジニアをしている永井です。 この記事は TVer アドベントカレンダー 2024 19 日目の記事です。 18 日目の記事は @k0bya4 さんによる 「Atlasを使った宣言的マイグレーションでDBスキーママイグレーションを自動化する」 でした。
19 日目の記事では、Web フロントエンドチームの内製化について紹介します。
※ TVer の Web フロントエンドは、広告プロダクトである「TVer 広告」の配信システム・広告周辺領域の開発を行うチームと、tver.jp といったユーザー向けのプロダクトを開発するチームの 2 つあり、今回の話は後者に関するものとなります。
現在 TVer の Web フロントエンドチームでは、tver.jp の フロントエンドを開発をしています。2024 年 12 月時点では、 3 名の正社員と 1 名の業務委託の計 4 名体制で開発しており、月間ユニークブラウザ数が 4,000 万 MUB を超える大規模プロダクトではあるものの、各々が高い専門性とオーナーシップを持ちながら少数精鋭で開発を進めています。
しかし、1 年前を振り返ると、TVer の Web フロントエンドの開発は外部ベンダーに委託しており、TVer 社内で Web フロントエンドのチームは存在していませんでした。
そうした状況の中、私が今年の 3 月に 1 人目の Web フロントエンジニアとして TVer に入社し、そこから約半年をかけて外部ベンダーとの契約終了と内製チームの立ち上げを行ってきました。
今回は、TVer の Web フロントチームの内製化への道のりと、これからの Web フロントチームについてお話しできればと思います。
先ほど Web フロントエンドを外部ベンダーに委託をして開発をしていたとお話ししましたが、今まで TVer では Web フロントエンド以外にも iOS、Android も同様に外部ベンダーに委託し、TVer はその開発の管理を行う形でユーザーに TVer を届けていました。
我々のミッションは「テレビを開放して、もっとワクワクする未来を TVer と新しい世界を、一緒に」であり、ミッションを軸に更なる成長を求めて 、スピード感を持って TVer の開発を進めていく必要があります。
そのためには、更なる品質を求めて引き継いだコードの拡張性や保守性や、開発イテレーションを改善していくことが重要です。
そのような課題感の中からモバイル、Web、QA 含めたフロントエンドの開発を内製化する計画が始まり、内製化の走り始めとして Android の内製チームが 2023 年の 1 月から立ち上がりました。 そこから 2023 年 8 月に QA エンジニアが入社して QA 内製チームの立ち上げ、 10 月に iOS エンジニアが入社して iOS 内製チームの立ち上げがスタートし、Web フロントエンドも、私が 2024 年 3 月に入社して内製チームが立ち上がりました。
ここのフロントエンド全般に関する内製化のお話は、以前 HR note の中で、EM と iOS、Android エンジニアのインタビュー記事がありますので、詳しく知りたい方は是非読んでみてください。
先ほど書いた通り、Web フロントチームの内製化は 2024 年の 3 月から立ち上がり、そこから半年をかけて内製チームを作っていきました。 入社した当時は私 1 人だったので、内製チームを作っていく上で、以下のことが最初のミッションとなりました。
入社した当時のチーム体制は、TVer 側は私 1 名と、外部ベンダーの Web フロントエンジニア 2 名の計 3 名でスタートしました。 当時は私が 1 人目の Web フロントエンジニアでしたので、Web フロントエンドに関する社内外からの質問や相談が集中することになります。しかし、私自身放送業界が未経験だったため、まずは 放送業界、動画配信技術、TVer 社内で使用される用語の整理や、コンテンツ入稿から TVer で配信されるまでの流れ、上司との 1on1 での細かい不明点の整理を行い、自分の知らないことを徐々に減らしていきました。
特に Web フロントエンドにおけるコア機能である VOD（ビデオ・オン・デマンド）や LIVE を視聴できるプレーヤー周辺の理解には苦労しました。一口にプレーヤーといっても、そのプレーヤーには広告を視聴できるようにするためのアドサーバーとの連携や、視聴ログの送信、画質や音量調整など、様々な処理や機能を包含してユーザーに提供しています。こうした部分に関しては、実際の不具合修正によるキャッチアップや外部ベンダーとの MTG などで疑問点をつぶしていきました。
とてもありがたかったこととして、外部ベンダーのエンジニアが内製化を見据えたコードの実装やドキュメンテーションをしてくれたことです。例えば、外部ベンダーとの契約が終了した後にコードの意図や背景を聞くことは難しくなりますが、それに備えてコードの各所にそのコードを実装した意図、背景のコメントや、そのコードを実装するために TVer サイドとやり取りをしたチケットや Slack のリンクを添えてコミットしてもらっています。
契約が終了した現在でも、コメントやリンクを辿ることでそのコードの意思決定の背景を掴み取ることができているので、内製チームで開発を進めていく上で大変助かりました。
上記のように私がキャッチアップしてきた内容は後から入社したエンジニアも必要になる知識であるので、入社した後に体系的にキャッチアップできるようにオンボーディング資料にまとめて共有するようにしました。
内製化を進めていく上で、私 1 人ではこの大規模プロダクトの Web フロントエンドは開発できません。そのため、TVer の開発と並行して、入社して早い段階から正社員と業務委託の両軸で TVer のフロントエンドを一緒に作ってくれる方を探しました。
Web フロントエンドの採用を進めていく上で、以下のようなことを重視していました。
TVer の Web フロントチームはサービスの規模からすると小さく、各々が持つ裁量はその分だけ大きくなります。また、既存のコードには拡張性や保守性の観点で様々の課題があり、そうした課題を自ら発見し、時には関係者を巻き込みながら修正していく動き、そして技術力が必要になってきます。
このように、まずは今のフェーズで必要な Web フロントエンジニアの候補者イメージを定め、それを上司や人事の方とすり合わせながらジョブディスクリプションを精査していきました。そして、こうしたイメージに合う候補者のスクリーニングや、カジュアル面談、面接の実施、内定者へのオファーレターなどを作成していきました。
そのような形で採用を進めていった結果、先ほども書いた通り、私含めて合計 4 名の Web フロントチームになりました。各々が高い専門性やそれを土台にした推進力を持っており、私 1 人ではできなかった様々な改善がこの数ヶ月で進んでいくことができ、とても感謝しています。
TVer の Web フロントエンドは内製化が始まったばかりで、解決したい課題は山のようにあります。ただ、この数ヶ月でもチームで沢山の改善を行うことができました。 代表的なところで言うと、以下のような感じです。
私たちは各々がプロジェクトを別で持って進めていますが、朝会で毎朝集まって、それぞれが改善したい内容やちょっとした共有、相談事項をカンバン形式で持ち寄って議論しています。
その他にも、通常リリースに含めるチケットの数の増加や PR Open から Merge までのリードタイムの短縮など、内製化する前とした後で大きく改善できていると実感しています。
しかし、私たちが解決したい技術的な課題や開発フローの改善点はまだまだ山積みです。そして、TVer というプロダクトも更なる成長を求めて様々な拡張が予想されています。その為には更なる仲間が必要です。
TVer の Web フロント技術は、tver.jp に留まらず、CTV（コネクテッド TV） というデバイスやその他様々な場所で使用されており、Web フロントエンドエンジニアが活躍できる場所は多く用意されています。
TVer の Web フロントエンジニアは絶賛採用中ですので、もし少しでも興味がある方はお気軽に下記からご応募ください！
TVer アドベントカレンダー 19 日目の記事では、Web フロントエンドチームの内製化について書きました。内製化はスタートラインに立っただけなので、ここからどのように内製チームとして TVer の成長に寄与するかが大切になります。2025 年も変化を楽しみながら開発していきます。
明日は @hide0101 の 「iOSDC Japan 2024登壇してきました&その後！」 です。ご期待ください！
この記事はTVerアドベントカレンダー2024 18日目の記事です。
17日目の記事は @HaSuzuki さんの 「Jetpack Compose で AppSearch に対応する」 でした。
こんにちは。TVerでバックエンドエンジニアをしている 小林 @k0bya4 です。
今回はDBマイグレーションツールであるAtlasを導入して、DBのスキーママイグレーション作業の自動化を進めていることについて書きます。
TVerサービスのバックエンドではDBスキーマのマイグレーションが必要なケースで手動でのクエリ実行によるスキーマの変更を行っています。
自動化を行う前の状況は
といったもので、課題としては以下のようなものがありました。
今回DBスキーママイグレーションの作業を自動化することで、クエリ実行時の人為的なミスに起因するリリース時のリスクの低減とリリース作業のリードタイムの削減を目指します。
今回スキーママイグレーションの方式として、主に宣言的スキーママイグレーション(Declarative Migration) が可能なツールを検討しました。
宣言的スキーママイグレーションを行うツールとは、理想状態のスキーマを定義に対してマイグレーション対象のDBのスキーマの状態が同一となるように差分を検知してddlを作成・実行していくようなアプローチで処理を行うツールです。
TVerサービスのバックエンドでは、今後テーブルの新規追加を伴う多数のプロジェクトが予定されています。 特に開発環境では試行錯誤を繰り返しながら頻繁なスキーマの変更伴うデプロイやローカル開発でのスキーマのsyncがしやすいように、開発者の負荷を減らすことを優先して都度差分を管理するバージョン管理型マイグレーション (Versioned Migration) ではなく、宣言的なマイグレーションが利用できないかを検討しています。ddlがオンラインで実行できるかなどチェックする必要はありますが、後述のワークフローでカバーできる判断をしています。
AtlasはGo製で宣言的マイグレーションとバージョン管理型のマイグレーションの双方に対応したツールです。
比較した他のツールについては今回割愛しますが、主に以下のメリットからAtlasを採用しています。
Atlasの設定ファイルはHCLで記述します。 理想状態のスキーマの定義として参照するSQLやHCLのファイルのパスなど、プロジェクト単位や環境単位で定義できます。 （Atlasでは、スキーマの定義にもHCLを使うケースを想定して書かれていることが多いです。）
今回、スキーマの破壊的な変更についてはスキップできるよう設定を追加しました。 HCLで設定を記述できるので、以下のように実行時の引数を参照してdiffのskipをするようにしています。
variable "destructive" {
type = bool
default = false
}
diff {
skip {
drop_schema = !var.destructive
drop_table = !var.destructive
drop_column = !var.destructive
}
}
CDでマイグレーションの実行を行う際の環境についても紹介します。 今回、AWS環境のプライベートサブネットにあるRDSにクエリ実行するにあたってCodeBuildを利用したワークフローを構築しています。
以下のようなワークフローでの実行を行います。 宣言的マイグレーションの採用理由で述べたddlの正当性についてのチェックはツールが生成したddlをPRのレビュー時と開発環境でのデプロイ時に行うこととしています。また、破壊的な変更についてはリリースのロールバックが必要となったケースなどで、スムーズな切り戻しができるようデプロイと同期的に行わないこととしました。
2024年4月よりCodeBuildをself-hosted GitHub Actions runnerとして利用できるようになっています。
GitHubとの接続方法などは以下の手順が詳しいため、ここでの説明は割愛します。
https://docs.aws.amazon.com/codebuild/latest/userguide/action-runner.html
VPC内に配置したCodeBuildをself-hosted GitHub Actions runnerとして利用することで、RDSに接続するDBマイグレーションのワークフローをGitHub Actionsの構文を利用して実行できます。
Atlasを利用して、宣言的スキーママイグレーションの仕組みの導入を進めていることについて書きました。 宣言的マイグレーションとGitHub Actionsのself-hosted runnerを利用して、バックエンド開発者の負荷を減らしたDBスキーママイグレーションの実施ができる形を目指しています。 現在は本番環境への導入に向けて準備を進めている状態なので、実運用上の課題など出てくれば追って発信できればと思います。
TVerでは、開発チームのスケールのため開発サイクル上の課題の改善に取り組むEnablingチームがあります。
Backend Enabling Team ができました in TVer
今回のDBスキーママイグレーション自動化の取り組みも、Enablingチームで主導しているTVerサービスのバックエンドリアーキテクチャプロジェクトの一環となっています。 Enablingチームの最近の取り組みについてはTVerアドベントカレンダー2024 15日目の記事 「Backend Enabling Teamと立ち上がりの半年」 もぜひご覧になってください。
ご興味を持っていただけた方は、ぜひカジュアル面談へのご応募お待ちしております。
https://herp.careers/v1/tver/xujbYGz8ZD5w
明日は @NagaiKoki さんの「Webフロントチーム内製化への道のりとこれから」が公開されます。
本記事はTVer Advent Calendar 2024の15日目の記事です。
14日目の記事は @gapao_ken さんの「テレビ局の技術職がPMに挑戦」でした。
こんにちは、3年連続で15日目の記事を書いているバックエンドエンジニアの伊藤です。今年もよろしくお願いします。
15日目の記事では、2024年7月に出来たBackend Enabling Teamの最初の半年について振り返っていきたいと思います。 立ち上げ期のこの半年間、どこを見て何をしたのかを書こうと思います。
機能開発チームがメンバーの能力になるべく依存しない状態で、より多くのサービス課題に注力できるように「当たり前を整備していく」ためのチーム、という位置付けでEnabling Teamは始まりました。
そしてこの上で「目の前のことにひたすら取り組む」ことが立ち上げ時最初の方針でした。 これは課題が多く、とにかくアウトプットし整理することが最優先で求められていたためです。
この半年たくさんの課題に取り組んでいく中で短期的な目標や直近でやるべきことが具体的に見えてきました。
現在は「機能開発チームがスケールできる状態にする」「一人一人の開発生産性を上げる」という少しだけ小さくした目標を手前に置いて課題に取り組んでいます。 その中でも特に開発難易度を下げることが直近の大きな課題となっています。
過去に立ち上げたタイミングで書いた記事がありますので、もし興味があればそちらもご覧ください。 techblog.tver.co.jp
TVerの機能開発チームは4人とごく少数な状況です。
人月の神話を考慮したとしても、中長期的に機能開発速度の上限値を上げるには増員がどうしても必要です。 本音を言えば短期的にも欲しい状況ですが、現状だと新規メンバーが開発をするには多くの知識が必要になっていました。 そのため、新規メンバーがなるべく早く機能開発に馴染めるような環境を作る必要があります。
オンボーディングの充実は機能開発チームが推進しつつ、より一般的な技術スタックでアプリケーションの開発ができる状態を提供することを進めています。 経験の浅いエンジニアでも手順とレビューがあれば機能開発に取り組めるような状況を作れるようにしたいと考えています。
たとえば以下のようなことを行っています。
この中でコスト最適化の見直しは少し特徴的な取り組みかなと思っています。 たとえば、アプリケーションレイヤーでのキャッシュを駆使した高速化をあえてやめる判断をしました。 現在のTVerではコスト以上に開発容易性のようなアプリケーション特性を重視しています。
また余談ですが、この記事を書こうと思いたった11月にsqlboilerはメンテナンスモードに入りました。
代替候補として上がっているBobを少し触ってみましたが、MySQLのバージョンによって動かなかったりとまだ不安定な印象を受けています。移行時に他のライブラリと共存が可能な箇所なので一旦はそのまま使い続けることにしました。
当初は不足する機能をアプリケーション基盤に順次足していく予定で進めていましたが、やるべきことと内製FWの相性がどうしても悪く、達成するには内製FWとアプリケーションの両者に対して大きな変更を加える必要がありました。 特にmiddleware(http.Handler)やアプリケーションロガーの導入が難しく、さらにテストによる動作保証もほぼ存在せずテスタビリティもかなり低い状況でした。
この状況下で既存アーキテクチャの基盤に手を入れつつさらに機能開発を進めるには、多くの部分を手作業によるQAによって継続的に動作保証する必要がありました。 既存のコードに大きく手を入れるよりリスクやコストが低いと判断し、リアーキテクチャへ踏み切ることにしました。 また、機能開発の状況的にも新しいアプリケーション基盤を作るならこのタイミングがかなり都合が良いという事情もありました。
全てを一気に新アーキテクチャに移行するのではなく一部機能や新規機能から導入し、スコープを絞ることでサービスに影響の出ないように進めています。
現在はひと通り基盤の構築を完了し、リリースに向けての準備を進めています。また新アーキテクチャへの移行ロードマップも作成中です。
Findy Team+を利用して、Four Keysなどの指標の取得を始めています。 リソースが不足しており全てを一気にできるわけではない中で、取捨選択をするためにまずは開発サイクルの計測を始めることにしました。
ここ最近でセットアップを始めたばかりなのでまだまだ色々試している状態ですが、開発サイクルが健全な状態かどうかの判断や改善すべき箇所の特定などに活用できたらと思っています。
この半年間で改めてドメインを理解することの重要性を感じました。
開発支援というのはただ言われたものを整備してそれを機能開発チームへ譲渡して終わり、というわけではありません。 それが正しく機能開発チームが抱える課題に寄与できているか、プロダクトが本質的に求めているものになっているのかという視点が必要です。 そのためにはドメインへの理解が必要です。
TVerというプロダクトの全体像を把握し、技術的な制約でプロダクトの成長を妨げることがないように開発支援していきたいと考えています。
Backend Enabling Teamは立ち上げから半年が経ちました。 なかなか濃い半年間だったかなと感じていますが、一方でようやくスタート地点に立ち始めたかなとも感じています。 まだまだやりたいこと・やるべきことがたくさんあるので、引き続き頑張っていきたいと思います。
TVerでは現在エンジニアを絶賛募集中です。少しでも興味がある方はぜひカジュアル面談でお話ししましょう！
TVerで、プロダクトマネージャー(PM)としてプロダクト戦略/開発を担当している松村です。こんにちは！
こちらは、TVer Advent Calendar 14日目の記事となります。
前回は、@fujioka_さんの「Google Cloudのコストレポートで急に利用料が0円になった話」でした。
2023年10月にテレビ局からTVerに出向して約1年強、“TVer”というサービス/プロダクトが、どんな体験をユーザーの方々に提供していくとワクワクする未来に近づくのか、考える日々です。
TVerでPMという職種に挑戦する中で頭の使い方がガラッと変わったので、そんな話ができればと思います。
※本記事は 会社の意見・方針を反映したものではありません。あくまでも個人の意見・感想ですので、ご了承ください。
新卒でテレビ局に技術職として入社し、番組制作現場なども経験したものの直近4年は動画配信に関する仕事をしていました。
具体的には、
動画配信コンテンツを管理するシステム(CMS:ContentManagementSystem)のリニューアル
TVerでリアルタイム配信を実現するためのシステム設計/構築
大型スポーツ番組のライブ配信システム設計/運用
などの技術的なディレクションとプロジェクトマネジメントです。
自局で制作した番組をTVer等の配信プラットフォームに届ける、という立場で、それをいかに効率的に、早く、正確に、そして安全に達成するか、“How”を考えることが多かったように感じます。
TVerでも、もちろん“How”を考える時間もありますが、“What”と“Why”が頭を占めることが多くなりました。
現在、私は縁あってプロダクト戦略を考えるUIUX戦略チームにジョインし、PMとしても働いています。 私の主担当は、「新しいコンテンツとの出会い」という切り口で、レコメンドを軸としたプロダクト戦略/施策の推進です。
レコメンドと言っても推薦システム/アルゴリズムだけを指すのではなく、“ユーザーが今見たいもの"を適切なタイミングで適切な場所に表示するUIUX改善を広義のレコメンドと捉えています。
UIUX戦略チームでは、
を徹底的に考えます。
この頭の使い方は個人的に新鮮で、エンジニアやデザイナーからPMにキャリアチェンジした方も似たギャップを感じるのではないかと想像します。
また、TVerのプロダクト開発現場ではRedashの分析環境が整っていて、データ分析チームと一緒にデータを見ながら仮説を立てて施策を考えていきます。 24年度下期には、まず
アプリ起動から再生に至るまでのユーザー行動(経路)
再生中の離脱行動
再生後のユーザー行動(離脱含む)
にフォーカスしたファネル分析を実施。その結果から、“What”と“Why”を突き詰めて施策を検討します。
直近では、以下の仮説を立て、トップ画面にある視聴中の番組コンポーネントを優先的に磨いています。
仮説① ユーザーは、動画を鑑賞する時間が限られているため(Why)、起動してからできるだけ短い時間で視聴途中(かつ最後まで見たいと思っている)作品に到達したい(What)
仮説② ユーザーは、視聴途中(かつ最後まで見たいと思っている)作品を配信終了期限までに見たいので(Why)、起動した際のファーストビューにそれらが見やすく表示されていてほしい(What)
まず第一弾として、“トップ画面で視聴履歴を削除できる機能”(What)をリリースしました。視聴途中だがもう見る予定のない作品をその場で削除できることで、最後まで見たいと思っている作品がより視認しやすい位置に表示されると考えたからです(Why)。
添付画像の３点リーダー(赤丸内)をクリックすると簡単に削除できます。リリースしてから一定期間が経過したので、これから効果検証をしていくフェーズに入ります。
そして、第二弾以降も様々な機能リリースを計画しています。
TVerの掲げるMissionを改めて。
「テレビを開放して、もっとワクワクする未来を TVerと新しい世界を、一緒に。」
“テレビの開放”って良いなぁと感じます。個人的にも好きな言葉です。
2024年夏時点で、全国100以上のテレビ局の2,000以上の番組を、場所や時間から開放した形で、インターネットの世界に配信しています（リリース記事はこちら）。
私自身の2025年の抱負は、“開放”の先に、誰がいつどこでTVerを開いてもこれらの番組を最適なカタチでお届けできるようにすることです。（まだできていないコトが多すぎる...！）
映像コンテンツが世に溢れかえり、視聴デバイスも多様化する中で、テレビ番組やテレビデバイスに触れていたとしてもテレビ自体を意識することは少なくなってきているかもしれません。
だからこそTVerは、テレビをアップデートし、新しいエンタメ体験を開拓していきます。
皆さま、今年も1年お疲れ様でした。 最後まで読んでいただきありがとうございます。 2025年のTVerにもご期待ください！
明日は@kanataxaさんの「Backend Enabling Teamができて半年くらい経ちました」です。お楽しみに！！！
