「ミラティブ × LIPS × クラシル】 開発トップが語る、ヒットアプリのグロース戦略」に参加してきた

bethesun.connpass.com

感想

• ミラティブ
  • 会社
    • 定量と定性をバランス取れてる印象を受けた。
    • 副業エンジニアが多く（20数名で、正社員の2倍ぐらい）、そんなに上手くまわるものなのか疑問に思った。
  • 発表内容
    • 配信サービスという性質もあり、実際の行動を追いやすいところがあるのは羨ましい。
    • チームの分け方にも定性定量の観点があって面白い
      • チームの目標を定性より、定量よりにそれぞれ設定して、全体のリソースのバランスをとっている。
      • 人数の規模感が近しいので非常に参考になった。
    • 定性的には、ユーザとのコミュニケーションを相互にとっていて、ユーザと向き合いながらグロースしている印象を受けた。
      • 運営が開発状況を配信
      • ユーザからのフィードバックを週次で共有して、解決策や現状の共有を行うのは取り入れたい。
    • 定量的には、ちゃんと段階的にリリースしたりABテストを行って、しっかり仮説検証を行っている印象を受けた。
      • slackでの速報や、リアルタイムのウォッチングは何かしらの形で取り入れたい。
• AppBrew
  • 会社
    • かなりエンジニア主体の会社の印象を受けた。
    • 機械学習周りは特に強そう。
    • 文化的にも、仮説検証を前提として共通認識がある印象を受けた。
  • 発表内容
    • 方法論は大体ブログに記載されてるものって感じだった。
      • tech.appbrew.io
    • 方法論より、組織として実践していくのが難しく重要というのはかなり共感した。
      • やはり採用と評価から組織文化を変えないと厳しいなと思った。
    • フルスタックエンジニアではなく、 マルチスタックエンジニアという捉え方はしっくり来た。
• dely
  • 会社
    • あまり会社については触れなかったので、特になし。
  • 発表内容
    • 新規獲得とチャーンが釣り合ったら成長が止まる構造を理解してない人が案外多かった。
      • DAU = 新規獲得 + 継続利用ユーザ + 復帰ユーザ - 離脱ユーザ

メモ

注意事項

• なるべく主観は取り除いてますが、少しは私の解釈が入ってます
• 聞き取れないorメモに記載できなかった箇所もあります
• 私があまり興味ない or 自明なものは省略してます

①「Mirrativのプロダクト開発について」

登壇者: 夏 澄彦（株式会社ミラティブ CTO）

• 2015年に株式会社ディー・エヌ・エーに新卒入社、ミラティブに最初期から加わる。
• 2015年度新卒MVP（1名）受賞。
• エンジニアチーム全体のマネジメントを担当し、サーバ・クライアント両面の開発にも従事。

沿革

• 2015年8月 DeNA社にてMirrativリリース
• 2018年2月 株式会社エモモ（株式会社ミラティブの前身）登記
• 2018年2月 DeNAからのMBOと10億円超の資金調達を発表
• 2018年4月 オフィス移転
• 2018年5月 株式会社ミラティブに社名変更
• 2018年8月 バーチャルアバター「エモモ」リリース
• 2019年2月 総額35億円の資金調達を発表

サービスの説明

• 数タップでスマホだけで配信できる。
• サービスコンセプト：友達の家でドラクエやってる感じ
• ゲームを中心とした、「コミュニケーション」
• リリース時はOSの機能のレベルの問題で、Android5のみ対応でiOSでは視聴のみだったが、iOS11がリリースされたタイミングで配信可能になり、そこでグンと伸びた

ポジショニング

ビジネスモデル

• マネタイズ
  • 視聴者の課金
  • 他配信者によるギフト
  • アバターショップでの素材購入、ガチャ

ミッション

• わかりあう願いをつなごう

人員構成

• 22名正社員で、半分は開発

エンジニアの割合

領域	人数
iOS	2人
Android	1人
Unity	1人
サーバサイド	2人
インフラ	2人
グロースハック	1人

評価、目標設定

• 四半期ごとにOKRで設定
• 全社のOKRをみんなで決めて、そこからチーム毎にOKRを設定して、みんなが納得感があるように

