こんにちは、ディレクターのcultivaです！ 最初に この記事は連載です。今回はディレクター編！ 以前の記事についてはこちら 【第1回】高速A/Bテストドリブンな改善フローでわずか5週でCVRを29%上げた話 【第2回】高速A/Bテストドリブンな改善フローの考え方と施策 【第3回】高速A/Bテストドリブンな改善フローでわずか5週でCVRを29%上げた話(開発編) この記事で扱う話 tech.speee.jp 上の記事で書きましたが、 私達のチームは高速A/Bテストドリブンな改善フローを回していくにあたって、 下記のような考え方で進めたことをお伝えしました。 速度！速度！速度！ 3打数1安打ではなく、300打数30安打 1つずつ検証するようにした 仮説と考察を施策毎にきちんと書くようにした この記事では上記を受けてディレクター側が、 この取り組みをチームで回していくために どんな運用や工夫

こんにちは、ディレクターのcultivaです！ A/Bテストをやったら、わずか5週間でCVRが29%上がった。 弊社のとあるサービス開発においてサイト改善のやり方を変える取り組みを始めて3ヶ月。 いきなり最初5週間で主要指標を大きく改善することができたので その結果と、何を変えたのか共有します。 CVRの変化 ※5週前の送客率をそれぞれ100とした場合 今回のサービスの最注力ページ『ページ種別A』における 最重要指標『CVR』の変化です。 トレンドを踏まえた上で実質的には 『29%増加』 の結果となっています。 その他主要指標の変化 まずは主要指標の数字がどれだけ変わったのかを書いていきます。 このように主要指標について 軒並み大幅に改善することができました。 見た目の変化 38件のA/Bテストの結果、一覧ページの見た目がこのように変わりました。 より細かく見ると、、、 これは1回で改善し

9/7の社内勉強会では、@nisshieeorgから、現在携わっている医療事業での開発のやり方の話をしました。 Speeeは事業会社です。正社員のみでも20人以上のエンジニアが在籍していますが、同時に多くの事業抱えているため、1事業あたりのエンジニア数は3人前後というチームがほとんどです。また、特に新規立ち上げ期の事業においては、非エンジニア職のメンバーを入れても少数のチームであることも多いです。結果として、エンジニアもよりビジネスのこと、ユーザのこと、マーケットのこと、クライアントのことを知り、ときには事業の意思決定にも深く関わる知識と責任を求められます。 もちろんそれこそが事業会社に所属するエンジニアの醍醐味であり、楽しさであり難しさでもあるわけですが、一方で、どうしてもより深い技術と向き合う時間が相対的に減ってしまうという側面もあります。 では、もし、ここに、高い知識・経験・スキルを

こんにちは！ ヌリカエ / 開発基盤エンジニアの @selmertsx です。 chatopsを導入しているチームで、chatops使える人と見れるだけの人を分けたいってことありますよね。 今回はそのための機能をご用意しました。 その機能を SpeeeKaigiで話したところ、ぎりぎり３位入賞をもらえましたので、 今回はそのお話をしたいと思います。 SpeeeKaigi自体については、こちらを御覧ください。 tech.speee.jp トークテーマ Rubotyで認可認証 & Deploy機能を作った話 キーワード chatops ruboty 認可認証 deploy 発表スライド 作成した gemはこちら。 https://github.com/selmertsx/ruboty-capistrano https://github.com/selmertsx/ruboty-authoriz

イエウール / 開発基盤エンジニアの@pataijiです。 画像リサイズをサーバーレスでやっちゃおうぜってことをSpeeeKaigiで発表して、まさかの、優勝しました。 SpeeeKaigiについてはこちらの記事が詳しいです。 tech.speee.jp トークテーマ サーバーレスアーキテクチャで画像リサイズ キーワード 画像リサイズ サーバーレスアーキテクチャ AWS Lambda Amazon API Gateway ImageMagick 発表スライド speakerdeck.com スライド中の動いているデモはこちら 質疑応答 リサイズした時のレスポンスタイムが気になる 計測していないので正確な回答はできないのですが、Lambda上で画像生成が走るのでかなりかかります。 オリジナル画像の容量や生成する画像サイズにより変わりますが、今回デモしていた感覚値では2000x2000pxの画

エンジニアの @suemoc です。 社内勉強会にて、イエウール事業におけるリリース手法について話しました。 トークテーマ 安心リリース in イエウール キーワード カナリアリリース ブルーグリーン・デプロイメント 発表スライド 質疑応答 カナリア環境で問題が発生したとき、どのようにロールバックするのか。LBの設定を切り替えているのか。 ロールバック時はソースコードをデプロイし直す。 カナリア環境での検証で、問題なしと判断する基準は何か？ 事業として許容できる数値の変動を事前に決めておく。 イエウールの場合はCVRなど。 kageのようなシャドウプロキシとカナリアリリースのメリット・デメリットは？ kageは外部公開せずにサービスのテストができる。 カナリアリリースは外部公開するリスクを負う代わりに 公開しないと発見できない問題を見つけられる。 スキーマ変更を伴うリリースの場合はどうする

社長室エンジニアの id:takanamito です @hiragramによる前回の tech.speee.jp につづき 今週の僕の発表もレポートさせていただきます。 トークテーマ あんしん大規模リプレースサポート キーワード Rails リプレース kage nginx Datadog 発表スライド 質疑応答 nginxでリダイレクトをしなかったのはなんで？ マスタデータに基いて生成されるURLが存在し、マスタ刷新によりDBから新旧マスタの対応を取得してリダイレクトさせる必要があったため kageに流すリクエスト量をスライドの中の数値に絞ったのはどういう理由？ kage導入にあたって検証時間があまり取れなかったため、障害時に影響を小さくするため kageはthinで動かしていたが、どの程度の負荷に耐えられるかわからなかったので 1req/s以下になるように調整 所感 3月ごろに行ったリ