読者です 読者をやめる 読者になる 読者になる

「Rubyエンジニアが語る、2016年の振り返りとこれから」レポート!

Ruby イベント エンジニア勉強会

こんにちは、海外メディアチームの id:takanamito です。

普段はASEAN地域向けのHRメディアの開発/運用をやっています。

今回は2017年1月18日(水)にSpeee Loungeで開催したイベント 「Rubyエンジニアが語る、2016年の振り返りとこれから」のイベントレポートをお届けします。

speee.connpass.com

f:id:takanamito:20170118201011j:plain

会場は弊社のSpeee Lounge 最近はよく社外の方を招いたイベントの会場として使われる頻度が増してきました。

f:id:takanamito:20170118200927j:plain

今回のイベントはGMOペパボさんとの共催 2社から数名のエンジニアが登壇していく形式で発表が進みました。

「minne の API 改善」by GMOペパボ株式会社 後藤 利博氏

使われていないAPIのエンドポイントを調査、削除する話と4つのバージョンが存在するAPIのバージョンを減らしていく話が中心でした。 発表の中で紹介されていたgemのlog-analyzerは、いずれ弊社でもお世話になるチームが出そうです。

「PHPで運用中のサービスをRubyに切り替える」by 株式会社Speee id:takanamito

所属する海外メディアチームで運用中のFuelPHPを使ったプロジェクトをRailsに切り替えるためにやったことを紹介しました。 発表後の懇親会では、資料の中でも紹介していた kageについての質問をたくさんいただきました。

「2017年をキャッチアップする三種の神器」by GMOペパボ株式会社 髙橋 健一氏

ここからはLT枠です!

以前、Speeeで開催した Speee Cafe Meetup #3でも登壇していただいた、けんちゃんさん。前回同様、非常に聞きやすい発表でした。 時間の都合で省略されてしまった後半の発表もお聞きしたかったです。。。

「No.1のCRMサービスからRails+Angularへリプレイスした」by 株式会社Speee 畑中 悠作氏

とあるCRMサービスをどう脱却したのか。コードカバレッジを上げるために、無意味なコードの行数を増やす手法の紹介をしていたシーンでは この日1番のざわつきが起きていました。

「サービス基盤におけるRuby~JSOX編~」by GMOペパボ株式会社 髙石 諒氏

こういった勉強会ではなかなか聞くことのないJSOXの監査対応のお話です。

まとめ

発表終了後はピザを囲みながら登壇者、参加者まじえて懇親会!

イベント終了時刻を過ぎても熱量は下がらず非常に盛り上がった懇親会となりました。

f:id:takanamito:20170118211336j:plain

またこの会の直前にリリースされた @yoshiko_pgさん製の 参加者の名は。を使うことで
とても円滑な会場受付を行うことができました。
この会の名札をつくるさいに見つかった不具合についても、弊社の畑中がすぐにPRを送り即mergeされるなど
非常によいOSS活動にもつながっています。 今後も使わせていただこうと思っています。

最後に、一緒にこの会をつくってくださったGMOペパボ株式会社さん、ありがとうございました :)

エンジニアイベントを5ヶ月間運営してみて

さくっと自己紹介

Speee人事のid:kana-nakanoです。実は人事(採用)のお仕事は初めて。
加えてエンジニアと一緒に働いたことがないので、エンジニア文化に馴染みがない。
そんな私がエンジニア採用をすることになって、メインで担当したイベント運営について、学んだこと・感じたことを書いてみました。

大事な3つのこと

イベント運営のノウハウは多岐に渡り、このオペレーションをエクセレントにしていくことはとても大事なのですが、私は特に、「Why(何を目的にするのか)」を決めた後の「What/Who/How」について学びが多かったので、その中で大事だなと感じた3つのことをシェアします。

ちなみにこれまでにSpeeeが実施したイベントとこれから実施予定のイベントです。

イベント名
内容
Speee Cafe Meetup #01 コーヒー好きエンジニアによるRuby勉強会
Speee Cafe Meetup #02 OSS開発の始め方やその中での学びをテーマにした勉強会
Speee Cafe Meetup #03 基盤開発における各社の取り組みをテーマにした勉強会
Speee Cafe Meetup #04 不動産系サービスの開発裏側について(ReTech)
Speee Matz Meetup #1 Speeeの技術顧問であるまつもと氏を招いての質問大会。12/15(木)実施予定。
Shippai Night~挑戦したから失敗がある~ 失敗の振り返り、そしてそこからの学びを共有して頂くイベント。12/19(月)実施予定。
①What:どんなテーマでやるか

