ビアバッシュと題してLT大会を開催しました!

はじめに

はじめまして。19新卒SREチームの id:t-kusakabe です。 入社して3ヶ月。僭越ながらtech blogを書かせていただくことになりました。頑張っていきます!

目次

  • ビアバッシュと題してLT大会を開催した
  • お前たちの1ヶ月の成長を見せてみろ!!
  • 実際にやってみて

ビアバッシュと題してLT大会を開催した

新卒の皆さんはいかがお過ごしでしょうか。 入社して3ヶ月。配属先も決まりタスクをバリバリとこなし始めたのではないでしょうか。 弊社でもエンジニア職は5月末頃に各事業部へと配属され、それぞれ活躍するようになりました。

実際にタスクをこなしていくのは楽しいのですが、他の事業部に配属された同期との関わりが薄くなってしまい、少し寂しくもありました。 そんな時、エンジニアならどうするか。 そうですよね、LT*1ですよね!!! みんな、大好きLTです!!!

そんなことで去る6月25日、弊社で19卒エンジニア限定でビアバッシュと題してLT大会を実施しました!

※残念なことに、開催した場所が来客者の方も居られるところであったためビアはお預けでした。残念。。。

お前たちの1ヶ月の成長を見せてみろ!!

配属されてから1ヶ月の振り返りをテーマに、お前たちの1ヶ月の成長を見せてみろ!! というタイトルでLTを行いました。

各事業部で新卒たちはどのようなことをしていたのか。 配属される前と配属された後でどのように変わったのかを見せつけるテーマにしました。

実際、配属先の事業部でこういうことやったぞ!こういうチームにアサインされたぞ!こういう能力が身についたぞ! という話がたくさん出てきました。

とはいえ普通にLTをやっても面白くないですよね。 というわけで色々コンテンツも用意してみました。

用意したコンテンツ

  • 目標とゴールまでの道のりを可視化
  • コメント活性化ツール「マサカリカード」
  • リーダー陣からのありがたいお言葉

目標とゴールまでの道のりを可視化

新卒それぞれがなりたい姿を宣言し、その姿を目指して山を登っていく、というのをイメージしてこんなものを作りました。

毎月、

  • 目標にどれだけ近づけているのか
  • しっかり頂上を目指して走れているのか

を可視化出来るようにしました。

この山を見つつ、

  • 今月はどれくらい登ることができたのか
  • 頂上に向かって登れているのか
  • 同期はどの辺りを登っているのか
  • 今のペースで本当に頂上にたどり着けるのか

がわかるのと、楽しみながら自分の状態を把握出来るのでとても効果がありました。

自分の現在地をどこにするかが悩みどころですが、僕の場合は新卒なのと経験をたくさん積みたいということで一番長い道のスタート地点を現在地にしました。 ここから一気に駆け上がっていく予定です!

今後はこの山を見ることで新卒たちの成長が伺えますね。 全員で頂上を目指せるように頑張っていきたいです。

ちなみにこれらは全て弊社のデザイナーに作っていただきました!!! 新卒たちが目標に向かって走っている感じを表現したい、と伝えるとこのような素敵なものを用意してくださりました。 新卒だけでなく、たくさんの社員に好評でした!!!

コメント活性化ツール「マサカリカード」

LTと言ったらマサカリですよね! しかし、意外と誰もマサカリを投げなかったり攻撃的なこともあるので、優しくマサカリを投げれるコンテンツも用意しました。

発表終了後に新卒全員でカードを引き、書かれている内容に沿って質問をします。 カードに書かれている内容によっては、笑いが起こるものであったり、クリティカルな質問になったりなど意外と面白い試みでした。

質問者:「〇〇さんの成長が自分ごとのように嬉しかったです!!!」
全員: 「(笑)」
質問者: 「ところで、来月の取り組みで気になったのですが、具体的にはどういうことをどれくらいされるのですか?」

のようなやりとりが行われ、笑いを生みつつマサカリを投げるということできました。 カードを引く人はランダムで決められるので全員が発表者のLTを集中して聞くようになったのも良かったです。

リーダー陣からのありがたいお言葉

新卒だけでLTをしてもただの発表会になりそうだったので、リーダー陣の先輩方に質問役をお願いいたしました。

1ヶ月で何をして、何ができるようになったのか。エンジニアとして何を意識すべきなのか。 などなど、1ヶ月の振り返りをさらに深掘りする機会をいただき、かつアドバイスもいただきました。 なんとしても翌月からの行動に取り入れていきたいです。

実際にやってみて

みんなでわいわいするのはやっぱり楽しいですね。 同期が活躍していることを知って自分も負けていられないなと感じます。

また、先輩方からも「面白かった」「良い会だった」と言っていただけたので良かったです。

思いつきベースでの企画ではありましたが、やってみなよと後押ししてくれる先輩に感謝をしつつ、今後もこのような活動をどんどんやっていきたいと思います!!!

*1:ライトニングトーク

2019年、AMP for Emailでメールは生まれ変わる!

はじめまして。
目指せ、カイゼンマスター! まえしょうです。

レバレジーズのマーケティング部CRMチームに所属しており、日々「最適なタイミングで最適なコンテンツを最適なチャネルで届ける」ため奮闘しています。

今日は、そんな私の重要なチャネルの1つであるメールの話です。
このブログの読者さんは嫌いかもしれませんね・・・。実は、そんなメールが生まれ変わろうとしています!
サービス・プロダクトのグロース手段としてメールを見直してもらえるよう、3月25日にGoogleから正式リリースされたAMP for Emailを取り上げます。

[ 目次 ]

そもそも、AMPとは?

モバイル端末におけるウェブページの高速表示を実現して、ユーザー体験向上させようぜってやつ。
Googleが中心となって開発した新しいHTML規格のことです。

