現実世界と仮想世界を融合する「XR」技術の発展により、メタバースに代表されるような、これまでにはなかった複雑で新しい体験を提供するアプリやサービスが急増している。

そのような高度な機能を持ったプロダクトの開発においては、従来より多様な技術や専門知識を持った開発者が必要とされる。そしてまた、彼らが互いにうまく連携できるチームを作ることの重要度も非常に高い。

「なりたい自分で、生きていく。」というビジョンのもと、誰でもスマートフォン1台で好きなアバターに変身できるスマホ向けメタバース「REALITY」や、法人向けのメタバース構築ソリューション「XR cloud」を展開するREALITY株式会社。

同社において、2022年10月に全世界のダウンロード数が1,000万を突破した「REALITY」の開発を担うプラットフォーム事業部では、事業成長にあわせて開発組織の形を大きく進化させてきたという。

「メタバース」「アバター」「ライブ配信」「アプリ内ゲーム」といった多くの機能を持つ同アプリでは、それを支える開発者の技術スタックも様々だ。そのため、以前はプロダクトのデリバリーにおける職種間のクリティカルパスが多く、開発スピードが上がらない、職種間の関係性の構築が弱い、といった課題があったのだという。

そこで現在は、機能型×プロジェクト型のマトリクス型組織をベースに、デリバリーのプロセスをルール化するリリーストレインの導入や、職種間のコミュニケーションを増やすチーム編成などによって、さまざまな技術を持つメンバー同士の分業と連携のバランスを最適化しているという。

今回は同事業部のシニアマネージャーを務める清 貴幸さんに、「REALITY」の開発組織の変遷と乗り越えてきた課題について、詳しくお話を伺った。

ロジックだけでなく、個々の感性を活かしてメタバース事業を展開

弊社はグリー株式会社の子会社で、グループ内ではほぼ唯一メタバース領域で事業を展開している会社です。toC向けの「REALITY」というライブ配信アプリと、toB向けのメタバースソリューションという大きく二つの事業を手掛けています。

その中で自分は、「REALITY」のアプリ開発を行っているプラットフォーム事業部の中にある、エンジニアリンググループのシニアマネージャーをしています。

前職はインターネット広告系の会社だったのですが、もともとVRコンテンツがすごく好きだったこともあり、VR事業の立ち上げに関わらせてもらって。

その事業が続けられなくなってしまったときに、グリーにいた友人からバーチャルYouTuber系のアプリを作るという話を聞き、2018年6月にREALITY社の前身となる株式会社Wright Flyer Live Entertainmentに入社しました。

現在、弊社の中でtoC向けの事業をしているのは、REALITYのモバイルアプリの開発を行うプラットフォーム事業部と、REALITYの中で遊べるゲームの開発を担うゲーム事業部、またBizdev/Marketing部です。そしてtoB向けのソリューションを担うのがXR cloud事業部という形で、どこへ向けたビジネスをしているかで事業部が分かれています。

▼REALITY社の組織図（同社の採用資料より）

会社のカルチャーとしては、やはりメタバースのような新しいテクノロジーが好きな人が多いです。また、グリーというゲーム会社から生まれたこともあり、エンタメのコンテンツを作ることに志向性が向いた人も多いかなと思います。

自分が前職でインターネット広告のビジネスをやっていたこともあって特に感じるのですが、やはりエンタメを作る場合と、SaaSのようなビジネス的なものを作る場合は考え方が全然違うんですよね。重要視している指標も異なるので、入ったばかりの頃はそのギャップを感じました。

エンタメの場合、「どうしたらユーザーがハッピーになるか」を考える上では、ロジックだけではなくて感性に頼る瞬間も多くあります。クリエイターも、言われたものを作るというよりは自分が好きなものを作りたい、という思いが強いですね。

このカルチャーはさまざまな活動に反映されていて、例えば今自分が使っているオンラインミーティングにアバターで参加できるツールも、業務というより余暇の中でみんなが作った感じです。

▼清さんが実際に使われているアバター

また、REALITYのアプリ開発の中でも、エンジニアがプロダクトマネージャーの意思決定を飛ばして好きな機能を追加できる「NEXT REALITY」という枠を設けています。

やはりエンジニアも、「こういう機能を足したい」というアイディアを持っている人が多いので、こうした余白を設けた形です。最初は自分がコメントの音声読み上げ機能を作ったのですが、今はもうすっかり、普通に使える機能として定着していますね。

