エンジニアだけで企画・開発・分析全てを遂行するチームを立ち上げた話 #sdevtalks / s-dev talks 20190730

Slide 1

Slide 1 text

企画開発分析すべてを遂行するチームを立ち上げた話 2019.7.30 s-dev talks チームビルディング @susunshun https://www.pexels.com/ja-jp/photo/1451447/ エンジニアだけで

Slide 2

Slide 2 text

自己紹介 ● 小野　駿（おのしゅん） ● Twitter： @susunshun ● 株式会社リクルートテクノロジーズ ○ リクルートマーケティングパートナーズも兼務 ○ 3年前にSIerから転職してきました ● お仕事 ○ ○○マネージャーや○○リーダーが多い ○ ときには企画したりごりごり開発したり分析したり ● 目標 ○ ”やさしいせかいをつくりたい” https://twitter.com/mok2mok2/status/893455693302214657

Slide 3

Slide 3 text

今日はなすこと ● カットオーバーから５年近く経ったプロダクト ● エンジニアオンリーのチームで企画・開発・分析、プロダクト改善のサイクル全てを担うチームの立ち上げを行いました ● 企画や分析方面への染み出しを行う中での泥臭い取り組みを事例ベースで共有します

Slide 4

Slide 4 text

仮説検証型チームの爆誕

Slide 5

Slide 5 text

（当時の）プロダクトの状況導入期成長期成熟期衰退期売上（イメージ）多分この辺

Slide 6

Slide 6 text

（当時の）プロダクトの状況導入期成長期成熟期衰退期売上（イメージ）多分この辺 ● 成長期のプロダクトなのでやることは沢山 ○ 大玉の案件で当分やることは決まっている ○ そしてMustであろう機能は出揃ってきた ● これからもう１段、プロダクトが成長するために、僕らが目指すべき方向、ユーザーへ提供すべき価値は何であろうかを改めて考え始める時期 ● どのような機能・価値が求められているかを仮説検証しながら模索するムーブが重要なのではないか

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

既存チームとの棲み分け（プロセス）

Slide 9

Slide 9 text

ここから多くの課題と向き合い時には泥臭い取り組みをしつつチームの改善を重ねていくことになります https://www.pexels.com/ja-jp/photo/209209/

Slide 10

Slide 10 text

最初にぶちあたった課題

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

開発以外のことが分からないワイよっしゃ仮説考えて自分で実装して世界最速のリリースだ！！！最強の施策考えて効果見立ても完璧、分析の予測も立っていて、法務的な懸念も全てクリアにしてあるぞ！

Slide 13

Slide 13 text

こうはならない終監修・著作 ━━━━━ susunshun

Slide 14

Slide 14 text

開発以外のことが分からない ● 仮説立案〜リリース、効果測定の流れがまるで分からない ● 勘所もない ● なぜなら僕らはエンジニア、開発しかやってこなかったのだから…

Slide 15

Slide 15 text

そもそも権限が移譲されていないワイ自分で施策も考えて開発して仮説検証回していきたいぞい！！！偉い人 OK！！！全部任せたよ！！！

Slide 16

Slide 16 text

こうはならない終監修・著作 ━━━━━ susunshun

Slide 17

Slide 17 text

そもそも権限が移譲されていない ● 僕らには開発スコープ以外の実績が無い ● 実績もなければ信頼もない ● そんな状態で任せてくれないのは当然 ● なぜなら僕らはエンジニア、開発しかやってこなかったのだから…

Slide 18

Slide 18 text

壁と向き合う ● 開発以外のことが全くわからない ● 権限委譲されない ● これらの課題と向き合う

Slide 19

Slide 19 text

仮説検証型チーム構築のSTEP

Slide 20

Slide 20 text

段階的なプロセスの磨き込み ● いきなりすべてを叶えることは難しい ● まずは現状を踏襲するところから、段階的に磨きこんでいく https://www.pexels.com/ja-jp/photo/434645/

Slide 21

Slide 21 text

Build - Measure - Learnのサイクル ● Build - Measure - Learnのサイクルをベースに改善を考えていく ● Build ○ 構築してリリース ● Measure ○ データを計測して検証する ● Learn ○ 検証結果から学びを得て、次に踏むべきアクションを明確にする Learn Measure Build

