「Speee Cafe Meetup #3」レポート!

f:id:mogmog2:20161129184458j:plain 開発基盤部エンジニアの森岡です。

本記事では、11/17(木)に 弊社 SpeeeのLoungeで開催された、 第3回 Speee Cafe Meetup の様子について レポートさせて頂きます!

第3回 Speee Cafe Meetupのテーマは「基盤開発における各社の取り組み」です。 株式会社オールアバウトの大原和人さん、GMOペパボ株式会社のけんちゃんくんさん、 株式会社ドリコムからさっちゃんさん、Speeeからは森岡が発表しました。 f:id:mogmog2:20161129184554j:plain

クラウド&コンテナ活用でDevOpsを加速させる

オールアバウト 大原和人さんの発表です。

オールアバウトではエンジニアが増えてきて、開発効率が上がりにくい状態になっていました。 そのため、サービス拡大のために、開発効率を上げる方法が求められました。 アプリ開発とインフラ部門間との調整にコストが掛かっていたので、技術基盤Gを作ったというお話でした。

技術基盤Gが選んだのは、GCP移行。 GCP移行したことによって、構成&デプロイがシンプルになって、 運用コストが下がったとのこと。

感想

AWSのECSとかもあるけれど...というお話をしましたが、 log周りの取扱いの楽さと、料金面といったところから、 GCPにしたというお話でした。 まさしく、僕たちが今取り組んでいる内容でしたので、 すごく興味深く聞かせて頂きました。

技術基盤チームでの2年間とこれから

GMOペパボから、けんちゃんくんさんの発表です。 「いいじゃん」「いい感じに」「バーンと」やることが基盤チームのお仕事というお話が面白い。 (詳細は発表資料を参照下さい)
新しい事業部を立ち上げるにあたって、技術的に難しい場所に、基盤チームが先回りで対処してたというお話。

その後、お話がチーフテクニカルリードの話に移ります。 チームが大きくなっていくにあたって、事業部固有の問題は、 事業部内で解決するための仕組みが必要となり、チーフテクニカルリードの必要性がでてきた。 チーフテクニカルリードとしては、エンジニアの目標面談をしたり、 re:dashなどの新しいツール導入を進めていくなどしているとのこと。

感想

大きな組織だからこそ発生する、エンジニアの課題についてお話された印象でした。 やはりエンジニアが増えてくると、小さい単位でチームをマネジメント・リードする チーフテクニカルリードみたいな役割が必要なんだろうなと。 とても勉強になるお話でした。

Speeeで採用した監視ツールの選定プロセス

3番めは、Speeeより森岡がお話させて頂きました。 エラー、リソース監視について、Speeeにて行った選定プロセスについて お話させて頂きました。

Serverless Frameworkを本番環境に投入するために

ドリコムから、新卒2年目のさっちゃんさんの発表でした。 サーバレスフレームワークと、それに関する周辺知識に関して すごく分かりやすく解説されていました。

感想

すごく良くまとまった発表で、大学の講義を聞いているような気分になりました。 お金を払っても見たくなるクオリティでしたので、2回目があればぜひ聞きに行きたいです!

まとめ

f:id:mogmog2:20161129184433j:plain いかがでしたでしょうか?

今回の Speee Cafe Meetupでは、各社様々なステージにある会社が集まって発表を行いました。 会社の規模やステージごとの基盤チームのあり方など、同じ会社がまったくなかったので、 参加された方は全て異なるお話が聞けたのでは無いかなと思います。

Speeeでは今後も、このようなイベントを開催していきます. 次回イベントの参加をお待ちしております!!

https://speee.connpass.com/

【第4回】高速A/Bテストドリブンな改善フロー(ディレクター編)

こんにちは、ディレクターのcultivaです!

最初に

この記事は連載です。今回はディレクター編!
以前の記事についてはこちら

