はじめまして。id:takanamitoです。
バックエンドエンジニアとしてTVerに入社して3ヶ月が経ちました。 TVerに入ってみて感じたこと、開発組織が何に取り組んでいるのか書いてみようと思います。
TVerのオンボーディング
TVerのバックエンドエンジニアは自分を含めて5名です。サービス規模に対してとても少なく感じるのではないでしょうか？自分も入社前の面談で聞いて驚きました。
バックエンドエンジニアは2チームに分かれており、プロダクトの機能開発をするStream Alignedチーム（SAチーム）、SAチームと連携し開発基盤を整えるEnablingチームがあります。
今はまだ人数が少ないですが、開発チームを大きくすべく採用活動中です。
Enablingチーム立ち上げの経緯はこちらをご参照ください。
自分はSAチームの一員としてTVerのプロダクト開発を行っています。
入社した直後は、こまごまとしたアプリケーションの改修を行いつつサービス理解を深めていました。
具体的には「運用者にSlack通知されるメッセージを修正する」だとか「管理画面のデータ書き込みAPIのバリデーションルールを変更する」といった軽微なものです。
こういった開発を続けながらTVerというサービスのデータフローや、運用の流れについて質問を繰り返して理解を深めていきました。
- なぜここでSlack通知が必要なんですか？
- Slack通知を受け取った人は、何をするんですか？
- この管理画面は誰がいつデータを入力するんですか？
- 管理画面以外からデータを入力する方法はあるんですか？
といった具合です。
質問とコードリーディングを通じて、TVerで番組データが作られる流れをシーケンス図に起こし自分なりに理解を深め、チームにシェアして学習結果の還元をすることもできました。
いきなり大きく抽象的なタスクではなく、サービス理解と開発の進み方を体感するためのタスクを用意してもらったので最初から変なプレッシャーを感じずに安心して開発に取り組むことができ、いいオンボーディング体験でした。
ドキュメントをたくさん書く文化を広める
「質問を繰り返して」と書きました。これには理由があります。
環境構築の手順書こそありましたが、その後どのように作業を進めれば開発してリリースができるのか、またどういう経緯で現状の機能やアーキテクチャになったのか、といった意思決定や技術的な思想に関するドキュメントが足りず、人づてに聞くしかないこともありました。
これはプロダクトの初期から関わる少人数の開発者だけで開発をしているタイミングでは問題になりにくいですが、エンジニア採用を加速させていってるTVerのような組織では徐々に大きな困りごとになっていくはずです。
自分より少し早く入社している開発者も同じように困ったことがあるそうで、ちょうど先述のEnablingチームがArchitecture Decision Record（ADR）やDesign Docの導入を進めていましたので、協調する形でドキュメントの記述を進めました。
たまたま自分は過去の職場でこういったドキュメントを書いた経験があったので、Enablingチームのドキュメントテンプレートのレビューや、第1号となるDesign Docの記述を行っていました。
今では新しい仕組みや機能の開発時に、どういう方針で作るのかDesign Docを記述、バックエンド開発全体に影響を及ぼすような技術的な意思決定を行う際にはADRの記述が当たり前のように行われています。この3ヶ月で合わせて15件以上のADRやDesign Docが書かれては日々レビューされています。けっこうすごいペースだなと思います。
たくさん質問・相談する
自分がどのくらい質問をしてたのか調べてみました。
Slackで「from:@takanamito 質問」と検索をしたところ44件ヒットしました。
（余談ですが、チャットで他者に声をかけるときはいつも冒頭に質問/相談/報告いずれなのか宣言するようにしていたのが今回ちょっと役に立ちました）
入社3ヶ月、60営業日だとするとざっくり1.5日に1回は質問をしていたことになります。まあまあ多い方じゃないでしょうか？
同時にオフラインでもたくさん会話をする機会を用意してもらいました。 バックエンドエンジニアは入社後1ヶ月、メンターと毎日1on1をすることが推奨されています。
小さな困りごとは毎日の朝会やSlackなどで解消しつつ、自分が課題に感じること、これからやってみたいことは1on1の場でメンターと相談しながら毎日働くことができました。
自分の場合はメンターが上長だったので、自分が希望するキャリアを伝えながらこの先半年何に取り組むのか認識をすり合わせることができました。
TVerが取り組んでいる開発とは
EnablingチームはTVerのコアとなるGo製アプリケーションの開発効率を上げるための改善を行っています。具体的には以下のような施策を進めてもらっています。
自分が所属するSAチームでは
を通じて、TVerのサービス改善に取り組み始めています。経験のある方はお気づきかと思いますが大変なプロジェクトです。
Enablingチームが検討した新アーキテクチャの設計に従ってコードを書いたり、OpenAPIのスキーマからコードジェネレートして開発を進める、スキーマ駆動な開発が徐々に始まっている状態です。
（逆に今まで入ってなかったのが不思議なくらい）
新しい仕組みやアーキテクチャの導入時にはEnablingチーム主催でモブプロ会が開かれ、一緒にサンプルとなるAPI実装をすることもありました。
コードを書きながらSAチームからEnablingチームへのフィードバックを直接行うことができ、気持ちよく新しい開発に乗っていけるいい機会でした。
この先やりたいこと
社内ではTVerユーザーにもっとサービスを便利に思ってもらうためにやりたいことが溜まっています。
例えば「配信終了日が近いお気に入り番組をリマインドするプッシュ通知」とか、、、 僕もとても欲しい機能なので自分で作りたいです。社内にはプロダクトバックログがあり、そこにチケットを積むと優先度がついて実際に開発着手に至ることもあるので、TVerの改善アイデアをお持ちの方はぜひ入社して起票してください。
プッシュ通知は小さい例で、もっと大玉な開発案件もあり、大小さまざまなやりたいことが溜まっているにもかかわらず、冒頭に書いたように人数は少ないチームなので、採用強化中です。
この記事を読んでTVerのオンボーディングプロセスに共感いただけた方や いまTVer開発チームが取り組んでいること、TVerやテレビに興味がある方はぜひお話しましょう。
もっとリアルな現場の姿や、あなたが求める環境・仕事がTVerにあるかどうかお話できると思います。 TVer採用サイトから「カジュアル面談希望」と書いてご応募ください。
応募の際「この記事を読みました」と伝えていただけると話が早いと思います。よろしくお願いします。
