サービス統合で行った 選択と意思決定

サービス統合で行った 選択と意思決定 株式会社U-NEXT R&D本部 富田 宙

自己紹介 氏名: 富田 宙 (とみた そら) 所属: 株式会社U-NEXT R&D本部 • 契約管理と決済の基盤システムの開発・運用 よく使う言語 • Kotlin、Java 趣味 • 社交ダンス、キックボクシング

はじめに 本日は「逆境を乗り越える意思決定プロセス」をテーマに、2023年に行われたU- NEXTとParaviのサービス統合プロジェクトでの実践事例をお話しします。 本日、皆様に持ち帰っていただきたいこと: • タイトなスケジュールの中でどう意思決定するか • アーキテクチャ選定における判断基準の作り方 • フラット組織での大型案件のリーダーシップの取り方 開発リーダーやエンジニアリングマネージャーなどの開発に携わる皆様が、同様の 大型プロジェクトに直面した際に「あの時の選択と同じだ」と参考にしていただけ る、再現性のある知見を共有します。

U-NEXTとは？ 44万本以上のビデオ、 127万冊の電子書籍を配信 Webはもちろん、 Android、iOS、Fire OSなど お使いのプラットフォームで 利用可能 媒体の垣根を超える シームレスな遷移

U-NEXTのマーケットシェア 2位 TBS、テレビ東京のParaviと統合 U-NEXTと、Paraviがひとつに。 TBSやテレビ東京の人気番組を約1万本追加！ 出典: GEM Partners「動画配信（VOD）市場5年間予測（2024-2028年）レポート」

Paraviとは？ Paraviは、TBS、テレビ東京、WOWOWなど6社が出資するプレミアム・プラット フォーム・ジャパン (PPJ) が運営していた動画配信サービス 特徴: • ドラマやバラエティ作品を中心としたコンテンツ • 2018年4月サービス開始 • 2023年7月にU-NEXTに統合 • 会員数は約80万人 統合により、U-NEXTユーザーはParaviの豊富な作品も楽しめるようになりました

前半戦 サービス統合

プロジェクトの全体像と担当領域 サービス統合で必要なこと: 「Paravi作品をU-NEXTを通して引き続き楽しめること」 • アカウント情報や契約情報を確実にU-NEXTに移行 • 1つのアカウントでParavi・U-NEXT両方の情報を扱える 私たちの担当領域: 「U-NEXTの契約サービス」と「U-NEXTの決済サービス」というミッションクリテ ィカルな基盤システム。複雑なドメインを扱い、高い可用性が求められ、ユーザー 体験の根幹を支える重要なシステムです。

逆境: タイトなスケジュール 2023年3月にプレスリリースが公開され、サービスイン日が決定しました。 2023年3月プレスリリース → 2023年6月30日サービスイン わずか4ヶ月で、このミッションを完了させる必要がありました。 直面した課題: • 統合に必要な要素が非常に多岐に渡る • 大型案件としては初めての試みで未知の部分が多い • 既存システムとの整合性を保ちながらの開発が必要

担当サービスと統合の概要 私たちのチームが担当したのは: 1. Paraviの契約情報をU-NEXTの契約情報に統合する 2. ParaviユーザーがU-NEXTユーザーとしてログインできるようにする この2つの対応について、具体的な意思決定プロセスを交えてお話していきます。 Paraviの契約情報を U-NEXTの契約情報に 統合する U-NEXT 契約サービス Paravi 契約情報 Paraviユーザーが U-NEXTユーザーとし てログインできるよう にする U-NEXT ログイン・認証サービス U-NEXT 決済サービス

技術選定における判断基準 限られたリソースや厳しい納期といった「逆境」の中で、私たちが使った4つの判 断基準: 1. 機能要件との適合性: 解決したい課題に対してその技術が適しているか 2. 非機能要件: パフォーマンス、セキュリティなど、システムが満たすべき品質 特性 3. 運用面: デプロイのしやすさ、モニタリング環境、メンテナンス性 4. チームの習熟度とエコシステム: チームが使いこなせている技術か、コミュニ ティやドキュメントが充実しているか これらを総合的に判断しました。この観点を軸にお話をしていきます。