Slide 22

Slide 22 text

段階的なプロセスの磨き込み初期 STEP１ STEP２ STEP３開発以外のことがわからない As-Isプロセスの踏襲仮説検証サイクルを回す仮説検証サイクルの高速化？？ Build Learn Measure Build Learn Measur e Build Learn Measur e Build

Slide 23

Slide 23 text

STEP1：As-Isプロセスの踏襲

Slide 24

Slide 24 text

地道に紐解いていく ● そもそもカットオーバーから数年経ったプロダクト ● 既にプロダクト改善の活動は日々日々行われている ● しかし、仮説立案〜リリース・効果測定の一連のプロセスが不明瞭 ● そこをまず可視化し、現状を踏襲するところから始めました ● その取組の一部を事例ベースで紹介します https://www.pexels.com/ja-jp/photo/2923/

Slide 25

Slide 25 text

徹底的な競合研究 ● 思った以上に自分のサービス、競合、マッチングアプリのことを知らなかった ● １日１サービス、１時間、メンバー全員で徹底的にアプリを調査 ● その中で思ったことをオンタイムで共有し、差分を徹底的に洗い出し ○ 自社と他社の差分 ○ 他社の中でのバージョンの差分 ● その差分がどのような効果をもたらすか、どのような意図があるのかを議論

Slide 26

Slide 26 text

２週間で施策１００本ノック ● 仮説立案・企画スキルを鍛える ● ひたすら施策を考えまくってひたすら事業責任者にレビューして貰う ● ２週間で１００個施策を考えた

Slide 27

Slide 27 text

AS-ISプロセスの可視化仮説出し〜リリース、効果測定の流れを可視化 ● 各プロセスのINPUTとOUTPUT ● 関連するセレモニー（会議や承認フロー） ● そこらじゅうに散らばっている関連ナレッジ

Slide 28

Slide 28 text

AS-ISプロセスの可視化 ● Build - Measure - Learn になぞらえてIN/OUTを整理する Learn Measure Build idea data Product アクションオブジェクト XX定例案だし会振り返り共有会施策リスト施策内容プランニング開発・テストリリース効果測定 Webアプリスマホアプリ etc... 数値の結果知見タスク/セレモニー成果物 IN OUT OUT IN IN OUT Learn Build Measure

Slide 29

Slide 29 text

AS-ISプロセスの可視化仮説立案仮説詳細化プランニング開発効果測定振り返りざっくりこんな感じです

Slide 30

Slide 30 text

As-Isプロセスの可視化 ● こういった取り組みを経て、As-Isのプロセスはだいたい理解・整理できた ● 次はそれを実行できるようにしていきます ● ここでもスーパープレーは特に無く、段階的に自分達のできる領域を拡張していきます

Slide 31

Slide 31 text

段階的な権限移譲やってない伴走独力伴走独力やってない独力伴走やってない伴走独力伴走仮説立案仮説詳細化プランニング開発効果測定振り返り自立度高低企画職の方に任せていた範囲伴走してもらっていた範囲独力で実行できる範囲

Slide 32

Slide 32 text

段階的なプロセスの磨き込み初期 STEP１ STEP２ STEP３開発以外のことがわからない As-Isプロセスの可視化仮説検証サイクルを回す仮説検証サイクルの高速化？？ Build Learn Measure Build Learn Measur e Build Learn Measur e Build DONE DONE

Slide 33

Slide 33 text

STEP2：仮説検証サイクルを回す

Slide 34

Slide 34 text

As-Isのプロセス課題を抽出現状↔As-IS ○ 僕らがAs-Isのプロセスを遂行できているか As-Is↔To-Be ○ 現状のプロセス課題はなにか ○ 理想との差分はなにかアプローチ ○ その差分を埋めるアプローチはなにか

Slide 35

Slide 35 text

見えてきた課題 ● Learnの質が低く、次なる仮説につながりにくい状況 ● リリース後に効果測定を行って、狙った数値が改善されるものの「良かったね！！！」で終わってしまう ● 次につながらない単発の施策になりがち Learnの質が低い

