本セッションでは、株式会社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つの対応について、具体的な意思決定プロセスを交えてお話ししていきます。
技術選定における判断基準
限られたリソースや厳しい期限といった逆境の中で、私たちが使った4つの判断基準があり、これらを総合的に判断しました。
- 機能要件との適合性：解決したい課題に対してその技術が適しているか
- 非機能要件：パフォーマンス、セキュリティなど、システムが満たすべき品質特性
- 運用面：デプロイのしやすさ、モニタリング環境、メンテナンス性
- チームの習熟度とエコシステム：チームが使いこなせている技術か、コミュニティやドキュメントが充実しているか
アーキテクチャの選定
アーキテクチャの選定として、既存のアーキテクチャを踏襲する案と、部分的にリニューアルをする案がありました。今回は実績のある構成を活用する既存アーキテクチャの踏襲を採用しています。
私たちが利用した技術スタックは、JavaもしくはKotlinとSpring Bootによるマイクロサービスアーキテクチャを採用しています。各リポジトリはDDD（ドメイン駆動設計）でレイヤーを分け、ビジネスロジックをプログラムで表現するように設計開発を行っています。
データストアはメインがRDB（MySQL）を採用し、アクセスの多いサービスのためキャッシュとしてRedisを活用しています。また一部Google Cloudを利用して柔軟な対応を行えるよう設計しています。
このアーキテクチャの選定も先ほどの4つの判断基準で評価しました。機能要件の面ではDDDが複雑なビジネスロジックの表現に適しているため、今回の要件に合致すると判断しました。非機能要件の面では、実績ある構成で可用性要件に対応できており、特にSpring Bootの機能が強力だった点が大きな要因です。運用面については既存のデプロイやモニタリング基盤をそのまま活用できました。チーム習熟度の面では既存のアーキテクチャであるため学習コストがゼロで即座に開発着手でき、他チームからのリソース調達も容易でした。
今回の判断の決め手は、タイトなスケジュールと実績のあるアーキテクチャという状況を踏まえ、大きな変更には挑戦せず既存構成を踏襲したことです。実績あるアーキテクチャを選択することで、アカウント統合などの本質的な課題に力を割くことができました。
逆境に対する意思決定の軸
まず、この後に使う用語について整理します。
- 「サービス統合」とは：
- U-NEXTとParaviのシステム自体はほぼ独立した状態で維持するが、ユーザーからはU-NEXTを通じてParavi作品が観られるようにすること
- 「完全統合」とは：
- U-NEXTとParaviのシステムを1つに統合し、シンプルな状態でサービスが利用できる状態
今回の最も重大な意思決定である統合の進め方について、CTOを交えて議論を行いました。論点はタイトなスケジュールの中、4カ月で「完全統合」まで実施できるのかという点です。ここで2つの選択肢が出てきました。4カ月で一気に完全統合まで行う案と、2段階統合案です。2段階統合案では、まず「サービス統合」を行いユーザーからはどちらのサービスも使えるようにし、その後U-NEXTとParaviのシステムを完全統合するという段取りです。
完全統合は構成としてはシンプルになるものの、対応すると工数がかかるという問題がありました。そこで私たちは2段階統合案を選びました。
判断基準に照らすと、機能要件の面では期限内にユーザー移行とアカウント統合を実現可能である点が大きな決め手になりました。非機能要件の面では段階的アプローチによりリスクを分散できます。運用面では一時的に2つのシステムを保守するコストが増えますが、まずは期限内の実現を優先し、第2段階で完全統合を行って1つにする方針としました。チーム習熟度の面では既存の仕組みの活用で学習コストを最小化し、段階的に確実に進行させることを目標としました。
判断の決め手
決め手はやはり期限内実現の優先です。期限はビジネス上、絶対に守らなければならない制約でした。完全統合を目指すと最低でも半年から8カ月ほど必要な見込みで期限に間に合わない状況だったため、最初の4カ月でユーザーから見たサービスの統合を実現し、その後の期間でバックエンドの完全統合を進めるという2段階に分けることで、期限内にユーザー価値を届けることを最優先しました。技術的な理想よりも「確実に動くもの」を期限内に届けることを優先した、現実的な意思決定でした。
具体的な対応の1つとして、U-NEXTの外部ID連携を活用しました。Powered by U-NEXTというブランド形式で複数のパートナー企業とアカウント連携している仕組みがあり、OpenID Connectの規格を利用してアカウント連携を実現しています。今回はParaviをパートナー企業の1つとして扱い、この外部ID連携の仕組みを横展開することに決めました。活用のメリットとしては開発期間を大幅に短縮できること、既存ですでに活用している仕組みのため可用性の確保ができること、そして保守運用を効率化できることが挙げられます。このことが、2段階統合案の第1段階を4カ月で実現できた大きな要因となりました。
ケーススタディで深掘りする取り組み
ケーススタディ1：アカウント統合機能の設計
ここからはケーススタディを交えて深掘りしていきます。まずアカウント統合機能の設計です。
直面した課題として、既存のU-NEXTユーザーがParaviも利用していた場合、移行により2つのU-NEXTアカウントを持つことになり利便性が下がってしまうという問題がありました。対応の選択肢として、システム側で自動的に統合する案、ユーザーが選べるようにする案、2つのアカウントをそのまま維持する案が出ました。ここではユーザー体験を最優先し、ユーザーが選択できる方式を採用しました。
アカウント統合機能を提供することで、いずれかのアカウントに統合するか、別々のまま維持するかをユーザー自身が選べるようにしました。これによりシームレスな統合プロセスを実現しています。元々U-NEXTアカウントを持っていたユーザーの場合、Paraviからの移行分で新しいアカウントが生成されるため2つのアカウントを持つことになりますが、ユーザーが新しいアカウントを使うことを選択すれば、そちらに購入情報や契約情報、履歴情報などを統合し、以降そのアカウントでU-NEXTを利用できるようになりました。
この対応によりユーザーの利便性に関する課題を解決しました。また、この機能は汎用的な設計でつくられたため、ほかの場面でも活用できるようになっています。ビジネス要件を満たすだけでなく、汎用的な設計にすることで投資対効果を最大化できるという知見が得られました。
ケーススタディ2：大規模データ移行の設計
続いて、大規模データ移行の設計についてお話しします。約80万人のParaviユーザーのアカウント情報や契約情報などのデータを、期限内に確実にU-NEXTに移行する必要がありました。その際に負荷が集中することを回避すること、そしてダウンタイムなしで移行することが要件でした。
選択肢としてはビッグバン移行案、段階移行案、ユーザー主導で移行していく案の3つが出ました。今回は段階的に移行するプロセスを採用しています。ユーザー移行導線を用意してユーザー起点で事前に移行してもらうことに加え、バッチ処理でバックエンドから事前に移行するというものです。これにより安全かつ要件を満たす移行を行うことができました。
サービス移行の実施日は2023年6月30日でした。数カ月にわたる入念な準備と綿密なリハーサルを行い、段階的な事前移行とパフォーマンステストを実施していたため、当日の役割は主に見守ることでした。入念な準備がもたらした静かな戦いだったといえます。80万人のアカウントが移行してきましたが、サービスのダウンタイムはゼロで移行を完了させることができました。
エラー率は想定の範囲内で即座に対応を行い、想定外のトラブルも発生しませんでした。ピーク値の負荷分散も設計通りに機能し、サービストラブルは起こっていません。一番強調したいところとして、Paraviユーザーを途切れることなくU-NEXTに迎え入れることに成功しました。
成功の裏側にあったもの
この裏側には、DDDとマイクロサービスアーキテクチャの選択が意味を持っています。ドメイン境界で明確に分離された複数チームと複数サービス間の連携がスムーズだったこと、問題発生時の切り分けが比較的スムーズになり迅速な対応が行えたこと、これが全体の安定稼働を支えたと考えています。
この経験から得られた教訓として、大規模移行で最も重要なのは何が起こるかわからないという前提に立った設計です。段階的なアプローチにより問題を早期発見し軌道修正する余地を残すこと、そして当日を見守るだけの日にできるほど事前準備に投資すること。これが成功への道でした。
完全統合と新たな逆境
サービス統合の時点ではParaviユーザーの決済処理はParaviシステムで行われている状態でした。そのためParaviシステムとU-NEXTシステムの2つをメンテナンスし続ける必要があり、これを1つに完全統合することが次の目標です。
改めて完全統合とは、ParaviシステムをU-NEXTのシステムに統合し、U-NEXTのシステムだけで処理できるようにすることを指します。様々な事情があり、今回もタイトなスケジュールで完了させる必要がありました。前回のサービス統合とは異なり新規開発部分がほとんどで、さらに完全統合以外にも対応しなければならない案件が多数ありました。
そのような中で直面した逆境が、リソース不足です。開発初期の段階でリソース不足が明白だったため、CTOとも相談し、他チームからもリソースを借りて人的リソース総勢15人ほどを確保してプロジェクトに当たることに決めました。しかし、人的リソースの確保は新たな逆境を生み出すことになります。
フラット組織で生じた課題と打開策
開発リソースは確保できたものの、設計が追いつかないという状況に陥りました。進捗確認で「設計待ち」という報告が続き、開発メンバーが待機状態になってしまったのです。
問題の根本原因として、U-NEXTは上下関係のないフラットな組織を採用しており、チーム全体が納得感を持って進める文化があります。これは通常の開発では強みとなりますが、今回の大型案件では課題を生んでしまいました。
課題は大きく3つです。
- 技術的な優先順位の相違：設計や実装についての議論が平行線になり、なかなか開発が進まなかった
- 評価軸の言語化不足：「何を捨て、何を優先するか」が不明確なため意思決定が遅れた
- 役割の曖昧さ：大型案件にもかかわらず専任のリード役を明確に置かなかったため、情報が分散したり意思決定が曖昧になった
私自身の失敗としては、組織文化や今までのやり方を意識するあまり設計と開発の両方に手を割いていました。結果として設計のスピードが開発に追いつかず開発を停滞させてしまいました。
課題への対応
この状況を打開するため、役割を明確化することを決断しました。まずリード役の専任化として、私自身はリードと設計に専念する役割とし、開発はほかのメンバーに任せる体制に変更しました。次に評価軸の言語化と共有として、何を捨て、何をするかの判断基準を明文化し、チーム全体に方針を共有して意思決定の迷いを減らしました。最後に責任範囲の明確化として、誰がどの領域の責任を持つかを明確にし、情報の集約先を定めるようにしました。
この決断の結果、設計のスピードが上がり、体制変更から1週間ほどすると開発のスピードも格段に上がりました。フラットな組織文化を維持しつつも、大型案件では専任のリード役が必要であることを痛感する出来事でした。
ここで得られた知見として、フラット組織は強力ですが、状況に応じて柔軟に役割を定義する必要があるということです。誰がどの責任を持つかを明確にすることで、チーム全体が迷わず進められるようになります。組織文化と実務のバランスを取ることがプロジェクト成功の鍵でした。
ケーススタディ3：技術的負債と現実的な対応のバランス
完全統合を実現するために必要だった対応の具体例を紹介します。まずはキャリア決済のリニューアルについてです。キャリア決済とは、モバイルの3大キャリアの携帯料金と合算してU-NEXTの料金を支払う決済方法です。
直面した課題として、U-NEXTではすでにキャリア決済に対応していましたが、U-NEXTとParaviという複数の加盟店に対応するつくりにはなっていませんでした。また既存の仕組みはフロントエンド主体のロジックとなっており、技術的負債があり拡張性が低いという問題がありました。
選択肢として、技術的負債を抱えたまま機能拡張するか、リニューアルするかで検討しました。結果として、時間はかかるものの将来の拡張性が高いリニューアル案を採用しています。判断基準としては目先の工数削減ではなく将来の拡張性を重視しました。技術的負債を今解消することで長期的なコスト削減につながるという判断です。
採用した解決策として、既存の処理は意識せずに設計を行い、サーバー主体での処理フローに変更しました。技術スタックも古い部分を刷新して運用しやすくしています。決済サービスで決済代行会社に投げるリクエストを生成し、フロントシステムを通じて決済代行会社にポストリクエストすることで決済を行う仕組みに変えました。この対応の結果、メンテナンス性と拡張性が高まり運用しやすくなりました。
ここで得られた知見として、技術的負債の返済は「今やるべきか、後でいいか」の判断が重要です。拡張性が求められる部分や既知の問題がある部分は思い切ってリニューアルすることで、長期的なコストを削減できます。
ケーススタディ4：ユーザー体験 vs 技術的シンプルさ
続いて、異なる決済代行会社を通じてのカード決済についてです。U-NEXTとParaviは共にクレジットカードでの決済機能を提供していましたが、利用している決済代行会社が異なるという問題がありました。
選択肢としては、U-NEXTの決済代行会社に統一する案と、両方の決済代行会社をサポートする案がありました。U-NEXTの決済代行会社に統一すればシステムはシンプルになりますが、ユーザーに再登録を促す必要があり、その際にサービスから離れてしまうリスクが高いという問題があります。そのため、システムは複雑になるもののユーザー体験を重視し、両方の決済代行会社をサポートする案を採用しました。
対応として、ParaviシステムからU-NEXTの決済サービスへ決済処理を移管し、決済代行会社AとBの両方をサポートする構成に変えています。ここで得られた知見は、「技術的にシンプル」であることと「ビジネス的に正しい」ことは必ずしも一致しないということです。ユーザー体験を優先した結果システムは複雑になりますが、サービスとしてはそれが正しい選択となることもあります。
このようにして完全統合を完了させました。完全統合後は契約サービス、決済サービスとログイン認証サービスが互いにやり取りをしつつ、ほかにも様々なマイクロサービスでU-NEXTのシステムを構成する形になっています。完全統合によりU-NEXTだけでParaviからの移行ユーザー分も含めたサービス提供を行えるようになり、保守対象は1つのシステムに集約されました。
まとめ
逆境を乗り越える意思決定プロセスということで、今回直面した3つの逆境がありました。わずか4カ月での統合というタイトなスケジュール、大型案件に対する人的リソースの不足、そして専任のリード不在による失敗とプロジェクトの停滞という組織特有の課題です。
これに対して意思決定の3つの軸を置きました。既存サービスを最大限踏襲すること、何よりもユーザー体験を優先すること、そして汎用的な設計でほかにも活用可能にすること、将来の変更にも対応できる柔軟性を持たせることです。
技術の意思決定プロセスとしては4つのステップがあります。
- 選択肢を明確にする：実現すべきことは何か
- 判断基準を言語化する：機能要件や非機能要件、運用面、チームの習熟度
- トレードオフを可視化する：メリットとデメリットを明確に
- 決断し、実行する：完璧を目指せない勇気
フラット組織での大型案件のリーダーシップとしては、誰がどの責任を持つか役割を明確にすること、何を捨て何を優先するか評価軸を言語化すること、そして専任のリード役を置くなど状況に応じて柔軟に組織を変えられるようにすることが重要でした。
このプロジェクトを通して学んだのは意思決定の重要性です。完璧な答えがない中でも根拠を持って決断し、それを実行に移し、必要に応じて軌道修正していく。そのプロセスそのものが大規模プロジェクトを成功に導く鍵となりました。
Q&A
Q. 4カ月での統合というタイトなスケジュールの中で、判断基準をつくって考えるというのは元から決まっていたのでしょうか、それとも試行錯誤しながらつくっていったのでしょうか。
A. 試行錯誤しながらというところが多かったです。4カ月という短いスケジュールの中で、チームやCTOの力も借りながら基準をつくって進めていきました。
Q. 大規模なデータ移行なのでQAやリハーサルなどの準備も入念にする必要があったと思いますが、スケジュールの内訳はどのような感じでしたか。
A. 実質4カ月とはいえ3カ月半ほどでした。最初の半月で様々な決め事を行い、約1カ月で移行に必要なコンポーネントを完成させたりアカウント統合の部分に力を割いたりしました。残りの2カ月のうち1カ月でQAを行いつつリハーサルの準備を進め、最後の1カ月で最終的な詰めと問題解消を行い、なんとか収めたという形です。
Q. タイトなスケジュールの中で手戻りは発生しなかったのでしょうか。
A. 結合部分がうまくいかなかったケースはあり、手戻りや移行のやり直しも実際に発生しました。ただ大きなトラブルは発生しなかったため、リカバリーにそれほど時間がかかるものではなく、4カ月で終えることができました。
Q. データベースは極力正規化されているのですか。
A. 私たちの基盤ではドメイン駆動設計を採用しているとお話ししましたが、極力正規化するよう設計しています。正規化した上で、Paraviから移行してくるデータをどう当てはめていくかをマッチングさせて、実際に移行していくプロセスを取りました。
Q. もう一度やり直せるとしたら、今と変えたいことや工夫したいことはありますか。
A. 後半戦でお話しした役割分担をしっかりしておきたかったというのがあります。開発リソースを確保した時点で役割を明確に決めておけば、もう少しスムーズに進められたのではないかと感じています。割くべきところにもっと力を割けたのではないかと考えています。
前半のサービス統合についてはあまり変えられるところはなかったという感触です。移行のところをもう少し入念に詰めたかったことや、チームとの連携のパイプ役を一人に集約させればよかったという思いはありますが、前半戦については大きな改善にはならなかったと思います。
アーカイブ動画・発表資料
イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。
▼動画・資料はこちら
※動画の視聴にはFindyへのログインが必要です。