アーキテクチャ選定: 既存構成の踏襲 技術スタック: • Java/Kotlinとspring-bootでマイクロサービスアーキテクチャ • DDD (ドメイン駆動設計) でビジネスロジックを表現 • RDB (MySQL) をメインデータストア、Redisをキャッシュに活用 • Google Cloudを利用した柔軟な設計 選択肢: 1. 既存アーキテクチャ踏襲案 - 実績のある構成を活用する (✅採用) 2. 部分的リニューアル案 - 一部だけ新技術を導入する

アーキテクチャ選定: 採用理由 4つの判断基準で評価: 1. 機能要件: DDDが複雑なビジネスロジックの表現に最適 2. 非機能要件: 実績ある構成で可用性・セキュア要件に対応 3. 運用面: 既存のデプロイ・モニタリング基盤を活用可能 4. チーム習熟度: 学習コストゼロで即座に開発着手、リソース調達も容易 判断の決め手: タイトなスケジュールと実績のあるアーキテクチャという状況から、大きな変更に は挑戦せず既存構成を踏襲しました。 実績あるアーキテクチャを選択することで、アカウント統合などの本質的な課題に 力を割くことができました。

逆境に対する意思決定の軸 まず、用語を整理します • 「サービス統合」とは: U-NEXTとParaviのシステムはほぼ独立した状態で維持するが、ユーザーから はU-NEXTを通じてParavi作品が観れるようにすること • 「完全統合」とは: U-NEXTとParaviのシステムを統合すること

意思決定の軸: 新しく作る vs 今ある 仕組みのブラッシュアップ 最も重大な意思決定: 統合の進め方 タイトなスケジュールの中で、CTOも交えた議論を行いました。論点は「4ヶ月で 完全統合まで実施できるのか」という点でした。 2つの選択肢: • A. 一気に完全統合案 - 4ヶ月でシステムの完全統合まで実施 • B. 2段階統合案 - まず、U-NEXTとParaviのシステムはほぼ独立した状態で維持 するが、ユーザーからはどちらのサービスも使えるようにする、その後、U- NEXTとParaviのシステムを統合する

選択肢の比較 項目 サービス統合 完全統合 ユーザー体験 U-NEXTとして統一 U-NEXTとして統一 (変わらず) バックエンド U-NEXTシステム + Paraviシステムが共存 U-NEXTシステムのみ 決済処理 Paraviシステムが担当 U-NEXTシステムが担当 アカウント管理 U-NEXTシステムが担当 (移行済み) U-NEXTシステムが担当 保守対象 2つのシステムをメンテナンス 1つのシステムのみメンテナンス

選定理由と判断基準 B案 (2段階統合) を選んだ理由: 4つの判断基準で評価 1. 機能要件: 期限内にユーザー移行とアカウント統合を実現可能 2. 非機能要件: 段階的アプローチによりリスクを分散 3. 運用面: 一時的に2つのシステム保守のコスト増だが、期限内実現を優先し第2段 階で完全統合する 4. チーム習熟度: 既存の仕組みの活用で学習コストを最小化、段階的に確実に進行

判断の決め手: 期限内実現の優先 判断の決め手: 期限は、ビジネス上絶対に守らなければならない制約でした。完全統合を目指すと 6〜8ヶ月必要で期限に間に合わない見込みでしたが、 • 第1段階 (4ヶ月): ユーザーから見た「サービスの統合」を実現 • 第2段階 (追加期間): バックエンドの「完全統合」を実現 と2段階に分けることで、期限内にユーザー価値を届けることを最優先しました。 これは技術的な理想よりも、確実に動くものを期限内に届けることを優先した、現 実的な意思決定でした。

具体的な対応方法: 既存の外部ID連携の活用 U-NEXTの外部ID連携: 複数企業と「Powered by U-NEXT」形式で提携済み (OpenID Connect標準規格) 今回の判断: Paraviを「パートナーサービスの1つ」として扱う 活用のメリット: 開発期間の大幅短縮 (新規2〜3ヶ月 → 既存基盤活用)、品質・ 安定性の確保、運用効率化 → 2段階統合案の第1段階を4ヶ月で実現できた大きな要因