AMP for Email誕生の背景

ここ10年で世の中のコンテンツは静的なものから動的で対話的なものにがらっと変化しました。
ぱっと上げるだけでも、LINE、Slack、Amazon、ニュースアプリ、マンガアプリ・・・。
そんな中、古の連絡ツールであるメールはどのような進化を経たのでしょう。

・・・し、進化してねぇ!!!!
メールで通知がきたり、おすすめが飛んでくるのに、メールからどっかに遷移させられる!!!!

そりゃ、まぁ、嫌われますよね。
しかし、AMP for Emailによって、メールは動的かつ対話的なツールに生まれ変わろうとしているのです!

ふむふむ、なにができるの?

例えば、メール上で次のようなことが可能になります。

  • アンケートに回答
  • おすすめ商品の内容を確認して購入
  • 配送状況が常に現在のものにアップデートされる

既に、開発に着手している企業もあるようで、メールというよりはウェブサイトのようなユーザー体験が期待できます。
oyo_amp.gif 出典: TechCrunch - Google makes emails more dynamic with AMP for Email

さっそく、試してみた

エンジニアでも、デザイナーでもないので上記サンプルに比べるとしょぼいですが、1時間くらいあればこんなのが作れます。
大まかな構造や画像は、amp.devのチュートリアルから拝借しています。
(セレクターなど、開発途中で時間切れになってしまいました。やろうと思えば、永遠にできる。)

sample_amp_for_email
サンプル (所要時間: 1時間)

HTMLにCSS直書きしたりして頑張った経験まである筆者は完成時、感動で涙しました。
メール屋さんな方は共感できるかと思います。
なお、メール作成者向けで、もう少し詳細な内容も書く予定です。少々お待ち下さい。
GitHubにコードを公開 していますので、待ちきれない方はそちらを御覧ください。

まだ、できていないこと

本格的な実装や検証を今後やっていく必要があります。

  • Gmailでのサンプルメール受け取り (Gsuite側の設定問題?)
  • 既存のHTMLメールと共存させるコーディング
  • 各種配信ツールでのテスト
  • 動的なコンテンツの埋め込み
  • より対話的なコンテンツの作成

これからのメールの未来について

賛否両論あり、まだまだこれからな技術ですが、大きな可能性を秘めている、と思っています。
きっとユーザーに「お、便利やん!」と言ってもらえるはず!!

そして、メールの進化に伴い、メール作成者に必要とされるスキルセットも大きく変化していきそうです。
静的で自由度の低いオワコンから、動的で対話的な今風のコンテンツになっていくにあたり、ぱっと思いつくだけでも、メール内での情報設計、フロントエンドデザイン、ウェブ系のエンジニアリング・・・。

そんなわけで、CRMチームは技術に興味のある方、腕に覚えのある方を募集しております。
We are hiring!

それでは、また次回、どこかでお会いしましょう。

BayesianABテストを実戦で使ってみた

はじめに

こんにちは、18卒のおでんとよばれているものです。 7月から看護のお仕事の実装をやっていく中、ABテストの検証結果待ち状態で新しい実装が着手できないという問題が発生しました。 これに対して、BayesianABテスト方法を提案してみところ、検証が終わるまでに2週間〜3週間かかっていたものが、わずか1週間で終えることができるようになりました。 今回は、その使い方について紹介したいと思います。

ABテストとは

Webサイトで画像や文章などをAパターンとBパターンの2パターンを用意して、どちらの方がよりユーザーに行動を促したを検証するものです。 Webマーケティングの施策検証方法の1つとして実施されています。

インターネット広告では、CV数(コンバージョン数)CVR(コンバージョンレート)を高くすることが求められており、ABテストを実施して広告を出し分けるようにしています。

活用方法

A社のおでんの広告を使った時とB社のおでんの広告を使った時に、どちらのCV率(コンバージョン率)が高くなるかの施策をして、次のような結果が得られたとします。

ABテスト例

クリック数 CV数 CVR
ページA 30000 425 1.42%
ページB 28000 340 1.21%

ABテストを実施して計測したCV数やCVRが、A社とB社の違いで本当に効果があるかどうかを検証する必要があります。 この検証をする際に、カイ二乗検定がよく使われています。 しかしカイ二乗検定には欠点がありサンプルサイズが小さい場合、効果があるかの判定が出にくいです。

ABテストサンプルサイズが小さい例

クリック数 CV数 CVR
ページA 2255 32 1.42%
ページB 1985 24 1.21%

冒頭での、ABテストの結果待ち状態になっている課題の原因が、サンプルがたまるまでの時間が長いことでした。 このサンプルサイズの問題を解決したのが、BayesianABテストです!

ABテスト実戦

では実際に上の2つのデータを使って、カイ2乗検定とBayesianABテストを用いた検証を用いた検証をして比較してみたいと思います。 使う言語は、解析でよく使われているRを使います。

カイ2乗検定を用いた検証

カイ2乗検定とは

カイ2乗検定について例を元に説明したいと思います。 Webページでテストをした結果、以下の結果が得られたとします。

ボタン押した ボタンを押さなかった
赤いボタン 70 180
青いボタン 30 120

この時に、赤いボタンと青いボタンと関係があるかないかを検証できるのがカイ2乗検定です。 詳しい説明に関しては以下の参考サイトをみてください。

独立性の検定―最もポピュラーなカイ二乗検定 | ブログ | 統計WEB

サンプルサイズが大きい場合の検証

まずは、サンプルサイズが大きい例を使い検証をしてみます。

実行プログラム

> AB <- matrix(c(30000-425, 425, 28000-340, 340), ncol=2, byrow=T) #データを入力
> chisq.test(AB) #検証結果出力

