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

この記事はRecruit Engineers Advent Calendar 2018 - 13日目の記事です。

追記

本記事の内容にて、s-dev taksで登壇してきました speakerdeck.com

前書き

本記事は個人的な見解を示したものであり、所属する組織を代表するものではありません。内容には留意しておりますが、もし不適切な内容や誤りがあれば、私個人当てにご指摘のコメントをいただけますと幸いです。

超概要

• カットオーバーから数年経ったtoCサービスにおいて、エンジニアオンリーのチームで企画・開発・分析、プロダクト改善のサイクル全てを担うチームの立ち上げを行いました
• 開発しか知らない僕らがよりよい価値を世に届けるために、企画や分析方面への染み出しを行う中での泥臭い取り組みや、やってみて分かった知見を共有します
• 経験ベースで築いてきた知見なので、理論を踏まえてなかったり、原理原則とは乖離する箇所もあるかと思いますが、温かい目で見守ってくださると幸いです

話さないこと

KPIを爆改善して圧倒的成果を挙げた話

話すこと

事業をグロースさせるための、仮説検証プロセスの装着を地道に、泥臭く行ってきた話

目次

仮説検証チームの爆誕

企画・開発・分析全てを担うチームとは

私が担当しているプロダクトはカットオーバーから数年が経過し、そこそこのユーザー数を抱えています。

これまでは、競合と対比して明らかに不足している（競合劣位となっている）機能の装着をメインとしてきたものの、競合との大きな差分が無くなったいま「これから何を目指すべきか」「どのような価値をユーザーへ提供していくか」を模索している段階でした。

そのような背景の下、「何が正解なのか」「どこがサービスのボトルネックなのか」に対する答えが無い中で、エンジニアオンリーのチームで仮設検証を高速で回し、プロダクトの磨き込みを行うことを目的に、チームが爆誕しました。

おっしゃ！やったるぞ！！という息巻いたものの、ここから多くの課題と向き合い、時には泥臭い取り組みをしつつ、チーム自体の改善を重ねていくことになります。。。

そもそも僕らはエンジニアである

最初に集まった３人は多少経歴の差異はあるものの、皆開発を生業としてきたエンジニアです。 そこで２つの課題が浮上しました。

その１：まず開発以外のことが分からない

• 仮説を立案し、コードとしてデプロイすることで世に放ち、その仮説をどのように評価するのか、まるで分からない
• なぜなら僕らは開発しかやってこなかったのだから

その２：そもそも権限委譲されない

• 開発チームがいる一方で、企画やプロデューサー等、プロダクト改善を担ってる先人達がもちろんいる
• いきなり以下のようにはならない
  • ワイ「自分で施策考えて開発して仮説検証回していきたいぞい！！！」
  • 偉い人「OK！！！！！！！！」
• なぜなら僕らには開発スコープ以外の実績が無い。実績もなければ信頼もない

これらの課題にまずは取り組んでいくことになります。

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

BMLプロセス

仮説検証という表現をここまで使ってきましたが、実際にはBML(Build-Measure-Learn)のプロセスを意識してプロセスの改善を行ってきました。以降、BMLになぞらえて話を進めていきます。 ここでは詳細な説明は割愛させていただきますが、 雑にWikipediaのリンクを貼っときます。 Lean startup - Wikipedia

気になる方はリーン・スタートアップあたりを読むと良いかもしれません。 http://amzn.asia/d/9ZSuzgMamzn.asia

段階的なプロセスの磨き込み

開発以外ド素人な僕らが立派にBMLを回していくために、以下のような段取りでプロセスの磨き込みや、知見の獲得をしました。

※ここでいう企画／プランナーはWebサービス／スマホアプリおける施策（機能追加／改善等）を考える人のことを指しています

それぞれのSTEPについて、以降掘り下げて説明していきます。

STEP1：As-Isプロセスの可視化

地道に紐解いていく

そもそもカットオーバーから数年経ったプロダクトなので、既にプロダクト改善の活動は当然行われています。しかし、仮説立案〜リリース・効果測定の一連のプロセスが不明瞭で、そこをまず可視化し、現状を踏襲するところから始めました。

段階的な権限委譲

結論としては、一連のプロセスを可視化した上で、１個ずつ知見を蓄え、権限委譲していくことになります。

こう図に示してみると綺麗に事が進んでいるように見えますが、実際には泥臭い取り組みの数々でした。そのうち何個かをピックアップしてご紹介します。

徹底的な競合研究

いざ仮説を立てようとしても、中々出てきません。というのも、意外と自分のプロダクトのこと、はたまた競合のことを全然分かっていなかったからです。従って、自社・競合のプロダクト研究を一番最初に取り組みしました。

