はじめに

こんにちは、3年連続で15日目の記事を書いているバックエンドエンジニアの伊藤です。今年もよろしくお願いします。

15日目の記事では、2024年7月に出来たBackend Enabling Teamの最初の半年について振り返っていきたいと思います。立ち上げ期のこの半年間、どこを見て何をしたのかを書こうと思います。

TVerにおけるBackend Enabling Team

機能開発チームがメンバーの能力になるべく依存しない状態で、より多くのサービス課題に注力できるように「当たり前を整備していく」ためのチーム、という位置付けでEnabling Teamは始まりました。

そしてこの上で「目の前のことにひたすら取り組む」ことが立ち上げ時最初の方針でした。これは課題が多く、とにかくアウトプットし整理することが最優先で求められていたためです。

この半年たくさんの課題に取り組んでいく中で短期的な目標や直近でやるべきことが具体的に見えてきました。

現在は「機能開発チームがスケールできる状態にする」「一人一人の開発生産性を上げる」という少しだけ小さくした目標を手前に置いて課題に取り組んでいます。その中でも特に開発難易度を下げることが直近の大きな課題となっています。

過去に立ち上げたタイミングで書いた記事がありますので、もし興味があればそちらもご覧ください。 techblog.tver.co.jp

機能開発チームがスケールできる状態にするために

TVerの機能開発チームは4人とごく少数な状況です。

人月の神話を考慮したとしても、中長期的に機能開発速度の上限値を上げるには増員がどうしても必要です。本音を言えば短期的にも欲しい状況ですが、現状だと新規メンバーが開発をするには多くの知識が必要になっていました。そのため、新規メンバーがなるべく早く機能開発に馴染めるような環境を作る必要があります。

オンボーディングの充実は機能開発チームが推進しつつ、より一般的な技術スタックでアプリケーションの開発ができる状態を提供することを進めています。経験の浅いエンジニアでも手順とレビューがあれば機能開発に取り組めるような状況を作れるようにしたいと考えています。

たとえば以下のようなことを行っています。

ADR/DesignDoc といった定点的なドキュメント文化の推進
スキーマ駆動開発の導入
- sqlboilerの導入
- oapi-codegenの導入
ブランチ運用の見直しとデプロイフローの改善
コスト最適化の見直し
オブザーバビリティの強化

この中でコスト最適化の見直しは少し特徴的な取り組みかなと思っています。たとえば、アプリケーションレイヤーでのキャッシュを駆使した高速化をあえてやめる判断をしました。現在のTVerではコスト以上に開発容易性のようなアプリケーション特性を重視しています。

また余談ですが、この記事を書こうと思いたった11月にsqlboilerはメンテナンスモードに入りました。

代替候補として上がっているBobを少し触ってみましたが、MySQLのバージョンによって動かなかったりとまだ不安定な印象を受けています。移行時に他のライブラリと共存が可能な箇所なので一旦はそのまま使い続けることにしました。

リアーキテクチャに踏み切った

当初は不足する機能をアプリケーション基盤に順次足していく予定で進めていましたが、やるべきことと内製FWの相性がどうしても悪く、達成するには内製FWとアプリケーションの両者に対して大きな変更を加える必要がありました。特にmiddleware(http.Handler)やアプリケーションロガーの導入が難しく、さらにテストによる動作保証もほぼ存在せずテスタビリティもかなり低い状況でした。

この状況下で既存アーキテクチャの基盤に手を入れつつさらに機能開発を進めるには、多くの部分を手作業によるQAによって継続的に動作保証する必要がありました。既存のコードに大きく手を入れるよりリスクやコストが低いと判断し、リアーキテクチャへ踏み切ることにしました。また、機能開発の状況的にも新しいアプリケーション基盤を作るならこのタイミングがかなり都合が良いという事情もありました。

全てを一気に新アーキテクチャに移行するのではなく一部機能や新規機能から導入し、スコープを絞ることでサービスに影響の出ないように進めています。

現在はひと通り基盤の構築を完了し、リリースに向けての準備を進めています。また新アーキテクチャへの移行ロードマップも作成中です。