検証結果

Pearson's Chi-squared test with Yates' continuity correction

data:  AB
X-squared = 4.4033, df = 1, p-value = 0.03587

この結果で重要なのはこいつです → p-value p-valueは、有意確率と呼ばれています。カイ2乗検定では、有意確率が 0.05以下の場合、要因の違いによってCV数に効果を与えていると判断されています。

今回の結果では、p-value が 0.0359(有意確率が 0.05以下) でした。 この結果から、A社の広告を使った方がCV数が良くなると判定をすることができます。

サンプルサイズが小さい場合の検証

次にサンプルサイズが小さい例を使い検証をしてみます。

実行プログラム

> AB <- matrix(c(2255-32, 32, 1985-24, 24), ncol=2, byrow=T) #データを入力
> chisq.test(AB) #検証結果出力

検証結果

Pearson's Chi-squared test with Yates' continuity correction

data:  AB
X-squared = 0.21426, df = 1, p-value = 0.6434

今回の結果では、p-value が 0.6434 でした。 この結果からは、別の広告を使ってもCV数に効果がないと判定されます。 このようにカイ2乗検定では、同じCVRであってもサンプルサイズが小さい場合、効果があるかの判定が出にくいと言われています。

BayesianABテストを用いた検証

BayesianABテストとは

BayesianABテストは、ベイズ推定の手法を取り入れた検証方法です。 事前確率と実際に得られたデータを元に、A社のおでんの広告がB社のおでんの広告に比べて何%の確率で良いかを検証をすることができます。 ベイズ推定については、参考書籍がとても分かりやすいのでぜひ合わせて読んでみてください。

参考書籍 完全独習 ベイズ統計学入門 著者 小島 寛之 2015/11/20

事前準備

BayesianABテスト用のパッケージを以下のコマンドでパッケージをインストールをします。

 > install.packages("bayesAB")

ミラーサイトをどこにするかというメッセージが表示されたら、japanを選択をしてください。 インストールが完了したら準備は終わりです。

サンプルサイズが大きい場合の検証

先ほどと同じように、サンプルサイズが大きい例を使い検証をしてみます。

実行プログラム

> library(bayesAB) #パッケージ読み込み
> set.seed(10)  #乱数固定
> A<-rbinom(30000,1,425/30000)   #Aページのクリック数、CV数を入力
> B<-rbinom(28000,1,340/28000)   #Bページのクリック数、CV数を入力

#ベルヌーイ分布の事前分布をベータ分布として初期パラメータを一様分布を仮定してa=1,b=1とし、シミュレーションを行う
> AB <- bayesTest(A,B,priors = c('alpha' = 1, 'beta' = 1),distribution = 'bernoulli')  
> summary(AB) #検証結果出力
> plot(AB) # グラフ出力

検証結果

Quantiles of posteriors for A and B:

$Probability
$Probability$A
        0%        25%        50%        75%       100% 
0.01175708 0.01402836 0.01448583 0.01495520 0.01764696 

$Probability$B
         0%         25%         50%         75%        100% 
0.009160405 0.011274530 0.011707422 0.012143179 0.014543185 


--------------------------------------------

P(A > B) by (0)%: 

$Probability
[1] 0.99852

--------------------------------------------

Credible Interval on (A - B) / B for interval length(s) (0.9) : 

$Probability
        5%        95% 
0.09790378 0.39482144 

--------------------------------------------

Posterior Expected Loss for choosing B over A:

$Probability
[1] 3.125861e-05

グラフ結果1

グラフ結果2

結果1

先ほど出力した結果の中で、最初に確認して欲しいのがP(A > B) by (0)%:の部分です。 この数字は、AのページがBのページよりもいい結果が得られる確率を表しています。

P(A > B) by (0)%: 

$Probability
[1] 0.99852

今回の結果では、$Probability が 0.99852 でした。 グラフ結果1のCVRと発生頻度を注目すると、AとBの間に差が開いていることがわかります。 また、グラフ結果2はCVRの相対効果値を示したヒストグラムです。このグラフからは、ページAがページBよりもいい結果が得られる確率がどれぐらいあるかを確認をすることができます。

これらのことから、AページのCVRが99.9%の確率でBページよりもいい結果が得られるという判定ができます。

結果2

次に確認して欲しいのが Credible Interval on (A - B) / B ~ の部分です。 この数字は、信用区間(credible Interval)に対してどれぐらいの効果が見込まれるかを表しています。

Credible Interval on (A - B) / B for interval length(s) (0.9) : 

$Probability
        5%        95% 
0.09790378 0.39482144 

この数字がちょっとイメージがしにくいので図を作ってみました。

解釈図

ここの数字では、CVRの効果が出る確率を示しています。 まず、5% 0.0979... は、AページをBページと比較した際に、Aページが109.7%以下の効果を出す確率が5%であることを示しています。 また、95% 0.394... は、AページをBページと比較した際に、Aページが139.5%以上の効果を出す確率が5%であることを示しています。

以上の結果から、AページをBページと比較した際に、Aページが90%の確率で109.7%〜139.5%の効果を出すと判定をすることができます。

サンプルサイズが小さい場合の検証

次にサンプルサイズが小さい例を使い検証をしてみます。

実行プログラム

> library(bayesAB) #パッケージ読み込み
> set.seed(10)  #乱数固定
> A<-rbinom(2255,1,32/2255)   #Aページのクリック数、CV数を入力
> B<-rbinom(1985,1,24/1985)   #Bページのクリック数、CV数を入力
> AB <- bayesTest(A,B,priors = c('alpha' = 1, 'beta' = 1),distribution = 'bernoulli')  #計算
> summary(AB) #検証結果出力
> plot(AB) # グラフ出力