Slide 36

Slide 36 text

３つの打ち手チーム目標の見直し ABテスト基盤の拡充効果測定の型化

Slide 37

Slide 37 text

● LTVをチームの主要KPIとして日々改善を行っていた ● 粒度としてはめちゃくちゃ大きい部類チーム目標の見直し KPIの粒度が大きすぎた

Slide 38

Slide 38 text

チーム目標の見直し利益売上コスト LTV A B C いままでフォーカスしていた目標 ▼ 再設定した目標 ▼ 一段ブレークダウン ● 施策毎にアプローチするサブKPIが異なり、知見が集約されない ● 大きい指標にすぐアプローチするためには、大きい施策を打たざるを得ない力学が働き、これによって仮説検証スピードが低下する ● なんとかしようと短期的な利益に得る施策に落ちがち

Slide 39

Slide 39 text

● 施策の効果測定は前後比較がメイン、するとこういうことが起きる ABテスト基盤の改善この前の施策、前後１週間の比較でCVRが爆改善されておる！！大当たりや！！！最近広告増やしてるから、そもそも流入ユーザーの特性が変わってるぞ広告の効果を考慮した場合、この施策は効果ないのかも... でもわからんなぁ...

Slide 40

Slide 40 text

Slide 41

Slide 41 text

● 実はABテストを行う環境はある ● しかしABテストを実施する度にそこそこ開発工数が掛かる状況 ● スピードを意識すると、前後比較で効果測定をしがちになっていた ▶　Firebaseを導入しABテスト実行コストを削減 ABテスト基盤の改善

Slide 42

Slide 42 text

分析設計の型化 ● 作業の無駄 ○ いざリリースしてみたら、効果測定に必要なログが取れていなかった ○ 分析のSQL書くのにめっちゃ時間掛かる ○ そうすると満足に深掘りできない ● 仮説を詳細化できていない ○ 各指標を見た後にどういう効果があったかを考える（予測していない） ○ 施策の調子が良くなさそうでも数値が改善されている指標を探しちゃう効果測定がブレブレだった

Slide 43

Slide 43 text

Slide 44

Slide 44 text

分析設計の型化 Why What Where How When 何を検証したいのかどの指標を見るのかデータソースはどこか比較方法は何か（前後比較／ABテスト等）算出方法は何かいつ測定するのか（リリース直後、３日後、７日後等）いつどの指標がどうなったら（上がる、下がる等）どうする（切り戻し、静観、計測終了）アクションの整理分析対象の整理 ✖

Slide 45

Slide 45 text

段階的なプロセスの磨き込み初期 STEP１ STEP２ STEP３開発以外のことがわからない As-Isプロセスの可視化仮説検証サイクルを回す仮説検証サイクルの高速化？？ Build Learn Measure Build Learn Measur e Build Learn Measur e Build DONE DONE DONE

Slide 46

Slide 46 text

STEP3：仮説検証サイクルの高速化絶賛模索中！

Slide 47

Slide 47 text

BMLを高速に回す初期 STEP１ STEP２ STEP３開発以外のことがわからない As-Isプロセスの可視化仮説検証サイクルを回す仮説検証サイクルの高速化？？ Build Learn Measure Build Learn Measur e Build Learn Measur e Build DONE DONE DONE ● プロダクト改善の成果を Learnの質 ✕ サイクル回数で考える ● ここまでは Learnの質を高める話 ● 今度はサイクル回数を増やす話

Slide 48

Slide 48 text

定常モニタリング基盤の構築目的は２つ ● 分析の自動化（サイクルの回数を増やす文脈） ○ 実はここまで（時にして半年弱）、ほとんどの効果測定をSQLで行っていた ○ 漢のSQL直打ちを続けてきたが、満を持して半自動化（理由は後述） ● プロダクトの健康状態を可視化（Learnの質を高める文脈） ○ プロダクトの主要KPIを定常的にモニタリングする ○ 施策による予期せぬ副作用の影響を検知しやすくする ○ 施策以外の影響を検知しやすくする

Slide 49

Slide 49 text