１日１プロダクト、１時間の枠の中で、メンバー３人で顔を合わせて徹底的にアプリを触りまくります。その中で思ったことを共有したり、自社と他社の差分を徹底的に洗い出して、その差分がどのような効果をもたらすか、どのような意図があるのかを考察していました。

２週間で仮説１００本ノック

競合研究で知識をインプットする傍ら、こちらでアウトプットの鍛錬を徹底的に行います。

仮説立案・企画スキルの醸成を目的として、ひたすら施策を考えまくってひたすら事業責任者にレビューして貰いました。

今思うと最初に持ち込んだ施策は、仮設の筋が悪く、てんで方向違いなものばっかりでセンスの欠片もなかったかと思いますが、事業責任者やプランナーさん達のご指導の下、何回も壁打ちしているうちに、勘所が掴めてきたかと思います。

As-Isプロセスの可視化

こういった取り組みを経て、仮説立案〜リリースまでの一連のプロセスを可視化及び整備をしていくと共に、各プロセスを独力で担えるようになりました。

ここで整理したのは以下です。

• 各プロセスのINPUTとOUTPUT
• 関連するセレモニー（会議）
• そこらじゅうに散らばってる関連ナレッジ（先人達の知見が色んなところに落ちている）

これをベースとして、次はプロセスの「改善」を進めていくことになります。

STEP１.５：As-Is課題の抽出

ようやくAs-Isのプロセスを遂行できるようになった僕らは、一定期間このプロセスに従ってプロダクト改善を実施しました。そして次なる課題を発掘するために、以下に分割して振り返りを行いました。

• 僕らがAs-Isのプロセスを遂行できているか
• As-Isプロセスの課題は何か
• 各課題のTo-Beは何か
• その差分を埋めるアプローチは何か

この振り返りを経て、次なるステップに進むことになります。

STEP２：Learnの質向上

見えてきた課題

STEP1を経て、仮説立案〜リリースまでを独力で遂行できるようになりました。 しかし、BMLを繰り返し行う中でも、特にLearnが質が浅く、次なる仮説につながらないという課題が浮上してきました。

リリース後に効果測定を行って、狙った数値が改善されたものの、「良かったね！...で、次はどうする？」という状況です。

そこでLearnの質を向上させるために、３つの打ち手を講じることになります。

• KGIの見直し
• ABテスト基盤の拡充
• 分析設計の型化

チーム目標の見直し

ここまで話には出していなかったですが、チーム目標としてはLTVを置き、それを向上させるべく日々改善を回していました。（チームの目標設定に関しては今回触れませんが、数値目標を置くよりもOKRを設定し、そこから落とし込んだ方が良かったかもということを今振り返ると思ったりします。）

つまり、LTVに寄与するプロダクトの改善ポイントを探し、施策に落とし込み、それをリリースした結果から学びを得ようとしていましたが、何せLTVはKPIツリーで考えるとだいぶ上位の指標です。

これにより以下の問題が発生しました。

• 施策毎にアプローチするKPIが異なり、学び・知見が集約されない
• 短期的な利益を得る施策に落ちがち
• 大きい指標にすぐアプローチするためには、大きい施策を打たざるを得ない力学が働き、これによって仮説検証スピードが低下する

等々の問題を解消するために、チーム目標の粒度を一段落とし、フィードバック得やすくしました。

ここでは担当プロダクトの詳しいことは述べられないのですが、イメージとしては以下です。

ABテスト基盤の導入

施策の効果測定はリリース前後での各種CVRの比較を行っていましたが、前後比較は曜日や季節・広告等の影響を排除した効果測定ができず、改善されているかどうか分からないということがしばしば発生していました。

ここでようやくABテスト基盤を導入するに至ります。

お恥ずかしながら、うちのプロダクトではABテストを柔軟に行える仕組みが無く、ABテスト１回に費やす開発コストが大きかったため、Firebaseを導入しABテストを実施しやすい環境を整備しました。

分析設計の型化

仮説を考え、施策を打って、さぁ効果測定だ！と息巻いたものの、実は見たい指標が取れていなかったり、そもそも「何の数字」が「どれだけ」、「どうなったら」成功なのだろうか、と思ったことは無いでしょうか？

僕のチームではこういうことがしばしば発生していました。 そこで仮説を考え、その開発に入る前に分析設計というフェーズを明示的に置き、その中で以下を整理していました。

測定対象の整理

• Why・・・何を検証したいのか
• What・・・どの指標を見るのか
• Where・・・データソースはどこか（DBから見るのかアクセス解析ツールから見るのか、それは現在取得できているのか）
• How・・・比較方法は何か（前後比較／ABテスト等）、算出方法は明確になっているか
• When・・・いつ測定するのか（リリース直後、３日後、７日後等）

アクションの整理

• いつ
• どの指標が
• どうなったら（上がる、下がる、横ばい）
• どうする（測定を継続、切り戻す、測定終了／どう解釈するか）