検証結果

Quantiles of posteriors for A and B:

$Probability
$Probability$A
         0%         25%         50%         75%        100% 
0.007731823 0.015774076 0.017579264 0.019503243 0.032946183 

$Probability$B
         0%         25%         50%         75%        100% 
0.004870983 0.011291718 0.012934394 0.014705932 0.027729893 


--------------------------------------------

P(A > B) by (0)%: 

$Probability
[1] 0.8921

--------------------------------------------

Credible Interval on (A - B) / B for interval length(s) (0.9) : 

$Probability
         5%         95% 
-0.09560675  1.06632725 

--------------------------------------------

Posterior Expected Loss for choosing B over A:

$Probability
[1] 0.01438976

グラフ結果3

グラフ結果4

結果1

P(A > B) by (0)%: 

$Probability
[1] 0.8921

今回の結果では、$Probability が 0.8921 でした。 グラフ結果3のCVRと発生頻度を注目すると、サンプルサイズが大きい時と比べて、AとBの間に差が開いていないことがわかります。 また、グラフ結果4のCVRの相対効果値に注目すると、ページAがページBよりもいい結果が得られる確率が89.2%であることが判断できます。

これらのことから、AページのCVRが89.2%の確率でBページよりもいい結果が得られるという判定ができます。

結果2

Credible Interval on (A - B) / B for interval length(s) (0.9) : 

$Probability
         5%         95% 
-0.09560675  1.06632725 

解釈図

ここの数値では、AページをBページと比較した際に、5%の確率でAページが90.5%以下で悪化させることを示しています。 また、AページをBページと比較した際に、5%の確率でAページが206.6%以上の効果が出ることを示しています。

これらの結果と結果1の数値を考慮すると、AページをBページと比較した際に、Aページの方が89.2%の確率でCVRの効果が期待できると判定することができます。

このように、BayesianABテストの検証では、サンプルサイズが小さい場合でもいい結果が得られる確率信用区間に対する効果の2つの結果から検証をすることができます。 そのため、サンプルサイズが小さい時の検証には、カイ2乗検定よりもBayesianABテストがむいていると思います。

おわりに

感想

BayesianABテストを調査&実践してみて、大学時代に勉強したことが結構でてきたので、学生時代にちゃんと取り組んでよかったなぁと思いました。いろんな場面で統計学は使えると感じたので、これからも統計については追っていきたいと思います。

次挑戦すること

今回は1つ1つコマンドを入力してBayesianABテストを行っていましたが、次はGASなどを使ってスプレッドシートから自動で検証をしていきたいと考えています。

最後までお読みいただき、ありがとうございました。

Slackbot開発で詰みそうな所とどう回避したか

はじめに

こんにちは! 18卒のいっちーと呼ばれている者です。もう入社してから1年が経ちました。そんな1年のほとんどの期間で実装を行ってきたSlackbotについての記事をここで投稿しておこうと思います。 今回は僕がSlackbotを実装する上で苦労した所を書きます。 僕のこの記事を読んで一人でも同じ失敗をしない人が増えればいいなぁと思います。

TL;DR

学んだこと

長いので簡単にまとめると、大変だからこれは心がけよう!と学んだことは次の3つです。

  • なるべくチャンネル間のやり取りを行う場合は、データベースを使ったほうがいいということ
  • ダイアログの要素のサイズに注意すること
  • ライブラリのチェックはこまめに行うようにリポジトリの通知をつけること

実際の申請画面のスクショはこちら。

申請画面の画像
申請画面

対象読者

  • これからSlackbotでチャンネル間のメッセージをダイアログで実現しようとしている人
  • ライブラリのチェックをしてないとどんなことがあるのか気になる人

社内ツール(Slack)

弊社では、コミュニケーションツールとしてSlackを使っております。

最近よく聞く「オープンな文化」を目指し、みんなパブリックなチャンネルで意見を述べ、質問もしています。僕個人では、必要な情報が過去の投稿から見つかることがあり、コミュニケーションコストが削減されているのを感じています。

また、弊社ではチャンネルの乱立を防ぐべく、チャンネル作成者の制限を行っています。以前は、チャンネルを作成する際は、担当者にメンションをつけて作成依頼をしておりました。 しかし、メンションをつけると、相手に通知が飛ぶだけではなく、送り手も送っていいのかなぁ、迷惑じゃないのかなぁ、といった不安を感じてしまう側面もあり、なかなかチャンネル作成を依頼できない、、、といった状況が頻発しました。

そこでBotになら気兼ねなく送れるのでは?という発想の元、Slackbotプロジェクトが発足しました。

Slackbot

SlackbotとはSlack上で動くBotのことです。

社内では、「チャンネルを作成して」という依頼をSlackbotに送ることで、その依頼を権限持ちの「誰か」が実行してくれるように、申請承認チャンネルに投稿してくれます。

実装について

Techblogという位置づけ上、技術的な話もしておきます。

使用環境

  • 言語: Golang 1.11.2
    • パッケージ管理: dep
    • slack用のパッケージ
  • サーバ: AWS EC2

機能一覧

現在搭載されている機能としては大きく分けて次のとおりです。

  • ユーザ招待機能
  • チャンネル作成機能
  • チャンネルリネーム機能
  • チャンネルアーカイブ機能

実装で苦労した所

別チャンネルに対してのThreadでの返信機能実装が大変だった

作ってきたSlackbotは基本的にはThreadとチャンネル間でのやり取りを行います。つまり、Slackbotを通して申請用と承認用の2つのチャネルに投稿されます。

