サービス統合で行った選択と意思決定── U-NEXT・Paravi サービス統合プロジェクトの実践事例のトップ画像

サービス統合で行った選択と意思決定── U-NEXT・Paravi サービス統合プロジェクトの実践事例

投稿日時:
富田 宙のアイコン

株式会社U-NEXT / ソフトウェアエンジニア

富田 宙

Xアカウントリンク
2026年2月26日に、ファインディ株式会社が主催するイベント「技術選定を突き詰める Online Conference ――逆境を乗り越える意思決定プロセス」が、オンラインにて開催されました。

本セッションでは、株式会社U-NEXTの富田 宙さんが登壇。2023年に実施されたU-NEXTとParaviのサービス統合プロジェクトを題材に、タイトなスケジュールの中でどのように技術選定や意思決定を進めたのか、4つのケーススタディを交えながら具体的な実践事例を語りました。フラット組織における大型案件のリーダーシップのあり方にも踏み込んだ、実務に直結する内容です。ぜひアーカイブ動画とあわせてご覧ください。

はじめに

富田:富田 宙と申します。株式会社U-NEXTのR&D本部で、お客さまのサブスクリプションに関わる契約管理と、決済の基盤システムの開発運用を担当しています。

本日は「逆境を乗り越える意思決定プロセス」をテーマに、2023年に行われたU-NEXTとParaviのサービス統合プロジェクトの実践事例をお話しします。みなさんに持ち帰っていただきたいことは次の3つです。

  • タイトなスケジュールの中でどう意思決定するか
  • アーキテクチャ選定における判断基準のつくり方
  • フラット組織での大型案件のリーダーシップの取り方

開発に携わるみなさんが同様の大型プロジェクトに直面した際に、再現性のある知見として共有できればと考えています。

サービス規模について

U-NEXTは44万以上のビデオと127万以上の書籍を配信しており、Android、iOS、Fire OSなど様々なプラットフォームに対応しています。1アプリでビデオやブックといった媒体の垣根を越えるシームレスな遷移が可能な設計が特徴です。

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

プロジェクトの全体像と担当領域

今回のサービス統合にあたり必要だったことは、「Paravi作品をU-NEXTを通じて引き続き楽しめるようにすること」でした。そのためにはアカウント情報や契約情報を確実にParaviからU-NEXTに移行すること、そして1つのアカウントでParaviとU-NEXT両方の情報を扱えることが求められました。

私たちの担当領域はU-NEXTの契約サービスと決済サービスです。これはミッションクリティカルな基盤システムであり、複雑なドメインを扱い、高い可用性が求められるユーザー体験の根幹を支える重要なシステムです。

タイトなスケジュールという逆境

ここで出てきた逆境が、タイトなスケジュールでした。2023年2月にプレスリリースが行われ、同年6月末にはサービスインしなければならないという状況で、わずか4カ月でこのミッションを完了させる必要がありました。

直面した課題として、統合に必要な要素が多岐にわたっていたこと、ここまでの大型案件は私たちも初めての試みで未知の部分が多くありました。そして既存システムとの整合性を保ちながらの開発が必要だったことが挙げられます。

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

担当サービスと統合の概要.jpg

技術選定における判断基準

限られたリソースや厳しい期限といった逆境の中で、私たちが使った4つの判断基準があり、これらを総合的に判断しました。

  1. 機能要件との適合性:解決したい課題に対してその技術が適しているか
  2. 非機能要件:パフォーマンス、セキュリティなど、システムが満たすべき品質特性
  3. 運用面:デプロイのしやすさ、モニタリング環境、メンテナンス性
  4. チームの習熟度とエコシステム:チームが使いこなせている技術か、コミュニティやドキュメントが充実しているか

アーキテクチャの選定

アーキテクチャの選定として、既存のアーキテクチャを踏襲する案と、部分的にリニューアルをする案がありました。今回は実績のある構成を活用する既存アーキテクチャの踏襲を採用しています。

私たちが利用した技術スタックは、JavaもしくはKotlinとSpring Bootによるマイクロサービスアーキテクチャを採用しています。各リポジトリはDDD(ドメイン駆動設計)でレイヤーを分け、ビジネスロジックをプログラムで表現するように設計開発を行っています。

データストアはメインがRDB(MySQL)を採用し、アクセスの多いサービスのためキャッシュとしてRedisを活用しています。また一部Google Cloudを利用して柔軟な対応を行えるよう設計しています。

アーキテクチャ選定_既存構成の踏襲.jpg

この記事のつづきを読もう
新規登録/ログインしたらできること
  • すべての記事を制限なく閲覧可能
  • 限定イベントに参加できます
  • GitHub連携でスキルを可視化
ログイン
アカウントをお持ちでない方はこちらから新規登録