はじめに

みなさまお久しぶりです、前回記事を書いたのが1年前というよこて @n0mimono です。今回はミラティブのプロダクト開発の体制的な話を書いてみようと思います。

ミラティブではMirrativというサービスを作り、運営していますがこれをどういう体制で作っているのかというお話です。開発フローとか技術的な話というより、どういう組織構造で作ってるのか、あるいは開発するものをどう決めているのかというあたりを語ります。（開発フローってどうなってんの？みたいな話は他の誰かが書いてくれるはず！）

先にネタバレするとこの記事はこの本の影響を受けています。

www.amazon.co.jp

本の影響を受けて開発体制をつくったというわけではなく、少しずつ改善していって後から振り返ったら「あれこれ似たようなことやってるな・・」という感じですね。

プロダクト開発と体制

The tribes

ミラティブのプロダクト開発の全体像はこのスライドで説明できます。

いわゆる機能開発チーム（feature team）が3つあるのですが、現状のミラティブではLeSSを採用していません。なのでfeature teamという言い方は厳密には適当ではないのですが細かく説明するのも面倒だしこう呼んでいます（delivery teamと呼んだほうがいいのかも）。実態としては Spotifyモデルのtribeに近い です。

チーム間の移動はそれほど多くない
チーム内にいくつかの小隊（squad）がある（社内ではこういう表現はしていませんが）、これはかなり流動的に組み変わる
チームがなすべきフォーカスは4半期程度（3ヶ月程度）に変わる
チームはクロスファンクショナルでフルスタックであり、チームは独立して課題解決が可能であり、チームにはデリバリーする能力と権限がある
各々のチームにはある程度の方向性とコンテキストがある

ミラティブ（21年10月現在）にはつぎの3つのチームがあります。

ライブプラットフォーム
エモモ
新規プロジェクト

3つ目は社内だとアルファベット3文字のちょっとかっこいいコードネームがついているのですがここでは適当に新規プロジェクトと呼んでおきます。それぞれのチームには次のような側面があります。

まず、ライブプラットフォーム:

主たるミッションは Mirrativのゲーム配信体験を良くすること
メンバーは、エンジニア（iOS/Android/バックエンド）、デザイナー（UI/UX）、PdM
コラボ配信やおすすめ配信はこのチームのアウトプット
KPIだとユーザーグロースに関わるもの（NUU、RR）を見ることが多い
一番想像しやすい？toCプロダクトの開発

次に、エモモ:

主たるミッションは Mirrativの雑談配信体験やアバター体験を良くすること
メンバーは、エンジニア（iOS/Android/ Unity /バックエンド）、デザイナー（UI/UX、 イラストレーター 、 3D）、PdM
UaaLやアバター周辺の開発はこのチームのアウトプット
KPIだと売上に関わるもの（ARPU）を見ることが多い
アバターの制作とイベントの運営が全体のリソースの多くを占める、 スマホゲームの開発に近い 構成

最後に、新規プロジェクト:

主たるミッションは・・・面談で聞いてください
メンバーは、エンジニア（iOS/Android/バックエンド）、デザイナー（UI/UX）、PdM、 bizdev
前述した2チームと違ってこちらはbizdevのリソースが多くを占める toBプロダクトの開発に近い 構成

チーム間の移動が少ないのは、それぞれのチームに強いコンテキストがあるためです。この強いコンテキストは最高のユーザー体験を作るために必須なものです。例えば、どういうアバターの衣装がどういうユーザーに刺さるかは、、これはエモモチームに長く所属しないとわかりません（逆に長くいればわかる）。

バックログとセレモニー

ミラティブではLeSSは採用していないと言いましたが、 LeSSのプラクティスは採用されています 。

バックログはただ一つである。
各チームごとに何らかのデイリーMTG
各チームごとの週次のMTG
開発チケットごとのキックオフとレトロスペクティブ
週に2回、全員参加でバックログを調整するMTG（通称、ぷろゆう）