ケーススタディを交えながら 深掘りしていきます

ケーススタディ1: アカウント統合機能の設計 直面した課題 既存U-NEXTユーザーが、Paraviからの移行により2つのアカウントを持つことで利 便性が下がる 選択肢: • A. 強制統合案 - システム側で自動的に統合 • B. ユーザー選択案 - ユーザーが選べる (✅採用) • C. 放置案 - 2つのアカウントのまま運用

アカウント統合機能の設計 判断基準: ユーザー体験を最優先し、ユーザーが選択できる方式を採用 採用した解決策: • アカウント統合機能を提供 • ユーザーが選択可能: 統合 or 別々のまま維持 • シームレスな統合プロセスを実現 U-NEXTシステム アカウントA アカウントB 購入情報 契約情報 履歴情報 アカウントB ※Paraviからの移行分 ユーザーが選択してアカウントを 統合できる機能を用意

アカウント統合機能の設計 結果: この対応により、ユーザーの利便性低下に対しての解決を行えました。 また、この機能は汎用的な設計で作られたため、他の場面でも活用されるようにな りました。 知見: ビジネス要求を満たすだけでなく、汎用的な設計にすることで、投資対効果を最大 化できます。

ケーススタディ2: 大規模データ移行 の設計 課題: 相当数のユーザーを期限内に確実に移行 (負荷集中回避、ダウンタイムな し) 選択肢: A. ビッグバン移行案 | B. 段階的移行案 (✅採用) | C. ユーザー主導移行案 採用した戦略: 段階的な移行プロセス (ユーザー操作による移行導線＋バッチに よる事前移行)

サービス移行の実施 2023年6月30日 - プレスリリースから4ヶ月弱 数ヶ月に渡る入念な準備と綿密なリハーサル。段階的な事前移行とパフォーマンス テスト。当日の役割は主に「見守ること」。入念な準備がもたらした静かな戦いで した。 80万人のアカウントが移行 • サービスのダウンタイムゼロでの移行完了 • エラー率は想定範囲内、想定外のトラブルなし • ピーク時の負荷分散が設計通りに機能 • ほぼ全てのParavi契約ユーザーを途切れることなく迎え入れることに成功

サービス移行の実施 成功の裏側にあったもの: DDDとマイクロサービスアーキテクチャという選択がこの移行で意味を持ちました • ドメイン境界で明確に分離され、複数チーム間の連携がスムーズ • 問題発生時の切り分けが瞬時に行え、迅速な対応が可能 • 各サービスの独立性が全体の安定稼働を支えた この経験から得た教訓: 大規模移行で最も重要なのは、「何が起こるか分からない」という前提に立った設 計です。段階的なアプローチにより問題を発見し、軌道修正する余地を残すこ と。そして、当日を「見守るだけの日」にできるほど、事前準備に投資すること。 それが成功への道でした。

サービス移行後のシステム概要 U-NEXTシステム Paravi システム U-NEXT 契約サービス U-NEXT ログイン・認証サービス U-NEXT 決済サービス

後半戦 完全統合

完全統合について 完全統合とはParaviシステムをU-NEXTシステムに統合し、U-NEXTシステムだけで 処理できるようにすることを指します。 • 様々な事情があり、今回もタイトなスケジュールで完全統合を完了させる必要 がありました • また、今回は前回の「サービス統合」とは異なり、新規開発部分がほとんどで した • そして完全統合以外にも対応しないといけない案件が多数ありました

直面した逆境: リソース不足 リソース不足への対応: 開発初期の段階でリソース不足が明白だったため、CTOとも相談し、他チームから もリソースを借りて人的リソースを確保すること (総勢15人ほど) に決めました。 しかし、人的リソースの確保は、新たな逆境を生み出すことになります。「船頭多 くして船山に登る」ということわざそのまに、組織的な課題が発生しました。

