Tweet
Tweet

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

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

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

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