Slackの仕様として、Threadで返信するためには、Threadで返信したい対象メッセージのタイムスタンプ情報が必要です。つまり、申請用のチャンネルで申請を出したあと、申請メッセージのタイムスタンプを承認用のチャンネルで保持しないといけないのです。普通なら、ここでKVSのようなもので保持するんですが、初期段階では用意してませんでした。

KVSなどが無い状態でどうしたのか、というと次の画像が語っているのですが、申請メッセージの中にタイムスタンプ情報を入れてます。そうすることで、ダイアログで承認を実行すると、今の実装では、タイムスタンプ情報をリクエストの中に乗せて、送信してくれます。 あとは、ダイアログ送信時の処理部分で、タイムスタンプ情報を扱うことで、実現しました。

承認画面の画像
承認画面

// 本来のコードとは違います
// GetTimestamps ... get timestamp from message
func GetTimestamps(message slack.AttachmentActionCallback) (string) {
    fieldLength := len(message.OriginalMessage.Msg.Attachments[0].Fields)
    applyTimestamp := message.OriginalMessage.Msg.Attachments[0].Fields[fieldLength-1].Value

    return applyTimestamp
}

別チャンネルの投稿と紐付いているタイムスタンプを返り値として渡すという関数を作りました。 タイムスタンプは、一番最後の要素にするので、 fieldLengthを使って最後の要素の Valueを取得しています。

最後に、申請結果をThreadで返す機能を作ったということもあり、この大変さに気づくまで遅くなりました。 というのもCallbackなどを設定しているので、てっきり前のダイアログ送信イベントでトリガとなったメッセージのタイムスタンプ情報を持っていると思っていたからです。(持っているはずがなかった…)

Dialogを使用した別チャンネルへの投稿が大変だった

このテーマだと、 messageAPIをSubmission時に叩けばいいんじゃないか?と思われるかもしれません。まさしくその通りで僕もそのまま実装しました。 でも、なんのエラーもなく、投稿されないという状況に陥りました。

原因は確実にこれ!と言えるわけではありませんが、いろいろ試してみたところ、Submission時に渡せる要素の長さに制限がありそうでした。

timestamp情報を先程持たせているという話をしましたが、そのtimestamp情報は申請元と承認側のtimestampを一度に送信しているため、文字列の長さが比較的長くなります。 画像にあるように、 1552527866.001200が2つある状態でそれに追加で originalTimestampというようなstructのフィールド名もつけているため1要素で渡す情報が長くなりました。 最初は定義したstructに問題があったのか、とか受け取り側のプログラムに問題があったのかなど考えました。 最終的に、渡すデータを短めの適当な値で試したところ、思った通りに動作したため長さに原因があることがわかりました。 なので、もともとoriginalTimestamp: 1552527866.001200, timestamp: 1552527866.100000としていたところを、 originalTs: 1552527866.001200, ts: 1552527866.100000に変更することでギリギリしのげました。

長さについては特に言及されていなかったので、試行錯誤が大変でした。 原因っぽいところに気づいて、無事動く状態に持っていけたのは非常に良かったですが、この原因調査が全実装のなかで一番大変でした。

ライブラリ自体に大きな変更があったときの対処が辛かった

例えば次のコードは、メッセージをThreadに対して送信するための関数です。

// 変更前のコード
// ReplyMessageToThread ... Threadで返信するための関数
// message: 返信する投稿内容, ts: Threadの対象の投稿のTimestamp, p: 投稿メッセージのパラメータ
func (s *SlackListener) ReplyMessageToThread(channelID string, message string, ts string, p slack.PostMessageParameters) error {
    p.ThreadTimestamp = ts
    if _, _, err := s.Client.PostMessage(channelID, message, p); err != nil {
        return fmt.Errorf("faild to post message: %s", err)
    }
    return nil
}
// 変更後のコード
// message: 返信する投稿内容, ts: Threadの対象の投稿のTimestamp, p: 投稿メッセージのパラメータ
func (s *SlackListener) ReplyMessageToThread(channelID string, message string, ts string, p slack.PostMessageParameters, a slack.Attachment) error {
    p.ThreadTimestamp = ts
    if _, _, err := s.Client.PostMessage(channelID, slack.MsgOptionText(message, false), slack.MsgOptionPostMessageParameters(p), slack.MsgOptionAttachments(a)); err != nil {
        return fmt.Errorf("faild to post message: %s", err)
    }
    return nil
}

PostMessageParametersに、AttachmentsというPropertyが入っていたことで、スッキリとかけていましたが、ライブラリの変更により、 PostMessageParametersのstructから、Attachmentが分離されました。その変更により、すごい長くなりました…。 このように、 PostMessageParametesrsAttachmentsを使っていた部分はほとんどが使えなくなりました。変更履歴を確認した所その変更が取り込まれたのが気づいた月の約3ヶ月ほど前でした… ライブラリの変更を追わずに、実装をし続けることで、こんなに大変なことになるんだ…ということの勉強になりました。 それからは、Slackにライブラリの変更通知を飛ばすように設定しました。

現状の辛い運用

Threadで返信するために、タイムスタンプ情報が必要だ、と述べたんですがそのタイムスタンプ情報は申請メッセージの中にあります。 ただ、それは運用している人にとっては全く意味のないものなので、表に出すようなものではないです。本来必要なものは、申請メッセージとの紐付け、つまり申請メッセージへのパーマリンクです。 若干申請者とのやり取りをThreadで行うことがあるのですが、それを手助けする機能が今無いのです。 これは非常に辛いと思うので、改善していこうと考えています。

改善への道