組織の拡大にあわせ、一つだった開発組織をマトリクス型に分化

自分が所属しているプラットフォーム事業部は、大きく四つのグループに分かれています。プロダクトマネージャーが主に所属するプロダクトグループ、エンジニアが所属するエンジニアリンググループ、3Dモデルやアバターのクリエイティブを作るアートグループ、そして分析をするアナリシスチームです。

その中で自分が見ているエンジニアリンググループは、現在は正社員のソフトウェアエンジニアが35名ほど、業務委託等の方もあわせると60名超の組織になっています。

グループの中では、さらにサーバーサイドとiOS、Android、Unityというチームに分かれていて、いわゆる機能・職能ベースの組織です。

ただ実務としては、機能型の組織で完結するわけではなく、プロダクトマネージャーやエンジニア、アート、デザイナーが混ざった形でプロジェクト単位のチームを作っているので、全体ではいわゆるマトリクス型の組織になります。

▼機能型組織×プロジェクト単位のチームの組織イメージ（編集部作成、一部情報を簡略化）

とはいえ2019年頃までは、そもそもあまり人もいなかったですし、コロナ禍前でもあったので、みんなで集まって顔を合わせて一つのデリバリーチームとして動いていました。並行して走っている開発の種類も少なかったので、各自が全体を把握できていたんですね。

ですが人が増えてきて、まずはピープルマネジメントをもっとしっかりしなければいけないよねという話が出てきて。そこで2020年に、もともと1個だったソフトウェアエンジニアのグループを、先ほど紹介した機能型のチームに分けたんです。

この頃は、機能型組織のマネージャーが「全体の開発進捗状況を把握しながら、設計の相談やアサイン・スケジューリングをする」という役割を持っており、開発の進行上は特に問題がありませんでした。

ですが、そこからさらに人が増えていった結果、2021年にはマネージャーがドメイン全体の設計や各メンバーの進捗全体を管理することも難しくなってきて。また、並行するプロジェクトの進捗状況によって起こるアサインのやり直しや、入れ替えの議論にも時間がかかるようになりました。

そこで他社の事例を参考にさせてもらいつつ、いわゆるSpotifyモデルのような形の、マトリクス型の組織に2022年の頭くらいから移行しました。

このように組織を変化させたことで、タスクのアサインをまとまったチーム（ユニット）単位で実施できるようになりました。また、同時にアサインの権限を機能型チームのマネージャーからプロジェクト型チームのPMに移行したので、アサインのすり合わせコストが大きく減りましたね。

結果として、機能型組織のマネージャーが開発のボトルネックになりづらくなったのと、PMが考えている優先順位をそのままアサインに反映できるようになったのは良い変化だったと思います。

ただ、マトリクス型組織への移行にあたり、ネガティブな影響が出たところもありました。

1点目は急激に組織構造を変化させてしまったため、新しいやり方に馴染むまでは開発のスループットが落ちてしまったこと。今考えると、組織構造を変えるにあたって「パイロットチームを作って小さく試す」を先に実施した上で、成功パターンを見つけてから横展開してもよかったかなと思っています。

もう1点は、PMにアサイン権限が移行したことで、PM自身が各エンジニアの性質を理解しなければならない、といった、ある種のピープルマネジメントの負荷が発生してしまったことです。

この点についてはPMは考えなくて良いという前提で権限を移譲したのですが、やはりゼロにはできない部分もあり、プロジェクト型組織のPMには難易度が高いという話があがりました。このあたりは今でもやり方を模索している最中で、日々議論して改善をしようと頑張っています。

リリーストレインの運用により、デリバリーのスピードを担保する

他にも、弊社の組織の特徴として、テクノロジースタックの多様性が挙げられます。REALITY自体が、3Dのアバターを動かしり、ゲームを開発したりと普通のライブ配信サービス開発にはない要素があるので、開発側に求められる専門性が広いんです。

▼スマートフォン向けメタバース「REALITY」

アプリ開発やWeb開発のソフトウェアエンジニアリングのスキルに加えて、3Dモデリングやアバターのデザインスキル、ゲーム開発のためのUnityのスキル、といったものが必要になります。

コンテンツの作り方としても、いわゆるモバイルゲームとは全然違っていて、例えばアプリをデリバリーするために必要な手順が多いんです。まずアートアセットがあって、それを基にして3DのコンテンツをUnityで作り、それをライブラリ化して、ネイティブアプリ側で取り込んで機能を作って、QAを経てデリバリーしていく…といった形で、クリティカルパスも多くなります。