チーム構成

• ライブ体験改善: 数字ドリブン
• エモモ:体験ドリブン
• R&D: エンジニア主導
• 開発体験向上: エンジニア主導

OKRの例

開発体験向上チームのOKR

項目	内容
O	開発に夢中
KR1	期初に洗い出した辛みを解消し、全プラットフォームで理想の状態を確立する
KR2	みんなが手軽にフルスタックになれる土壌を整える
KR3	テックブログ2週間に1本

エモモチーム

• 基本的な機能をブラッシュアップ・改善
• スナップ機能
• 礼和Tシャツ

R&Dチーム

• ボイスチェンジ
• 配信の遅延が最低2,3秒なので、1〜1.5秒とかにしたい
• 配信するにはパーミッションとらないといけないが、よくわからんし、毎回手動で切り替えないといけないのがめんどくさい
  • ユーザの画面の画像認識で推定して、自動で切り替えるように試行錯誤中

R&Dチーム

• 開発上の不満解消
• 全プラットフォームのベースラインの知識を備え、さらに得意領域を伸ばす
• エンジニアが増えてもスケールできるように

MVPでのリリースへの捗り

• どの機能も他に類を見ない機能
  • 目指したい世界観はあれど、ユーザに受け入れられないものに時間はかけない
• ユーザさんの体験を定量・定性的の両方で追える
• 実際に使ってくれる様子をリアルタイムに観測可能
  • 少人数からの展開であれば視聴者として実際にやりとりできる
  • 録画を見て振り返ることも可能
  • リリース直後からリアルタイムに分析できる仕組み
• 熱狂的なファンのニーズや不満に応える姿勢、そこを起点に徐々に他のファンにも展開

ロジカルさとエモさの両立

• 定量的
  • 新規リリース後、1時間後には速報値がでるように分析チームが待機
  • 1日数回slackに各KPIが自動更新で表示され、全員チェック可能な体制に
  • 新機能リリース時にはKPIを見ながら段階的に解放。仮説とのギャップを見ながら必ず判断
• 定性的
  • ユーザがその機能を使っている様子をリアルタイムで観察できる
  • 見守りチャンネルを機能毎に作成して、配信者の様子を見守る

ユーザに向き合い、ユーザから学ぶ開発体制

• 運営が直近の開発の内容や、リリース予定の機能などを配信してユーザに共有
• 毎週1時間かけて、ユーザからのフィードバックを見直して認識をあわせてる
  • AppStoreのレビュー
  • お問い合わせ
  • twitterのDM

ユーザ体験？？？

• ユーザのスマホのあらゆる体験から、発明
• ユーザが勝手に発明してくれる
  • ex. 質問箱の配信

副業

副業20数名と大量にいる。

• 情報は事業状況含めフルオープン
  • slackだけではキツいので、毎月のプレミアムエモいデー
• 必要のない時間管理はなし、プロ意識に一任
  • slackで日報で共有
• 不安解消
  • 簡単なUI改修などから入ってもらう
  • R&Dよりの期限のないものをお願いする
• 社員の状況がわからないので、質問し辛い
  • 分報チャネルで話してもらって、手の空いてる社員が対応

質疑応答

• 新機能と改善のリソース配分はどうしてるか
  • チームわけて、優先順位を決めてる
  • 新機能とバグ対応の優先順位を決める
  • チーム分けるときは、アーキテクチャも意識する
    • お互いの作業がコンフリクトしてしまうと意味ない

②「LIPSのグロース戦略とプロダクト開発について」

登壇者: 深澤 雄太（株式会社AppBrew CEO）

• 1994年生まれ、2013年度東京大学入学。
• 中学時代に独学でプログラミングを習得。
• 大学入学後の2013年に友人らと共に「東大無料塾」を立ち上げた後、大学を休学しfreee株式会社で1年間インターンを経験。
• 個人でのシステム開発の受託などを経て、2016年2月に株式会社AppBrewを設立。
• コスメのコミュニティアプリ「LIPS」を2017年1月にリリース。

プロダクト説明

• 300万DLL突破
• コスメのクチコミ「コミュニティ」
  • 探す・見る
  • 共感する
  • 投稿する
  • 共感される