直面した問題 直面した問題: 停滞の兆候 • 開発リソースは確保できたが、設計が追いつかない • 進捗確認で「設計待ち」という報告が続く • 開発メンバーが待機状態に陥る 問題の根本原因 U-NEXTはフラット組織を採用し、チーム全体が納得感を持って進める文化があり ます。これは通常の発では強みですが、今回のような大型案件では次の課題を生 みました

フラット組織での意思決定の課題 課題 1. 技術的な優先順位の相違 - 設計・実装についての議論が平行線 2. 評価軸の言語化不足 - 「何を捨て、何を優先するか」が不明確 3. 役割の曖昧さ - 大型案件にも関わらず専任リード役を明確に置かなかった 私自身の失敗: • 組織文化を意識するあまり、設計と開発の両方に手を割いた • 設計のスピードが開発に追いつかず、開発を停滞させた 転換点: この状況を打開するため、役割を明確化することを決断しました。

課題への対応 実施した対応: 1. リード役の専任化 ○ 自分はリード・設計に専念する役割とすることを明確化 ○ 開発は他のメンバーに任せる体制に変更 2. 評価軸の言語化と共有 ○ 「何を捨て、何を優先するか」の判断基準を明文化 ○ チーム全体に方針を共有し、意思決定の迷いを減らす 3. 責任範囲の明確化 ○ 誰がどの領域の責任を持つかを明確にし、情報の集約先を定める

対応結果と得られた知見 この決断の効果: 役割の明確化により、設計のスピードが上がり、1週間ほどで開発スピードも格段 に上がりました。フラットな組織文化を維持しつつも、大型案件では専任のリード 役が必要であることを痛感しました。 得られた知見: フラット組織は強力ですが、状況に応じて柔軟に役割を定義する必要があります。 「誰がどの責任を持つか」を明確にすることで、チーム全体が迷わず進めることが できます。組織文化と実務のバランスを取ることが、プロジェクト成功の鍵でし た。

完全統合を実現するために 必要なこと 完全統合を実現するために必要な主なことの一部として以下の対応がありました。 1. キャリア決済のリニューアル 2. 異なる決済代行会社を通じてのカード決済の追加 それぞれの対応と意思決定プロセスについてお話します。

ケーススタディ3: 技術的負債と 現実的な対応のバランス テーマ: キャリア決済のリニューアル 直面した課題: • 複数の加盟店 (U-NEXTとParavi) に対応するつくりではなかった • 既存の仕組みはフロントエンド主体で技術的負債があり拡張性が低い 選択肢: • A. 技術的負債を抱えたまま機能追加 - 短期的には早い • B. リニューアル - 時間はかかるが将来の拡張性が高い (✅採用)

キャリア決済のリニューアル 判断基準: 目先の工数削減ではなく、将来の拡張性を重視。技術的負債をいま解 消することで、長期的なコスト削減につながると判断 採用した解決策: 既存の処理は意識せずに設計を行い、サーバー主体での処理フローに変更。技術ス タックも古い部分を刷新して、運用しやすくした 刷新後のシステムフロー図 U-NEXT フロントシステム U-NEXT 決済サービス キャリア決済 代行会社 決済基盤でリクエスト情報を生成して決 済代行にリクエストを送信

キャリア決済のリニューアル 結果: メンテナンス性、拡張性が高まり運用しやすくなりました。 知見: 技術的負債の返済は「今やるべきか、後でいいか」の判断が重要です。拡張性が求 められる部分や既知の問題のある部分は、思い切ってリニューアルすることで、長 期的なコストを削減できます。

ケーススタディ4: ユーザー体験 vs 技術的シンプルさ テーマ: 異なる決済代行会社を通じてのカード決済 直面した課題: U-NEXTとParaviで利用している決済代行会社が異なる 選択肢: • A. U-NEXTの決済代行会社に統一 - システムはシンプルだがユーザーに再登録 させる • B. 両方の決済代行会社をサポート - システムは複雑だがユーザー体験は良い ( ✅採用)

異なる決済代行会社を通じての カード決済 判断基準: ユーザー体験を最優先。システムは複雑になるが、ユーザーの利便性を 重視 対応: ParaviシステムからU-NEXTの決済サービスへ決済処理を移管し、決済代行 会社AとBの両方をサポート 知見: 「技術的にシンプル」と「ビジネス的に正しい」は必ずしも一致しませ ん。ユーザー体験を優先した結果、システムが複雑になるが、それが正しい選択と なることもあります。

