logo-img-townwork (1)

こんにちは、タウンワーク開発チームの武藤です。

こちらの記事でも書いた通り、現在はタウンワークネットの開発ディレクターとして働いています。タウンワークの開発チームは現在4つのチームに分かれていて、その中でも私が所属するフロントチームでは、A/Bテストを軸としたUI改善、グロースハックをミッションとしています。
今回はタウンワーク流グロースハックのススメとして、主に運用フローやチームビルディングの観点からフロントチームで取り組んでいることを少しでも紹介できればと思います。

全体の流れ

全体の流れは下図の通りです。

Pasted image at 2015_12_01 01_41 PM

スクラム開発の手法を採用し、2週間スプリントでテスト案件の実装とモニタリングを継続的に行っています。
1スプリント内で行われるイベント(スクラムではセレモニーと呼ばれています)は主に下記の通りです。

スプリントプランニング

次回スプリントで行う案件のインプット、開発工数の見積りをチーム全員で行います。案件の規模にもよりますが、1スプリントあたりの案件数は平均して4~5くらいです。

バックログ・グルーミング

主に新規起票案件の確認と、次回行うテスト案件の優先順位付けを行います。こちらもチーム全員で議論しながら進めていきます。後ほど説明しますが、エンジニア・プランナー・デザイナーのロールを超えて、誰でも思いついたアイデア、検証したい仮説を自由に書いてストックできるようにしています。A/Bテストをがりがり進めていくと徐々に検証するネタがなくなっていき、案件が枯渇することはよく出る話だと思いますが、そのようなことを解消する為に、他社の事例や、ユーザーテスト・ユーザーインタビューの結果を参考にして、案件出しを行っています。

スプリントレビュー

スプリント中に開発した案件がリリース可能かどうかをジャッジします。テストパターン別にUI上の問題がないかを確認するのはもちろんですが、A/Bテストという特性上、計測用のログが正常に出力されているか等もこのタイミングで丁寧に確認します。

スプリントレトロスペクティブ

スプリント期間中によかったこと/悪かったことをKPTを用いて振り返っています。

効果確認会

案件ごとのモニタリング結果をチーム内で振り返り、結果から次の打ち手を考える場として使っています。効果が良かった案件は、「他の画面やデバイスを跨いで横展開できないか」、効果が良くなかった案件は、「なぜ良くなかったか」を言語化して、「じゃあ次はここを改善してもう一回テストしよう」といったことを議論しています。また、A/Bテストの結果は後々振り返られるように全てQiita Teamにまとめています。(画像1、2を参照)

Pasted image at 2015_12_07 03_46 PM
画像1: A/Bテスト関連のプロジェクトページを作り、知見は全てここに集約しています

Pasted image at 2015_12_07 03_46 PM-1
画像2: 案件概要・画面キャプチャー・テストの結果を案件ごとに共有しています

意識しているのは、スクラムが目的にならないようにすることです。スクラムはあくまでも開発を円滑に進めるための手段なので、チームや環境に合わせて臨機応変に対応していくことが大事だと思っています。

高速でA/Bテストを回し改善につなげるためには?

チームはなるべく少人数で

当前のことですが、チームが大人数になればなるほど全体のスピード感は遅くなりがちです。グロースハックを成功させるためには、効果検証のサイクルをいかに早く回せるかが重要になってくるので、タウンワークではグロースハックを行うチームと工数が大きい機能開発を行うチームを分けています。フロントチームの構成は、プロダクトオーナー兼プランナー1名、プランナー1名、エンジニア3名(専属)、デザイナー1名(兼任)の合計6名体制になります。

現場で意志決定できるようにする

タウンワークの開発チームでは、基本的に各チームのプロダクトオーナーが意志決定権を持っているので、テスト実行までに無駄な時間がかかりません。
これが、テスト実施の度に上司への確認作業が発生してしまうような組織構造だと、その分スピードは落ち、実施できるテストの数が減ってしまいます。

エンジニア・デザイナーといった役職の垣根をなくす

上記でも紹介しているように、いわゆる「プランナーが案件を考えて、エンジニアが実装する」といったような役職による分業体制は敷いていません。思いついたアイデアがあったら誰でも起票することができるし、要件を具体的に詰める際も、チーム内で「こうした方がいいんじゃない?」「こっちの方がいいと思うよ」などと議論しながら進めており、最近ではエンジニア起案の案件もどんどん増えています。ゆくゆくは、状況に応じてエンジニアがプランナー業務も、プランナーがエンジニア業務も行うといった、クロスファンクショナルなチームを目指していきたいと思っています。

最後に

いかがだったでしょうか?
グロースハックやA/Bテストというと、「ボタンの色を赤にしたらクリック率が◯◯%改善した!」といったような事例やテクニックがどうしても注目されがちですが、大事なのはそのようなテストができるための仕組みだったり、組織体制やマインドの醸成だったりします。タウンワークでは、今年からグロースハックを行うチームを新しく立ち上げ、高速でA/Bテストを回す体制に移行することで、年間で実に150回近くのA/Bテストを実施し、成果につなげることができました。
次回以降はA/Bテストを行う上で注意するポイントやそこで得られた知見等も紹介できればと思います。

筆者プロフィール

AAEAAQAAAAAAAAKjAAAAJDQxNjRhYjU3LWNjOTEtNDYwZS05ZDFmLTgwYTJiOTRiYjExYw

武藤 尚也(むとう なおや)

株式会社リクルートジョブズ IT戦略室 カスタマウェブ開発部 カスタマウェブ開発1グループ
2014年4月にリクルートホールディングスに新卒入社。同年7月にリクルートジョブズに出向になり、A/Bテストを軸としたWebサイトのリーン開発、グロースハック、IA/UI設計に従事。