まず、KVSを導入しメッセージ間の紐付けをそこで行います。 KeyとValueとしては、それぞれ 申請元メッセージのタイムスタンプと、承認メッセージのタイムスタンプとします。 そうすることで、承認メッセージのタイムスタンプ情報を元に、元のタイムスタンプ情報を得ることができます。 また、元メッセージのタイムスタンプ情報がKVSの中に保持されているので、承認メッセージにタイムスタンプ情報が不要になるため、代わりにパーマリンクを貼ることができます。 パーマリンクを取得するAPIとしては、chat.getPermalink - slackを使用します。

おわりに

学んだこと

  • OSSのライブラリを使うときは、アップデートを気にしておかないと、動かなくなる
    • 通知を飛ばすことでちゃんとアップデート情報を追う
  • SlackのAPIについての知識
  • ダイアログを送信したときのリクエストの長さに上限があり、正常なステータス返しても処理が実行されないこと

今後の改善

  • KVSのような仕組みを導入
  • タイムスタンプ情報ではなくパーマリンクを乗せる

以上の2つをこれから取り組んでいこうと考えています。

感想

全社で職種関係なく使うコミュニケーションツール内で、実現したいことをサポートをするBotを作って、色んな人に使ってもらえる経験をできてよかったなーと思います。社内で使用していることもあり、すぐにフィードバックを貰え、改善できる環境っていうのはエンジニアにとって非常に楽しい環境でもあります。 また、この開発を通して、Slack APIについては社内でも詳しい方になった気がして、なんか嬉しいです!

今後も社内で使っているSlackbotがより良いものになるようにしていきたいと思います。

ありがとうございました!

予約1年待ち!「ヴァル研究所」社内見学に行ってきました!

はじめに

こんばんは。もうすぐ新卒1年目が終わりそうで焦ってるM.Kです。

先日、予約したら1年待ちと噂のカンバン運用で有名な「株式会社ヴァル研究所」(以下、ヴァル研究所)のオフィス見学ツアーにマーケ・エンジニアの計7名で参加しましたので、その様子について書きたいと思います。

ヴァル研究所とは?

ヴァル研究所とは、路線検索のパイオニアとも言われている「駅すぱあと」を始めとする様々な有名サービスを提供している1976年に設立された会社です。 今回のツアーの案内もしていただいた、カイゼン・ジャーニーの著者である新井剛さんが所属しており、新井さんの知識と経験も加味されて、会社全体で多くの業務カイゼンが進んでいます。

ヴァル研究所エントランス
ヴァル研究所エントランス

オフィス見学ツアーとは?

今回参加したオフィス見学ツアーは、ヴァル研究所が実際に業務カイゼンのために導入している「見える化・カンバン・カイゼン」の活用事例を紹介してもらえるツアーです。 ツアーの内容は、開発部やマーケティング部、総務部など、様々なチームのメンバーが、各々で導入しているカンバンやカイゼンの方法について実際に使用しているカンバンの前で説明してもらえる贅沢なものになっています。

予約したら1年待ちのこのツアーですが、弊社森實がもともと新井さんと面識があり、入社前から予約をしていたため、今回は参加することができました。

オフィス見学ツアーの様子

ロビー

ツアー前に集合したロビーですが、すごくおしゃれで、様々な賞も飾られていました。 中でも、弊社社員一同が最も盛り上がったのは、電光掲示板に弊社への歓迎のメッセージを表示してもらえたことです。 なかなか電光掲示板での歓迎はされないので、とても新鮮で嬉しいおもてなしでした。

エントランスの歓迎電光掲示板
エントランスの歓迎電光掲示板

ツアー開始

実際のカンバンを見せて頂く前に、ヴァル研究所の歴史についても学ばせてもらいました。 私達の後ろにあるのが歴代の紙の時刻表なのですが、今でも一部はここから手作業でデータを入力したり、実際に徒歩にかかる時間を計りに現地へ行ったりしているそうです。

弊社社員での集合写真
弊社社員での集合写真

業務カイゼン用カンバン紹介

本当に多くのカンバンを拝見させて頂けたので、その中でいくつかピックアップして3つ紹介していきます。

チーム内タスクの見える化

最初に、お邪魔させていただいた総務部で、週・日単位でのタスク管理のカンバンを見ました。 カンバンとしては、

  • 今週の予定
  • 今週のタスク
  • 待ちタスク(他の人に渡しているタスクを置いておく)
  • 本日のタスク
  • 完了したタスク

に分類されています。 そして、チーム内でのフローとしては、次の日にやるタスクは毎週金曜日に決める。毎朝の朝会でその日に取り組むタスクを決めて、タスクを「今週のタスク」から「本日のタスク」に移動する。最後に、終わったらタスクを「完了」に移動するとのことです。

タスクの見える化の役割もありますが、タスクを消化していくことで達成感も味わうこともできるのでモチベーションが上がる方法だなと感じました。

タスクの見える化用カンバン
タスクの見える化用カンバン

非効率の見える化

監査部では、VSM(バリュー・ストリーム・マッピング)と呼ばれている業務のプロセスを見える化して無駄を改善していくためのカンバンが印象的でした。

自分たちの業務のプロセスを全て書き出し、より効率化できる部分はないかをチームで洗い出しているそうです。 具体的には、エクセルの作業をモブプログラミングでの改善などをして、以前は42時間かかっていた作業を17時間ほどまで短縮できたとのことでした。

非効率の見える化用カンバン
非効率の見える化用カンバン

残業の見える化

マーケティング部で見たのは、各社員がどれだけの残業をしたかを「う○ち」の絵で見える化したカンバンです。 フレックス制度を利用し、定時前に帰れたらお金の絵を書いて溜まった「う○ち」は相殺できるとのことです。 残業が多いことを見える化することによって、忙しい理由の分析をより正確にやることができ、結果的に残業時間の削減につながっているといいます。

残業の見える化用カンバン
残業の見える化用カンバン

社員サポート用のカンバン紹介