タイムボックスを切っていないこと以外はだいたいスクラムのプラクティスが利用されています。最初からこうしたというより（バックログは昔から一つでしたが）チームが拡大したり整理する過程において改善されていったという経緯があります。

デリバリーという点では

アプリは毎週リリース（= 機能が完成したら次の週デプロイ）
バックエンドは機能が完成したらデプロイ

Mirrativは他のエンタメサービスやコミュニティサービスと同様に一つ一つの施策の不確実性が高い（=デリバリーしないと結果が読めない）ため、正確に当てにいくよりもどれだけ速く学びを得られるかということを大切にしています。

プロジェクト

体制に属さないもの、言い換えるとプロダクトバックログではないもの、例えば採用とか完全新規の企画とかどうしてるの？

これはケースバイケースですが、ミラティブではプロジェクト（project）という単位をつくって横断的な課題解決を行なう場合があります。

こんな感じ

Slackにチャンネルをつくる
関係しそうな人を招待する
あいさつする
あとは、よしなにやる

さすれば課題は解決されるであろう。

組織

開発チームとは別に組織としてどうなっているのかというとこちらはいわゆる機能別組織です。一番上の部分は事業部制っぽく

toCのプロダクト開発の事業部 ← エンジニアとかはこっち
toBのbizdevの事業部

で中は機能別に

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

エンジニアの中も機能別に

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

のどこかに所属しているという感じです（実際はちょっと違うのですが単純化しています）。

ユーザーファーストに開発する（これは自体は良い！）と後手に回りやすい長期的な概念をこちらで下支えしています。

開発チームごとの技術のサイロ化を防ぐ
キャリアマネジメント（問：インターン生は誰が面倒を見るの？）
そもそもプロダクト開発の枠組みで考えないほうが上手く進みそうなもの（基盤開発とか）

PdMとEMの意見が対立したらどうするか？うーむ、、ミラティブではそういうケースはないですね。。PdMが技術とエンジニアのことを理解して、EMがプロダクトとユーザーのことを理解していればなんとかなるのではないか。わかりあい is 大事。

意思決定

「企画はどうやって決めるのか」

ミラティブではこれはトップダウン的に決まるものもあるしボトムアップ的に決まるものもあります。例えば、コラボ配信はPdMの企画が元で（CPOの企画だった気がする、たぶん）、エモモRUNはエンジニア（よこて）のプロトタイプが元になって作られたという経緯があります。

重要なことは

全てをやろうとしない
今最も重要なことにのみフォーカスする

なににフォーカスするかは会社の意思決定（=company bet）、なにをやるかは各チームが考えること、という考え方をとります。すなわち、具体的になにをつくるかは各開発チームの裁量となります。

今最も重要なこととは、これを言い換えると「今最も未知で学びが必要なもの」です。企画そのものは必ずしも重要ではなく、どれだけ速く学びを得られるかが重要です。そのためには、開発者全員がフォーカスの意図と背景を十分に理解していることが必要になります。

実際に企画のアイデアが出てそれが形になる雰囲気はこんな感じです。

gatherで雑談する
meetで雑談する
Lookerをながめる
エンジニアと雑談する
デザイナーと雑談する
コーヒーを飲む
ペライチの仕様書（mini spec）をつくる
PdM同士で互いにFBしあう
作るエンジニアとデザイナーが集まってわかりあう
チケットを切る
開発する

雑談が大半を占めてしますがアイデアは雑談から生まれるのが自然です、だいたいあっています。

おわりに

開発体制みたいな話をしましたが、未来永劫こうやっていきたいというわけではなくcompany betすべきことに合わせて柔軟に変えていきたいなあと思っています。例えば、ライブプラットフォームチームやエモモチームは実は2019年頃のミラティブのOKRチームの名残です。スタートアップなので組織構造のレベルで変遷しているわけですね。ついでに、この記事だとテックなことをやっているチームに全く言及していないのですがそういうチームもあります（が、筋がぶれるのでやめた、次はここをがっつり書きたい）。