社内外問わず、多くのエンジニアに「どんなテーマだったら参加したくなるか」をヒアリングさせてもらいました。

  • 絞り込んだ具体的な技術の話
  • 登場して新しく、まだネット上でも情報が少ない技術やツールの話

言葉は違っていても、総じてこの2つが多かったかなと思います。 1番多かったのは「絞り込んだ具体的な技術の話」という意見。それはその人が今扱っている技術だったり、そこでつまづいていたりして、そのイベントに参加することで知見を深められるから。そりゃそうだ、素直に納得。

次に多くいただいたのが、「登場して新しく、まだネット上でも情報が少ない技術やツールの話」という意見でした。 そこでしか得られない情報があるから足を運びたいと思う。これまた深く納得。

前者で良かったなと思う例は、11月17日に実施したSpeee Cafe Meetup #03でしょうか。
「基盤開発における各社の取り組み」というテーマで実施したのですが、「基盤開発」という技術分野といえばかなり幅広いのですが、直面しているフェイズが異なる各社の取り組みという点に焦点を当て、その話が聞けるという部分が参加者にとって好評でした。

technica-blog.jp

ということで、今後もこの2つを意識したイベントを考えていきたいと思っています。
そんなテーマがぱっと思いつくように、自分のアンテナを張りめぐらせることができるようになったらベスト。ベターはエンジニアがワイガヤしているのテーマを早くキャッチアップできることようになること。ワーストはわからない、気づかないことじゃなくて、気づいても調べない・理解しようとしないことかなと思っています。
とりあえずベターを目指して、色んな情報に敏感になっていきたいです。

②Who:誰と/どの会社と一緒にやるか

え?他力本願??そんな風に思われそうですが、現在のSpeeeの、テクノロジーカンパニーとしての立ち位置を踏まえると、集客したときに目標人数が集まらなかったり、直前のキャンセルが多いのが現状です。

ここもヒアリングをさせていただきました。
1番多かった意見は「自分の興味のある技術分野で突出している人が登壇するイベントなら参加する」でした。 イベントはそんな人の話が直接聞けること、また会えることがメリットですよね。そしてそんな人たちが登壇するイベントは、目の前の業務より優先度があがるわけで、「業務終わってないからやっぱりキャンセル....」みたいなことはぐっとおこりにくくなります。

また、誰とやるかと同様、どの会社と一緒にやるかも重要だという意見も多くいただきました。登壇する人、ではなくその会社がもっているプロダクトの話を聞いてみたいというのも一つですよね。

現段階で、誰と/どの会社と一緒にするかは私たちにとってはイベント企画において大事なポイントです。自分たちの認知度をあげる目的だけでなく、そんな人たち/企業が登壇するイベントだからこそ、参加者の満足度も高くなると感じています!

これからも、その技術分野の第一人者だったり、技術力に定評のある企業様と一緒にイベントしていきたいので、出たいと思われるようなテーマ・コンテンツを企画していきたいですし、運営も頑張っていきたいと思います。

③How:エンジニアと一緒に企画する

ここが1番大きな学びだったかなと感じています。
エンジニアイベントや勉強会って、エンジニアが主役ですよね。エンジニアが満足するイベントを、エンジニアの意見を聞かずにつくることは出来ないということに数回実施してようやく気づきました(遅)。

その気づきと合わせて、少し前に「盛り上がる(満足度の高い)イベントは、その会社のエンジニアがたくさん参加していて、話したい分野で話したい人がいてくれるようになってる」という意見をもらい、イベントの参加や懇親会の盛り上げを担ってくれるエンジニアをアサインするようになりました。それだけでも当日の雰囲気であったり、アンケートから参加者の満足度があがったのではないかなと感じてます!

ただ、当日の参加お願いします!って言われたってエンジニアだって具体的に何すればいいかわからないし、それって何のためだっけ?みたいな気持ちになるはず。

ですので、来たる12月19日(月)のイベントShippai Night~挑戦したから失敗がある~では「目的は何で、どんなイベントにしていくか」という段階からエンジニアに携わってもらっています。この部分から一緒にやることの重要性を日々実感しています。むしろこの部分が1番大切なのになぜ今まで一緒に企画してこなかったのかと反省...。

エンジニア視点で何が良くて何がイマイチなのかを納得しながら進めることができて、とてもいい経験だなと感じています。そして何より楽しいですね。複数人でやるからこそ意見が割れて時間もかかったりしますが、全員が真剣にやっているので悪い方向には進まないです。

