グロースハッカーの十戒
こんにちは。Web エンジニアの kakihara です。
この記事は『LITALICO Engineers Advent Calendar 2020』の 14 日目の記事です。
はじめに
この一年間はひたすら、現在携わっている Web サービスのグロースハックに取り組んできました。もう少し具体的に言うと、自サービスのユーザー最大化をミッションとして、検索機能やチャットボットといった新機能開発から、マーケターがやるような SEO 対策や細かいボタンの AB テストまで本当に様々なことに取り組んできました。
その結果、プロダクトの KPI として設定している指標をサービスの歴史史上最大の成長率でグロースさせることに成功しました。
しかしその過程は失敗の連続でした。私自身の一年の振り返りとして、そしてプロダクトのグロースに関わる全てのグロースハッカーに向けて私の学びを「グロースハッカーの十戒」という形にまとめて共有したいと思います。
この記事の前提
私の行っていたグロースハックは 3 ~ 5 人のチームで取り組んでいました。事業戦略からブレイクダウンしてマーケティング戦略を立て施策を立案するディレクター、ディレクターの施策アイデアを具体化して UIUX に落とし込むデザイナーがそれぞれ 1 人ずつ、そのデザイナーが具体化した施策を開発・実装するエンジニアが 1 ~ 3 人という構成です。
私の役割はそのエンジニアチームのリード、またディレクターが他のプロジェクトとの兼務だったので彼がこちらのプロジェクトに入れないときは代わりに施策の立案も行うという役回りでした。なので今回の十戒もそのような人間の視点からまとめたものになります。
因みに、同じチームで働いているこのデザイナーも同じプロジェクトについて記事にしているのでよければ併せて読んでいただけると幸いです。
この記事の活用方法
これから述べる十戒を犯していないかをプロジェクトが上手くいっているかの健康診断として、定性的な振り返りのきっかけとして使っていただければと思います。
グロースハッカーに取っての定量的な振り返りは、プロダクトの KGI・KPI がしっかり伸びているのかという数値の観測によってなされるため、経験の有無に関わらず一定のロジカルシンキングの力があればある程度行うことができます。
しかし定性的に見て「今のプロジェクトは良い状態なのか」「さらに成長スピードを上げていけないのか」という振り返りは一定経験がないと分からないことが多いため、その材料としていただけると幸いです。
私自身もグロースハックに取り組んで歴が長い訳ではありませんが、この辺がまとまった記事等は意外に少なく私自身も苦労したため、私のようなペーペーがまとめたものでも一定価値があると思い、恥を忍んで書いていければと思います。
グロースハッカーの十戒
1. 細かい AB テストに逃げてはならない
たとえば「月間の新規会員登録数を 2 倍にして欲しい」というようなオーダーを受けたとします。こういったときにやってしまいがちな失敗が「細かい AB テストをひたすらする」ということです。
「ここの文言を 3 パターン用意して検証しよう」「ここのボタンの色の変更を次は試してみよう」などの施策は、プランニングにそれほど時間も掛からない上にやれば数値も少しは伸びるため、数値を伸ばそうとしている人間に取って真っ先に飛びつきたくなる施策です。
しかし、まず最初に考えるべきなのは目標から逆算して数値シミュレーションを行いながら「あるべき会員登録の体験はどんなもので何種類あるのか」「それらの体験全てがサイト上で実現できているのか」「現状ない体験はどのようなページを作っていくことで実現していくべきなのか」という体験・ページの設計を行うことです。
会員獲得のためにひたすら LPO をやっているが、それよりも SEO 対策してオーガニックからの会員獲得にリソースを割いた方がインパクトが出るのではないか。
顕在層へ広告を打つより、潜在層へのコンテンツマーケティングを強化する方が KGI にヒットするのではないか。
目先の改善ポイントだけに目を向けるのではなく、こういった「あるべきなのにまだない体験」「まだまだ磨き込みが足りていない体験」という切り口から、伸び代の大きい改善ポイントを見つけにいった方が大きな成果が得られることが多いです。
また細かい AB テストはその上段のページ設計が甘いと全て無駄になります。
たとえば問い合わせフォームを改善するために必死にボタンの色や位置などを AB テストで改善したが、「今は縦に長いフォームを使っているがウィザード形式に変えた方が良い」みたいな結論が出てしまうと、新しいウィザード形式のフォームで再度細かい AB テストをやり直さなければなりません。
細かい AB テストでの磨き込みは最後の最後に行うようにしましょう。
2. 機能を作ることが目的になってはならない
グロースハッカーの成果は「KPI をどれだけ上昇させられたか」です。そして「KPI の上昇数 = 一施策当たりの KPI 上昇数 × 施策リリース数」となります。
いくらディレクターが筋の良い施策を考えてデザイナーが素晴らしいプロトタイプを作っても、エンジニアがそれを実装してリリースできなければ KPI には何もヒットしません。
やってしまいがちなのが、機能を作ることが目的となって機能を作り込んでしまいエンジニアチームのリソースを食い潰して施策リリース数が少なくなってしまうというものです。
たとえば「コンテンツマーケティングで作成している記事の検索機能を作って会員登録数増加に寄与するか検証しよう」となったとします。このとき、そもそも検索機能自体にそれほどニーズがなければ会員が増えるはずもないので、まずはどれほど検索機能が使われるかを検証する必要があります。
その検証であれば、ちゃんとした検索機能を作らなくてもいくつかの記事にタグを設定しておいて「タグ絞り込み機能」みたいなものを簡易的に作ってどれだけ使われたか確認するだけで検証の目的は果たされると思います。
しかしこの目的がいつしか「記事検索機能を作る」にすり替わってしまい「記事カテゴリ・タグ・フリーワードで検索できるようにする」みたいな割と大きな機能を作り込んでしまう、そのせいで他の改善施策がほとんど打てていない、しかもこの検索機能も結果全く使われていないというようなことは気をつけないと頻繁に起きます。
目的に対して必要十分な機能（MVP）を作るということを意識しましょう。
3. KPI にヒットしないところを雑に作ってはならない
上記にもちらっと書きましたが、目的に対して必要十分なプロダクト・機能を「リーン・スタートアップ」では MVP（= Minimum Viable Product）と呼びます。
この MVP という言葉は有名で知っている人が多いのですが、これを「初期リリースでは雑に作って良い」と曲解してしまっている人が多いです。
MVP という考えを都合良く解釈して、私自身もエンジニアとしてよく「ここ実装面倒だな。今回の検証ではここまで作り込まなくてもそんなに数値変わらないから最悪やらなくても良いよな。」という誘惑に駆られるのですが、仮説の検証のために必要十分な仕様であると判断された機能はしっかり細部まで作り込むべきです。
特に KPI にそれ単体ではヒットしない細かいレイアウトやアニメーションなどは初期リリースの段階で極限までクオリティを高めるべきです。KPI にヒットするコンバージョンボタンなどは最後の仕上げとしての細かい AB テストをいつか必ず行うので今後改善するタイミングがありますが、KPI に直接ヒットしない細部は初期リリースで作り込まなかったらもう二度とこれからクオリティを上げるタイミングは訪れません。
こういった細かいところを雑に作り続けると、プロダクト全体を通して見たときにチリが積もってどこか陳腐に見えてしまいます。数値にヒットしない細かい部分もしっかり作りましょう。
4. トライアンドエラーを繰り返してはならない
失敗を許容する文化はとても良い文化だと思っています。しかし「この改善施策は当たるかどうか分からないけどやってみましょう。数値が変わらなかったり下がったりしたらこの変更は取り下げましょう。」という施策が連発しているときには「もっと確実に数値を伸ばせる改善ポイントが他にあるのではないか」と疑うべきです。
「2. 機能を作ることが目的になってはならない」で述べた通り、「KPI の上昇数 = 一施策当たりの KPI 上昇数 × 施策リリース数」です。施策リリース数だけを考えるのではなく、筋の良い施策をチームとしては生み出し続けなければなりません。
プロダクトのフェーズにもよるのだとは思いますが、「ここの改善は絶対にやった方が良いでしょ。やれば必ず KPI にヒットするでしょ。」という箇所は必ずあります。KGI・KPI を上昇させることを目的として最も費用対効果の高い、不確実性の低い箇所を見極めたいです。
また、試して数値が変わらなかったり減少したりしたときも、その原因をちゃんと言語化して何かしらの学びを意地でも見つけるべきです。こういった学びをチーム内に蓄積していき他の施策に応用していくことで、「この施策はほぼ確実に数値の改善に繋がる」と企画の段階で自信を持てるような施策を生み出せる確率が上がります。
トライアンドエラーでどんどん試している状態は、何も行動しないよりはマシですがベストな状態ではありません。トライアンドサクセスし続けている状態を目指すようにしましょう。
5. エンジニアに楽に仕事をさせてはならない
ディレクター・デザイナーが具体化した施策をエンジニアが特にプレッシャーも感じずに自分たちのペースで実装する、という状態はエンジニアにとっては楽な状態です。しかし成果をあげるためには、エンジニアは「自分たちは今楽な状態である」と認識したらすぐにディレクターにアラートを上げるべきです。
トライアンドサクセスし続けるチームは企画の筋が良く、「この施策はほぼ確実に数値の改善に繋がる」と企画の段階で自信を持てるような施策がどんどん生み出されます。そして企画・デザイン・実装のフェーズの中で最も時間が掛かるのがエンジニアが担当する実装のため、エンジニアが施策の実装が完了する前に次から次へと見込み効果の高い施策が生まれて滞留していきます。
こうなってくると「あとはエンジニアが実装さえしてくれればプロダクトがかなり改善されるのに」という思いがディレクターやデザイナーに生まれてきます。これはエンジニアにとっては結構なプレッシャーです。
しかしこの状態こそが最も成果が出やすい状態です。プレッシャーを受けたからといって開発スピードが上がる訳ではないので、エンジニアはディレクターが「これはいける」と思っている施策リストの中から、その中でも見込み効果が特に大きい極上の上澄みの施策のみを選択して実装・リリースしていくことになります。こうなると今までとは「一施策当たりの KPI 上昇数」が桁違いに大きくなって成果をあげられるようになります。つまりエンジニアがプレッシャーを感じるのは良い企画がどんどん生まれている証拠です。そのためプレッシャーを特に感じない場合はエンジニアの方からディレクターに「この施策で本当に成果が出るのか」「施策リストは十分にストックできているのか」としっかり詰めに行くべきです。
6. メンテ系タスクだけをやる期間を作ってはならない
スピード感を持って開発を進めてどんどん機能をリリースしていくと、リファクタリングしないとまずい箇所が多くなってきたり、早くリリースするためにライブラリを多く入れたためにその更新作業が入ってきたりして、やるべきメンテ系のタスクも積み上がっていきます。
こうなってくるとエンジニアとしては「一旦改善施策はストップしてコードを整理したい」という欲に駆られます。こういったメンテ系タスクは絶対にやらないといけないのですがやり方に工夫が必要です。
「今週来週の 2 週間は改善施策はストップしてメンテ系タスクのみを行います」といったことはやるべきではないです。これをやってしまうと改善施策が打てない期間が続いてしまい、定量的にプロジェクトの状況を振り返ったときに「今月は KPI が横ばいでした。しかしメンテ系タスクを行わなければならなかったのでこれはしょうがないことです。」というプロジェクトの目的の KPI 改善がなされていない不健全な状況にも関わらず、それをチーム内で正当化してしまうようになってしまいます。こういったことが続くと成果への拘りがどんどん薄れていき弱いチームに成り下がってしまいます。
こういった場合にエンジニアは、「メンテを入れたい機能・ページについての KPI にもヒットする改善施策を考えて提案する」と良いです。たとえば何かしらのフリーワード検索機能のリファクタリングを行いたいのであれば、「フリーワード検索の検索ロジックを変更し、関連のあるより多くのコンテンツをヒットするようにしてユーザーの離脱を防ぐ。」というような施策を提案して、その実装段階で既存のコードの書き直しも同時に行うようにします。
それが難しい場合は 1 週間のうちのこの時間はメンテ系タスクに当てるという日を作ってその時間で行うのも良い選択です。施策がリリースできない期間が発生するよりかなりマシです。それでも対応できないような重たいメンテ系タスクは別プロジェクトとして切り出してしまった方が良いでしょう。
7. KPI にヒットしない改善はなるべく行なってはならない
上で書いた通り、数値への拘りが薄れてしまうとチームとして弱くなり成果が出しにくくなります。これが理由で「KPI にはヒットしないがやった方が良い改善」みたいなものも極力行うべきではないです。「今月は KPI は伸びませんでしたが改善は行いました」という成果が出てないことを正当化する空気が生まれてしまいます。
「KPI にはヒットしないがやった方が良い改善」には大きく分けて 2 つあるかと思います。
1 つ目は、あれば便利だが KPI にどうヒットするのかのロジックが見えにくい類の機能開発です。たとえば「コンテンツマーケティングで作っている記事の検索機能」などは直接的に KPI にヒットするかどうかは分かりにくく難しいところです。こういった機能開発の企画時には以下のように考えると良いです。
ユーザーにとって本当にあれば便利なのであれば KPI には必ずヒットする。どうヒットするのか分からないのは「この機能を開発することでどう KPI にヒットするのか（どのようにユーザーに価値を与えマネタイズするのか）のロジックが描けていないだけ」である。
つまり「1. 細かい AB テストに逃げてはならない」で述べた体験・ページの設計がまだちゃんとできていないという証拠なので、デザイナーがデザインを始める前にディレクターがもう少し考える必要があります。
2 つ目は、細かい UI パーツやアニメーションなどの細部の部分です。これについては「3. KPI にヒットしないところを雑に作ってはならない」で述べた通り磨き込む時間はないので初期リリースの段階で作り込んでおくべきです。ただ積み残しが発生してしまった場合はしょうがないので、メンテ系タスクのように週にいくらか時間をとって、施策を止めない中で改善を行なっていくしかないかと思います。
8. 数値の変化の理由を時期要因と言ってはならない
グロースハッカーとして、現状の KPI がどうなっているか・どう変化しているかは毎日ウォッチしておくべきです。毎日見ていると特に何もしていないのに数値が伸びたり落ちたりすることがあります。こういった変化を「これは時期要因による変化です」とは極力言わないようにしましょう。
数値が上がったのであれば、何故上がったのか、それが分からなくても具体的にどこの数値が上がって KPI が上昇したのかはしっかり押さえておく必要があります。あるページの価値訴求がその時期にサイトに訪れたユーザーに刺さっているのかもしれません。それであれば時期によってサイトに訪れているユーザーの属性が異なっているということなので、その価値訴求を時期によってカスタマイズしていけば KPI を改善することができます。
逆に数値が落ちている場合も同様です。「平日に比べて休日にコンバージョン数が少ないのはしょうがない」「お盆に数値は毎年下がります」などで済ませずに「休日にコンバージョン数が下がるのは具体的にどういう理由なのか。平日並み・あるいは平日以上のコンバージョン数を叩き出せないのか。」「お盆にサイトに来訪しているユーザーはそれ以外のユーザーと比較して属性が異なるのではないか。長期休み中のユーザーに刺さる訴求方法はないのか。」と考えると今まで思いつかなかった施策が生まれることが多いです。
時期要因と考えてしまっているときは思考停止してしまっている合図です。数値の変化の要因を分析して成果に繋げられるようにしましょう。
9. たくさんの仲間と取り組んではならない
私などが言うまでのことではなく、各所で言われていることではありますが、グロースハックはスモールチームで行うべきです。これは物理的な人数を制限するというより「大胆な仮説をスピード感を持って検証ができているか。現状のチーム体制はやりたいことに対してベストな布陣か。」を確認するという意味合いの方が近いかと思います。
特に企画・デザインは組織でもエース級の人間が少人数で行うべきです。何度も言うように「KPI の上昇数 = 一施策当たりの KPI 上昇数 × 施策リリース数」です。施策リリース数はエンジニアの数を増やしていくことで増やすことができますが、「一施策当たりの KPI 上昇数」はディレクター・デザイナーの数が増えるほど下がっていく傾向にあります。人数が増えるとどうしても仮説はありきたりなものになっていき、デザインも思い切ったものを試しにくくなっていきます。なるべくチームメンバーの数は企画系に近い人程絞っていくべきです。
ただしこれはプロダクト開発系の職種だけで内輪で進めるべきというわけではありません。ユーザーに価値を与えるためにプロダクトを作っているので、ユーザー目線で意見をくれる方からのフィードバックは積極的にもらうべきです。
ユーザーインタビューを実施したり、toB 向けサービスであればユーザーと日々接している営業やカスタマーサクセスからプロダクトに関する意見をもらったりするとプロダクト開発系の職種だけでは気付けなかった改善施策を思いつけることが多くあります。
10. 自分を追い込みすぎてはならない
グロースハッカーは成果責任を負い、思考量行動量共にかなり求められるため、精神的にも肉体的にもそれなりのプレッシャーが掛かります。人によってはこのプレッシャーは押しつぶされかねない程に大きなものです。このプレッシャーに押しつぶされることなく、楽しんで仕事をするというのが一番だと思います。
私自身も大変な時期もありましたが、今ではプロダクトのグロースハックという仕事はとても面白い仕事だと思っています。今までグロースハックの他にも、完全新規のサービス開発プロジェクトにもジョインしたことがありますが、圧倒的にグロースハックの方が面白いです。
新規開発は当然リリースされていないサービスなのでユーザーにとって良いというより、どちらかと言うと PM が良いと思ったものを作ることになりがちです。しかし、既に存在するプロダクトのグロースハックはマーケットに出して試せるため、本当にユーザーにとって良い機能を作っているという実感があります。ユーザーに受け入れられないと数値は変わらなかったり如実に減少したりしますが、ユーザーに受け入れられると数値が目に見えて大きく上昇します。自分たちの立てた仮説がドンピシャで当たった時には何とも言えない高揚感があります。
しかし残念ながら最近学生さんと面接等で話すことが多いのですが、新規サービス開発の方に興味を持っている方が多いです。私は毎回そんな学生さんを見つけると、グロースハックの面白さを話す老害になります（笑）。
やりがいは何でも良くて人によって異なって良いと思いますが、グロースハックに対して自分なりのやりがいを見つけて楽しめると、グロースハッカーとしてとても良い状態だと思っています。
終わりに
「十戒」という形でまとめましたが、全て私がやってしまった失敗を振り返ってまとめたものです。気付いたらこの中の十戒を犯していたということは今でもよくあります。ただ、「今は良い状態ではない」ということに自分で気付けるようになったのは大きな成長だと感じています。自分で状況を改善していくことが少しずつできるようになってきました。
これからもこれらの十戒を胸に刻んで、またこの十戒もアップデートしていきながらグロースハックに従事していきたいと思います。最後まで読んでくださった方々、どうもありがとうございました。
明日は @GengroHirano さんの記事です。お楽しみに！
この記事が気に入ったらサポートをしてみませんか？