エンジニア生存戦略論と、生存に向けての場の提供

メディアシステム部 部長の久松です。

今回のテーマに関わってくるので自己紹介させて頂きますと 2000年からIT革命真っ只中のIT業界にインフラの研究開発から入り、20年が経とうとしています。

  • 20代 大学教員を目指す
    • インターネット動画配信、P2Pをテーマに研究員として活動
    • 博士進学翌年にリーマンショック、その後 事業仕分け・震災
  • 30歳 学術からビジネスへの転身
    • 博士取得と共にポスドクのポジションが無期延期になり、就活も難航し、就職課に「進路未定」で提出
    • 高学歴ワーキングプアとしてアルバイトプログラマに(額面で月給15万円)
    • ベンチャー企業に就職後、やがてインフラ責任者をやりながら気がつけばリクルーターに
  • 現職への転職
    • エンジニアの取りまとめの役割ですが、ほぼVPoE
    • エンジニア紹介事業のレバテックでは技術顧問としてエージェントの専門性向上を担当
    • エンジニアキャリアに悩んだり採用したりするうちに新卒・中途採用、オンボーディング、新卒・博士キャリアをテーマにしたセミナーをするようになる

今回は私が現在、レバレジーズ社員やエージェント教育の過程でお話しているエンジニアの生存戦略とその機会提供についてご紹介させて頂きます。

エンジニアを勤め上げるにあたっての脅威

人生100年時代と言われている中、年金の支給タイミングの後ろ倒しを加味すると80歳程度までは 何かしらのキャリアチェンジ・ジョブチェンジを繰り返しながら行きていく必要があります。 特にITエンジニアとしては

  • 技術トレンドの移り変わり
  • AIによる自動化
    • Sketch2CodeだったりAmazon CodeGuru Reviewerだったり足音は聞こえますね
  • 「巨人の肩の上」に乗ったできる若手
    • 構築がスムーズな開発環境、溢れる教材、溢れるソースコード、QA環境・・・
  • 海外からの高度人材
  • フリーランスやクラウドソーシングの一般化による有期のスポット人材の増加

を考えなければなりません。

生き残りやすいエンジニアの特徴

私自身が事業仕分けられたということで需要の底を経験したということもありますが、20年の間に

  • ITバブル
  • クラウドバブル
  • SNSバブル
  • ソーシャルゲームバブル
  • AIバブル

と各種のバブルと共に数多くのエンジニアの栄枯盛衰を見ることができ、生き残りやすいエンジニアの特徴が見えてきました(図)。 これを意識し、メディアシステム部のエンジニアには様々な機会に挑戦してもらっています。

エンジニア生存戦略

ベースとなる基礎知識

計算機の基礎、インターネットの基礎が挙げられます。特にインターネットの低レイヤについての知識はJavaScriptのフレームワークのようなハイレイヤーの技術に比べると革新速度はゆっくりですし、パケット交換方式は当面続きそうなので臆することなく身につけておくことをおすすめします。

専門性 2つを時流に合わせて変化

ヒトとは基本的に怠惰なものなので「可能であれば身につけた一つの技術で生涯食べていきたい」と思いがちです。 ただIT業界とは無情なもので5年程度でパラダイムシフトが発生し、身につけた技術は骨董品になります。 加えていかにも流行りそうな顔をして近づくバズワードというのもあります。

どちらか一方の専門分野が廃れても良いように2つの専門性、加えて時流に合わせて変化させることが必要です。

コミュニケーション力

他業種とのコミュニケーション力です。よくあるできるエンジニアの凋落パターンとして、

「いつも何をやっているのかよく分からないし、何を話しているか分からないし気難しそうなので話しかけにくいけど流行りの技術を身に着けているらしいので今は仲良くしておくと得だ」

と、周囲に思われているうちは需要があるものの、流行の終焉と共に周りから人が居なくなるというものです。

いざというときに周りに助けを求めるためにもコミュニケーションは取りましょう。転職してもフリーランスになっても繋がりは役に立ちます。

リーダーシップ、マネージメント、プレゼンテーション、教育、採用より2つ以上

いくつか補足をしておきます。

プレゼンテーション

プレゼンテーションはブログの投稿でも構いません。その人が何をしているかを自分以外に積極的に知ってもらう術を持っているかということです。

短期的には予算の出どころに対する説得や説明に繋がります。中期的には「指名をもらう」ことに繋がりますし、怠ると控え目に表現して「忘れられてしまう」ということになるケースも多くあります。  

教育