【第1回】高速A/Bテストドリブンな改善フローでわずか5週でCVRを29%上げた話
【第2回】高速A/Bテストドリブンな改善フローの考え方と施策
【第3回】高速A/Bテストドリブンな改善フローでわずか5週でCVRを29%上げた話(開発編)

この記事で扱う話

technica-blog.jp

上の記事で書きましたが、
私達のチームは高速A/Bテストドリブンな改善フローを回していくにあたって、
下記のような考え方で進めたことをお伝えしました。

  • 速度!速度!速度!
  • 3打数1安打ではなく、300打数30安打
  • 1つずつ検証するようにした
  • 仮説と考察を施策毎にきちんと書くようにした

この記事では上記を受けてディレクター側が、
この取り組みをチームで回していくために
どんな運用や工夫を行ったのかについて話したいと思います。

1、チームの方向性をすりあわせる

高速A/Bテストドリブンな改善フローを回す中で
試したい施策or試すことができる施策は無限にあります。

以前からもチームの個々がサービスを成長させるために
よかれと思って考えた行動できていましたが、
実際には、全体視点では微妙にズレていて、非効率になってしまったところがありました。

そこで、今回の新しい取り組みの中で
素早く、効率よく、検証を進めて改善フローを回していくためには、
チームの方向性を高い精度で一致させていく必要がありました。

そこで、

  • サービスをどんな方向性に持って行きたいのか
  • 直近ではどのページのどの指標を改善したいのか
  • どんな順番で改善を進めていきたいのか

をチームに対して示して、
その方向性に向かって、チーム運営を行いました。

大枠としては、下記のような内容です。

i) サービスの長期ゴール
→■■■の市場でNo1になる

ii) そこから落ちてくるサービスの中期・短期ゴール
→既存のサービスに加えて、新しいサービスでマネタイズしつつ、□□□と△△△を増加させる
→新サービスでのスムーズな立ち上げのためには、
→既存サービスについては○○○程度のポジショニングまでは到達しておくべき

iii) そのために、直近でサービス側で達成するべき目標を示す。
→具体的には月間の訪問数がxxxぐらい、CV数が●●●ぐらい

iv) そのKPIを達成するためには…
→ページAの指標αという指標を△△△から◎◎◎まで改善する必要がある

2、改善注力ポイントに対して施策を出す

『300打数30安打』のような
大量、かつ、ある程度精度があり、
しかもサイトの本質的な価値の向上に結びつく
テストを行うためには

  • アイデアの総数を確保する
  • アイデアを検証していく優先順を決める
  • 実装順をわかりやすくする

を行っていく必要があります。

そのために、私達のチームでは
まず、アイデアの総数を確保するために、
チームメンバーであれば誰でも書き込み可能なスプレッドシートを準備し、
そこにアイデアを書き込んでもらうようにしました。

■アイデア記入シート

f:id:mogmog2:20161115132438p:plain 次に、集まったアイデアに対しては
ディレクターが
仮説の強度/期待効果/開発工数の観点から
『検証するかしないか』
『どの順番で検証するか』を判断します。

更にそれらを開発順番に並び替えることで、
最終的には
『とにかくリストの上にある施策内容から実装して試す』
という運用にしました。

■施策リスト

f:id:mogmog2:20161115132441p:plain

3、1つずつ検証する

検証するとなると、一度に多くの内容を検証したくなりますが、
それだと、『結局、何がよかったのか』がわかりづらくなってしまいます。

しかし、1つずつ検証するとなると、
検証回数が増え、それらの管理や共有のコストが高くなります。

そこで下記のような施策が必要になります。

  • 何が改善に結びついて、何が改善に結びつかなかったのかを整理する
  • 検証している内容に関する数字がわかりやすいところに表示されている

私達のチームでは、
splitを使った管理画面をエンジニアに開発してもらい、
その数字を見ながら検定を行って検証を行いました。

■splitを使った管理画面で数値管理

f:id:mogmog2:20161115144737p:plain

