しくじりグロースハック

はじめまして。freeeの@tetsuwadaと申します。
この記事は freee Engineers Advent Calendar 2015 15日目です。

freeeにはエンジニアの組織の中に「グロース」というチームがあります。
今日はこれまでの技術的な話しの流れと打って変わり、私がこのチームに入って１年間でやらかした数々のしくじりについて赤裸々に書いてみようと思います。

うまくいかないことを発見する

2010年頃からグロースハッカーという言葉が生まれ、今ではすっかりバズワードになってしまいましたが、そもそもグロースハックって何でしょう？freeeでは、グロースチームのミッションを次のように定義しています。

「freeeを継続して利用してくれるユーザーを増やすために、圧倒的な速さで枠にとらわれない施策を大量にリリースし改善を続けていく。それすなわち、エジソン。」

継続利用してくれるユーザーを増やすために何が必要なのか、ボトルネックは何なのかを分析し、それに対する施策を考え、実行し続けるのがグロースチームです。
ここで私達がこだわっているのはスピード感です。ユーザーに迷惑をかけない限り、いいと思った施策はすぐにリリースしてその是非を問います。施策の数が増えると失敗することも増えていきます。しかしその失敗こそが重要で、そこからの学びがあるからこその成功があります。かのエジソンは、「私は失敗したことは一度もない。うまくいかないことを発見したのだ」と言っています。まさにこれがグロースチームで最も大事にしている価値観です。なので、チームミッションはそれすなわち「エジソン」なのです。

グロースハックというとtwitterが最初に数人フォローさせることで非線形的に成長した、オバマ大統領の選挙サイトのABテストなどが有名ですが、こんな綺麗な話しばかりではありません。実際には泥臭いトライアンドエラーの繰り返しだと思います。
というわけで、なかなか普段は語られないグロースハックのしくじり（学び）をこれから紹介していきます。

こんなグロースハックは嫌だ

施策の効果をトラックできない

グロース施策を進めていく上でまず最も重要なのは結果をトラックできることです。リファクタリングにはまずテストが必要みたいな話しで、それがよかったのか悪かったのか判断する術を持たないと怖くてしょうがありませんし、トラックできなければやりっぱなしで学びもありません。

あるとき、既存の仕様を変更するにあたってその影響と効果をABテストで確認しました。そのときトラックするためのログを一つだけタイプミスしていたため、そのテストによるネガティブな影響はないことがわかったものの、どれだけの改善効果があったかはトラックできませんでした。
ではもしちゃんと改善効果をトラックできていたらどうなっていたでしょう？効果が高ければ、この変更が効くのならば別の場面で応用してはどうか、こうすれば更によくなるんじゃないか、という次の一歩が進んでいたと思います。効果が低ければ、このアプローチは今後優先順位を下げようと判断ができたはずです。
トラックできなければそこには学びが生まれず、学びがなければ成長も周囲からの理解もなくなります。私達にとって、トラックできるようにすることがいつでもまず最初にやるべきことです。

一度の失敗で諦める

昨年のこと、ある機能がどういうものなのかユーザーに伝わりづらいということで、ラベルだけを変更するABテストをしました。結果は全く有意差が出ず、その変更には価値がないと判断しました。
１年後、やっぱり去年テストした方が伝わりやすいのではないか、という話しがあがりました。昨年のテスト結果もあるので私は否定的でしたが、そっちの方がいいという強い意見を受けて再度ABテストを実施しました。すると結果は明らかに有意差のあるレベルで改善しました。

ではなぜ今回はうまくいったのか？そのラベルを表示している画面を今年フルリニューアルしていたからだと考えています。前回の画面はかなりもじもじしく、そもそもそのラベルに目がいきづらい状態でした。リニューアル後はかなり画面をシンプルにしたので、そのラベルの見え方が全く違ったのではないかと思います。そこがユーザーへの伝わりやすさにつながったのではないかと。

ここからの学びはいくつかありました。まず一つのテスト結果だけで善し悪しを決めつけないこと。何かテストを実施したとして、その結果が思わしくなかったとしても原因は他の部分にあるのかもしれません。
もう一つはこっちの方がいいと思ったら諦めずにトライすること。今回は、こっちの方が絶対いいと思うという声があってこその成果でした。こういう想いこそ大事なのだと思います。

ただ改善する

お客様にとって非常に有益な新しいサービスを始めたときのことです。それを多くの方に使って頂くにはどうすればいいかということで施策をうちました。
何をしたかというと、その申し込み数を増やすために、いかにそのサービスの魅力を伝えるかにこだわってUIを改善しました。ABテストを繰り返し、コンバージョンを上げる施策をうったわけです。たしかにそれは10〜20%の効果がありました。
しかし色々な試算をしてみると、そもそも私たちに本当に必要なのは200%の改善でした。
その目標を達成するにはそもそも何倍ものユーザーがその画面を訪れる必要があったのです。そのためにはコンバージョンよりも、より多くのユーザーが目にする場所に導線を変更する必要があったのです。

10%改善するのと200%にするのではやるべきことは異なります。なので、目標設定は施策を考える上で重要な要素であり、そこを見誤るとやるべきことを見誤ることがあります。

仮説がふわふわしてる

ある機能の利用率がユーザーの継続率と相関があると分かったとします。そうすると、その機能の利用率を上げる施策を打っていくということになるのは自然な流れです。
そのために私たちがやったことは、その機能への導線を増やすことでした。いくつかの画面にそこへの導線が追加されていきました。それを続けるとプロダクトがどのようになるか・・・なんとなく想像つきますよね。
やっかいなのは、ユーザーがそれに対してネガティブな印象を受けたとしてもそれが何かの数字には出づらいので、善し悪しの判断が難しかったりします。