このステップバイステップの中で、アート職、Unityエンジニア、iOSエンジニアとAndroidエンジニア、そしてQAといった形で、細かく分業がされています。

ここも以前はしっかりと分かれてはおらず、コミュニケーションでどうにかなっていました。それがチームの拡大に伴って徐々にごちゃつくようになり、デリバリーのスピードも遅くなること、またリリースまでの調整コストが非常に高くなることが課題でした。

その解決のために、デリバリーのプロセスをある程度ルール化する「リリーストレイン」を作っています。これが、週に1回のリリースを前提にして、「この日までにこれが上がらなかった次に飛ばす」ということをルール化しているものです。

例外がないわけではないですが、リリーストレインを導入することによって、個別のチーム間で毎回調整しなくて済むように仕組み化しているということですね。

現在のリリーストレインにはアプリのリリースと、アセット（3Dモデルなど）のリリースという二つの線があり、それぞれ曜日単位で締め切りを決めて運用しています。

▼リリーストレインのイメージ（編集部作成、一部情報を簡略化）

また、リリーストレインをうまく活用する小さい工夫として、アプリやライブラリのリリースバージョンをWeek numberベースで管理しています。

この運用によって、アプリバージョンと現実の週が紐づくのでどのバージョンに何を入れるかの議論がしやすかったり、どのバージョンに何が入っていてそれがいつリリースされたのかが特定しやすくなります。

▼実際のアプリのバージョン

ただ、分業のための工夫をしていると言っても、やはりひとつのサービスを作っていくにあたり職種を横断した横軸のつながりも必要です。その課題に対するソリューションが、先ほどお話ししたプロジェクト単位のチーム編成への移行でもあります。

都度都度チームを作るという以前のやり方と比べると、コミュニケーションがとりやすくなり、効率も良くなりましたね。

また、プロジェクトチームを作るときに、「あなたはコミュニケーションの領域」「あなたはアバターをより魅力的にすることを担う」といった形で、各々が担当するドメインを決めたんです。その結果として、各メンバーにドメイン知識がしっかりと積まれるようになったのがとても良かったと感じています。

「逆コンウェイの法則」的に、事業部を跨いだ組織を再構築していく

弊社に関して、「アバターのコンテンツを作っているからUnityエンジニアが多いんじゃないか」「よくわからないけれどメタバース的なことをやっている会社だよね」という印象を持たれて、アプリエンジニアからは少し敬遠されてしまうこともあります。

ただ、実態としてはネイティブアプリの実装にものすごくこだわっていますし、こうした印象は変えていきたいなと。そのため、iOSDCやDroidKaigiにスポンサードさせていただくなど、エンジニアリングコミュニティにアピールできる場所にはがんばって出ていくようにしています。

とはいえ、どうしても根がゲーム会社なので、いわゆるWeb系の会社が普通にやっていることが全然できていない部分もあって。特に自分が入った頃は、その課題は大きかったです。

そこから組織のケイパビリティだけではなく、実務的な運用のプロセスや、文化面も含めて足りていなかった部分を習得していくこと、そしてその領域でキャリアを持っている人を採用することに、この3年はすごく注力してきました。結果的に、組織として大きく変化できたのではないかと思います。

今後は、プロダクト開発の形もより進化していくと思っています。これまでは、プラットフォーム事業部が単独でアプリを作っていましたが、事業規模の拡大に伴って少しずつ他の事業部とも連携しながらプロダクトを作る構造に変わってきているんですね。

それによって、異なる文化を持った人同士が作ったものをうまくマージしなければならない、といった課題も出てきています。この流れは不可避のものと捉えているので、今後は複数事業部でひとつの大きなプロダクトを開発するための組織を作ることが必要になってきます。

それを実現する上では、適切なドメインをきちんと分けていくことや、小さい単位で完結してリリースできる組織を作ること、ソフトウェアとしてのモジュールの分割が重要ですね。

いわば、逆コンウェイの法則（※）のような形で、コンテキストに沿って正しく組織を作っていくことが、これからの一番のチャレンジになると思っています。（了）

※メルヴィン・コンウェイが提唱した概念で、組織の構造は、その組織が開発するシステムの設計（アーキテクチャ）に似るという法則のこと