■検定結果を確認して送客率の差分が統計的に有意な差分かどうかを検定

f:id:mogmog2:20161115132502p:plain

4、仮説と考察を施策毎に振り返って、チームに共有して、考察を残す

第2回の記事でも触れた

300打数30安打→30回改善+270学習

こちらの考え方を実際にチームで実現していくためには、

  • サービスの中長期的なゴール
  • そのために今達成するべきこと
  • KPIとKPIを達成するためには何を改善していけばよいのか
  • なぜそのKPIが重要なのか
    という前提となる部分を整理した上で、

実際の運用レベルでは
- 各施策について仮説を立てる
- 結果についてチームに共有する - チームメンバーの各人から考察を集める

というサイクルをチームで回していく必要があります。

それを行っていくために
私達のチームでは専用チャンネルや週次MTGの場を通じて、
施策結果の共有や議論を行いました。

■Slack上での様子(#専用チャンネルにて)

f:id:mogmog2:20161115132459p:plain f:id:mogmog2:20161115144917p:plain

Slackのチャンネルは速報性と対話性に優れているので、
とにかくいち早く結果を伝えつつ、
そのままチームで考察したり、次の施策を考える上ではよい場だったと思います。

■週次MTG資料

f:id:mogmog2:20161115132446p:plain 一方、週次MTGではいくつかの施策を横断的に振り返りつつ、
じっくり考察を深めていくための場として活用しました。
この場を設けることで、Slackで瞬発的に盛り上がるだけではなく、
別の角度から施策を振り返ることができたと思います。

チームに起きた変化について。

あと、追加して、今回の高速A/Bテストドリブンな改善フローの前後での
チームの定性面の変化についてまとめておきます。

変化前 変化後
改善アイデアを出す人 ほぼディレクターだけ チーム全員
アイデアを出す難易度 難しい。アイデアは出したいけど、何に対して出せばよいのかわからない 簡単。どのページのどの指標を改善したいのか明確
チームマインド これ本当に効果あるの?とにかく調査だ!! 有力そうな仮説なら、後はとにかく試してみよう!
検証とそこからの学び きちんと検証しない→学ばない きちんと検証する→改善しなかった施策からも学ぶ

なお、若干、個人的な所感としては、
『チームマインド:これ本当に効果あるの?とにかく調査だ!!→有力そうな仮説なら、後はとにかく試してみよう!』
という部分がけっこう大事、かつ、その後の開発にも大いに活きた変化だったと思っています。

今回の高速A/Bテストドリブンな改善が一段落した後に、
次の開発や検証を行ったりしていっていますが。
その際にも『有力そうな仮説なら、後はとにかく試してみよう!』というスタンスで比較的スムーズに進められていると思います。

そして、前提となる部分である、
『サービスの中長期的なゴール』
『そのために今達成するべきこと』
を最初にチームで共通認識をとれたことが大きいと思います。

正直、上の部分を整理するのは非常に大変だったのですが、
これらを整理しておかないと後で崩れていたかもしれないので、やっておいてよかったと感じました。

最後に

高速A/Bテストドリブンな改善フロー、というと
『xxを変えたらCTRが◯◯%向上』ですとか、
『△△を変えたらCVRが■■%向上』のような各論的な施策の話になりがちです。

そこで、今回の一連の連載では、
もうすこし上段から
『チームとして継続的に数値を改善していくためには、
どのようなスタンス・マインド・仕組みを行っていくべきか』
を中心に紹介をさせていただきました。

今回の連載を読んでいただいて、
読者の皆様の各チームが『高速A/Bテストドリブンな改善フロー』を実践していく際には 各論的な施策レベルではなく、
『スタンス・マインド・仕組み』の部分を是非各チームに取り入れていただければと思います。

連載は以上となります!ここまでお読みいただき、ありがとうございました。

【第3回】高速A/Bテストドリブンな改善フローでわずか5週でCVRを29%上げた話(開発編)

はじめに

こんにちは takanamitoです。
この記事は連載です。今回は開発編だよ!
以前の記事についてはこちら
technica-blog.jp technica-blog.jp この記事では、
『エンジニアが高速A/Bテストをどう実現したのか』
を書きたいと思います。

高速A/Bテストのためにリリースissue数を80%・回数を47%増加させた

変化量(%)
平均消化issue数 80%↑
平均リリース回数/週 47%↑

今回の一連の『高速A/Bテストドリブンな改善フロー』を始めてから、リリース項目とその回数を増やしました。
この数の増加は単純に何か良さそうな変化ですが、チームとしては明確に意図があって起こした変化です。
これは第1回の記事にもあるように

  • 「改善率よりも改善数」を優先した
  • 「成功した施策からも失敗した施策からも何かを学び取る」ため

こういった理由で起こした変化でした。

エンジニアがプロダクトに貢献するためにできる大きなポイントの1つに
「実施できる施策の数を増やすこと」があると思っており、ディレクターを中心に課題出しの質は担保してもらい
エンジニア側ではその施策をひたすら実施していくことに注力しました。
エンジニアチームはどうやってそれを実現したのでしょうか?

1.バグを即検知可能な環境でリリース回数を増やした

f:id:mogmog2:20161107094129p:plain
リリース本数を増やすということは、単純に考えると バグの増加 につながります。
ですがA/Bテストをやるにあたって、監視環境を整備していたことが役立ちました。
やっていたのは大きく2つ

  • Datadogでnginxの指標をグラフ化 (レスポンスタイム, ステータス)
  • Sentryを使った例外の監視

これによって

  • 急激な500系のレスポンスの増加
  • 一部ページに重いSQLが発生した場合にレスポンスタイムの悪化
  • バグによるエラーの発生

などに気付くコストが圧倒的に軽くなっていたため100%の精度ではなくても、
気付いてすぐ戻せることからガンガンリリースをしました。  

また、まとめて一度にリリースするよりも、アプリケーションに対する変化量が小さく
すぐロールバックできるので、以前よりリリースに対する心理的負担が大きく減ったと思います。

2.リリース頻度が増したので1回ごとのコストを下げた

A/Bテストを始めて、徐々にリリースの頻度が増えてきました。
すると今度はリリース1回ごとの手間が気になり始めたので
以下のように減らせそうな手順を減らしました。

Before After
コードレビュー エンジニア全員のLGTM(承認)必須 1人のLGTM(承認) or ユーザーに影響しない系はレビューなし
ステージング確認 ディレクターが確認 ディレクターが確認
リリースノート リリース毎に必ず作成 手でコマンド叩く作業がない限り作らない
リリース時間 ユーザーが少ない時間帯 大きめのリリース以外は出せる時にすぐ出す

先述した監視環境があるため、リスクを小さくリリースコストを下げることができました。
とはいえ、レビューを減らすといった作業は個人の責任や負担を増やしてしまうため
チーム内で「やばそうなやつや心配なやつは積極的にレビューしてもらおう」と話していました。

3.シンプルな仕組みでA/Bテストを実施するためにsplitを導入

A/Bテストを高速に進めるにあたって役に立ったのがsplitです。
splitrb/split: The Rack Based AB testing framework
https://github.com/splitrb/split
f:id:mogmog2:20161103171227p:plain

これは@iharaに教えてもらって入れたgemで

  • A/Bテストの実装
  • 実施するA/Bテストの切り替え
  • A/Bテストの集計/結果画面 (Redisサーバーを1台用意) 

までカバーしてくれるgemです。

このgemを入れてA/Bテストを実装するだけで   集計結果は勝手に生成されるため、リリース後にディレクターが勝手に結果画面を見てSlackに共有するフローができました。

Redisの集計サーバーが死んだ場合にはA/Bテストを強制終了して
アプリケーション全体が死なないようにしてくれるあたりも安心ポイントです。

逆にファネル的な連続する数字を追いたくても、splitでは機能が提供されていないため
GoogleAnalyticsなどと併用して数字をチェックする必要があるところは気になるかもです。

やってみて感じたこと

1.エンジニアがプロダクト改善の意見を出しやすくなった

A/Bテストを始めてから起こった変化の1つです。
下記の表はA/Bテスト開始前後の施策についての比較です。

Before After
施策内容 SEO対策 A/Bテスト
結果が出るまで 数週間 最短1日
結果に対する感覚 何が効いたのかよくわからない 理由を考えてエンジニア同士で議論できる

SEO系の施策が多く、いくつもの施策が同時に走ったり、結果が出るまで時差があるため
仮に順位が上がったとしても「いつの」「何の施策が」「どういう理由で」効いたのかわかりにくい。という現状に悩んでいました。

対してA/Bテストを始めてからは以前のの記事にもある通り

  • 1つずつ検証するようにした
  • 仮説と考察を施策毎にきちんと書くようにした

など、1つ1つのテストに対し「何の数字に」「どういうインパクトがあるのか」を定義して実行し、2~3日すれば結果が出るため、即みんなで結果について話すことができました。

実際にはこんな感じで朝会やSlackで話しています。
f:id:mogmog2:20161107094022p:plainf:id:mogmog2:20161107094024p:plain

2.とにかく数多く試していくしかない

改めて今回A/Bテストを試してみて思ったことですが
自信のある施策であまり数字が上がらなかったり、ちょっとした文言追加で大きく数字が跳ねることもあり
何度も試さないとわからないことが多いということを実感しました。

逆に何度もやってると、ユーザーがどういうものを好むのかだんだんわかってきました。

エンジニアという立場で、プロダクト改善に協力するには
仮説を検証するというプロセスをいかに早く、数多くこなせるかが重要だと思っています。  

A/Bテストという手法もそうですが、エンジニアチームにとっては   この改善プロセスの変化が最も大きな収穫でした。  

次回予告  

ここまでは 

  • 第1回:『成果』
  • 第2回:『考え方』『施策』
  • 第3回:『開発チームの貢献の仕方』

について書きました。
次回はまたまたディレクターの@cultivaから
具体的なA/Bテストの施策の考え方についてのブログを書きます。

RubyWorldConferenceに出展してまいりました!

こんにちは!新卒エンジニアのMKentaです!

先日SpeeeがRubyスポンサーとして協賛させていただいたRubyWorldConference2016に行ってまいりました! 去年の記事はこちら

ブースの内容については、去年と同様にお菓子神社を運営してまいりました!

社内のお菓子神社事例については去年の記事をご覧ください!

今年のお菓子神社

今年のお菓子神社は去年と同様にMacを設置し、

omikuji = %w( 大吉 吉 凶 )
p omikuji.sample

という最もシンプルな実装を運営側で用意し、実行してもらう形で運営をしておりました。
エンジニアではない方にはこちらの全ての確立が均一な状態でおみくじを引いていただき、
エンジニアの方には独自のおみくじ実装を書いて、実行することでお菓子を手に入れてもらいました。

今回の景品は

  • 大吉: 金の延べ棒(チョコレート)
  • 吉: うまい棒
  • 凶: パインアメ

となっておりました! 金の延べ棒の迫力がすごいです...!

一日目

初日は祝日だったこともあり、たくさんの方にご来場いただき、
ブースはとても賑わっておりました!

実装例

実装をしてくださった方の中にはQiitaに記事を上げてくれた方まで!
とても嬉しかったです、ありがとうございました!

kuji = %w(大吉 中吉 吉 末吉 凶 大凶)
num = rand(30)
0.upto(num) do |i|
  print "\r#{kuji.shuffle[i % kuji.size]}"
  sleep 0.1
end

qiita.com

こちらが弊社エンジニア陣驚きの実装

omikuji = %w(大吉 吉 凶)
p omikuji[rand.to_s.length % 3]

引数なしのrand関数は0.0 以上 1.0 未満の実数を返すのですが、
この桁数には偏りがあり、それを利用することにより約6割の確立で
大吉がでるというものでした。

ただ大吉を高確率で出す、という実装ではなくいかに面白く実装するかに挑戦していただき、
本当にありがとうございました!

a=[0,0,0]; 10000.times { a[rand.to_s.length % 3] += 1 }; p a
=> [6184, 2836, 980]

二日目

二日目には、先輩エンジニアの@hatappiさんによるスポンサーセッションが行われました! 会社としての認知度は昨年より向上したのですが、具体的に何をやっている会社なのかの認知はまだまだだな、と感じました。

まとめ

RubyWorldConfereceにブースを出すのは企業としては二回目でしたが、出展メンバーはほぼ全員が初出展だったので、最初は勝手がわからず大変でしたが、なんとか無事終えることができました! 昨年と同じ内容のブースになってしまい、新しいことにチャレンジできなかったのは少し良くなかったかなと思っていますので、来年は何か新しいことをやる...かもしれません!

セッション自体もとてもおもしろく、RubyKaigiでの技術的な取り組みの話と言うよりは組織の運営や取り組み方に焦点を置いたスライドが多かったので、気になった方は是非配信アーカイブをご覧ください! 来年もよろしくお願いいたします!

【第2回】高速A/Bテストドリブンな改善フローの考え方と施策

こんにちは、ディレクターのcultivaです!

はじめに

この記事は連載物です。以前の記事についてはこちら。 technica-blog.jp

この記事では、
『私達が高速A/Bテストをどんな考え方で行ったのか』
『私達が実際にどんなA/Bテストの施策を行ったのか』
を書きたいと思います。

そもそもなんでA/Bテストを始めることにしたのか

私達のチームではそもそもA/Bテストをやっていませんでした・・・
当時は施策を投入し、全体指標を見て「たぶん良い感じ」とか
「効果が出るまでしばらくモニタリング」などの会話をしていました。

その時はPDCAを回しているつもりだったのですが、
今から考えてみると改善効果を理解できておらず、
本当の意味でのPDCAには全くなっていなかったと思います。

その結果、 最初のうちは調子よく成長していたサービスの成長速度にちょっとずつ陰りを感じるようになりました。
このままではいけないと思い、
A/Bテストを取り入れて本当の意味でのPDCAを行う改善フローを学習しつつ、
サービスにとって本質的な指標の改善を行うことにしました。

とはいえ、そもそもやったことがなかった取り組みなので、初歩の初歩から始めることにしました。 よって、A/Bテストドリブンな進め方、の第一歩は「まずA/Bテストすること」からでした。

実際にやってみて、改めてA/Bテストをオススメする4つの理由

A/Bテストドリブンでやってみたことのメリットを振り返ってみました。
想定通りだったことと体験して今振り返ってみてわかったことがあります。

1.結果がはっきりわかるため、迷わず前に進める。

(当たり前ですが)オリジナルとその施策の比較が明確に出るので、迷うことなく判断できます。
逆にやらないと、本当によかったのか判断できません。(外的要因をすべて考慮することは困難です)

2.テストすることで、判断スピードが上がり、結果プロダクト改善サイクルが高速になる

同条件で外的要因を排除した状態での比較になるので、結果分析が不要になります。
解釈も人によってぶれないので、報告時にもぶれません。
逆にやらないと、速いようで結果的に分析に時間がかかり、もやっとした結論になります。

3.あくまでテストと割り切れることで、開発スピードも上がる

A/Bテスト時に改善がされなくても切り戻せばよいです。
ちなみに、これが本番リリースだとそうはいきません。

さらに今では「あるテーマを評価するための最小限のA/Bテスト実装」を意図的に行って、
テスト工数を最小限にとどめるようにしていて、良い結果が出たらきちんと実装する、というステップを踏むこともあります。

4.一つ一つテストすることで「何をするとユーザーがどう動く」が明確にわかり、経験となり、次につながる

一つ一つ分けてテストをすることで、どんなことをするとユーザーがどう動くのははっきりわかり、ユーザー行動の理解が深まります。 その結果、では次どうするか、につながって、案件の精度が上がる、かつ案件が連想ゲーム的にすぐ出てくるようになります。 複数混ぜて行うと、何をするとユーザーがどう動くのかがわからず、次以降に何もつながりません。

A/Bテストの進め方

A/Bテストは下記のような感じで進めていきました。

1.3打数1安打ではなく、300打数30安打

それぞれを改善率ベースで
3打数1安打 →3割3分3厘
300打数30安打→1割
と考えるのではなく、改善数ベースで
3打数1安打 →1回改善
300打数30安打→30回改善
と考えて、『改善数』を積み重ねることを目指しました。

更にいうと、想定通りにいかなかったことも、きちんと振り返れば、
『こんな風に見せるとユーザーはこんな反応を見せる』という学びになるので、
実際には、
300打数30安打→30回改善+270学習
こんな感じの考え方で進めました。
※ちなみに、『最低限の改善率』の目安としては『改善率は20%でOK』という感じにしました。

2.速度!速度!速度!

上述の通りで改善数を重要視することにしましたので、
とにかく速く施策を試して、小さくとも改善数を積み重ねることにしました。

あと、私達にとってが『高速A/Bテストドリブンな改善フロー』が初めての挑戦だったので、
その意味でも、とにかくこのフロー自体に慣れるために、施策を積み重ねることに注力しました。

3.仮説と考察を施策毎にきちんと書くようにした

『成功した施策からも失敗した施策からも何かを学び取る』ために、
仮説立てと考察については毎回書くことにこだわりました。

考察については
改善した施策は『仮説があたったとして、更にどんな内容をで改善していくべきか』
改善しなかった施策からは、『そこからの学び』や『新しい仮説を立てること』
を書くことにしました。

正直にいって、仮説立てや考察自体の精度も低い状態のスタートになりましたが、
それらを改善フローを回していく中で改善をしていくことにしました。

4.1つずつ検証するようにした

複数同時に検証してしまうことで『結局何がよかったのか、悪かったのか、よくわからない』という状態になることを防ぐことを考えました。 そこで同時に複数箇所を改善するのではなく、1つずつ地道に改善を重ねるようにしました。

改善した施策(ほんの一部を抜粋)

1.求人情報の表示レイアウトの改善

f:id:mogmog2:20161028120113j:plain

仮説

仕事探す時、ユーザーが一番気になるのは企業名と地域名なのではないか。

検証結果

f:id:mogmog2:20161028115153j:plain

考察

やはり、仮説通りに企業名と地域名はユーザーにとって重要な情報。
なので、この2つの情報はユーザーから見てわかりやすい箇所に配置するべき。 他ページでも同様に試してみるべき。

2.募集要項をなくす

f:id:mogmog2:20161028120112j:plain

仮説

募集要項はユーザーにとって重要度が低いのではないか
          +
求人一覧が縦長に冗長化傾向であるので、コンパクトに収めたい

検証結果

f:id:mogmog2:20161028115155j:plain

考察

求人一覧ページを見る段階(求人同士を比較する段階)では、
求人の募集要項の重要度はやっぱり低そう。
          +
募集要項を消したことに伴って求人一覧ページの一覧性が上がるので、
求人一覧ページ内でユーザーが興味のある求人が見つかる確立が上がったとも考えられそう。

次回予告

ここまでは
第1回:『成果』
第2回:『考え方』『施策』
について書きました。
次回以降の記事では 『高速A/Bテストドリブンな改善フローをどうやって実現したのか』
について、エンジニア・ディレクターそれぞれがどんな取り組みを行ったのかを書きます。