大事なのは、これは「利用率が低いのはユーザーがそもそもその機能を知らないからだ」という仮説を検証しているのだという認識をしっかりと持つことです。この仮説が間違っていたらやることは導線を増やすことではありません。明確な仮説をもち、それを検証する施策をうっていくことが大切だと学びました。

リスクを避けてしまう

ある目標を達成するためにいくつかのアイデアがあったとします。効果が高いがリスクも高い、効果は小さいかもしれないがリスクはない。期待される効果とリスクでポートフォリオを組んだ場合に、まずどこから手をつけますか？
私はリスクのない施策からまず試すことを選択しました。そして大方の予想通り、それは十分な成果をもたらしませんでした。結局は効果の高い施策をうつのが遅れ、そこには機会損失が残りました。

今ではまずはリスクがあっても効果の高い施策からやること（少なくともそれをどうにかできないか考えること）が重要と考えています。そしてリスクが高い場合、そのリスクをいかに下げられるかが腕の見せ所になります。考えればやり方はでてくるものです。もしでてこなくても、まず考えるのが大切だと思います。

議論してたら日が暮れた

施策を考える際に意見が割れることは多々あります。そもそもそのアプローチは違うんじゃない？という意見の相違や、実現するまでのコストと理想との狭間でどのレベルで落としどころをつくるか難しいこともあります。その議論ばかり続いて先に進めなかったり、最終的に中途半端なところに落とし所をつくったらそれに対して結局誰も納得感がないということがありました。

スピード感を大事にするには決断のスピードを上げなければいけません。
そのために私達が実施したこととして、まずは意思決定者を施策毎に分けました。以前はチームリーダーが全ての施策の最終的な意思決定をすることが多かったですが、施策の数が増えると一人ではまわらなくなりますし、各自がリーダーシップを持てなくなるとその施策への熱意を失いかねません。なので施策毎にオーナーを立て、リーダーはどうしてもというときだけ拒否権を持つという形に変更しました。
次は課題感や施策のインパクトを整理し、チームとして共通認識を持てるようにしました。ターゲットとしているユーザーにはどういう属性があり、それぞれどんな課題を抱えていて、そのボリュームや課題の重要度などを定性/定量的に整理します。それをまとめたドキュメントがチームとして一つの共通認識としてあると、課題と提供しているソリューションにずれがないか、インパクトがどの程度でそれに対してどれだけのコストをかけるべきか自ずと決まってきます。
また、全体の施策の優先順位を2週間毎のスプリントで決めるようにしました。この場でスプリントのKPTを振り返り、次のスプリントで何を目指すのか議論します。ここで各オーナーが互いの施策の重要性を話し合い、全体の優先順位を決めます。これによって納得感と自信を持ち、かつスピーディーに施策を決めていけるようになりました。

データに翻弄される

グロースチームは基本的にデータドリブンで進めていますが、データだけを見ていると罠にはまることがあります。
データは理由までは教えてくれません。目標としているKPIに対してこのデータが強い相関があるとわかったとしても、その因果関係まで明確にわからないこともあります。例えば継続して使ってくれるユーザーは当然ログイン頻度もそれなりに高いはずで、では継続率を高めるために毎日ログインを促すメールを送ろうといった施策は本質的ではありません。
また、データは複合的な要因や、緩やかな変化に対して解を見つけるのが困難です。何か変更を加えることで、何かの数字が下がることも当然あります。しかしその下がり方が軽微だった場合はそれに気づきにくく、またいくつかの変更により緩やかに下がり続ける場合は原因の特定が困難でもっとも厄介です。

そこで重要になるのは定性的なデータです。ユーザーテストのフィードバックやユーザーからの問い合わせといった情報は大きなヒントを与えてくれます。ユーザーの声をそのまま受け入れるわけではなく、その本質的な意図を掘り下げ、それが納得いくものであれば仮にデータに現れなくても変更すべきです。

要は本質的にどうなのか？を見失わないことが重要だと思います。そもそも会計って何のためにやるんだっけ？ターゲットとしているユーザーってどんな人達で、どんな働き方をしているのか、そういった本質的な部分での考察がないと、ついデータに翻弄されてしまいがちです（何度もしてしまいました・・）

グロースハックに必要なスキルって何だろう？

グロースハックに必要なスキルは何だろう？と考えることがあります。実装スキルに加え、データ分析、マーケティング、ユーザーの理解、他チームとのコミュニケーション、経営上の数値の理解などカバーすべき分野はものすごく広いです。

ですがこのうちなにかが突出して優れていればずば抜けた成果が出せるとは限りません。むしろこういうことを実現したいというマインドセットが重要だと思います。結局のところ、こういうサービスや世界を目指したいというものがあり、そこに辿り着くための仮説検証の繰り返しです。なのでこうなりたい、そのためにはなんでもやろうというマインドが大事なのではないかと思います。

そして最も重要なのは組織力だと思います。施策を実行するのに必要なハンコの数が多ければ多いほど、スピードもモチベーションも失われていきます。
変化をすることはサポートの方々などにとって大変なことが多々あると思いますが、freeeではそれでユーザにより高い価値を提供できるのであればと支えてくれます。
変化を許容し、チームに一任してくれる組織力がfreeeの強みだと思います。

明日はついにあの男が登場！？

さぁ、明日はとうとうあの男が登場するのか？はたまたゴーストライターか！？
freeeの3分の1はこの男のコミットでできている（いた）
赤いふんどしをこよなく愛する男の中の男
freee代表取締役@dice-sasaki@github

出てこいや！