プロダクト開発ってなんですか？ 「仮説検証のサイクル」
運用は実は難しい。
仮設・検証があってるかどうか

プロダクト作りの大前提: 「仮説検証のサイクル」

• 目標地点を定めておく（短期・中長期）
• 仮設を立てる
  • 現在と目標の差分（課題）の解決
  • 適切なサイズとコストとインパクトの大きさ（枝葉末節に陥ってないか）
  • 検証可能性（= 基本は数値ベースで測定・比較）
• 実行/検証する
  • 仮説通りに変化したか
  • それを踏まえて、次の仮説に

LIPSの「仮説の立て方」

• 短期目標：「ユーザの求めるコスメ・美容レビューの提供」
• 長期目標：「ユーザ（若年女性）の求める実用的なレビュー全般の提供」

仮説の必要要素を固める(githubのissue templateを利用)

• ユーザの抱える問題
• 問題の解決策
• インパクト想定
  • 対象： ヘビーユーザ, 全ユーザ, 他の特定ユーザ（ex: 投稿ユーザ）
  • 対象画面のDAUU
  • 使用頻度： daily, weekly, monthly
  • 改善する数値
  • 数値の伸び幅：○倍 or ○％
• コスト想定
• 検証内容

仮説の具体例

通知許可率の向上についての仮説

• ユーザの抱える問題
  • 通知許可しないことで、本来ニーズがあるはずの情報も受け取れない
• インパクト想定
  • 対象： 全新規ユーザ
  • 対象画面のDAUU：数千〜
  • 使用頻度：1度
  • 改善する数値：通知許可率
  • 数値の伸び幅：数％ = 通知の開封数にして数％
• 問題の解決策はなにか
  • 「許可しないと損するかも」という訴求を加える。実際他社で通知のABテスト行ったエンジニアいわく細かい文言の調整も効いたとのことだったので、とりあえず「許可しないと〇〇できません」の文言追加
• コスト想定
  • 文言変更のみなので小さい

検証の方法

• 数値の取得（分析基盤・ログの仕込み）
• 数値の変化を観る
  • A/Bテスト（時系列だけの観測では外部要因が多い）
  • できるだけ多角的に（ある数値が増えた分、他が減ったなどはよくある）
    • 検索だと、CTR下がるのは本当は良いことが多い
    • ユーザが解決することが重要
• 仮説通りにならなかった場合
  • 想定・現実間の差分を把握し、次の仮説に反映
  • 機能自体を差し戻すか否かの判断

検証結果の具体例

通知許可率の向上についての仮説

• 検証内容
  • ABテストが必要か: yes
  • 取りたいイベント: 通知許可
• 結果
  • 全体で2%程度向上→長期のRRにも寄与

仮説の具体例2

「おすすめ」タブのCTR向上についての仮説

• ユーザの抱える問題
  • フィードに興味のあるコンテンツが十分に出てきてない
• インパクト
  • 対象： DAU全体にたいして9割
  • 対象画面のDAUU：xxxxx
  • 使用頻度：起動ごと
  • 改善する数値：CTR、投稿の閲覧数
  • 数値の伸び幅：数％〜数十％ = 閲覧数も同様に変化
• 問題解決策はなにか
  • 協調フィルタリングのアルゴリズムの特徴量を少しだけナイーブに変える
• コスト想定
  • アルゴリズムの導入自体は大きいが、特徴量の変更だけなので小さい

検証の具体例2

「おすすめ」タブのCTR向上についての仮説

• 検証内容
  • ABテストが必要か: yes
  • 取りたいイベント: 「おすすめ」タブのクチコミのタップ率
• 結果
  • 約10%程度改善
  • (特徴量に関しては、数十回試していて、その中の1つ。ほかは僅差か悪化)

開発フローのまとめ

実際には仮説のうち、3割は悪化、5割は変化なし、2割が改善
さらに1割=2%が事業に大きなインパクトを与えられる

だから、

• ディスカッションでも一喜一憂せず、想定と現実のずれをいかに把握して次に活かす
• とにかくスピードもって打席を増やす

積み重ねるのが難しいので、組織文化・風土作りの方が重要

