サービスプロダクト本部技術統括（TVerサービス開発部門内のVPoEみたいなポジション）兼バックエンド部部長の脇阪(@tohae)です。 この記事はTVerアドベントカレンダー 2024 25日目の記事です。24日目の記事はSREチームの鈴木さんの「AWS re:Invent 2024に1人で参加してきました」でした
今年の1月からEMとして入社し、約1年間開発組織の拡大や開発生産性の向上のためにいろいろな取組みを行ってきました。 本記事では約1年前のTVerのエンジニア組織がどのような課題を抱えていて、それに対してどのような手を打ってきたかというところをまとめます。
2024年初頭の課題
入社前の時点で経営陣から期待されていたのは下記のような部分でした。
- 機能開発をより早くしたい
- サービスを安定させたい
- そのためにエンジニア組織を強く大きくしたい
まずはこれがどこまで本当で、どこまで深刻なのかを把握することから始めました。 そのためにエンジニア組織の全員との1on1を行い、エンジニア組織以外のマネージャーとも多く会話をさせてもらい、そして自身も一部の開発タスクを受け持ち現状を把握することに努めました。 おおよそ1〜2ヶ月経った頃に自身が得た情報をもとに改めて課題だと認識したのは下記の通り。
Q. 「機能開発をより早くしたい」は本当？
事実
夏のオリンピックや、テレビ局から入稿される番組データの刷新プロジェクトなどの重要機能開発にリソースを集中させていて、常に締切に追われている状態でした。 事業側は他にもやりたい施策はあるものの、リソース不足によりマーケティングとコンテンツで伸ばすという意思決定がなされていました。
上記とは別に中途入社の社員の立ち上がりが遅いという課題もありました。 これは社内にドキュメントも少なく把握が難しく、オンボーディングに改善の余地があったことが理由です。 前述した通り、常に締切りに追われたことが原因で、このあたりの整備がなされておらず、在籍期間が長い人に話を聞きたいが彼らは仕事で忙しいという悪循環。 また開発環境に関しても認知負荷が高い状況でした。
これらの諦めてきた部分が機能開発において大きな障壁になりつつあります。 暗黙的な何かが大きくなってしまい、新規メンバーの初速が出にくくスケールが難しい状態になっているのです。
こちらの記事にあるような状況であり、なかなか初速が出にくくスケールが難しい状態でした。 上記は主に内部の実装面の話が大きいですが、全体のアーキテクチャにも認知負荷の観点で課題がありました。 TVerサービスはTVer Media Platformと呼んでいるPlatformを利用するサービスという位置づけで運用をしています。このTVer Media Platformは地上波データ放送や、放送局のWebサービスなどに利用されるPlatformでありながら、ほぼTVerサービス専用の機能も用意されているPlatformです。
このPlatformへの依存が高く、TVerサービスのための修正が思わぬ影響を及ぼしたり、逆にデータ放送や外部サービスの影響によってTVerサービスに影響が出るようなことも起こり得る構成になっていま。 ただでさえ複雑なTVerのドメイン知識の他に、Platformの知識もインプットする必要があるということが認知負荷を高めていました。
Q.「サービスを安定させたい」は本当？
事実
下記3点においてサービスが不安定な部分がありました。
- サーバインフラ面
- セキュリティ面
- アプリケーションの品質面
インフラ面に関しては普段は比較的安定しているのですが、急なスパイクに耐えられない構成になっていました。 社内で「枠切れ」と言われている事象があります。これは地上波で放送していたスポーツ中継などが、地上波での放送は時間が来て終了するが、続きをTVerで見ることが可能なため、地上波を見ていた人たちが一斉にTVerにアクセスしにくるというものです。 徐々にアクセス数が増えるものであればオートスケールが可能なのですが、急激なスパイクでは対応することができず落ちるということがよくありました。
セキュリティ面に関しては、TVerというサービスの社会的影響が大きくなってきたことから、これまでよりセキュリティ強度を上げることが求められてきました。
最後にサービスの特にアプリケーションの品質面です。 iOSやAndroidアプリはもともと外部ベンダーに開発を依頼をしていましたが、品質管理面に課題がありました。品質向上や開発生産性向上を目的に内製化に舵を切って組織づくりに取り組んでおり、以下のようなタイムラインで徐々に内製化が進んできました。
しかし依然としてコードの品質は低いままであるため、よく不具合が発生していました。リリース前に見つかることもありますが、本番に出したあとに問題が発覚して修正リリースをすることもしばしば。 不具合対応に追われる時間が大きな割合を占め、機能開発に割ける時間が減り、機能リリースが遅れていくという悪循環に陥っていました。
現場はこのような状況な一方で、ユーザー規模が大きくなり、ジャンルもドラマ・バラエティだけでなくニュースコンテンツも取り扱うようになるなど徐々に「社会的なインフラ」としての役割も期待されるようになってきました。
ただでさえ困難な目標ですが、現在地点からはあまりにもかけ離れた目標で、機能開発に追われている現状の組織のままでは改善もなかなか進みません。
Q. 「そのためにエンジニア組織を強く大きくしたい」は本当？
ここまでの流れでわかると思いますが、当然事実。 そもそも私が入社した当時、正社員のエンジニアはバックエンド・フロント・QA・インフラ全て合わせてたったの15名程度なので、これをいかに効率化や最大化させたとてたかがしれてます。 一にも二にも採用です。
またそれ以外にエンジニアの現場と事業側や経営陣との溝のようなものがあると感じました。溝と言うほどではないかもしれませんが、うまく噛み合っていないのは事実。お互いが遠慮をしていたり、あるいは忙しさから高圧的になってしまっていたり、部署間のコミュニケーションの課題もありました。
課題解決の方針
問題がだいたい把握できたタイミングで、4月から技術統括とバックエンド部の部長になることが確定したこともあり、経営陣向けと現場向けに方針の共有を行います。
- エンジニア組織の人数を1年で倍にする
- 組織拡大に伴う基盤を整備する
他にも細かくいろいろあるのですが、大方針としては上記2点を目標として立てました。
将来的に目指す姿は、エンジニア組織も主体となって技術の力でプロダクトの成長を支え、事業を成長させることだと考えていました。（今も考えています） そしてより未来のことを考えるのが技術統括としての期待値だろうと思ったものの、ただ理想形に至るにはまだまだ道のりは遠く、そして自身も入社3ヶ月で信頼貯金がまだ足りず、ドメイン知識も大してない状態であったので、理想論を語っても誰もついて来てくれません。 なのでまずは現状の課題を1年で解決しようと目標を立てました。
エンジニア組織の人数を1年で倍にする
まずは採用する人物の方針について定めました。 手が足りないのですぐにでも人を増やしたいところですが、オンボーディングが整ってはおらず、育成に割ける時間もないので、即戦力が必要です。
ただ一方でスキル偏重の採用もしないことを決めていました。 TVerのMission・Visionに共感してくれて、Valueを体現できることは最低限必須。加えて社内の等級制度において、ある等級以上の能力を有している（あるいはそれがすぐに期待できる）人を採用すると決めました。
とは言えすぐにでもリソースが必要という際には、業務委託も一定割合において採用を進めていくということにしました。 この方針を定めた後に、自身が選考フローに入り、徐々に改善してから組織全体に浸透させるという進め方をしていきます。
まずは求人票のアップデートです。当時のバックエンドエンジニアの必須条件はあまりに厳しかったため、応募数をまずは増やして候補者に会う数を増やします。 そしてそのアップデート内容を採用エージェントにもエンジニア自身が伝えるようにします。これまでは採用人事に多くのことを任せていましたが、エンジニア採用はエンジニアがある程度リソースを投下しなければうまくいきません。
またエージェントの定例会にも参加するようにし、応募数などの数字を一緒に追っていくことにします。 そこで得た情報から下記のようなことを実施しました。
- 書類選考などの返信時間を24時間以内にする
- カジュアル面談の体験をあげるために職種別（あるいは個人別）にカスタマイズした資料を作成する
- オファー面談も個別カスタマイズした資料を作成する
など。 特に奇抜なことはせず、選考における各ポイントの数値改善のために当たり前のことを当たり前にやるようにしました。
ここまである程度自身が行ったあとは、次は組織全体への浸透です。 採用を自分ごと化させるために、チームや個人の目標に採用に関するものを含めました（直接的な採用活動だけでなく、間接的なブログ執筆や登壇なども含む） これまで一部の管理職だけが行っていた採用活動を、チーム全体で行えるようになったことでスケールでき、採用活動が加速していくようになりました。
またリファラルについても合わせて強化。もともと社内にはリファラル制度があったため、これの周知を行い、いい人がいないかを雑談の中などで確認し、必要あらば採用会食などもセットしてチームで仲間集めに取り組みました。
選考の過程で、TVerに内製の開発組織があることを知らなかったという人が多数いるという課題感も見えてきたため、技術広報面も強化。 このアドベントカレンダーの取り組みもその一環で、今年始めて完走できたのは感慨深いものがあります。
組織拡大に伴う基盤を整備する
これまで事業成長のための機能開発にほぼほぼ100%の全力投球をしていましたが、このままではいつまで経っても基盤が整備されていきません。 そこでチームトポロジーを参考に、基盤を整備するEnablingチームとPlatformチームを立ち上げることにしました。 一時的に機能開発のリソースが減ることにはなりますが、死守しなければならない機能開発は最優先で行うということをコミットし経営陣や事業側に説明を行いました。
チームを立ち上げたあとはオンボーディング資料を整理し、以降の開発に関してはDesign DocやADRなどのドキュメントを整備していくことにします。 ドキュメント文化の取り組みに関しては、こちらの記事にまとめているので良ければご覧ください。
そしてリアーキテクチャへ 結論から言うと、バックエンド、iOS、Androidはリアーキテクチャをすることを決めました。 加えてバックエンドは前述したPlatformに関してはリプレイスを行うことにしました。
バックエンドはこれまでサーバのスループット向上のためにアプリケーションレイヤーでのキャッシュを多用してきました。なぜならTVerのコンテンツデータは変更されにくく、Read heavyなサービスなので、キャッシュしやすくキャッシュ効率の良いサービスであるからです。
このアーキテクチャによりここまでTVerを支えてこれましたが、昨今のスパイクには耐えることが難しくなってきました。またアプリケーションレイヤーでのキャッシュ実装により、実装やテストが難しいという課題もありました。
そこでアプリケーションの実装はシンプルに保ちつつ、キャッシュの最適化を効かせる方法を模索し、CDNでキャッシュする方針を取ることにしました。そうなったときに既存コードのリファクタリングよりはリアーキテクチャを取ったほうが最適であると判断するに至りました。
プラットフォームに関してはリプレイスをすることに決めました。新プラットフォームを新しく作成し、既存データをマイグレーションして互いに疎である状態を目指していきます。
リアーキテクチャもリプレイスもまだまだまたまだ道半ばでありますが、来年には段階的にリリースができる予定なので、その後にまたどこかでお話させていただきます。
iOS、 Androidに関してのおさらいですが、ざっくり言うと以下のような状態でした。
- 保守性が低く、開発チームは変更をおこなうために多くの工数がかかる。
- 変更時に不具合が発生しやすい。また修正にも時間がかかる。
「もはや作り直すしかないよね」というところは社内の誰もが思うところではあったのですが、問題はどのようにして安全に作り直していくかというところでした。 そこの問題に対しては、一括リリースは避けて分割リリース可能なアーキテクチャにつくりなおしていくという方針を定め、Feature Flagによる段階的な開放を可能にする仕組みを用意し、ついに12月にリアーキテクチャの第一弾のリリースができました！ このリアーキテクチャの方針に関しては、今年のiOSDC Japan 2024年で弊社の小森が登壇した資料があるのでそちらをご覧ください
なおバックエンドに関してもFeature Flagやカナリアリリースによる段階的な開放が可能になる仕組みを用意し運用しています。
部署間の溝の話
ここはもうひたすら泥臭くやりました。
経営陣や事業側、人事の人たちは物理的に出社してる人が大半だったため、それに合わせて出社することにしました。また経営陣はエンジニアがいるフロアとは別のところにいるので、暇を見つけてはそちらのフロアに向かって話をしてました。
経営だけでなく、事業側の定例会にも参加してとにかく情報収集をしました。
ただ情報収集するだけでなく、話の流れの中で彼らの要望を聞き、すぐに対応できるものは可能な限り早く対応できるようにしました。
こうして得られた情報を部内に持ち帰り全て共有するということを繰り返します。 これ以外にも予実管理や人員計画、経営会議の決定事項など、これまではマネージャーしか知らなかった情報もひたすらオープンにしました。 結果としてエンジニア陣は経営陣や事業側の思いを以前よりは知ることができ、経営陣や事業側もエンジニアに依頼・相談しやすい形ができつつあると感じています。
ちなみにアーキテクトエレベータという話をご存知でしょうか？
The Architect Elevator — Visiting the upper floors
ざっくり説明すると（ChatGPTに要約させたところ）
「アーキテクトエレベーター」というコンセプトは、技術アーキテクトが経営陣（上層部）と技術者（現場）の間を行き来し、両者をつなぐ役割を果たすというアイデアです。現代の大規模なIT組織では、上層部がビジネス戦略や目標を設定し、現場がその目標を実現する具体的な技術的ソリューションを提供します。しかし、両者間のギャップを埋める役割がなければ、組織全体の連携がうまくいきません。アーキテクトエレベーターは、このギャップを解消し、組織全体の変革を推進する中心的な役割を担います。
この話を知ったのは後の話ではありますが、結果としてアーキテクトエレベータを実践した形になります。
まとめ
長々と書きましたが、色々な方針を定めて着実に歩みを進めた1年でした。一部課題の紹介だけで解決内容が記載できない項目もありますが、これらも着実に進めております。
また他のアドベントカレンダーも見てもらうとわかりますが、今回紹介した内容だけでなくいろんな場所でいろんな改革を進めてきました。 組織は確実に強く大きくなってきており、4月に立てたエンジニアの数を倍にするというのも1月時点で達成見込みです。
来年はTVerローンチから10周年の記念すべき年です。今以上にさらにサービスに磨きをかけ、これまでにない新たな価値を生み出していかなければならないと思っています。 そのためにはエンジニア組織がもっともっと強く大きくなる必要があるので、1年先の未来だけでなく、数年先の理想形を描きそこから逆算する形で成長の戦略を描いていきます。
来年はTVerサービスを通してサービスの進化をお伝えし、そしてこの場でその裏側のエンジニア組織の話をお伝えできればと思います。
