スタートアップはどのタイミングからサービスの改善プロジェクトを立上げるべきなのだろうか？

そもそも大きなサービスで改善プロジェクトを回したことがある、失敗も成功も体験した開発者、マネージャーでなければどうやってプロセスを回したらいいかも分からないかもしれない。

簗島亮次氏はデータマイニングの専門家であり、グリーでゲーム以外のプラットフォームに関するプロジェクトマネジメントを経験後、フリークアウトでDSPの入札アルゴリズム企画などに携わっている。現在はフリークアウトでの業務と並行して「ビッグデータをお金に換える」環境開発を推進するIntimate Mergerの代表取締役も務める。

本稿では彼がMOVIDA SCHOOLでスタートアップに共有した「データドリブンな」改善プロジェクトの実例とノウハウについて整理してお伝えする。

簗島亮次氏

グリーの退会ページは「改悪」で退会数を半分に減らした事例

簗島氏のレッスンで面白かったのが退会ページを活用した「天の邪鬼」な改善プロジェクトの解説だ。

彼がグリー時代に取り組んだ退会ページはハウツーサイトに方法が掲載されるほど、使いにくいもので有名だった。

しかしこれは別に偶然できたものではなく、簗島氏たちがユーザーの膨大なデータを解析し、ユーザーにとって心地よい操作感とは「徹底的に逆の」アプローチを愚直に実装した結果なのだという。こうやって「改悪」された退会ページによって退会者数は半減したのだという。

いくつかスライドをお借りしたので、簗島氏が解説したユーザーが使いにくくなる「改悪の手法」をご覧頂きたい。ちなみに私の方で「改善するための」補足もコメントで入れておいた。

改善するには：クリックさせたい情報はファーストビューに入れる

改善するには：クリックさせたい情報と並列で紛らわしい情報は並べない

改善するには：各ページで遷移した時にリンクのタイプはフォーマットを統一する

改善するには：スマートフォンにおける指でのクリックはやや下に反応する場合が多い。なので、上下ではなくリンクは左右に置くのが鉄則

改善するには：入力必須などの場合はかならずその旨を書いておく。フリーワードは入力ストレスが高いので、なるべく使わない

なるほど、逆張りすることでここまで完璧なまでの改悪ができるのかとある意味感心してしまう。さらに逆に言えば、間違ってもこのような間違いを「正しい」インターフェースに使ってはならないということだ。では、続いて簗島氏が共有してくれた、改善プロジェクトの進め方についてもお伝えしよう。

すべてを明確にすることから始まる

簗島氏はとにかくこのレクチャーの中で何度も「明確化」という言葉を使っていた。それだけ改善プロジェクトは曖昧になりやすいポイントが隠れているということでもある。簗島氏が指摘する明確化すべきポイントはまずこの三つだ。彼の言葉を紐解いてみよう。

実施施策の目的を明確化する
プロセスを明確化する
達成基準と撤退基準を明確化する

実施施策の目的を明確化する

まずはゴール設定だ。 「改善して何かを作ってみたはいいものの、何のために作ったのか、何を達成したかったのかが分からないのではゴールがいつまでたってもやってこない」と簗島氏 。これではプロジェクトは永遠に終わらない。ポイントは言葉の定義にある。

「例えば脱落したというのは最終ページに辿り着かなかった、と定義してそれを数値化する。売上とは何か。ユーザ数と課金を掛け合わせたものなのか、平均単価を購買数で掛けたものなのか」。

また達成したいKPIがシステム上に存在し、かつ改善のアクションプランに繋がる分解ができているかどうかも大切だ。

「顧客の満足度を上げようなんて話になっても実はシステムにその解析方法がなかったり、1時間の売上とかでKPIを設定しても最終売上に対する影響が微々たるものだったりする。適度な粒度での設定が必要だということだ」。

このKPIの粒度や質については獲得した会員の時期や流入経路によっても変化する。例えば簗島氏が「Twitterで呟いたら一気に登録してきたユーザーと自然に流入してきたユーザーは違うと認識すべき」と助言していたように、全てを同じKPIで判断せず、リファラを確認して検索流入でやってきてる人には「興味があるだろう」と仮定して継続率向上の方法を考えるなど、アクションプランを変える必要があるのだ。

さらに簗島氏はKPIについてはシステムで出せるようにし、余計な工数をかけないことが大切であることも付け加えていた。見落としがちなポイントだが、ここは結構重要な箇所だったりする。

プロセスを明確化する

最終の目標が決定したら改善のプロセスに落とそう。ここのポイントは責任者の設定だ。

「改善プロジェクトには意思決定のポイントが多くなる。なので責任者をつけることが必要。A/Bテストで意思決定者がいないとテスト結果を伸ばしてしまいがちになる」。

また、曖昧になりがちな改善プロジェクトに対してトップが理解を示し、リソースをアサインさせることも大切だ。

「来週何やるか決まっていないような改善プロジェクトにはリソースをちゃんとアサインしていない場合が多い。決定権のある人が改善プロジェクトを進めた方がやりやすい」。

また、責任者を明確にした上で、様々な技術を使えないといけないので、ひとりのスキルによらず、チームで取り組むことが大切とも伝えていた。この点は改善ノウハウを会社に蓄積する上でも重要なポイントになる。このノウハウが溜まる仕組みづくりについては、例えば、改善専門のプロジェクトチームを作るのではなく、1カ月で終わるような短期間のプロジェクトを細かく立上げるといった方法が有効なのだそうだ。

達成基準と撤退基準を明確化する

最後の明確化ポイントは達成と撤退の目標値だ。簗島氏によれば、いつまでにどの程度達成すればいいかという達成基準と同時に撤退基準も決めるのがコツだという。例えば1カ月後に10%と決めてそれが達成できなければやめる。数字が上がらないのに継続すると終わらなくなるのを防ぐ目的だ。

そして前述のプロセスにも関係するが、マイルストーン的に設定するオフィシャルな承認会議も重要なポイントになる。

「例えばA/Bテストをやっても誰かが決めないといけない。誰かに決めさせるとその日の気分で全部決まっていってしまう。なので一週間に一回とか、オフィシャルに改善を決定する会議を用意するべき」。

また、達成したプロジェクトの後始末も忘れがちで 「楽しくなってそのコンテンツの改善を永遠に続けてしまう」ようなトラブルもまれに発生するという。いずれにせよ、オフィシャルな承認プロセスを用意して、適切なジャッジが必要というのは理にかなっている。

さて、いかがだっただろうか。ところで冒頭にスタートアップはいつから改善プロセスに着手すべきか、という問題提起をしていたのだが、この点について簗島氏のアドバイスは「創業者の手を離れたタイミング」と表現していたのが興味深かった。つまり、サービスの規模がある程度になって創業者から次のチームに開発プロジェクトが渡る頃にこのような改善プロセスを回し始めるのが効果的、というわけだ。

このようなフェーズに差し掛かっているスタートアップのみなさんは準備を始めてみてもいいのではないだろうか。