STEP３：BMLの高速化

BMLを「高速」に回す

これまでの取り組みで、ようやくBMLサイクルを回せるようになりました。（もちろん回すこと自体が目的ではないですが）

次なる課題として、以下に多くの学びを得るか、学びの量を「質✕回数」と定義すると、質の面はSTEP２に示した通りのアプローチを行いました。つまり次は回数へのアプローチを行います。

定常モニタリング基盤の構築

定常モニタリングの狙いは以下の２つです。

• 分析の自動化
• 健康状態の可視化

分析の自動化

これまで効果測定における分析作業は、全て手動でSQLを叩くという苦行のような作業を行っていましたが（リアルガチで苦行だった）、ここでようやく分析の自動化を行うことになります。

健康状態の可視化

何か施策を打った際に、KPIは小さい指標から先に効果が出て、より大きい指標へと波及していきます。 それらの分析として自分が認識している範囲内であれば、これまで通り手動でSQLを叩き効果を見るということができますが、予期せぬ箇所まで影響が及んでいることも時にはあるかと思います。

もしくは施策直後には大きく影響が出ていないが、じわじわと影響を及ぼしていることも考えられるでしょう。

施策の効果測定という側面でだけでなく、仮説を立案する際に「どこかボトルネックになっているのか」を特定するためのフックとして、プロダクトの健康状態が常に可視化されていることが望ましいです。

定常モニタリング構築のSTEP

これだけで記事一本書けちゃうくらいなので詳細な説明は割愛しますが、定常モニタリングも最初は手動のSQLから初め、不確実性を排除しながら徐々に構築していきました

フロー効率を重視したプロセス構築

開発プロセスの話は欠片もしてこなかったのですが、ここに来てようやく考え始めました。

この取り組みはまだやり切れていないのと、「フロー効率」でググれば素晴らしい知見が沢山出てくるので、ここも今回は割愛させていただきます。

終わりに

長々と綴りましたがいかがだったでしょうか？ グロースハック、仮説検証、BML、最近ではよく聞く言葉になりましたが、その裏には泥臭いこういう取り組みもあるよ、という事例を今回紹介させていただきました。

ここではプロセスに偏った話をしましたが、僕らは正しい問題にフォーカスして理想のプロダクトを作り上げることでユーザーに良い思いをして貰いたいお気持ちで、このような取り組みをしています。

より良いコードを、よい良いシステムを作り上げていく一方で、正しい問題にフォーカスしてムダなコードを書かないためとも解釈できるこのような取り組みも、僕らエンジニアのやりがいなのかなと思う最近です。

APPEND

まだまだ書きたいことがあるのですが、もうキリが無いのでその他トピックに関して軽く補足して終わりとします。

既存チームとの棲み分け

僕が担当しているプロダクトでは、元々はプランナーと開発が明確に分かれており、プランナーは施策を考え、開発チームがひたすら開発する、という一般的なスタイルでした。

そんな中、うちのチームと既存のチームでどう棲み分けてやっていくべきかということを考えました。

包括的に言うと、我々のチームはSoE、既存の開発チームはSoR的な思想に基づき、棲み分けすると良いのかなと感じております。

SoEとSoRについては@i2keyさんの↓のスライドが１億倍分かりやすいし造詣が深いです。

事業が対峙する現実からエンジニアリングを俯瞰する #devlove from Itsuki Kuroda

www.slideshare.net

そのような分けの中で、我々はBMLを回しながら不確実性を落としにいき、ある程度のところで大きく踏み出す施策を、既存チームにバトンタッチして開発してもらう関わり方を考えています。

プランナーとの棲み分け

「エンジニアだけでもう良いじゃん」

「もうプランナーはいらなくない？」

このようなチームをやっているとよく聞かれることです。 しかし、僕はプランナーは必要だと言うことを声を大にして言いたいです。

というのも僕らのチームでは、不確実性を落とすという側面から仮説検証を小さく踏み、結果として施策の大きさが小さくなるため、１回の施策あたりで検討することも少なく、プランナーとして求められるスキルもそこまで多い訳ではないです。（もちろん仮説の構築にあたって、目先の施策だけ見てる訳ではないですが）

一方で、前述のSoR的案チームで扱うような施策は単純に規模が大きいです。大きいというということは検討することが膨大にあります。

• マーケットをより踏まえた要件の検討
• 売上影響レベルでの効果予測
• 法務観点でのリスクチェック
• 投資決裁
• そもそも僕らよりも圧倒的にビジネスに詳しい

などなどです。これらを僕らが開発の傍らでできるとは到底思えません。 つまり取り扱う施策によって棲み分けるべきということです。

そういった理由でプランナーは必要不可欠だし、リスペクトしております。