ここからは、業務上のタスクの管理ではなく、目では見えない心やスキルに焦点を当てたカンバン運用について2つご紹介します。

スキルの見える化

1つ目のカンバンは、誰が何のスキルが得意で何を身に付けたいと思っているのかを見える化させたカンバンです。 スキルを見える化することで、「〇〇については〇〇さんに聞こう」「〇〇君は〇〇をもっとやりたいから次は任せよう」などの行動をサポートすることができるようになったとのことです。

スキルの見える化用カンバン
スキルの見える化用カンバン

気持ちの見える化

出社したときと退社するときに、社員が今の心理状態を色で分けて貼るためのカンバンです。 心の状態を見える化することで、管理者は「この人最近落ち込んでる」「この人出社と退社で心の状態が落ち込んでる。仕事で何かあったのかな?」などを考えることができ、いち早くサポートをしてあげることができるとのことです。

気持ちの見える化用カンバン
気持ちの見える化用カンバン

他にも「モヤモヤの見える化」や「チーム目標の見える化」、「価値観の見える化」など多くの「見える化」の施策が実践されていました。 チームごとで使用してるカンバンも異なり、日々カイゼンをしていることがとてもよく伝わってきました。

おまけ

カンバンとは違いますが、とても面白いかつ便利な見える化がされていました。 それが、「エラーの見える化」です。 毎分リクエストをサーバーに送り、もしもエラーが返ってきたらダ◯スベイダーが音を立てるのだそうです。 コンソールを毎回見に行かなくてもエラーがわかる仕組み作りとそれをみんなが見えるようにする施策はとてもいいですね。

エラーの見える化
エラーの見える化用

まとめ

ヴァル研究所はまさに「見える化」を全社的に取り組んでいる企業であることがとてもよくわかるツアーでした。 「カンバン」と言っても種類が豊富で、チームによって全く違いました。 どのチームも各々にあった方法を模索し、実践し続けていることが、説明していただいた内容からも、社内に置いてあるカンバンからもよくわかりました。

チームで施策全体や各メンバーの業務、心理、スキルについて共通認識を持つのはとても大変なことです。 そこを、ヴァル研究所のようにカンバンを使って「見える化」を進めていくと、問題発見から話し合い、そして解決までのスピードが加速する気がしますね。

弊社もまだまだカイゼンしていく課題が多い会社ではありますので、少しずつ、ヴァル研究所の皆さまを見習ってカイゼンをしていきたいと思います。

【JaSST'19 Tokyo 登壇レポート】テストプロセス改善「プロばこ 4 JaSST」ワークショップを実施しました

こんにちは!メディアシステム部の森實です。

f:id:samuraiRed:20190328123321j:plain

