TVer iOSチームの共通認識のつくり方

株式会社TVerでiOSエンジニアをしている小森と申します。本記事では、TVer iOSがこれまで取り組んできたこと、組織体制、今後の展望についてご紹介します。

現在、TVer iOSでは大規模なリアーキテクチャを進行中です。技術スタックに関しては、SwiftUI、TCA、Swift Package Managerを活用したマルチモジュール、アトミックデザイン・デザインシステムの導入、そして各種テストの実装という形でリアーキテクチャを進めています。

リアーキテクチャ前の既存ソースはLegacyAppFeatureというモジュールとして切り出し、リアーキテクチャしたものはスコープごとに新しいモジュールとして随時追加していきます。その際、既存のソースは順次削除していきます。最終的には、全ての機能がリアーキテクチャ後の新しいモジュールに置き換わる想定です。

TVer iOS開発の内製化とチーム体制

では、なぜリアーキテクチャをしているのか、TVer iOSチームの歴史について話します。

2023年4月、iOSチームが所属する「フロントエンド部」が社内に発足しました。これは、元々外部ベンダーに委託していたTVer iOSアプリの開発体制を、サービスグロースのため社内に構築するというミッションを担っていました。そして、2023年10月に私が入社するとともに、iOS内製開発チームが本格的に立ち上がりました。外部ベンダーと並走しながら開発を進め、社内にノウハウを蓄積し、やがて内製で開発を完遂できる体制を築くことを目指して活動を開始、その結果、2024年4月には、外部ベンダーからのソースコード引き継ぎを終え、iOS開発の完全内製化が完了しました。社員は私一人で、業務委託メンバー6名との合計7名体制で開発していましたが、2025年1月には社員が2名加わり、チーム体制がより強化されました。

現在は、社員3名と業務委託9名の計12名体制で活動しています。それぞれがオーナーシップを持ち、リードとして活躍しながら、社員が業務委託メンバーをアサインし、iOSチーム内でチームごとに分かれて継続的に開発を進めています。

この3名体制で、事業KPIに基づき、ミッション軸で機能開発チームを編成しています。各チームはそれぞれのミッションを担当し、iOSチームの代表として、バックエンドエンジニアやテクニカルディレクターと連携しながらプロジェクトを推進しています。

課題と3つのレビュープロセス

社員2名の加入により、チームのフェーズが大きく変化し、新たな課題として、リアーキテクチャ推進における共通認識の不足が露呈しました。特に、コードレビュー時の差し戻しが頻繁に発生するという問題が起きていました。

この課題を解決するため、TVerのiOSチームとして以下の3つのレビュープロセスを定義しています。

1. UI設計レビュー

TVerアプリはデザインシステムを導入しており、デザイナーはFigmaでデザインアウトプットを作成しています。Figmaのビュー階層を意識してビューを作成する方針ですが、時にはFigmaの階層と異なる定義で進める場合もあります。

このレビューでは、異なるモジュール間で参照される共通デザインコンポーネントについて、どのように作成するか、どのチームが担当するか、拡張する上での好ましいインターフェースは何かなどをディスカッションできるプロセスを設けています。

2. Reducerリデューサー設計レビュー

TVerはTCA（The Composable Architecture）を採用してリアーキテクチャを進めていますが、Fat Reducerが生まれてしまう課題がありました。これを未然に防ぐため、Reducerの設計を事前にすり合わせるようにしています。

具体的には、ステートやアクション、分割方針などを事前に議論します。実装面で不確実性が高い機能もあり、このレビューが通らないと実装できないわけではありませんが、あくまで実装における不確実性を減らし、最終的な差し戻しを減らすことを目的としています。

3. テスト設計レビュー

このプロセスでは、機能開発時にどのようなテストで品質を担保するかを取り決めています。ユニットテストはもちろんのこと、開発する機能によっては手動テストに頼らざるを得ないものもあります。

手動テストが必要な場合は、動作確認のパターンを手厚くし、手動テストのボリュームを増やすようにしています。時には、機能開発後にテスト導入フェーズを設けるといった考慮事項を事前に洗い出すことで、テスト設計におけるスケジュールの精度を高め、プロジェクト全体の工程管理を向上させています。

チーム文化・基準の構築化を支えるドキュメント整備

フェーズの変化に伴い、これら3つのレビュープロセスを共通認識として導入しましたが、TVer iOSチームとしてのチーム文化や基準を構築する必要性も高まりました。そのため、並行してドキュメントの整備も進めています。

コーディング規約

GitHubのIssueベースで起案し、採択されたものを規約として採用するスタイルで運用しています。これにより、社員、業務委託関係なく起案できるようになっています。フォーマットやSwiftLintのルールなど、プロダクト開発で追加・削除したい項目も、同様にGitHubのIssueベースで起案し、必要に応じて採択しています。

ADR（Architectural Decision Records） の活用

ADRも採用しています。TVerのiOSアプリ開発では、特殊な状況や例外的な判断が必要なケースがあるため、「なぜこの判断をしたのか」「なぜこの選択をしたのか」という理由を記録しています。その目的は、将来チームメンバーが増えた際に、ソースコードだけでは分からない文脈をADRを参照することで追跡しやすく、また、複雑な仕様の部分でも、誰でも過去の意思決定を効率よく参照できるようにしています。

Tipsによるナレッジ共有

ドキュメントは厳密なイメージを持たれるかもしれませんが、Tipsは業務上の便利なノウハウを共有するスペースです。これは規範ではなく、メンバーが気づいた際に自己判断で自由に記載し、全体に周知するものです。

「このやり方をすれば作業が早くなる」「端末登録をこのコマンド一発でできる」といった時短情報など、業務効率化に繋がるノウハウを共有する場として活用しています。

運用してみての所感

一人で業務委託メンバーと開発していた体制から、社員メンバーが2人増え、リアーキテクチャや大型プロジェクトを並行して進められるようになったことで、多くの変化がありました。チーム認識の課題感はありましたが、レビュープロセスという合意形成の仕組みを導入できたことで、プロジェクトを円滑に進められています。

しかし、これはまだ感覚的なものなので、今後は、これらの取り組みを定量的に評価し、改善を重ねていく体制を構築する必要があると考えています。

今後の展望

今後の展望としては、スピードと品質の両立をより一層追求していきます。

具体的には、開発スピードの向上、開発生産性の向上、ソフトウェア品質の向上という3つの軸を、AIなども活用して定量的に評価できるようにし、継続的な改善サイクルの確立を目指したいと考えています。これまでにお話したレビュープロセスやドキュメントなども、これら3軸に貢献しないと意味がないと考えているため、常に「価値あることに時間を使えているか」という視点を重視しています。この3軸を定量評価し、改善サイクルを回していくことが、今後の主要な課題です。

We Are Hiring！

「テレビがオワコン」と言われる時代に、私たち自身はテレビコンテンツを誇りに思っています。放送の制約、時間も場所も超えてテレビを開放していく、というビジョンを持っています。TVerというサービスの知名度と比較すると、iOSチームはまだ発展途上のフェーズです。この「整っていない」フェーズの課題解決を推進できる機会は非常に稀だと考えており、このアンバランスさを一緒に追求していける方々と働きたいと思っています。興味を持っていただけた方は、ぜひカジュアル面談でお話ししましょう。^[1]