開発フローへの組み込み方

• zenhub
• 検証中フェーズを設けて管理
• 週一のMTGで検証中のissueを一つずつディスカッション

一人ひとりがE2Eで仮説に関わる

マルチスタックの要求

• 全員がE2Eで施策に関わるために、AppBrewのエンジニアは「マルチスタック」の精鋭
• 「サーバとフロント」ではなく、仮説検証のベーススキル（入ってから身につけるでもよし）と各カテゴリのスキルセット
• 各カテゴリへの高い専門性も要求すると同時に、技術のみでは採用しない
• 大きく、ソフトウェア・アルゴリズムに分かれてる
  • ソフトウェア：サーバ、クライアント、インフラ
  • アルゴリズム：統計やデータアルゴリズム、ML
  • 共通の基本：データ分析、仮説検証リテラシー、事業理解

開発組織を支える文化

• 少数精鋭・ユーザ主義
  • マルチスタックの少数精鋭
  • 数値や事業のリテラシーと仮説検証
• オープン
  • 事業に関する情報全公開(リテラシーにそのまま繋がる)
  • 給与や、SOまで含めて公開
• 自律分散的
  • フラットで、各々が意思決定する（誰も命令しない・スタンスをとることを要求）
  • ルールなどを最小化し業務の邪魔をしない（勤務時間自由・フルリモート可）
  • 評価や査定を全て相互評価（分散的に評価する）

ユーザが熱狂するプロダクトを再現性を持って生み出す

機械学習スタック

③「グロースの構造を理解する」

登壇者: 大竹 雅登（dely株式会社 CTO）

• 2014年、慶應義塾大学在学中にdely株式会社のCTOに就任。
• 数回のピボットを経て、2016年1月よりレシピ動画サービス「クラシル」を運営。
• CTOとして開発を牽引したレシピ動画アプリ「クラシル」が、Google Play ベスト オブ 2016「ベスト自己改善アプリ賞」、App Ape Award 2016「スタートアップアプリ賞」を受賞するなど、昨年5月のリリースから約1年半で国内最大のレシピ動画サービスとして成長させた。

グロースとは？

概念の説明ばかりふわっとした理解になりがち。
解像度高くしたい。

成長曲線のS字カーブ

DAUの成長はS字カーブを描くので、サービスがどのフェーズにいるのか理解するのが重要。

• 広告とか打てば打つほど、DAUが伸びるフェーズ
• DAUが寝てくるフェーズ
  • スナップチャットはDAUが寝てる
  • 新規獲得とチャーンが釣り合うとそうなる

成長曲線のS字カーブをデータや構造から理解する

1. リテンションカーブ
2. リテンションコホート
   • リテンションカーブより情報量が多い
3. 積み上げDAU
   • コホートを斜めに足せば算出できる
   • エクセルでは結構表現するのが難しい
     • 
4. チャーンユーザ
5. DAU成長率

新規獲得のボリュームによって、DAUが寝るタイミングは変化する

広告突っ込んでも、長期的にはチャーンと釣り合うようになるので

いかに新規獲得を増やすか

• 広告: 新規獲得数 = 広告予算 / CAC
  • 予算を増やす
    • 資金調達
  • CACを下げる:
    • Organic CAC: 口コミとか
    • Paid CAC

• オーガニック獲得のチャネル
  • SEO
    • アプリ主体で始まったサービスでも途中からSEO頑張るのは結構ありがちなパターン
  • 口コミ
  • 招待プログラム（招待した人にインセンティブ付与）
  • 復帰ユーザ(機種変更など)
  • TVCM（直接計測不可なのでオーガニック扱い）
    • クリエイティブを見た直後と、ランキング上昇してDL増えたとか副次的な影響に分解できる
  • オフライン施策(リアルイベント、チラシ配布)
  • ASO

自然独占の法則

• ライトユーザは大きなブランドを好む
• 市場シェアを拡大するほどライトユーザが獲得しやすい

ブランディングの科学 誰も知らないマーケティングの法則11

オーガニック獲得を増やすために広告を踏むという逆説的な施策もあり

質疑応答：クラシルで特にグロースで頑張ったのは？

• SEO頑張った
• SNS