プロダクト開発と体制

組織

まず基本情報から。プロダクト開発に関わる組織そのものは今まで通りです。いわゆる機能別組織です。メンバー一覧見たら80人くらいいました、エンジニアは30人くらい。

技術部 ← エンジニアとか
分析部 ← 分析とか
企画部 ← PdMとか
デザイン部 ← デザイナーとか

エンジニアの組織はエンジニアの成長や技術的な課題解決にコミットしてきます。エンジニアの中も機能別に

アプリのグループ
バックエンドのグループ
インフラ／ストリーミングのグループ

この前までわたしがUnityのグループのマネージャーやってたとか細かい話はありますが今回は端折ります（CTOとマネージャー兼任が解消されました、やったね）。

Company bet

Mirrativは『配信者のためのSNS』、そのコンセプトは「友だちの家でドラクエやってる感じ」、さらに『ライブゲーミング』にパワーをかけていきます。

prtimes.jp

つまり・・？

今後は、ゲーム・ライブ配信・アバターの融合をテーマに、スマホ版メタバースの確立を目指し、配信者や視聴者といったユーザー・開発者・プラットフォームが共生していくエコシステムを構築してまいります。

そういうわけでこれに基づいてチームの編成をしていきます。

Stream-aligned teams

開発とデリバリーを行うチームは次の6つになります。

Platform eXperience
Streamer eXperience
Game development [Emomo]
Game development [with Partners]
Game community & integrations
ToB development

エンジニアとかデザイナーはこの中のどこかにだいたいいます。また、これらに加えて基盤開発のようなチームが別途あったりします。これを書いてる時点で名前が特にないチームがあったので今つけました（明日には変わってるかもしれない、許してください）。

Platform eXperience

主たるミッションは ライブゲーミングのプラットフォームをつくる こと
メンバーは、エンジニア（iOS/Android/バックエンド）、デザイナー（UI/UX）、PdM
ライブゲーミングに関わる周辺の機能や基盤を作ります

Streamer eXperience

主たるミッションは 配信者や視聴者に最高の体験を提供する こと
メンバーは、エンジニア（iOS/Android/Unity/バックエンド）、デザイナー（UI/UX、イラストレーター、3D）、PdM
ゲーム配信サービスとしてのMirrativの様々な機能を開発します。また、エモモ（Mirrativのアバター）のイベントに係る開発や運用も担当します

Game development [Emomo]

主たるミッションは エモモを利用したゲームの開発を行う こと
メンバーは、エンジニア（iOS/Android/Unity/バックエンド）、デザイナー（UI/UX、3D）、PdM
ゲームそのものを作るチームその1
UaaLによるゲーム開発を行います

Game development [with Partners]

主たるミッションは 開発パートナーと協力して新規ライブゲームをつくる こと
ゲームそのものを作るチームその2
先行開発パートナーと協働して、新しいライブゲーミングタイトルを開発します

Game community & integrations

主たるミッションは リリース済みまたは予定のゲームとの連携を行う こと
ゲームをつくるのではなく、ゲームとの連携を行い新しい遊び方を提供するチームになります
ゲームを遊んでもらうという意味だとToC、ゲームタイトルとやりとりするという意味だとToB、と両側のある開発になります

ToB development

主たるミッションは B向けのサービスや基盤の開発 を行うこと
ミラティブのサービスにはToBの側面もあります。リンク先によると月間60タイトルを超えているらしいです。
比較的純粋なToBの開発になります

これまでと同様に各チームが強い裁量をもってデリバリーしていくスタイルです。

チーム依存関係の可視化

チームを変えたのは今年に入ってからですが思ったこととして

チーム編成してみたけど本当にこれでいいのかわからん問題
誰がどこでなにやってるかわかりにくい問題

両方ともチーム編成あるあるです。メンバー総数が20人くらいなら悩みませんが、今のプロダクト開発に関わるメンバーを数えると100人近くいるので工夫が必要になります。

で、年末に本を読んでいてこんなアイデアを見つけました。『チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計』より

Spotifyではスクワッドとトライブの相互依存関係を検出して追跡するのに、単純なスプレッドシートを使っている。スプレッドシートで明らかにするのは、同じトライブのスクワッド間に依存関係があるか（この場合は許容範囲だ）、他のトライブとの間に依存関係があるか（この場合はチーム設計か仕事の割り当てがおかしい可能性を示唆している）だ。また、その依存関係が、それに依存しているチームのフローにどれだけすぐ影響を与えそうなのかも追跡している。

これは良い。

というか昨年に似たようなことをやっていました。今月もやってみます。

実際のものと違うのですが雰囲気はこんな感じです。これを全メンバーでやります。なにをやっているかというと

プロダクト開発に関わるメンバーの一覧をつくる
全メンバーに対して、名目上のチームを1つだけ割り当てる
- ここでいうチームはstream-aligned teamのこと
1ヶ月分の寄与率を入れる（これが実質的なチームになる）
- 0.1刻みとか、結構適当

管理会計上、コスト計算をするときに似たようなことをすることがあるかもしれませんが、ここで考えたいのは依存関係の追跡をしてチーム編成のPDCAを回すことです。そのため

組織図は無視して関係するメンバーを全員並べる
「その他」は基盤開発とか、stream-aligned teamに分類されないものへの貢献
採用への寄与は無視する。採用貢献を考慮すると「全員が0.2ずつ採用に貢献」となってしまって本来の意図と違うものができてしまう。違うそうじゃない

極端にあっちこっちで仕事をしているメンバーがいたら

チームの編成自体を再検討すべき
メンバーのアサインを再検討すべき

というシグナルが得られます。上のシートの例だとEveさんがこれに該当します。

寄与率をどうやって計算しているのかというと手動です。5人くらいに聞いて適当に埋めてもらっています。Slack上のコミュニケーションから自動で収集できそうな予感もしますがそれはそのうち考えます（スタートアップだと組織の形が頻繁にごっそり変わったりするので、あまりモデルを固定化せずにスプレッドシートの運用くらいで抑えるのが良い気もしています）。

こんな感じで月ごととかQごとに振り返ります。また、さらにこれを可視化します。具体的にはシートをいい感じに参照して適当にWebアプリ（GASとか）つくってマップを作るだけです。