なぜ“優秀なメンバー”がTVerを選ぶのか？月間ユーザー数4,120万、今まさに再構築フェーズにあるサービスの舞台裏

なぜ“優秀なメンバー”がTVerを選ぶのか？月間ユーザー数4,120万、今まさに再構築フェーズにあるサービスの舞台裏

民放公式テレビ配信サービス「TVer（ティーバー）」は、創業以来、右肩上がりで成長を続けてきました。2024年12月には月間動画再生数が4.96億回を突破し、2025年1月には月間ユーザー数（ユニークブラウザベース）で4,120万を記録*。名実ともに日本最大級の動画配信サービスのひとつとなっています。

*…自社調べ。出典：「[TVer] 2024年12月の再生数　過去最高の4.96億回を記録」「【TVer】2025年1月の月間ユーザー数 過去最高の4,120万MUBを記録」。

一見すると、事業・システム・組織のすべてがすでに整っているように見えるTVerですが、サービスプロダクト本部 副本部長 兼 バックエンド部部長の脇阪博成さんは「課題がたくさんある。むしろその課題こそが魅力でTVerに来た」と語ります。

放送局・広告会社出身者に加え、メガベンチャーやスタートアップで実績を積んだ多種多様なバックグラウンドのメンバーが集まる企業。なぜ“優秀なメンバー”たちはTVerを選ぶのでしょうか。脇阪さんに、開発組織の現在の取り組みやこれからの挑戦について話を聞きました。

事業基盤が強固、かつエンジニアリングで解決できる課題が多い

――脇阪さんはこれまで、株式会社ディー・エヌ・エーのエンジニアリングマネージャー、株式会社ZOZOの開発本部長、スタートアップのCTOなど、要職を歴任されています。なぜ、次なる挑戦の場としてTVerを選ばれたのでしょうか？

前職のスタートアップでは、予算やリソースが限られた中でエンジニア組織の強化を進めていましたが、なかなかうまく成長させることができませんでした。それに加えて入社時に想定していた事業の方向性も変わったため、自身のキャリアを再考し、次なるチャレンジの場を探していました。

複数の企業と採用面接を行いましたが、エージェント経由で紹介されたTVerの“課題”に強く興味を持ったことが大きな決め手でした。通常、採用面接では担当者が企業の良い面を話すものですが、TVerは「うちはここができていない」と赤裸々に語ってくれました。

――具体的には、どのような課題だったのでしょうか？

プロダクトはすでに一定の認知があり、事業の方向性も固まりつつあります。ですが、開発組織はまだまだ発展途上で、「成長を支えるマネジメント人材が足りない」という課題が伝わってきました。

前職では、開発組織を大きくできなかったという反省があります。これは自分の力不足でもありますし、事業を軌道に乗せられなかったことも要因のひとつです。TVerはすでにプロダクトの成長が見込める状況にあるため、組織づくりに集中できると考えました。

経営陣の多くも「現状に満足せず、さらにプロダクトを成長させたい」と語っており、そこにも大きな魅力を感じました。また、友人や元同僚にTVerの印象を尋ねてみると、「普段から使っているし、良いサービスだけれど、ここを改善してほしい」といった反応が多く寄せられました。ユーザーの生活に根ざしていて、かつ多くの要望がある。つまり、エンジニアリングが力を発揮できる余地がたくさんあるということです。

私はもともと、難しい課題を解くのが好きな性格なので、課題の多い環境のほうが面白いと感じます。だからこそ、TVerは自分に合ったチャレンジができる場所だと思いました。

――入社後、開発組織ではどのような方針を掲げましたか？

「品質とスピードの両立」をミッションとして掲げました。というのも、現在のシステムには古いコードも多く、手を加えると他の部分にバグが発生してしまうケースがあります。

その結果、障害が起き、影響範囲の調査や修正対応、場合によっては謝罪対応まで求められることになります。こうした対応により、ユーザーへ価値を届けるまでの時間が長くなってしまう。これが大きな課題でした。そこで現在は、「技術」「組織」「開発プロセス」の3つの切り口で改善を進めています。

まず「技術」面では、フロントエンド・バックエンド・インフラのリアーキテクチャに取り組むとともに、自動テストの追加やQAの強化を進めています。QAについては、いわゆる「シフトレフト」を実践し、要件定義の段階から品質やセキュリティを意識しています。