教育は自分の持っている技術や知識を後進に伝えられるかどうかです。特に知識の更新の早いIT業界では、知り得た事柄をまとめて周りに拡散していくという能力が強く求められるようになっています。

採用

採用はチームビルディングに繋がります。人材不足という中でどれだけ自分の属している組織に勧誘し、人を引き込むことができるかというスキルは年々高まっています。

まとめ

1990年前後の金融バブルを解説する専門家の間でも目にしますが「バブルの中に居る人はバブルだと思わない」と仰っしゃります。先に述べたIT界隈のバブルの中の人も、永遠の需要と反映を信じている人が多く居ましたが、今のエンジニア売り手市場もバブルですし弾けてから改めて認知されるでしょう。

良いのか悪いのか分かりませんが80歳まで労働しなければならないと仮定した場合、ジョブチェンジやキャリアチェンジを想定して生きなければなりません。   一つのヒントとして「これは自分の仕事じゃないな」という仕事が目の前に現れたとき、それを受け入れるか拒否するかというのが分かれ目になるのではないかなと考えています。

Engineering Manager vol.2 Advent Calendar 2019 qiita.com

「てっくらんち」はじめました

ogp

はじめに

メリークリスマス!(早い)
レバレジーズ株式会社エンジニアの村本です!

12月も半ばに差し掛かり、ようやく冬らしい天気になってきました。皆様はどうお過ごしでしょうか。
我が家では電気カーペットを購入したのですが、あれは人をダメにしますね。最高です。

ということで、Leverages Advent Calendar 2019 11日目の記事です。

今回は、有志のエンジニアで開催している勉強会「てっくらんち」についてご紹介したいと思います。

TL;DR

  • ランチの時間に勉強会を始めました
  • ゆる〜い雰囲気作りを目指しています
  • 発表希望者が増加中...!
  • Youtube Liveで配信する(かも)...!?

「てっくらんち」ってどんな勉強会?

お昼にやっているゆる〜い勉強会です。

毎週金曜日に開催しており、社内エンジニアの発表をお昼ごはんを食べながら聞くスタイルの勉強会です。
発表者は毎回一人で、発表時間は15分〜30分程度、質疑応答も含めると30~45分ほどの内容になっています。

ジャンルは様々で、エンジニアの生存戦略的な内容から、Dockerの踏み込んだ話まで、技術に関する内容であれば何でもOKな形をとっています。
発表者も様々で、あらゆる部署のエンジニアや、フリーランスでJoinされている方、支店や外勤のエンジニアなど、社内の多くのエンジニアが参加しています。

この勉強会の目的としては「お昼の時間を使い、自分が知ってる技術を自慢して、社内の技術力を底上げをしよう!」というものを掲げています。
元々社内の勉強会には、エンジニアミートアップという社内のエンジニア全員が集う会があり、そこに発表枠が設けられていたのですが、発表ハードルが高く、開催頻度が低いことから、発表者が少なく、社内でのアウトプットがあまり活発ではない印象でした。

そこで、お昼の時間にローカルな場で勉強会を開催することで、発表ハードルを下げ、アウトプットの場を増やそうというのが「てっくらんち」の成り立ちです。

運営は有志のエンジニア数名で行われており、2019年7月頃から始めて累計16回開催されました。

ちなみに「てっくらんち」はひらがなで固定しているのですが、名前の由来も以下のようにかなりゆる〜くベンチャーらしい素早い意思決定がされています。

chat

「てっくらんち」のる〜る

「てっくらんち」では堅苦しくならない程度で、会の目的や存在意義がズレないように3つだけルールを定めています。

1. 発表者は次々回の発表者を指名できる権利を持つ

勉強会を重ねるにあたって発表者が固定化されることを防ぐために、発表者には次々回の発表者を指名できる権利を持たせています。

俗に言う「いつものメンバー」だけでやっている勉強会では参加しづらく、そういう勉強会はメンバーの意思が弱くなった時点で衰退していきます。このルールを定めることで、発表者の新陳代謝を促し、参加しやすく続きやすい勉強会になることを意図しています。

またこのルールでは、知り合いのエンジニアから指名されることになるため、普段アウトプットの少ないエンジニアも発表しやすくなるのではないかという狙いもあります。
実際に、自分から発表したいです!と手を挙げるより、知り合いから「お前のこの話聞きたいから話してよ〜」って言われる方が気持ちが楽ですよね。

とはいえ、いきなり「次はお前だ m9(^Д^)」とか言われて揉めても困るので、予め「指名するかも」ということを指名予定者に伝えることを推奨しています。

