文化、制度、ビジネスとの関係性まで…U-NEXTの開発組織を紹介します
モバイルアプリやWeb、各種ゲームコンソール、TV、セットトップボックスなど…多種多様なプラットフォームに展開するU-NEXT。
これらはすべて、社内にある開発組織で開発を行っています。対応領域・デバイスの幅もさることながら、AndroidアプリではGoogleベストアプリ2022へ選出、iOSでも「Apple今日のアプリ」へ幾度もピックアップされたり、App Storeでは4.6、Google Play4.4（※いずれも2024年7月現在）のスコアを集めるなど、さまざまな形で評価もいただいてきました。
本記事では、その中枢を担う100名超の開発組織の思想や文化、特徴までをCTOのLi Rutong（リー・ルートン）、エンジニアと協働する機会の多いプロダクトオーナーの鏡 優、中島 健へのインタビューを通してご紹介します。
全員が「利用者の合理性」を自然と考える組織
——はじめに、開発組織の全体像について教えてください。
Rutong：現在、組織は100名を越える規模で、専門性ごとに小さなチームを組成しています。iOS、Android、サーバサイド、インフラ……と各領域ごとに複数名所属しており、それらを統合して“開発組織”と呼んでいます。
——Rutongさんは約10年前に参画し組織の立ち上げに尽力されましたが、その道のりで最も重視しつづけてきたことは何でしょうか？
Rutong：当初から一貫し続けているのは、「利用者の合理性」を第一に考える文化だと思います。
開発上の都合でも、目先の売上でもなく、利用者にとって合理的な選択を自然とできるように、あらゆる要素を組み立てています。“そんなの当たり前では？”と思われるかもしれませんが、首尾一貫させるのは簡単ではないと考えています。
やりきるには、文化から意思決定、組織構造に至るまであらゆるものを最適化しなければいけません。そこに尽力し続けてきたのが、今のチームです。
——方々手を尽くされたとの話ですが、特に鍵になっていることはありますか？
Rutong：大きな要素として真っ先に思い当たるのは、「社内受発注NG」を徹底してきたことですね。ここで言う社内受発注は、「ビジネスサイドからの依頼を、エンジニアは言われた通り無心でこなす」ような上下関係のあるコミュニケーションを指します。
もちろん、「依頼を受けて作業する」こと自体は否定しませんが、「言われたことを無心でやる」のではなく「依頼内容を実現すると何が良くなる、誰が喜ぶ」のかをちゃんと把握して、達成するための最善手段を実現する、のがエンジニアの仕事だと思っています。把握するために必要な情報が足りなければ質問や調査をしますし、目的に対してより良い解決策があれば代案を出すこともあります。
中島：これはエンジニアに限らず、あらゆる職種で徹底されている感覚がありますね。言い換えるなら、「誰かの命令に盲目的に従う」というよりは、「その意思決定は合理的か」を考えている。「なぜやるべきなのか（Why）」「何をするのか（What）」「どうやるか（How）」様々な立場の人間の視点が反映されるのを歓迎しています。
どんなプロジェクトでも、機能開発でも、当初の目的をしっかりすりあわせた上で、「どうやるか？」の議論をする。単純受発注のような「これやっておいて、以上」なコミュニケーションではなく、「目的に対してどう対応するのがいいのか」「その方法は利用者目線で合理的か」と考えるのが自然になっているんです。
変化の波に最適化した、全員の視点を持ち寄る体制
——「社内受発注NG」というのはなぜ生まれたのでしょうか？
中島：歴史を遡ると、元々U-NEXTが外注で開発していたのが背景にあります。もう10年近く前ですが、当時は文字通り「受発注」で、全ての要件に都度工数や費用を見積り、承認を得て作業が進んでいました。
しかしITの世界を見渡すと、圧倒的に優れたソフトウェアサービスを運営している事業者で外注をしているところはない。競争環境で生き抜くために覚悟を決めて数年かけて内製化したのですが、その先に待っていたのは「全て入れ替えざるを得ないほどのシステムの負債」との戦いです。本当に大変な思いをして、全面的にリニューアルをすることになりました。
なぜ、そのような事態に陥ってしまったのか。その根本的な原因こそが「受発注の構造」でした。当時のシステムは、要件として“その時点のニーズ”に最適化されていて、メンテナンス性や拡張可能性など“一歩先”を考えていなかった。その積み重ねで大きな負債になってしまっていました。
これは受発注という、いわゆる上下関係ができてしまう構造では必然です。そうした気づきと痛みのもと、「（社内であっても）受発注的なコミュニケーションはやめよう」となったんです。
——上下ではなく、全員が対等に議論し各々の視点を持ち寄ることで、「数歩先」を見据えられるようにしたのですね。
鏡：結果的に、U-NEXTの事業特性を考えても不可欠なものになりました。U-NEXTが競合するのはグローバルに事業展開する私たちよりもはるかに大きな資本をもった企業ばかり。この中で生き残るには変化し続けなければいけないですし、より素早く変化しなければいけません。
すると常に「次なる変化」に柔軟に対応できるシステムやプロダクトが必要で、想像もできないような形に変わっている覚悟も必要です。この数年だけでも「ライブコンサート配信」「ライブスポーツ配信」「Paravi統合」 のようにかつて誰も予想していなかった機能・コンテンツ追加が当然のように発生してきました。激しい変化に耐えうるプロダクトを運用できるのが、このありかたなのだと思います。
エンジニアたちを見ていると、そういった「難題を解くこと」をある意味楽しんでいるような印象すら受けますね。「この機会をどう活かそうか」「次に似たようなことが起こっても柔軟に対応できる土台をつくろう」という話をしているのをよく目にします。
たとえばライブコンサート配信をはじめた時、Rutongは「もし、別のリアルタイム配信コンテンツが入ってきても、次はかなりの低コストで対応できるようにした」と言ってました。実際できあがったシステムは洗練されていて、言葉の通りでした。難題を乗り越えるたびに強くなっている気がしますね。
完璧なフラットな仕組みが導く、主体的な姿勢
——ここまで鍵になったものとして「社内受発注NG」の話を出していただきましたが、それ以外にも特徴的なものはあるのでしょうか？
Rutong：「社内受発注NG」が文化的な話だとすると、構造的な話としては「組織を完全なフラットにした」のが大きいと思います。U-NEXTの開発組織は、中間管理職がいなくて階層構造がない、完全にフラットな組織構造を採用しています。私も肩書きはCTOですが、業務時間の大半はエンジニアとして製品開発に費やしています。
このフラットというのは、マネジメントをする人や上司がいない…という意味だけではありません。全員がミニCTOのように、職務に対して主体的に向き合うことが求められます。
たとえば、U-NEXTの開発組織では仕事を誰かから強制的に「アサインされる」ということはありません。もちろん「好きな仕事だけできる」と言う意味ではなく、プロダクトオーナーが定義する「誰かが必ず実装しなければならない開発タスク」があります。その中で「誰が何をやるか」を、「各々が自分の意思で選択する」という意味です。
深めていきたい技術に関わる仕事を積極的に選ぶ人もいれば、緊急度が高いものを選ぶ人もいる。あえて“他の人が選びたがらないもの”を積極的に選ぶ人もいます。
——フラットな組織…というのは近年良く目にするワードでもあります。構造上フラットにするだけで、そこまで皆の行動が変わるものなのでしょうか？
Rutong：組織構造をフラットにする以外にも色々工夫しています。
たとえば、「評価手法」もこの組織構造を機能させるために最適化しているもののひとつ。U-NEXTの開発組織では、上長が部下を主観的に評価するのではなく、全員が全員を評価する、いわゆる「360度評価」を導入しています。360度評価自体は珍しいものではありませんが、自社に合わせてかなりアレンジをしました。
具体的には、投票システムになっています。社内向けにソースコードを公開しているウェブサービスで、メンバーは誰かを評価するための権利を組織の人数分だけ「票」として持っています。たとえば、エンジニア組織が100人であれば、一人100票投票できる。
誰にどれだけの票を入れるかは、完全に自由。100票を100人に対して1票ずつ入れることもできれば、1人に対して多めに10票入れることも可能。多くの票を集めるほど、そのエンジニアの評価が高まる仕組みです。
この制度のポイントは「評価をする権利」が分散されていることです。特定の人物がこの権利を持っていたり、手持ちの票数に差がある場合、どうしても「どうすればその人物から高評価を得られるか？」に気を取られてしまいますよね。結果、利用者ではなく社内を向いて仕事をしてしまう。そうしたバイアスを省くことが目的です。
——評価までフラットとなると、みんなどのように他の人のパフォーマンスを見るのでしょうか？他の人の情報を参照する機会も少ないのではと感じました。
Rutong：情報の共有を当たり前にしています。小さい集団で意思決定が完結することのデメリットとして、属人性が高まりやすかったり、車輪の再発明のような無駄な仕事があちこちで起きかねないという側面があります。それを避ける意味でも、情報の透明性にはとりわけ気を遣っています。
大前提として、個々のエンジニアの仕事のログは社内で共有されています。誰がどんな仕事をどの程度担当しているのか、は常に調べればわかる状態です。
加えて、仕様書に代表される文書に関しては「ここに置いたので見たい人は自由に見て」というような姿勢で共有するのが基本的な考え方です。管理職がいないので報告のためだけの書類は不要ですから、まとめるべき情報は「誰かの役に立つ情報」に絞られます。そして、全員に評価されるという評価システムだから、重要な情報をわかりやすい形で共有することは、当人の評価を高めることにもつながります。
重要な情報や優れた知見が個人の頭の中やPCのローカル環境に閉じ込められている状態はチームにとってもったいない。ただ、それを「出して」といって出してもらうのも「見てね」と言って届けるのも負荷が高いので、可能な限りみんなが自発的に「出す」「見る」という行動をした方が得な環境整備を心がけているんです。非協力ゲームになりがちな仕事関係を協力ゲームに留めるための仕掛け、とも言えるかもしれません。
——同僚に対して積極的に協力した方が得な仕組みを作っているのですね。
Rutong：はい。他にも合理的な働き方もできるように制度を整えています。最たる例が勤務方法の自由度。自分の仕事は自分で管理する、という前提なので、働き方も自分で選択できるような状態にしています。
働く場所はリモートワークが定着していて、出社が必要になる特別な場面を除いて、自身が最も快適に仕事できる環境を選んで仕事ができます。居住地を都心から地方都市に移したり、外国出身の人が帰省の際に移動時間+αだけ有休をとり、母国からフルタイムで一定期間働くようなことも制度上可能です。逆に毎日オフィスに出社して働くのも自由です。
時間に関しても、コアタイムなしのフルフレックス。たとえば、朝5時から14時までを就業時間とすることもできれば、週の4日間多めに働いて金曜日を非稼働日にする、ようなことも制度上はできます。
開発環境もかなり自由に選択できます。モニターやPCをはじめとする機材やセミナー補助も完備。開発効率を高めるツール・サービスの利用も積極的に認めていますし、新しい開発言語やフレームワーク、アーキテクチャの導入に対しても賛同者が3人いれば本番運用も含めて導入できます。形式的な承認プロセスもありません。
フラットさを後押しする、ルールや仕組み
——フラットゆえの苦労はないのでしょうか？特に一緒に働いている人からすると「承認」や「確認」先が分からなくなるのではないかと思いました。
中島：一緒に働いている身としては、正直ほぼ気にすることがないですね。実際なにかのプロジェクトを動かすときには、専門領域ごとのチームに対して相談をし、出てきてくれた人と仕事をしているだけ。体感として「フラットゆえの苦労」を感じる機会がないんです。
そもそもプロダクト開発の場面で個別の実装方針や手法に対して「承認を得る」必要がない会社なんですよね。その場の関係者で話し合って決めたことがすべてなので。だから「承認」や「確認」先が分からなくなるという課題自体を感じないですね。
鏡：たしかに。いわゆる不安要素は本当にないですね。たとえば「品質に関して誰が責任持ってくれるの？」みたいな不安も、本当に一度もありません。たとえ何らか問題が出ても、みんなが自分事として解決まで動いてくれています。
中島：むしろ別チームの関係ない人でも「ヘルプ必要ですか？」と出てきてくれますし、障害が起きた際には、自然と総出で原因究明に尽くします。
これは、U-NEXT全社的に「誰の責任なんだ」という人の責任追及をしない文化があることも大きいですね。どんなに時間をかけて準備して細心の注意を払っても問題は起こる時は起こりますし、社内の誰かを糾弾してやり込めたところで、全くもって問題の解決につながりませんから。
そこに時間を割くならより早く問題を解決したり、意味のある再発防止策を練ったり、よりよいサービスに進化させることに注力した方がいい。
——Rutongさんは口を出すことはないのでしょうか？
鏡：彼もいちエンジニアなので担当している仕事には自分の意見を言っています。
担当外の仕事については「誰が考えた案でもいい案なんだったらそれでいいよ」というのがRutongの基本スタンスですね。なので自分の意見を押し通すことに関心はなさそうです。ただいつでも全体像を把握していて、「致命的な問題が生じる可能性があるが誰も気付いていなさそう」みたいな時には出てきてくれます。
障害の時も、だいたい最初に出てきて手を動かしてる印象がありますね。真っ先にRutongが現場に行き、必要なスキルや経験を持つメンバーにサポートを請うような感じです。
徐々に組織に慣れていく感覚
——組織文化から、構造、関係性に至るまで「フラット」を突き抜けているからこそ、冒頭話された「利用者の合理性」を貫けているのですね。
Rutong：そうですね。ただ、新しく入社される方にとっては慣れるのが難しい環境なことも確かです。
入社直後からその人本来100％のパフォーマンスを出すことはまず難しい。どんなにすごい経験を持っている人でも、U-NEXTの職場文化はすごく変わってますから、全員例外なく未体験の領域に足を踏み入れることになります。だから半年から1年くらいは慣れるための期間でもあります。
——組織に染まるには時間がかかるんですね。
中島：ただ、全員が全員無理に「一つの価値観に染まる」必要もないんですよ。U-NEXTの仕事でも0→1といった何かを生み出すシーンもあれば、1→10、10→100と拡張していくような時期のものもある。
利用者が楽しい気持ちになるためのプラスアルファの要素で早く世に出すことの方が大事な機能もあれば、決済まわりのように万に一つも間違いが起こってはいけないシステムもある。その中で必要となる素養は変わりますから。
「多少の不具合があっても問題が起こったらすぐに直せばいいや」でも、「不具合が起こって休みの日に仕事したくないから十分にテストしてデプロイしよう」でも、どちらも正解になりうるんですよね。
「主体性」「合理性」「複雑性」の掛け合わせ
——最後に、これからU-NEXTの開発組織に求める人を教えてください。具体的な要件は募集要項にあると思うので、マインドや姿勢という観点を伺えますと幸いです。
鏡：「与えられたことだけをこなすのが得意」な人は少し難しいかも知れません。というのもU-NEXTは個々の自立や学習を前提に組織が回っているので、待っているだけでは誰も教えてくれない。
自分から情報を集めたり、知ってそうな人に聞きにいかない限り、慣れるきっかけも見いだせないと思いますから。慣れるべき範囲は人それぞれでも、そこへ向かう“主体性”はやはり必要になりますね。
中島：私は合理性を挙げたいですね。我々のプロダクト開発は、Why/What/Howや、As IsとTo Beを比較的ていねいに分けて議論する風土があると思います。これは合理性を大事にするという前提を共有できているから成立するんじゃないかと思うんです。
たとえば新機能のMVPを設計している時に、「あったらいいな」機能が混じると、もはやMVPではないですよね。長く働いてる人が言ってるから、声の大きい人が熱心に説いているから、に引きづられて仕様が肥大化してしまうのは避けたい。誰からともなく「MVPはMVPとして切り分けようよ」と意識が統一できるのが今の組織だなと感じています。
——いずれも言葉を見る限りは難しくないものの、求められる内容は決して一筋縄ではいかないものですね。
中島：あと最後にひとつだけ、「複雑性を楽しめる人」は相性が良いと思います。入社前後のギャップとして言われるのが「U-NEXTってこんなに複雑なサービスだったんですね」ということです。U-NEXTのシステムは、外側から見える景色の想像を遥かに超える、とんでもなく巨大で複雑なものなんです。
鏡：アカウントの種類×課金方式の種類×コンテンツの種類の掛け合わせがあって複雑さを増していますね。
アカウントで言えば、U-NEXTはウェブサイトからの登録以外にも映画館経由で加入する人もいれば、Apple/Google/Amazonのアプリストア経由で加入する人もいる。直近ではParaviと統合したのでParavi経由の人もいます。そういったアカウント種別がサービスの歴史上で多々生まれたので、同じ「会員」でも何種類もいるんです。
その上に「SVOD（見放題）」「TVOD（都度課金）」という2つの課金方式があり、さらにコンテンツも、好きなタイミングで視聴する「映画／ドラマ／アニメ」、リアルタイムで視聴する「音楽ライブ／スポーツ」、映像ではない「書籍／マンガ…….」と扱いの異なるものが存在する。それらを掛け合わせるとプロダクトは複雑になるしかないという事情があるんです。
中島：とはいえ、「利用者体験まで複雑になってしまう」のは避けたい。だから内部的な複雑さを表面上には感じさせず、いかにスマートに仕上げるかに常に挑戦しているんです。
そんな環境を楽しめるのは大きな素養になると思いますね。