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テストドリブンな改善フローをどうやって実現したのか』
について、エンジニア・ディレクターそれぞれがどんな取り組みを行ったのかを書きます。

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

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

A/Bテストをやったら、わずか5週間でCVRが29%上がった。

弊社のとあるサービス開発においてサイト改善のやり方を変える取り組みを始めて3ヶ月。
いきなり最初5週間で主要指標を大きく改善することができたので
その結果と、何を変えたのか共有します。

CVRの変化

f:id:mogmog2:20161028143052j:plain
※5週前の送客率をそれぞれ100とした場合

今回のサービスの最注力ページ『ページ種別A』における
最重要指標『CVR』の変化です。
トレンドを踏まえた上で実質的には 『29%増加』 の結果となっています。

その他主要指標の変化

まずは主要指標の数字がどれだけ変わったのかを書いていきます。
f:id:mogmog2:20161021095450j:plain

このように主要指標について
軒並み大幅に改善することができました。

見た目の変化

38件のA/Bテストの結果、一覧ページの見た目がこのように変わりました。 f:id:mogmog2:20161021095721j:plain より細かく見ると、、、 f:id:mogmog2:20161021095720j:plain これは1回で改善したわけではなく、実際にA/Bテストで改善していく上では
色分けしたように該当ページを各パーツに分割し、表示させるか/表示させないか
どのような見せ方にするか
何度も検証しながら、少しずつ改善をしていきました。

次回以降の記事で、このような結果を生んだA/Bテストを通じた改善を
サービス開発チームが実際にどう進めたのかを
・ディレクター視点
・開発視点
それぞれ書いていこうと思います。

広告運用における基本的な仕組みとモデル共通化の話【社内勉強会レポート #10】

こんにちは、speee-nakajimaです。

社内勉強会で、「広告運用における基本的な仕組みとモデル共通化の話」をさせていただきました。

キーワード

  • 広告
  • モデル共通化

質疑応答

migration ファイルを rename しているのなら role: db 外さなくても大丈夫では? 確かに。

所感

今まで何度か技術的な内容のみをピックアップしてエンジニアMTGで話させていただきましたが、今回はプロダクトのバックグラウンドについてお話しました。

ちょっとエンジニアリングとは外れた話とはなったものの、他のエンジニアに対してどんな課題を解決しているのかが共有でき、また自分の中でも整理できる良い機会となりました。

また、モデルの共通化についてはままよくある問題であるとも思いますし、弊社でも別なアプローチで実現しようという試みがあったので今のプロダクトでやってみたのでやってみてどうだったか、という知見を共有しましたので活かされると良いなと思います。

GitHub Projects運用を考えてみる

こんにちは、id:takanamitoです。
今年のGitHub Universe conferenceでは色々な発表がされました。

なかでも「Projects」「Cards」は非常に魅力的な機能だったのでさっそく使ってみました。

僕達のチームはGitHubとTrelloを使ってチーム全体のタスク管理をしています。
GitHubは開発側の、Trelloは開発以外のタスク管理にそれぞれ使っており
ツールの数を減らせると楽なので、今回の「Projects」発表を期にGitHubだけでタスク管理できないか考えてみました。

現状の運用

Trello, GitHubではそれぞれ以下のようなフローでタスク管理をしています。
またGitHubはZenHubも併用し、Boardsを使ってカンバン運用を導入していました。

  • タスク単位でIssue(GitHub), card(Trello)を発行
  • Assignees(GitHub), Members(Trello)で担当者設定
  • Estimateで予定時間を設定
  • Pipeline(GitHub), list(Trello)でステータス管理(Todo, Doing, Done)

こんな感じ。

Projectsに移行するとこうなりそうです

  • タスク単位で「Card」を発行
  • 本格的に着手するタイミングで「Convert to issue」
  • Assigneesで担当者設定
  • 「Columns」でステータス管理(Todo, In Progress, Closed)

Cardsを使う

ProjectsにはIssueの他にCardsという概念が登場します。

GitHub Projects Cards

Issueより軽量で、まさにカンバンに付箋を貼るイメージで作ることができるので
ひとまずタスクをここに残し、本格的に着手する際にConvert to issueして詳細を詰めていく運用ができそうです。

Trello脱却

またProjects自体は複数作成できるため、文字通りプロジェクト単位で作成し
それぞれのカンバンでプロジェクトごとに状況を確認できるのもよい点です。

GitHub Projects

今までLabelを使って、開発系Issueと事業サイドのIssueを振り分ける運用をしていましたが
Label設定漏れやフィルタリング機能を駆使しないと全体を把握しにくいことから、Trelloとの住み分けをしていました。

しかしProjectsが複数つくれるおかげで、Issueの種類分けが簡単になりTrello脱却ができそうです。

GitHub Projects

またZenHubがChromeエクステンションとして動作するため
どうしてもブラウザの描画完了まで「遅い」と体感できるほどの時間が発生していました。
機能数はまだZenHubには及びませんが、軽快に動作するのはうれしいですね。

悩みどころ

Projectsが複数作れるのはうれしいのですが「どういう単位でProjects」を作るか。について、これという結論が出ていません。
Projectsが増えすぎるとそれぞれを追いかけるのが大変になるし、少なすぎるとCardがIssueが増え管理しにくくなりそう。
この辺、運用スタートしていい感じにハマってるやり方あれば教えてほしいです。

まとめ

ざっとTrelloやZenHub脱却のための運用を書いてみましたが、まだまだProjects自体に機能が少ないことや
僕達のチームでもまさにこれから運用開始!というタイミングなので、いろいろ悩むところはありそうです。

またSpeeeのCEOが猛烈なTrelloファンなため、この記事をどういう心境で読むのか考えると非常に心苦しい限りです。
※参考: TrelloにはじまりTrelloに終わる | CEO Blog – 株式会社Speee 大塚英樹