この記事は Tverアドベントカレンダー2025 25日目の記事です。24日目の記事は @tomat_oooさんのTVerでテレビの体験をつくる！5つの壁とUIデザインの工夫でした。
サービスプロダクト本部 本部長の脇阪(@tohaechan)です。
1年前に上記のような記事を書きました。
当時は技術統括（TVerサービス開発部門内のVPoEみたいなポジション）として、主に技術戦略や組織マネジメントに責任を持っていました。 そこからPdMやデザイナーも含めた開発組織の本部長となったこともあり、これまでの仕事に加えてプロダクト成長にもより強くコミットすることとなりました。 そこで本記事では、プロダクト成長のためにどのような組織戦略、技術戦略を立てて実現したのかを共有したいと思います。
品質とスピード
昨年末の記事でも課題を書きましたが、機能開発のスピードは期待するほどのスピードが出ず、品質に関しても様々なトラブルが発生しその解消に追われて開発が後手後手に回るという状況でした。
一部の開発チームでは変更障害率の計測をしていたのですが、その数字はよくありませんでした。 実際、年末年始は怒涛のhotfixリリースをして胃が痛かったです…。しかも特定の領域で多く発生しているというようなことはなく、iOS, Android, Web, バックエンド、インフラとまんべんなく問題が発生していました。 体感3割くらいは緊急の不具合対応に追われており、当初予定していたリリーススケジュールがずるずる遅延していくという悪循環です。
このころ組織の人数としては約1年で2倍になり、育ってきた環境が異なるメンバーが増え、TVerというプロダクトや組織の課題感の認識もバラバラという課題感もありました。
「クソコードすぎるから事故るんだ！リアーキテクチャだ！！！（意訳）」「開発のスピードが遅すぎる！！！（意訳）」「まずは落ちまくるインフラの品質を担保すべき（意訳）」
ざっくりわかりやすく意訳すると上記のような感じで、人によってバラバラです。 それぞれの課題感が間違っているわけではないものの、人によって課題感が異なるので優先順位付けの際に揉めたり話が噛み合わなかったりします。 まずは開発組織全員の認識を揃え、同じ方向を向かせたい。そしてある程度覚えやすく認知しやすい方針にしたい。その思いから「品質とスピード」をスローガンに掲げることにしました。 品質とスピードはトレードオフの関係にあると考えられがちですが、品質を高めることで結果としてスピードを上げることができると考え、このようなメッセージにしました。
品質とスピードの両立の実現に向けて
これまでも品質とスピードの向上は各チームで取り組んではいましたが、 一方で「目指すべき理想形の状態」を定量的に示せていないことで認識のズレが起こっていました。
「インシデントが多い」「開発がなんとなく遅い」「リリース回数が少ない」といった定性的な課題感はあるものの、具体的にどの程度の問題なのか、改善が進んでいるのかを判断できない状態でした。 各チームの取り組みで改善できることには限界があり、組織全体でプロセスや手段を変えていく必要があるとも感じていました。
そこで品質とスピードのスローガンとともに、定量目標を設定しました。
- インシデント発生件数
- インシデントレベルを定義し、レベルごとの発生件数をn件以内にする
- 平均修復時間
- ポストモーテムで平均修復時間を計測し、平均修復時間をn時間以内にする
- リリース頻度
- 各デバイスごとの一ヶ月以内のリリース頻度を定義し、それ以上のリリースを行う
- リードタイム短縮
- FY25はまずは計測から始める
このように各指標の定義を明確にして、計測することから始めました。
課題と対策1: インシデント管理 && 平均修復時間の改善
まずはインシデントについて。インシデント管理において大きく3つの課題がありました。
- インシデント定義が曖昧
- インシデントの重大度の判断が、人やチームによって異なる
- インシデント改善タスクの優先度を決められない(あるいは、誤った優先度を設定している)
- インシデント対応を各チームバラバラに実施
- 他のチームでどのようなインシデント対策を行っているのか知らない
- インシデントが発生したことすら知らない
- チーム横断的に対応した方がよいインシデントもあるが、対応できていない場合がある
- 再発防止&恒久対応をやりきっていない
- 暫定対応や緩和措置の一時的な止血対応が、そのまま再発防止&恒久対応になっている
- いつかちゃんとやろうと思っていても、機能追加に追われたり新しいインシデントへの対応でしっかりとした再発防止&恒久対応ができずに埋もれていく
こういった課題を解決するため、インシデント管理委員会を設立し、全チームから1人ずつ集めてインシデントの管理について話し合いを進めました。 全チームを呼んだのは全チームが自分事とし、現実的な管理ができるよう議論してもらうためです。
1のインシデント定義が曖昧だったところに対しては、本部全体で統一的なインシデントレベルを定義します。 過去1年のインシデントを手作業で洗い出し（各チームのポストモーテムであったり、Slackの障害報告であったりを地道にサルベージしました）、 インシデントを「アプリ」、「広告」、「ログ計測」などのカテゴリに分類しました。 このカテゴリ別にレベルを分類していくのですが、例えばアプリであれば、影響ユーザー数と機能重要度の掛け算でレベルを決めることにしました。もう少し具体的に言うと「コンテンツを再生できないユーザー数がxx万以上」であればインシデントレベルSというような形です。
このような定義を行い、本部目標として「インシデントレベルSを0件、Aをn件以内に抑える」ということを通期の目標として追っていくこととしました（件数に関しては前年発生件数から現実的な目標を算出）
許容できるリスクの明確化と段階的ロールアウト
あらゆるインシデントを起こさないのが理想的ではありますが、ソフトウェア開発でそれは不可能に近いです。テストに多くの時間を割けば限りなく少なくすることはできるかもしれませんが、スピードとの両立は難しくなります。
そこで重要になるのが、インシデントレベルに影響ユーザー数を含めることで許容できるリスクが明確になったことです。 例えば「影響ユーザー数が1000人未満ならインシデントレベルB」という定義があれば、新機能のリリース時に「まずは1000人未満に開放してフィードバックを得る」という判断ができるようになります。
この明確な基準により、過度に品質を作り込むことが無くなりました。 従来は「万が一何か起きたら大変だ」という心理的安全性の欠如から、リリース前に完璧を目指して長時間のテストや検証を行っていました。しかしインシデントレベルの定義により「このレベルなら許容できる」という共通認識が生まれ、スピードを上げることができるようになったのです。
具体的には、Feature Flagを使用して段階的にロールアウトしていく方法を全デバイスで標準化しました。
昨年のiOSDCでiOSの事例を発表していますが、Android、Web、コネクテッドTV、バックエンドの全てでこの考え方を適用させています。
バックエンドの事例に関してはこちらの登壇資料もご確認ください。
運用としては、数%ずつの段階開放を行い、クラッシュ数やサーバのエラー数、事業KPIへの影響などを観測します。 さらに、仮に問題が発生したとしてもインシデントレベルがB未満に収まるように開放率をコントロールする運用を心がけていました。 これにより、許容できるリスクの範囲内で新機能をリリースし、実ユーザーの反応を早期に確認できるようになりました。
この手法により、仮に何か問題が発生したとしてもすぐ0%に切り戻せる運用が確立し、実際に途中で切り戻して事なきを得たケースも何度かありました。 また、影響範囲を小さくしてリリースすることで、実ユーザーから早期にフィードバックをもらえるようになり、プロダクトの改善サイクルも大幅に向上しています。
今ではほとんどの機能リリースが段階的ロールアウトすることが当たり前になっており、品質とスピードの両立を実現する重要な仕組みとなりました。
インシデント情報の共有と透明性の向上
2のインシデント対応の課題に関しては、まずは本部全体でポストモーテムのテンプレートを作成し、一箇所に集約しました。
合わせて目標の一つである平均修復時間を計測できるように、「平均検出時間（MTTD）」「平均認知時間（MTTA）」「平均原因特定時間（MTTK）」「平均修正時間（MTTF）」「平均確認時間（MTTV）」をポストモーテムに含めることとします。
続いてインシデントが発生したことや、どのようなインシデント対策が行われているかを知らないという課題に対し、本部の正社員が全員いるチャンネルにSlackワークフローを2つ作成しました。
1つ目は「インシデント疑い報告」で、インシデントかどうかはわからないが、何らか調査を始めたときにこのワークフローを呼び出し、実際調査に当たってるチャンネルやスレッドを共有し全員が認知できるようにしました。
2つ目は「ポストモーテム作成報告」で前述のポストモーテムを作成したら共有するためのものです。 これに加えて本部の毎月の定例で、ポストモーテムとして良かった事例をインシデント管理委員会から共有し、本部全体に対してポストモーテムの重要性や対応してくれた人に感謝を示す場を設けて運用しています。
再発防止の徹底
3の再発防止&恒久対応をやりきっていない課題に関しては、ポストモーテムが整備されたことで管理しやすくなったため、開発ディレクターを中心にタスク管理を行うことでカバーしています。
課題と対策2: リードタイムの短縮 && リリース頻度
こちらの課題もまずは計測から始めました。
こちらの記事でも少しだけ触れていますが、バリューストリームマッピングを実施し エンジニア、QA、PdM、デザイナー、ディレクターそれぞれの視点で、リリースまでにどういうプロセスがあり、そこにどれだけの時間がかかっているかをMiroで可視化していきました。 各視点でおおよそ2時間強かかるなかなか重い作業ではありましたが、開発プロセスが可視化できて非常に意味のある取り組みだったかと思います。
それぞれの視点で見ていくと、大きくコストがかかっていたのは各職種間での連携です。
チーム固定化による品質と生産性の向上
これまでのチームビルディングはプロジェクトごとに人員がアサインされる方式でした。この方式には以下のような課題がありました：
チームが成熟しにくく、内部品質が悪化する
- プロジェクト都度でメンバーが入れ替わるため、未成熟なチームワークのまま開発が行われる
- チーム内でのコードレビューやナレッジ共有が十分に機能せず、内部品質が悪化しやすい
- プロジェクトごとにチームビルディングをやり直すコストが発生
同時並行プロジェクトによる認知負荷の高さ
- リーダーが横断的に複数プロジェクトの詳細を把握する必要があり、認知負荷が高すぎる
- メンバーも複数のプロジェクトに跨って参加することが多く、コンテキストスイッチのコストが大きい
- 同時並行で動くプロジェクト数が多すぎることが、品質や生産性を下げる大きな要因となっていた
これらの課題に対し、職能別の組織をクロスファンクショナルなチームにして固定化することで解決を図ります。
チーム固定化により以下のような効果を狙いました： - チームメンバーが固定されることで、チームが成熟しやすい環境をつくる - 同時並行で動くプロジェクト数を制限し、認知負荷を下げる - 基本的にはチーム内のみ詳細を見ておけば良い状態を目指し、横断的な把握の負担を減らす
実はチーム固定化自体は2024年の早い段階から実施したかったのですが、人が十分に採用できていないことや、既存プロジェクトがありなかなかタイミングが合わず実現できてませんでした。 しかしエンジニアも増え、PdMやデザイナーも含めて同じ組織になるこのタイミングで実行するしかないとなり、ついに実現できました。 上記の決起会の記事にも「長年の悲願だった固定スクワッドチーム体制への変更が本運用開始〜」とあるように、マネージャー目線では悲願of悲願で、決起会やその後の本部の定例などでスクワッドチームの代表者が一丸となったチームの成果を発表する姿を見ると、マネージャー陣はうれしくてニヤニヤしてしまうというのが最近の恒例だったりしますｗ
チームの固定化でコミュニケーションの質を上げリードタイムの短縮は着実に改善されていったわけですが、各チームでの開発がそれぞれ進むとチーム間でどう連携をしてリリースしていくかという次の悩みが生まれることが予想されました。 これに関してはリリーストレインで解決することを事前に決めていました。
リリーストレイン（Release Train）とは、アジャイル開発において、複数の開発チームが連携し、電車のように決まったスケジュール（頻度）で定期的にソフトウェアをリリースする仕組みです メルカリなどで導入され、リリース遅延の防止、チーム間の同期、品質の安定化、ビジネス部門との連携強化などを目的とし、間に合わなかった機能は次の「列車」に乗せる（先送りする）イメージです。 (Geminiによる概要)
スクワッドチームは3チームあるのですが、隔週でリリースするという決め事の中で、間に合わなかったものは次のリリースに回すという運用をすることにしました。 この結果、安定して月に2回以上の機能リリースを実現できるようになりました。
このようにアウトプットが加速すると、今度はQAのリソースが不足する懸念が生まれてきました。 生産性が高まったからこそ生まれたうれしい悲鳴ではあるのですが、QAがボトルネックになってリリースができないという事態は避けなければなりません。
テスト自動化によるQAの効率化
これに関しては先ほどのバリューストリームマッピングの結果や不具合分析から改善点を抽出し、「SET（Software Engineering Test）チームによるテスト自動化の文化づくり」により改善していくこととなります。 リグレッションテストに大きな工数がかかっていることがわかったため、SETチームを組成しまずはWebとiOSからE2Eテストを開発していきました。QAやSETだけがテストをするというのではなく、各エンジニアがユニットテストを書くような文化づくりも行ってもらいました。 その結果大幅にテスト工程を削減でき、品質とスピードの両立に大きく貢献しています。
課題と対策3: 生成AIの活用
生成AIの活用に関してはあくまで手段であって目的ではないのですが、年初から他社での活用事例が多く出てきており、ある程度トップダウンで方向性を示さなければあっという間に周回遅れになりそうな危機感があり、期初の戦略に含め活用を推進してきました。 春先からClaudeやDevinの活用を始め、6月には生成AIをテーマにした開発合宿を実施、その結果プロダクトへの生成AIの適用なども順次始まっています。 今回のアドベントカレンダーでも多くのAI活用事例が書かれていますが、エンジニアだけでなくPdMやデザイナーも多くがAIを中心とした開発を進めています。 しかし、まだまだAI活用が他社よりリードできているとは全く思ってません。むしろ少し遅れてるくらいの認識でいます。 来年はAIエージェントの開発も含め、AIを活用しより品質とスピードを高めていきたいと考えています。
まとめ: 品質とスピードのその先、アウトプットからアウトカムへ
これらの課題を解決した結果、期初に立てた本部目標は概ね達成できており、着実に品質とスピードが上がってきているのを実感しています。 しかし、プロダクト開発において重要なのはアウトプットではなくアウトカムだともよく言われます。 アウトプットを高めることに費やした約2年間で、ようやく競合他社と比較しても目劣りしないレベルのアウトプットを出せる開発組織になったと自負していますが、ここからはアウトカムを得るフェーズになったと思っています。 PdMやデザイナーを含めたスクワッドチームは、このアウトカムを全員で得るために様々な創意工夫を行える体制でもあります。 実際、今年はショート動画のリリースや、各種出面のパーソナライズなど、プロダクト開発でのKPIへの寄与が着実にできた一年でもあります。 来年はさらなる飛躍の年にしていくので、みなさまTVerをこれからもよろしくお願いいたします。年末年始はTVerで動画をお楽しみください。 良いお年を！