実際にこのルールを運用してみて、新卒エンジニアや、普段前に出て話すことの少ない人が発表者になっていたりするので、想像以上にうまく機能しているように思います。

あと、嬉しい誤算としては、当初は隔週開催予定だったのですが、発表者希望者が増えたことにより、毎週開催に切り替わりました 😆

2. 堅苦しくしない (お昼だもんw)

これは会の雰囲気を定めつつ、発表のハードル下げるために設けているルールです。
折角お昼ごはんを食べながら発表を聞くので、殺伐とした空気にするのではなく、一エンジニアとして、技術を楽しめるような会にしたかったという思いがあります。
発表者としても殺伐とした空気より、和やかな雰囲気の方が話しやすいですよね。

とはいえ、外部の発表の練習として真剣なフィードバックが欲しいという方もいますので、発表者のリクエストがある場合には答えるように柔軟な対応をしています。

ただ、正直これはまだ完璧には機能できていないと思います。
やはり発表を聞くとなると発表者以外喋らないので、少々堅苦しい空気になってしまいます。
この空気を打破するために、発表スライドにコメントを流してみるなどアイディアでの解決を考えています。
最終的には発表中に良い野次が飛ぶくらいゆる〜い雰囲気になれば良いなと思っています。

3. チャレンジングな姿勢を忘れない

折角アウトプットのハードルが低い勉強会なので、失敗や間違えを恐れずに、大胆な意見が出やすいようにこのルールを設けています。
正確な情報をアウトプットするのはとても良い事ですが、自分の意見や思いを伝えることも同じく重要だと考えています。自分の意見をアウトプットする際には、反論やマサカリなどが飛ぶ恐れがありますが、ローカルな場でご飯を食べながらアウトプットするようなゆる〜い場所では、失敗をしても大した痛手にならないし、むしろ大胆に自分の意見を披露することで今までなかった視点からフィードバックを貰える可能性も出てきます。

また、フィードバックに関しては質疑応答の時に貰えなくても、同じ職場で働いている社員同士なので、雑談のタイミングや社内のチャットツールの中で貰えたりします。なので、発表に対する意見はかなり貰いやすい環境であるということは実感しています。

質疑応答やフィードバックで技術的な議論が活発にされるのが理想です。

実際の様子

event1
event2
event3

まとめ

アドベントカレンダーの11日目ということで弊社の勉強会をご紹介いたしました。
ランチタイムローカルな場で行うことで、アウトプットのハードルを下げつつ発表者を増やす仕組みを作っています。

また、実際に4ヶ月程運用してみて、以下のような傾向が見受けられました。

  1. アウトプットする人が増えた!
  2. 社内エンジニアの技術スタックを知る良い機会になった!
  3. 全然知らない技術に触れる機会が増えた!

個人的な感想としては、一人のインプットには限界があるので、自分が深堀りができていない技術や体験できていない技術を、身近な社内のエンジニアを通して学ぶことができるのは最高だと思っています。
(人間の集合知ってすごい...!)

今後について

「てっくらんち」は既に次々回まで発表枠が埋まっており、引き続き開催する予定です。

また、徐々にアウトプットの範囲を広げていくことも検討しています。
その第一歩として、Youtube Liveでの配信を検討しています。

元々、支店や外勤のエンジニア用にMeetを使ってストリーミング配信を行っていましたが、アーカイブが残らず、参加できなかった場合の救済策がありませんでした。そのような流れから、Youtube Liveで見逃し配信を可能にし、シェアしやすいようにしようとしています。
また、Youtube Liveに移行することで、外部公開が可能になるので、内容によっては公開するなどして、徐々にアウトプットの範囲を広げていく計画です。

ということで、今後も「てっくらんち」を通して技術力の底上げに寄与しつつ、もっと盛り上がるように努力し続けていこうと思います。

We Are Hiring

レバレジーズでは「てっくらんち」のような社内での勉強会や「ヒカラボ」という外部の講師を招いたパブリックな勉強会も開催しております。
また、最近では横浜に開発拠点ができるなど、新たな働き方も創出しています。
弊社に少しでも興味を持っていただいた方はご連絡いただけると幸いです。

https://recruit.jobcan.jp/leverages/

we_are_hiring

ビアバッシュと題して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つ目のカンバンは、誰が何のスキルが得意で何を身に付けたいと思っているのかを見える化させたカンバンです。 スキルを見える化することで、「〇〇については〇〇さんに聞こう」「〇〇君は〇〇をもっとやりたいから次は任せよう」などの行動をサポートすることができるようになったとのことです。

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

気持ちの見える化

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

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

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

おまけ

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

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

まとめ

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

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

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