みなさま、おはようございます。よこて @n0mimono です。令和になってなんと4年目に入りました。
今回はミラティブのプロダクト開発チームを更新したよ、という話をします。ついでに周辺の取り組みも紹介してみます。
前回記事はこちら
ちなみに今日はこの本の影響を受けています。
プロダクト開発と体制
組織
まず基本情報から。プロダクト開発に関わる組織そのものは今まで通りです。いわゆる機能別組織です。メンバー一覧見たら80人くらいいました、エンジニアは30人くらい。
- 技術部 ← エンジニアとか
- 分析部 ← 分析とか
- 企画部 ← PdMとか
- デザイン部 ← デザイナーとか
エンジニアの組織はエンジニアの成長や技術的な課題解決にコミットしてきます。エンジニアの中も機能別に
- アプリのグループ
- バックエンドのグループ
- インフラ/ストリーミングのグループ
この前までわたしがUnityのグループのマネージャーやってたとか細かい話はありますが今回は端折ります(CTOとマネージャー兼任が解消されました、やったね)。
Company bet
Mirrativは『配信者のためのSNS』、そのコンセプトは「友だちの家でドラクエやってる感じ」、さらに『ライブゲーミング』にパワーをかけていきます。
つまり・・?
今後は、ゲーム・ライブ配信・アバターの融合をテーマに、スマホ版メタバースの確立を目指し、配信者や視聴者といったユーザー・開発者・プラットフォームが共生していくエコシステムを構築してまいります。
そういうわけでこれに基づいてチームの編成をしていきます。
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とか)つくってマップを作るだけです。
キャプチャはデータ適当版です。これで誰が何をどれくらいやっているかをざっくり把握しやすくなります。また、今月入社したメンバーのオンボーディングツールにも使えたりもします。
おわりに
とりいそぎテックブログに今のチーム状況を書いてみましたが、そのうち他の資料の方も更新していく予定です。
We are hiring!
ミラティブではライブゲーミングのプラットフォームを作っていきたいエンジニアやプロダクトマネージャーを募集中です!