次に「組織」面です。これまではプロジェクト単位で人が集まり、終われば解散するという流動的な体制だったため、ナレッジの蓄積が困難でした。今後はチームをある程度固定化し、プロダクトマネージャーやデザイナーも含めたクロスファンクショナルな体制で、チーム単位にミッションを持たせて動く方針に変えています。

最後に「開発プロセス」について。以前はプロジェクトの進め方が各メンバーに委ねられていたため、ばらつきによって進行に支障が出るケースがありました。そこで、ドキュメントの標準化や開発プロセスの整備を進めることで、最終的には品質とスピードの両立につなげたいと考えています。

現場の裁量の高さゆえに、リアーキテクチャの決断も高速

――それらの改善について、具体的な事例をピックアップしてお話しいただけますか？

システムのリアーキテクチャについてお話しさせてください。社内で「枠切れ」と呼んでいる事象があります。これは地上波放送の番組が終了した後、「TVer」で引き続き視聴できる場合に、ユーザーからのアクセスが一斉に集中する現象のことです。

これに対して同時接続数を事前に予想し、多めのサーバー台数を立ち上げて待ち構えていたのですが、それでも突発的なスパイクには耐えられなかったり、または逆に想定していたよりもアクセスが来ずコストの無駄が大きくなったりして、この状態を継続するのは厳しいと感じていました。

また、アプリケーション内ではパフォーマンス向上のためにキャッシュ処理を導入していたのですが、その処理も次第に複雑化していました。対応方針を考えていたところ、CTOから「より良い設計になるように、作り直したらいいんじゃない？」という提案があったんです。「それ、アリですか？ ではやります！」となり、現場のリーダーたちと集まって方針を議論し、翌週にはリアーキテクチャを直ちに開始することが決まりました。

一般的に、ある程度の規模のサービスではリアーキテクチャの決断に至るまでの計画段階で相当な時間がかかります。こうしてスピーディーに動けたのは、TVerの開発組織における柔軟性や現場の裁量の高さが影響しており、大きな方向転換も即断即決で進めることができました。

――たとえばインフラがどのように変わるのか、ピックアップしてお話しいただけますか？

現状、インフラの技術スタックとしてはAWSのマネージドサービスを主に活用しており、アプリケーションサーバーはAmazon ECS、データベースはAmazon Aurora MySQL、検索にはAmazon OpenSearch Serviceなど、オーソドックスな構成です。

ただし、現在のアーキテクチャでは急激なスパイクが発生した際にオートスケールが間に合わないケースがあるため、リアーキテクチャ後はCDNによるキャッシュ構成の導入を検討しています。前述のアプリケーション内でのキャッシュは実装が複雑になるという課題があったので、そちらの課題を合わせて解決するという狙いもあります。

CDNキャッシュも万能ではありませんが、「TVer」のトップページは、一部ユーザー向けの出し分けはあるものの、基本的には同一のコンテンツです。だからこそ、キャッシュが効果的に機能すると考え、このようなアーキテクチャにすることに決めました。また、これとは別に急激なスパイクにもスケールが可能なように、インフラ面でのリアーキテクチャも検討しています。

「チームとしての目標がない」状態からの、SREチーム再構築

――他の事例についても教えてください。

直近の半年ほどで、組織体制を変更していった事例についてお話しします。私がバックエンド部の部長に就任したのは2024年4月です。就任後しばらくして、SREチームには「チームとしての目標がない」という課題があると感じました。目の前の必要なタスクには対応できていたものの、チームとして何を重視し、どのような状態を目指すのかが明確になっていなかったんです。

とはいえ、私自身はもともとSREのバックグラウンドがあるわけではなく、どんな目標を設定すればよいか迷っている状況でした。そんなとき、採用活動に注力していたところ、2024年10月にマネージャー候補のメンバーが入社しました。その方と議論を重ねる中で、「今の組織の状況を踏まえ、まずは品質改善に注力しよう」と方針を決定しました。

2024年度の上期に発生したトラブルを、Slackの投稿やポストモーテムの記録から洗い出した結果、半年間で相応の件数の配信トラブルが起きていたことがわかりました。実際には、より小規模な障害も数多く発生していたはずです。サービスの信頼にも関わる部分ですし、一度ここで「血を止める」必要があると感じました。

そこで、「配信トラブルを○○件まで減らす」「トラブル発生時の影響時間を○○まで短縮する」といった具体的な目標を立て、その実現に向けて「アラート情報の整理」や「重要情報のログ出力」といったタスクへ落とし込んでいきました。