さて、今回は実行委員の坂さんから声をかけていただいた縁で、3/27〜28に日本大学理工学部 駿河台校舎1号館で行われたソフトウェアテストシンポジウム 2019 東京(以下、JaSST'19 Tokyo)にて「プロばこ 4 JaSST」というワークショップをプロジェクトマネージャ保護者会として実施してきたのでレポートします。

 

 

はじめに 

ソフトウェアテストシンポジウムってなに?

ソフトウェアテストシンポジウム(以下、JaSST)とは、『ソフトウェア業界全体のテスト技術力の向上と普及を目指して、NPO法人ソフトウェアテスト技術振興協会(ASTER)』が全国各地で開催するイベントで、2003年から行われています。

JaSSTにはソフトウェアテスト技術に関心の高い多くの参加者が集まり、交流を深めることのでき、2003年から行われています。

 

JaSSTソフトウェアテストシンポジウム

 

プロジェクトマネージャ保護者会ってなに?

プロジェクトマネージャ保護者会は、2016年当時、野村総合研究所だった僕とエクサだった稲山さん(現在はUZABASE)ではじめたユニットです。現在では正メンバー5人となり、プロジェクトマネージャを支援する活動をすることを目的に、パネルディスカッションやワークショップを不定期に行っています。

 https://www.facebook.com/pmhogosyakai/

 

プロばこってなに?

プロばこは、プロジェクトマネージャ保護者会で作っているプロセステーラリングを学ぶためのワークショップコンテンツです。

各会社にはいわゆる開発標準プロセスがあると思いますが、単にそれにのっかってもプロジェクトはうまくいきません。制約事項、プロジェクトの特性に応じてそれらのプロセスをテーラリングして使うために、チームの作業プロセスのデザインと合意形成のフローをワークショップ形式で体得することを目的としています。

 

プロばこ 4 JaSSTってなに?

プロばこは通常プロセステーラリングを行いますが、今回JaSSTの参加者がテストに精通した技術者が集うということで、対象をテストに関する部分に絞っています。

テスト技術者やテスト環境の「あるべき姿(なりたい姿)」を吐き出し、どうしてそうなりたいのか、そのためには何をしたら良いのか、を初めて会った人同士のチームで考え、共有するコンテンツです。

 

speakerdeck.com

  

 

ワークショップ

テスト技術者としての思い

今回は、90分という枠の中で、テスト技術者としての積もり積もった思いをできるだけ出してもらい、その本質を見直して、正しいアプローチをチームで議論することが目的です。

参加者が主体的にならないとこのワークはできないのですが、本当にみなさん集中して、とても楽しそうに、思いの丈をぶちまけてくれたと思います。

特にテストというのは、リードタイム短縮と障害削減のバランスが非常に難しい部分です。テストエンジニアとしても理想と現実のギャップにおける葛藤を感じるとともに、前向きに考えていることが普段からあるのでしょう。

同じテスト技術者同士の議論、とてもいい顔してますよね!!

f:id:samuraiRed:20190327175425j:plain

 

テスト技術者が感じていること

 僕が見ていて感じたことの一番は、多くの場合、テスト技術者というロールがプロジェクトの中では大きな意味付けをされていないという現実です。

プロジェクトマネージャにとって、プロジェクト計画書、全体テスト計画書、全体リリース計画書というのは、プロジェクトの初期にほぼ同時に作らなければいけない大切な3つの計画書です。

しかし、書き出された付箋を見るからに、そもそもテスト計画がなかったり、テスト期間をバッファと見做されていたり、テスト云々の前にプロジェクトが正しくスタートを切れていないことに起因する、プロジェクト管理上のあるべき姿(ありたい姿)がとても多く挙げられていました。

昨今、アジャイル界隈でもQA部門を開発チームに入れるという話がよく聞かれるようになりましたが、言葉は違えど、現場の意見としてそういう関わり方をしたほうがいいということを感じていることもよくわかりました。

f:id:samuraiRed:20190327175534j:plain

 

おわりに 

テスト技術者としてできることからはじめる

みなさんがすごくステキだったのは、明日から変えるために、現実的な世界に何を持ち帰るかを真剣にディスカッションしていた姿です。

それは、テスト仕様書のフォーマット改善を提案してみるとか、開発チームにお菓子を差し入れしてみるなどの本当に小さな一歩でしたが、きっとその一歩の積み重ねが大きな成果につながっていくのだろうなと感じました。

f:id:samuraiRed:20190327182257j:plain


次回予告

ぁ、(プロジェクトマネージャ保護者会としての活動は)未定でした・・・ので、オファーお待ちしておりますw

若者の登壇の場も募集しておりますので、いつでもお声がけください。

Leveragesのエンジニア組織紹介します! ~ミートアップ編~

はじめに

お久しぶりに更新です。KTです。

これから2~3回に分けて、Leveragesのエンジニア組織についてご紹介できればと思います。

第1回目は、月に1回行われるエンジニアミートアップについてです。

目次

  • エンジニアミートアップって何?
  • 具体的にどんなことしているの?
  • おわりに

エンジニアミートアップって何?

f:id:taniai-lvgs:20190320101750j:plain
ミートアップの様子

エンジニアミートアップとは、各事業部のエンジニアが集まり、現状報告や全体周知をする会です。

月に1度、約1時間ほどの短い会ではありますが、様々なコンテンツを持ち回りで運営しております。 全エンジニアが参加し、事業部間での知の共有を目的としております。

具体的にどんなことしているの?

過去に行ったコンテンツは、こんなものがあります。

  • 今月入社のメンバー紹介
  • イベントの周知
    • 月に1度、BIT VALLEY -INSIDEというイベントを開催しているので、そちらの詳細について
  • 発表練習の場
  • 持ち寄り勉強会
  • 各事業部の困りごと、やってること共有

この中から、いくつかを詳しく紹介させていただいます。

発表練習の場

まずは、登壇前の練習の場としてこのミートアップの活用です。 外部の登壇機会がある人が、この場を使って発表練習をする時に使われます。

単に登壇者の発表練習としての機会以外にも、知の共有といったメリットもあり頻繁に実施されているコンテンツの1つです。

例えば最近では、JAWS Days 2019に登壇したメンバーが、登壇前に練習の場としてこのミートアップを使っていたり、

tech.leverages.jp

過去にはTwilioのMeetupに登壇したメンバーのレビューが行われたりもしました。

tech.leverages.jp

持ち寄り勉強会

持ち寄り勉強会も開催されたりもします。 個人単位や、事業部単位で得意な分野を他のエンジニアに共有する場として使われています。

例えば、フロントエンドのベストプラクティスについて持ち込みで、勉強会を開いてくれたり、

qiita.com

事業での取り組みを他事業部に展開するにあたって、前段階で勉強会を予定してくれたりと、個人や、組織単位で知の共有を行う取り組みもなされています。

各事業部からの共有

最近からですが、「各事業部の困りごとや、力を入れているところ」の共有を追加し、各部署が何をしていて、何に困っているのかを全員が把握できるような機会を作り出すことができました。

そもそもなぜそんな機会が必要かというと、自分以外の部署がやっていることを把握できなくなってきたからです。

  • メンバーも増え部署内で完結することが多くなってきたこと
    • 結果、部署内でのやりとりは多くなったが、他部署とのやりとりは減った
  • 働くオフィスの階や、場所自体が異なるためリアルなコミュニケーションが減った
    • Slack上の表面的な情報だけでは他部署の事例を知ることは難しい

この結果、他の部署が前にやっていたことを再度実装するようないわゆる「車輪の再発明」が起こる状況にありました。

そこでこのミートアップで、各部署の現状を共有することによってこうした負をなくしていこうというのが目的です。

まだ、初めて間もない取り組みなので具体的な成果は見えませんが、参加しているメンバーの満足度は高かったようです。

おわりに

まだまだ取り組みとしては、始まったばかりで内容に関してもこれから精査されていくことになると思いますが、参加している側の所感として、他事業部の取り組みを知る機会は大切だと感じました。

例えば、よく言われている車輪の再開発のように他部署で利用されている技術をうまく利用したり。 サービスによっては同じようなフェーズを経験することになるので、そうしたときの「転ばぬ先の杖」的な状態を会社全体で保っていけることで、開発スピードを加速させ事業に貢献できる開発組織を作り上げる事ができると思います。

それ以外にも、外部で登壇する人が増えてきて「自分もやりたい!」と競争心を燃やしてくれる機会であったりと、個々人の成長にもうまく働いているように思います。

参加者自体の満足度を担保するためにも、定期的なコンテンツの見直しも行われています。

最後までお読みいただき、ありがとうございました。 次回は、エンジニアの作業環境などについての記事をお届けできればと思います。