独りよがりのイベントにはしたくない、参加者もだけれどもSpeeeエンジニアにも「自分たちの会社、いいイベントするじゃん。参加してよかった。」って思ってもらえるようなイベントをし続けていくことが当面の目標です!

f:id:kana-nakano:20161012162240j:plain

最後に

長々と技術以外の内容を読んでいただきありがとうございました!
id:kana-nakanoに会ってみたいと思ったそこのあなた。Speeeが隔週で開催しているもくもく会に参加してもらえれば、ほぼいます。もくもく会に興味のある方はコメントください!Speee ラウンジで実施しています。
以上週末ヒロイン改め、週末ラウンジお姉さん(自称)でした!

TravisCIでiOSの依存ライブラリの更新を自動化する

これはSpeee Advent Calendarの1日目の記事です。

iOSアプリエンジニアの@hiragramです。

私がいるチームでは、依存ライブラリ管理にCarthage、CIにTravisCIを使っています。

また、ライブラリのバージョンアップに積極的についていくために、TravisCIのCron Jobshubコマンドを使い、定期的に依存ライブラリの最新バージョンをチェックして、アップデートがあればGitHubにPRを投げるような仕組みを構築しています。

実際に投げられるPRはこんな感じです。僕のトークンを使ってるので僕が作ったみたいになってますが、CIのタスクから作られたものです。

スクリーンショット 2016-10-21 16.31.23.png

パッチやマイナーアップデートの優先度は下がりがちだと思います。しかし、Swiftは言語のバージョンが比較的速いスピードで上がっていくこともあり、ライブラリにバグが残る可能性は大いにあるのでこまめに更新しておきたいところです。

やってみましょう

  • TravisCIサポートに連絡してcronを開放してもらう
  • cronの設定をする
  • 環境変数の設定をする
  • cron用のスクリプトを用意する
  • PRの本文を作るスクリプトを用意する

このようなステップで準備していきます。

TravisCIでcronを有効にする

Cron Jobsのページにあるように、cron機能はデフォルトでは設定できなくなっているので、サポートに連絡して有効にしてもらう必要があります。

TravisCIのダッシュボード左上の Help -> Email Support から Please enable cron jobs configuration on "Hogehoge" organization. とか送っておけば、翌営業日には対応してくれます。

cronの設定をする

リポジトリを選択して、設定画面を開きます。

スクリーンショット 2016-10-21 17.10.08 のコピー.png

サポートから返事が来ていれば、設定項目の中に"Cron Jobs"があるはずです。

スクリーンショット 2016-10-21 17.17.41.png

ここで定期的に実行するブランチと周期と実行条件を設定します。

私たちは、週に1回masterブランチで実行するようにしています。

ちなみにtipsですが、毎週のタスクを任意の曜日や時間に設定する項目はありませんが、cronの設定をAddした時(金曜17時に設定したなら毎週金曜17時)に実行されるようになります。

タスク内でcarthage updateを実行するため非常に時間がかかります。私たちは月曜の朝7時にしています。

TravisCIに環境変数を設定する

Personal access tokensのページで、TravisCIからPRを作るのに使うトークンを発行します。

TravisCIの設定画面で、GH_TOKENに発行したトークンを、GH_USERにGitHubのユーザー名を書きます。

スクリーンショット 2016-10-24 10.30.40.png

cronから起動された時用のビルドタスクを書く

各種タスクは.travis.ymlでシェルスクリプトを指定してその中に書くようにしています。

# .travis.yml

language: objective-c
osx_image: xcode8
script:
  - ./.travis_scripts/build.sh
notifications:
  slack: **********
before_install:
  - ./.travis_scripts/before_install.sh
before_script:
  - sudo systemsetup -settimezone  Asia/Tokyo

cronによって実行されている時、環境変数$TRAVIS_EVENT_TYPEcronという値になっているので、それをみて処理を切り替えるようにしています。

#!/bin/bash

# build.sh

if [ $TRAVIS_EVENT_TYPE = cron ] ; then
    if carthage outdated | grep "All dependencies are up to date." ; then
        exit 0
    else
        carthage update --platform ios --configuration Debug
        createPR
    fi
else
    carthage bootstrap --platform ios --configuration Debug
    runTest
fi

$TRAVIS_EVENT_TYPEがcronだった場合、まずcarthage outdatedでアップデートがあるライブラリを探します。 もしもアップデートがあるようならcarthage updateで更新します。 最後に、自分で定義したcreatePRを実行します。

createPRの中身はこんな感じです。