定常モニタリング構築のSTEP ● ここでも仮説検証を繰り返しながら構築していく ● 目的の不確実性を下げてから、手段の不確実性を下げていく俺の定常モニタリング（物理）真・俺の定常モニタリングチームの定常モニタリングプロダクトの定常モニタリング「何を」「どのように」見るかの検証自動化によるコスト削減副作用の検出健康状態の可視化保守性の向上運用の最適化自分は見えていない領域目的漢のSQL直打ち RedashやDataStudio等の簡易的なツールでサクッと自動化 ←の磨き込みデータマートの整備プロに任せる手段目的の不確実性を下げる手段の不確実性を下げる

Slide 50

Slide 50 text

手軽に始める定常モニタリング構築のSTEP ● ここでも仮説検証を繰り返しながら構築していく ● 目的の不確実性を下げてから、手段の不確実性を下げていく俺の定常モニタリング（物理）真・俺の定常モニタリングチームの定常モニタリングプロダクトの定常モニタリング「何を」「どのように」見るかの検証自動化によるコスト削減副作用の検出健康状態の可視化保守性の向上運用の最適化自分は見えていない領域目的漢のSQL直打ち RedashやDataStudio等の簡易的なツールでサクッと自動化 ←の磨き込みデータマートの整備プロに任せる手段目的の不確実性を下げる手段の不確実性を下げる何も無い所から始めるのであれば、まず何を見るべきかを最小コストで検証する

Slide 51

Slide 51 text

手軽に始める定常モニタリング構築のSTEP ● ここでも仮説検証を繰り返しながら構築していく ● 目的の不確実性を下げてから、手段の不確実性を下げていく俺の定常モニタリング（物理）真・俺の定常モニタリングチームの定常モニタリングプロダクトの定常モニタリング「何を」「どのように」見るかの検証自動化によるコスト削減副作用の検出健康状態の可視化保守性の向上運用の最適化自分は見えていない領域目的漢のSQL直打ち RedashやDataStudio等の簡易的なツールでサクッと自動化 ←の磨き込みデータマートの整備プロに任せる手段目的の不確実性を下げる手段の不確実性を下げるある程度の規模になってきたらデータ基盤の乱立を避け、任せるべき所は任せて全体の最適化を図る

Slide 52

Slide 52 text

作らない ● 極力作らない ○ 価値ある最小単位、MVPを強く意識する ○ 作らないことが一番フィードバックを早く得られる、失敗リスクも小さい ● 段階を分ける ○ 機能を分割して段階リリース ○ インクリメンタルにリリース ● そもそも作らない ○ ツールを駆使してノーコーディングで検証（メルマガ、アプリ内メッセージ） ● 機能や対象セグメントを小さくしすぎて充分なフィードバックを得られないなんて失敗もありました

Slide 53

Slide 53 text

段階的なプロセスの磨き込み初期 STEP１ STEP２ STEP３開発以外のことがわからない As-Isプロセスの可視化仮説検証サイクルを回す仮説検証サイクルの高速化？？ Build Learn Measure Build Learn Measur e Build Learn Measur e Build DONE DONE DONE DONE？

Slide 54

Slide 54 text

仮説検証型チームを立ち上げて得られた学び ● やってみて分かったメリット ○ 一個小隊にBuild - Measure - Learn をすべて担うケーパビリティをもたせ、各工程の伝導率を高めることで最速の仮説検証を実現することにあると思う ○ なので全員エンジニアである必要はない ● エンジニアしかいない背景 ○ 実は企画の人をアサインできなかったからです... ● 理想 ○ 各ロール（企画、エンジニア、アナリスト等）が一個小隊に揃っている状態

Slide 55

Slide 55 text

まとめ ● プロダクト改善サイクルの全てを担うチームの立ち上げ ● 都度As-Is、To-Beを整理、その差分を段階的に埋めていくムーブ ● その過程で多くの泥臭い取り組みを重ねる仮説検証を回すことが目的ではありません全てはプロダクトを少しでも良いものに仕立て上げ、ユーザーに喜んでもらいたいという想いが根底にあります

Slide 56

Slide 56 text

ご清聴ありがとうございました