異なる決済代行会社を通じての カード決済 U-NEXT 決済サービス 決済代行会社A カード会社 Paraviシステム ↓ U-NEXT 決済サービス 決済代行会社B

完全統合の完了 完全統合後は私たちの「契約サービス」、「決済サービス」と「U-NEXTのログイ ン・認証サービス」が互いにやりとりをしつつ、他にも様々なマイクロサービスで U-NEXTというシステム、サービスを構成する形になりました。 完全統合により、U-NEXTだけでParaviからの移行ユーザー分も含めたサービス提 供が行えるようになり、保守対象は2システムから1システムに集約されました。 2段階での統合は、後半戦で見てきたように課題もありましたが、ビジネス面と開 発面双方の事情を考慮した現実的な判断として、結果的に良い形で着地できまし た。

完全統合後のシステム概要 U-NEXTシステム U-NEXT 契約サービス U-NEXT ログイン・認証サービス U-NEXT 決済サービス

まとめ: 逆境を乗り越える意思決定 プロセス 直面した3つの逆境 1. タイトなスケジュール - わずか4ヶ月での統合 2. リソース不足 - 大型案件に対する人的リソースの限界 3. 組織的な課題 - 専任のリード不在による失敗とプロジェクトの停滞 意思決定の3つの軸 1. 既存サービスを最大限踏襲 - ゼロから作らず、実績ある仕組みを活用 2. ユーザー体験を最優先する - 技術的な理想よりもユーザーの利便性を重視 3. 汎用的な設計で他でも活用可能にする - 将来の変更にも対応できる柔軟性

まとめ: 逆境を乗り越える意思決定 プロセス 技術選定での意思決定プロセス 1. 選択肢を明確にする - 実現すべきことは何か 2. 判断基準を言語化する - 機能要件、非機能要件、運用面、チームの習熟度 3. トレードオフを可視化する - メリット・デメリットを明確に 4. 決断し、実行する - 完璧を目指さない勇気

まとめ: 逆境を乗り越える意思決定 プロセス フラット組織での大型案件のリーダーシップ 1. 役割を明確にする - 誰がどの責任を持つか 2. 評価軸を言語化する - 何を捨て、何を優先するか 3. 専任のリード役を置く - 状況に応じて柔軟に組織を変える

実績 プロジェクトの成果 逆境を乗り越える意思決定プロセスを活用し、大型でタイトなスケジュールの案件 を成功させることができました。 このプロジェクトを通じて学んだのは、意思決定の重要性です。 完璧な答えがない中でも、根拠を持って決断し、それを実行に移し、必要に応じて 修正していく。そのプロセスそのものが、大規模プロジェクトを成功に導く鍵とな りました。

本日のまとめ: 皆様へ持ち帰ってい ただきたいこと 開発に携わる皆様 (特にリードやアーキテクトの方) が、同様の大型プロジェクト に直面した際に参考にしていただける知見を共有しました。 持ち帰っていただきたいこと: 1. 意思決定フレームワーク - 選択肢を明確にし、判断基準を言語化する 2. アーキテクチャ選定の考え方 - 実績ある技術を活用し、本当に重要な部分に力 を割く 3. フラット組織でのリーダーシップ - 状況に応じて専任のリード役を置く

最後に IT エンジニア採用中です！ 以下にピンと来る方はぜひ • 超フラットな組織体制 • 国際色豊かなメンバーと日本語中心に複数の言語でのコミュニケーション • 全エンジニアがプレイヤー 就業形態 ：コアタイムなしフレックス制度 リモートワーク率 ：98%+ ※ 平均残業時間 ：約6時間/月 ※ 出身国 / 地域 ：20カ国 (利用言語は日本語メイン) ※ 産休育休復帰率 ：100% ※ ※ 2024年11月の情報 評価制度等について詳しくは 弊社技術同人誌 Vol01で！ 弊社採用ページ

ご清聴ありがとうございました！ Q&A