グロースハッカー的開発手法を導入するときに気を付けるポイントを備忘の意味も含めて描きだしてみました。
なお、グロースハッカーとは、自分は常に間違えていると思い、数字にしか正解はないと考えていて、世の中は常に変化していることを意識しつつ、破壊的創造を繰り返し、サービスは複利で成長するなどと熱弁するような職種と定義します。
足し算だけ考えない
サービスを運用していると、どんどん機能を追加したくなります。
そして、機能を追加すればするだけ、PVが増えていくような気がします。
「だって機能を足したんだから、その分新しいユーザーが来るじゃないか」と考えます。
しかし間違いです。
例えば、ライバル関係にあるAサービスとBサービスについて考えてみます。
Aサービスはa,b,cの機能を持っています。そしてBサービスがa,b,c,d,e,fの機能を持っています。
このような状態のときに、Bサービスは常にAサービスに勝つでしょうか？答えは否です。
もしこれだけでBサービスが勝てるのなら、世の中のウェブサービスは皆このようにできているでしょう。
しかし実際は違います。成功しているウェブサービスはファンクショナルです。Instagramは写真だし、クックパッドはレシピです。
それはなぜかというと、Bサービスは機能がありすぎて、ユーザーにとって本当にメリットを感じるa,b,cが埋もれるためです。
林と庭園という比較ができます。
林はごちゃごちゃしているので居心地が悪い。適切に間引いてある庭園に居心地の良さを感じます。
ウェブサービスもまったく同じです。
使い方を解説文で表現するときは要注意
サービスを開発していると、機能を文章で解説したくなります。「このボタンはページをシェアするボタンです」といった具合です。
しかし、こういう場面に遭遇したら要注意、解説文は極力減らす努力をするべきです。
理由は二つ。
①解説文は一度読んだら駄文になる
解説文は１度見たユーザーにとっては、不要になります。
つまり、２度目以降に訪問したユーザーにとっては、貴重なブラウザ領域を無駄に占有する、ただの邪魔者になってしまいます。
②そもそもUIが悪い可能性
ユーザーが直感で分かるデザインがもっともすぐれています。
ユーザーにとって学習は負担です。解説文はユーザーに学習を要求しています。
分かりにくい機能を解説文で補おうとする前に、直感でわかるようにできないかよく考えるべきです。
ユニバーサルデザインは時間とともに変化していく
すべてのユーザーが直感で利用できるデザインのことをユニバーサルデザインと言います。
ユーザーに学習させたくないウェブサービスはユニバーサルデザインを目指すべきです。
注意するべき点として、ユニバーサルデザインは時間とともに常に変化しています。
これは言語が時間とともに変化していく様子に似ています。
例えば、今は歯車のマークは設定を意味するユニバーサルデザインになっています。しかし、１００年前であればまったく違った意味で用いられていたはずです。
インターネットの世界ではかなり早いペースでユニバーサルデザインが変わります。
例えば、Yahoo!全盛期の時代にはYahoo!が採用しているデザインが、その他の多くのサイトでも採用されました。Web2.0的なデザインというのも一時期の流行になりました。今だとFacebookのデザインでしょうか。
使いやすいウェブサービスであり続けるためには、インターネット全体の流行を反映させ続けなければなりません。
つまり、ウェブサービスというのは誕生した瞬間から常に変化を求められているのです。
直すことは常に正解
サービスを修正しようとすると思わぬ抵抗にあることがあります。
「これまでうまくいっていたのに変える必要はないのでは？」、「それにはこういう経緯があって・・・」、「前任者がこのように考えていたから・・・」
これらの意見は貴重な意見ですが、すべてを受け取る必要あありません。
ウェブサービスというのは常に変化し続けない限り、市場の競争に勝てなくなります。
ウェブサービスを直すことは、変化へ対応することなので、常に正しい行いです。
むしろ、ウェブサービス運用ではDNAとして、常に変化する仕組みを作るべきです。
改善したいポイントを明確にして、観測可能にする
ウェブサービスを修正するときにありがちなのが、なんとなく気に入らないから修正するという意思決定方法です。
これでは個人の主観によった修正しか行われず、グロースハックの正しいPDCAを行うことができません。また、主観であるため、その後の修正が非常にやりにくくなります。
修正は、主観によらず、改善したいポイントを明確にしてから、常に客観的に行うべきです。
また、改善したいポイントは定量目標であるべきなので、観測可能にする必要があります。
一度にすべてを解決しようとしない
ウェブサービスには常にたくさんの問題があります。
しかし、全てを１度に解決しようとすると、修正箇所が膨大になります。
膨大な修正は正確な観測を難しくするため、PDCAサイクルを回すのが困難になります。
また、リリースまでの期間も長くなり、PDCAサイクルが遅くなります。
修正は細かく、素早く行うことをお勧めします。
AかBかで迷ったら、どっちもやる
AかBかで迷ったら、どういうプロセスを取るべきでしょうか。
通常は議論を重ねてどちらかに決めてリリースをします。
グロースハックは、PDCAサイクルを高回転で回すという考え方です。
正解がないという前提に立てば、議論を重ねている時間はすべて無駄な時間です。たまたま集まったメンバー間で合意がとれたからといって、ユーザーにとってはほとんど意味がありません。
AかBかで迷った時の、グロースハッカーにとって正しいプロセスは、どちらも試して高速にPDCAを回すというプロセスです。
最後に
グロースハックとは昔から日本が得意だったKAIZENに他なりません。
細かなPDCAサイクルを高速に回すことで、リスクなく、最大の効果を得られます。
人間はチャレンジすることに喜びと興奮を感じ、リスクに胃を痛めます。
リスクなく、たくさんチャレンジできるグロースハッカーは最高に楽しい職種ではないでしょうか。
それと
エンジニア熱烈募集してます。
興味あれば個人あてにでもメッセージください。
サービスのことを考えることと、グロースを考えることが大好きです。 どんどん世の中が便利になってうれしいです。 どうぞよろしくお願いします。
