エンジニアだけで企画開発分析すべてを遂行するチームを立ち上げた話

2019/7/30 s-dev talks 〜サービス開発勉強会〜「チームビルディング」での小野の講演資料になります

Transcript

1. 企画開発分析すべてを遂行 するチームを立ち上げた話 2019.7.30 s-dev talks チームビルディング @susunshun https://www.pexels.com/ja-jp/photo/1451447/ エンジニアだけで
2. 自己紹介 • 小野　駿（おの しゅん） • Twitter： @susunshun • 株式会社リクルートテクノロジーズ ◦ リクルートマーケティングパートナーズも兼務 ◦ 3年前にSIerから転職してきました • お仕事 ◦ ◦◦マネージャーや◦◦リーダーが多い ◦ ときには企画したりごりごり開発したり分析したり • 目標 ◦ ”やさしいせかいをつくりたい” https://twitter.com/mok2mok2/status/893455693302214657
3. 今日はなすこと • カットオーバーから５年近く経ったプロダクト • エンジニアオンリーのチームで企画・開発・分析、プロダクト改善のサイク ル全てを担うチームの立ち上げを行いました • 企画や分析方面への染み出しを行う中での 泥臭い取り組みを事例ベースで共有します
4. 仮説検証型チームの爆誕
5. （当時の）プロダクトの状況 導入期 成長期 成熟期 衰退期 売上 （イメージ） 多分この辺
6. （当時の）プロダクトの状況 導入期 成長期 成熟期 衰退期 売上 （イメージ） 多分この辺 • 成長期のプロダクトなのでやることは沢山 ◦ 大玉の案件で当分やることは決まっている ◦ そしてMustであろう機能は出揃ってきた • これからもう１段、プロダクトが成長するために、僕らが目指すべき方向、ユー ザーへ提供すべき価値は何であろうかを改めて考え始める時期 • どのような機能・価値が求められているかを仮説検証しながら模索するムーブが 重要なのではないか
8. 既存チームとの棲み分け（プロセス）
9. ここから多くの課題と向き合い 時には泥臭い取り組みをしつつ チームの改善を重ねていくことになります https://www.pexels.com/ja-jp/photo/209209/
10. 最初にぶちあたった課題
12. 開発以外のことが分からない ワイ よっしゃ仮説考えて自分で実装して 世界最速のリリースだ！！！ 最強の施策考えて効果見立ても完璧、 分析の予測も立っていて、法務的な懸 念も全てクリアにしてあるぞ！
13. こうはならない 終 監修・著作 ━━━━━ susunshun
14. 開発以外のことが分からない • 仮説立案〜リリース、効果測定の流れがまるで分からない • 勘所もない • なぜなら僕らはエンジニア、開発しかやってこなかったのだから…
15. そもそも権限が移譲されていない ワイ 自分で施策も考えて開発して 仮説検証回していきたいぞい！！！ 偉い人 OK！！！全部任せたよ！！！
16. こうはならない 終 監修・著作 ━━━━━ susunshun
17. そもそも権限が移譲されていない • 僕らには開発スコープ以外の実績が無い • 実績もなければ信頼もない • そんな状態で任せてくれないのは当然 • なぜなら僕らはエンジニア、開発しかやってこなかったのだから…
18. 壁と向き合う • 開発以外のことが全くわからない • 権限委譲されない • これらの課題と向き合う
19. 仮説検証型チーム構築のSTEP
20. 段階的なプロセスの磨き込み • いきなりすべてを叶えることは難しい • まずは現状を踏襲するところから、段階的に 磨きこんでいく https://www.pexels.com/ja-jp/photo/434645/
21. Build - Measure - Learnのサイクル • Build - Measure - Learnのサイクルをベースに改善を考えていく • Build ◦ 構築してリリース • Measure ◦ データを計測して検証する • Learn ◦ 検証結果から学びを得て、 次に踏むべきアクションを 明確にする Learn Measure Build
22. 段階的なプロセスの磨き込み 初期 STEP１ STEP２ STEP３ 開発以外のことが わからない As-Isプロセスの 踏襲 仮説検証サイクルを 回す 仮説検証サイクルの 高速化 ？ ？ Build Learn Measure Build Learn Measur e Build Learn Measur e Build
23. STEP1：As-Isプロセスの踏襲
24. 地道に紐解いていく • そもそもカットオーバーから数年経ったプロダクト • 既にプロダクト改善の活動は日々日々行われている • しかし、仮説立案〜リリース・効果測定の一連のプロセスが不明瞭 • そこをまず可視化し、現状を踏襲するところから 始めました • その取組の一部を事例ベースで紹介します https://www.pexels.com/ja-jp/photo/2923/
25. 徹底的な競合研究 • 思った以上に自分のサービス、競合、マッチングアプリのことを知らなかった • １日１サービス、１時間、メンバー全員で徹底的にアプリを調査 • その中で思ったことをオンタイムで共有し、差分を徹底的に洗い出し ◦ 自社と他社の差分 ◦ 他社の中でのバージョンの差分 • その差分がどのような効果をもたらすか、どのような意図があるのかを議論
26. ２週間で施策１００本ノック • 仮説立案・企画スキルを鍛える • ひたすら施策を考えまくってひたすら事業責任者にレビューして貰う • ２週間で１００個 施策を考えた
27. AS-ISプロセスの可視化 仮説出し〜リリース、効果測定の流れを可視化 • 各プロセスのINPUTとOUTPUT • 関連するセレモニー（会議や承認フロー） • そこらじゅうに散らばっている関連ナレッジ
28. 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
29. AS-ISプロセスの可視化 仮説立案 仮説詳細化 プランニング 開発 効果測定 振り返り ざっくりこんな感じです
30. As-Isプロセスの可視化 • こういった取り組みを経て、As-Isのプロセスはだいたい理解・整理できた • 次はそれを実行できるようにしていきます • ここでもスーパープレーは特に無く、段階的に自分達のできる領域を拡張し ていきます
31. 段階的な権限移譲 やってない 伴走 独力 伴走 独力 やってない 独力 伴走 やってない 伴走 独力 伴走 仮説立案 仮説詳細化 プランニング 開発 効果測定 振り返り 自立度 高 低 企 画 職 の 方 に 任 せ て い た 範 囲 伴 走 し て も ら っ て い た 範 囲 独 力 で 実 行 で き る 範 囲
32. 段階的なプロセスの磨き込み 初期 STEP１ STEP２ STEP３ 開発以外のことが わからない As-Isプロセスの 可視化 仮説検証サイクルを 回す 仮説検証サイクルの 高速化 ？ ？ Build Learn Measure Build Learn Measur e Build Learn Measur e Build DONE DONE
33. STEP2：仮説検証サイクルを回す
34. As-Isのプロセス課題を抽出 現状↔As-IS ◦ 僕らがAs-Isのプロセスを遂行できているか As-Is↔To-Be ◦ 現状のプロセス課題はなにか ◦ 理想との差分はなにか アプローチ ◦ その差分を埋めるアプローチはなにか
35. 見えてきた課題 • Learnの質が低く、次なる仮説につながりにくい状況 • リリース後に効果測定を行って、狙った数値が改善されるものの 「良かったね！！！」で終わってしまう • 次につながらない単発の施策になりがち Learnの質が低い
36. ３つの打ち手 チーム目標の見直し ABテスト基盤の拡充 効果測定の型化
37. • LTVをチームの主要KPIとして日々改善を行っていた • 粒度としてはめちゃくちゃ大きい部類 チーム目標の見直し KPIの粒度が大きすぎた
38. チーム目標の見直し 利益 売上 コスト LTV A B C いままでフォーカス していた目標 ▼ 再設定した目標 ▼ 一段ブレークダウン • 施策毎にアプローチするサブKPIが異なり、知見が集約されない • 大きい指標にすぐアプローチするためには、大きい施策を打たざる を得ない力学が働き、これによって仮説検証スピードが低下する • なんとかしようと短期的な利益に得る施策に落ちがち
39. • 施策の効果測定は前後比較がメイン、するとこういうことが起きる ABテスト基盤の改善 この前の施策、前後１週間の比較でCVRが爆 改善されておる！！大当たりや！！！ 最近広告増やしてるから、そもそも流入ユー ザーの特性が変わってるぞ 広告の効果を考慮した場合、この施策は効果 ないのかも... でもわからんなぁ...
40. • 施策の効果測定は前後比較がメイン、するとこういうことが起きる ABテスト基盤の改善 この前の施策、前後１週間の比較でCVRが爆 改善されておる！！大当たりや！！！ 最近広告増やしてるから、そもそも流入ユー ザーの特性が変わってるぞ 広告の効果を考慮した場合、この施策は効果 ないのかも... でもわからんなぁ... やっぱりABテストだよね！！！
41. • 実はABテストを行う環境はある • しかしABテストを実施する度にそこそこ開発工数が掛かる状況 • スピードを意識すると、前後比較で効果測定をしがちになっていた ▶　Firebaseを導入しABテスト実行コストを削減 ABテスト基盤の改善
42. 分析設計の型化 • 作業の無駄 ◦ いざリリースしてみたら、効果測定に必要なログが取れていなかった ◦ 分析のSQL書くのにめっちゃ時間掛かる ◦ そうすると満足に深掘りできない • 仮説を詳細化できていない ◦ 各指標を見た後にどういう効果があったかを考える（予測していない） ◦ 施策の調子が良くなさそうでも数値が改善されている指標を探しちゃう 効果測定がブレブレだった
43. 分析設計の型化 • 作業の無駄 ◦ いざリリースしてみたら、効果測定に必要なログが取れていなかった ◦ 分析のSQL書くのにめっちゃ時間掛かる ◦ そうすると満足に深掘りできない • 仮説を詳細化できていない ◦ 各指標を見た後にどういう効果があったかを考える（予測していない） ◦ 施策の調子が良くなさそうでも数値が改善されている指標を探しちゃう 効果測定がブレブレだった 仮説立案 仮説詳細化 プランニング 開発 効果測定 振り返り 分析設計 分析設計フェーズ を設ける
44. 分析設計の型化 Why What Where How When 何を検証したいのか どの指標を見るのか データソースはどこか 比較方法は何か（前後比較／ABテスト等） 算出方法は何か いつ測定するのか （リリース直後、３日後、７日後等） いつ どの指標が どうなったら（上がる、下がる等） どうする（切り戻し、静観、計測終了） アクションの整理 分析対象の整理 ✖
45. 段階的なプロセスの磨き込み 初期 STEP１ STEP２ STEP３ 開発以外のことが わからない As-Isプロセスの 可視化 仮説検証サイクルを 回す 仮説検証サイクルの 高速化 ？ ？ Build Learn Measure Build Learn Measur e Build Learn Measur e Build DONE DONE DONE
46. STEP3：仮説検証サイクルの高速化 絶賛模索中！
47. BMLを高速に回す 初期 STEP１ STEP２ STEP３ 開発以外のことが わからない As-Isプロセスの 可視化 仮説検証サイクルを 回す 仮説検証サイクルの 高速化 ？ ？ Build Learn Measure Build Learn Measur e Build Learn Measur e Build DONE DONE DONE • プロダクト改善の成果を Learnの質 ✕ サイクル回数で考える • ここまでは Learnの質を高める 話 • 今度は サイクル回数を増やす 話
48. 定常モニタリング基盤の構築 目的は２つ • 分析の自動化（サイクルの回数を増やす 文脈） ◦ 実はここまで（時にして半年弱）、ほとんどの効果測定をSQLで行っていた ◦ 漢のSQL直打ちを続けてきたが、満を持して半自動化（理由は後述） • プロダクトの健康状態を可視化（Learnの質を高める 文脈） ◦ プロダクトの主要KPIを定常的にモニタリングする ◦ 施策による予期せぬ副作用の影響を検知しやすくする ◦ 施策以外の影響を検知しやすくする
49. 定常モニタリング構築のSTEP • ここでも仮説検証を繰り返しながら構築していく • 目的の不確実性を下げてから、手段の不確実性を下げていく 俺の定常モニタリング（物理） 真・俺の定常モニタリング チームの定常モニタリング プロダクトの定常モニタリング 「何を」「どのように」 見るかの検証 自動化によるコスト削減 副作用の検出 健康状態の可視化 保守性の向上 運用の最適化 自分は見えていない領域 目的 漢のSQL直打ち RedashやDataStudio等の 簡易的なツールでサクッと 自動化 ←の磨き込み データマートの整備 プロに任せる 手段 目的の不確実性を 下げる 手段の不確実性を 下げる
50. 手軽に始める定常モニタリング構築のSTEP • ここでも仮説検証を繰り返しながら構築していく • 目的の不確実性を下げてから、手段の不確実性を下げていく 俺の定常モニタリング（物理） 真・俺の定常モニタリング チームの定常モニタリング プロダクトの定常モニタリング 「何を」「どのように」 見るかの検証 自動化によるコスト削減 副作用の検出 健康状態の可視化 保守性の向上 運用の最適化 自分は見えていない領域 目的 漢のSQL直打ち RedashやDataStudio等の 簡易的なツールでサクッと 自動化 ←の磨き込み データマートの整備 プロに任せる 手段 目的の不確実性を 下げる 手段の不確実性を 下げる 何も無い所から始めるのであれば、 まず何を見るべきかを最小コストで検証する
51. 手軽に始める定常モニタリング構築のSTEP • ここでも仮説検証を繰り返しながら構築していく • 目的の不確実性を下げてから、手段の不確実性を下げていく 俺の定常モニタリング（物理） 真・俺の定常モニタリング チームの定常モニタリング プロダクトの定常モニタリング 「何を」「どのように」 見るかの検証 自動化によるコスト削減 副作用の検出 健康状態の可視化 保守性の向上 運用の最適化 自分は見えていない領域 目的 漢のSQL直打ち RedashやDataStudio等の 簡易的なツールでサクッと 自動化 ←の磨き込み データマートの整備 プロに任せる 手段 目的の不確実性を 下げる 手段の不確実性を 下げる ある程度の規模になってきたら データ基盤の乱立を避け、任せるべき所は 任せて全体の最適化を図る
52. 作らない • 極力作らない ◦ 価値ある最小単位、MVPを強く意識する ◦ 作らないことが一番フィードバックを早く得られる、失敗リスクも小さい • 段階を分ける ◦ 機能を分割して段階リリース ◦ インクリメンタルにリリース • そもそも作らない ◦ ツールを駆使してノーコーディングで検証（メルマガ、アプリ内メッセージ） • 機能や対象セグメントを小さくしすぎて充分なフィードバックを得られない なんて失敗もありました
53. 段階的なプロセスの磨き込み 初期 STEP１ STEP２ STEP３ 開発以外のことが わからない As-Isプロセスの 可視化 仮説検証サイクルを 回す 仮説検証サイクルの 高速化 ？ ？ Build Learn Measure Build Learn Measur e Build Learn Measur e Build DONE DONE DONE DONE？
54. 仮説検証型チームを立ち上げて得られた学び • やってみて分かったメリット ◦ 一個小隊にBuild - Measure - Learn をすべて担うケーパビリティをもたせ、各工程の伝導率 を高めることで最速の仮説検証を実現することにあると思う ◦ なので全員エンジニアである必要はない • エンジニアしかいない背景 ◦ 実は企画の人をアサインできなかったからです... • 理想 ◦ 各ロール（企画、エンジニア、アナリスト等）が一個小隊に揃っている状態
55. まとめ • プロダクト改善サイクルの全てを担うチームの立ち上げ • 都度As-Is、To-Beを整理、その差分を段階的に埋めていくムーブ • その過程で多くの泥臭い取り組みを重ねる 仮説検証を回すことが目的ではありません 全てはプロダクトを少しでも良いものに仕立て上げ、 ユーザーに喜んでもらいたいという想いが根底にあります
56. ご清聴ありがとうございました