createPR() {
    CREDENTIAL_FILE="$HOME/.config/git-credential"
    mkdir -p $HOME/.config

    echo "https://${GH_TOKEN}:@github.com" > $CREDENTIAL_FILE
    echo "github.com:
- oauth_token: $GH_TOKEN
  user: $GH_USER" > $HOME/.config/hub

    which hub
    if [ $? != 0 ] ; then
        brew install hub
    fi

    git config --global user.name "TravisCIたん"
    git config --global user.email "hiragram@users.noreply.github.com"
    git config --global hub.protocol "https"
    git config --global credential.helper "store --file=$CREDENTIAL_FILE"

    BRANCH_NAME="dependencies_autoupdate_"`date "+%Y-%m-%d_%H-%M-%S"`
    git checkout -b $BRANCH_NAME

    touch pr.txt
    echo "Detected outdated dependencies." > pr.txt
    echo "# Outdated dependencies" >> pr.txt;
    git diff Cartfile.resolved | perl .travis_scripts/check_version.pl >> pr.txt # 後述
    git add Cartfile.resolved
    if git commit -m "[Auto generated] Update dependencies" ; then
        git push origin $BRANCH_NAME
        hub pull-request -F pr.txt
    fi
}

処理の流れとしては、

  • 環境変数に入れたトークンとユーザーをhubの設定ファイルに書き出す
  • hubが入ってなければ入れる
  • gitの設定
  • ブランチ切る
  • PRのタイトル/本文をファイルに書き出す
  • リモートにpushする
  • PRを作る

という感じです。

PRの本文を作るPerlスクリプトを書く

先程のシェルスクリプトの中に

git diff Cartfile.resolved | perl .travis_scripts/check_version.pl >> pr.txt

とありましたが、これの解説をします。 PRの本文には

## Quick/Nimble
v5.0.0 -> [v5.1.0](https://github.com/Quick/Nimble/releases/tag/v5.1.0)
[compare](https://github.com/Quick/Nimble/compare/v5.0.0...v5.1.0)
  • 導入済みのバージョン
  • 最新バージョンとリリースノートへのリンク
  • そのバージョン間のdiffへのリンク

が記載されています。 これを作る為にPerlでこのようなスクリプトを書きました。

#!/usr/bin/perl

use strict;
use warnings;

my $input = "";
while(my $line = <STDIN>) {
  $input .= $line;
}

while ($input =~ /\-github "(.*?)" "(.*?)"/gms) {
  my $repository = $1;
  my $oldVersion = $2;
  if ($input =~ /\+github "$repository" "(.*?)"/ms) {
    my $newVersion = $1;
    my $oldDispVer = $oldVersion;
    my $newDispVer = $newVersion;
    if (length($oldVersion) > 25 && length($newVersion) > 25) {
      $oldDispVer = substr($oldVersion, 0, 6);
      $newDispVer = substr($newVersion, 0, 6);
    }
    print("## $repository\n");
    print("$oldDispVer -> [$newDispVer](https://github.com/$repository/releases/tag/$newVersion)\n");
    print("[compare](https://github.com/$repository/compare/$oldVersion...$newVersion)\n");
  }
}

carthage updateを実行すると、アップデートがあった場合にCartfile.resolvedが更新されます。 git diff Cartfile.resolvedの結果を標準入力に渡してやると、先程のPRの本文を生成するスクリプトです。

試しに動かしてみる

準備の手順は以上です。 通常のpushで動くタスクはTRAVIS_EVENT_TYPEcronでは無いので、テストの段階ではシェルスクリプトの中でTRAVIS_EVENT_TYPE=cronとしてやるといいでしょう。

まとめ

従来は依存パッケージ7個のビルドだけで20分ほどかかっていましたが、そこが短縮されたのは非常に大きかったです。

細かいアップデートは、放置すればするほど後回しになってしまい、健全さが失われていくと思います。 とはいえ、人間が定期的にアップデートをチェックして更新するのも手間なので、自動化してしまえということで今回の仕組みを構築しました。

この仕組みを導入する前は、気づいたときにGitHubをみて新しいリリースがないかを確認していましたが、導入後はある程度ほったらかしでもアップデートに追随できるようになりました。

今のところは破壊的な変更のないマイナーアップデートまでしか自動化出来ていないので、メジャーアップデートも同じような仕組みで追随できるようにしたいと思っています。

参考

Travis CIからGitHubにPull Requestを送る - GeekFactroy

「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テストドリブンな改善フロー』を実践していく際には 各論的な施策レベルではなく、
『スタンス・マインド・仕組み』の部分を是非各チームに取り入れていただければと思います。

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