この施策を進めている間、SREチームのリソースが不足し、開発チームからのインフラ関連の要望に応えられなくなる可能性もありました。そこで、開発チームにAWSのIAM権限を付与し、組織全体の生産性に影響が出ないような方針を取りました。

――この記事はSRE候補の方も読まれるはずです。そうした方に、どのような役割を期待されていますか？

お願いする内容は、その方のスキルセットによって異なりますが、大きく3つの領域があります。1つ目はインフラ構築で、DevOpsチームの強化を進めています。2つ目はオブザーバビリティで、ダッシュボードやSLOの整備が課題です。3つ目はセキュリティで、セキュリティ関連業務の標準化・自動化や、脆弱性対応をリードできる方を求めています。

また、インフラだけに特化している方よりも、アプリケーション開発の経験がある方が望ましいですね。TVerのSREチームは、今後ものすごく大規模にする予定はありません。だからこそ、個々のエンジニアの役割を完全に分けるのではなく、必要があれば領域を越境するような体制にしていきたいと考えています。SREのメンバーにも、アプリケーションのコードを読み、ときには修正してPull Requestを出せるような方に来ていただけると理想的です。

優秀な人たちにとっての「ちょうどいい」チャレンジの場

――ではここから、採用候補者向けの質問です。いわゆるWebサービス系の企業と比べたとき、TVerならではの面白さや特徴があれば教えてください。

TVer社内には、放送局や広告会社出身の人や、放送局や広告会社から出向で参画している方が多く在籍しており、一般的なIT企業とは少し毛色が異なるところがあります。一方で、中途採用で入社してきた方々は、メガベンチャー出身者やスタートアップでCTOを務めた経験のある方など、幅広い経歴の持ち主が集まっています。この規模の会社としては人材の多様性が際立っており、それがTVerの組織としての面白さだと思います。

サービス面では、ユーザー数の多さがやはり特徴です。日々、フィードバックが山のように届くんですよ。自分たちの取り組みの影響範囲が大きいですし、TVerという会社でしか見えない世界があります。

――有名企業を経験してきたような、いわゆる“優秀な人たち”が、TVerに惹かれる理由は何でしょうか？

やはり、課題が多いという点に惹かれる方は多いですね。余談ですが、最近入社した開発組織のマネージャーたちに話を聞いたところ、「TVerはいろんな意味でちょうど良い」と言っていました。要するに、組織のサイズやサービスのフェーズが程よく、なおかつ社会的意義のある事業を提供している。それらを魅力に感じているようです。

――どういった要素を持ったエンジニアを、組織としては求めていますか？

私が採用基準として重視しているのは、笑顔があることです。これは単にニコニコしているという意味ではなく、「相手とより良い会話をしようという気持ちがあるかどうか」です。良いプロダクトをつくるには、さまざまな方と協力することが不可欠ですから、そうしたやり取りを自然にできる人を求めています。

そして、「TVer」というサービスと真剣に向き合い、成長させていきたいという思いがあること。そのために必要な手段は問いませんが、自分の専門領域はしっかり持っている。そういう人と一緒に働きたいと思っています。

また、エンジニアはつい「要件をはっきり決めてください」とか「納期はいつですか」と言いがちですが、そうした考え方をしないこと。未確定な要素があるのであれば、みんなで一緒に考えていくというスタンスが大切です。

他にも、できればtoCサービスの開発経験がある方が望ましいです。要するに、事業会社で自社サービスを開発・運用した経験があること。受託開発とは異なり、サービスは出して終わりではなく、そこからがスタートです。ユーザーの声を聞きながら改善していく経験が重要だと考えています。

――TVerにジョインしたエンジニアが得られる成長機会について教えてください。

TVerでは、裁量を持って自ら考え、自ら動くことができます。自分の担当領域にとどまらず、周囲を巻き込みながら動ける。それが大きな成長の機会になると思います。そして何より、社会的な影響力の大きいサービスの中で、それを実践できるという点が魅力です。

組織としても失敗を許容しながら前に進む文化がありますし、優秀なマネージャーがそろってきているので、チャレンジしやすい環境が整っています。きちんと自分で動ける方であれば、ご自身が描くキャリアをTVerの中で実現できると思います。

取材・執筆：中薗昴

撮影：山辺恵美子

提供：株式会社Haul