「Engineers in VOYAGE」が ITエンジニア本大賞2021 技術書部門ベスト10に選ばれました #voyagebook

こんにちは。技術広報の丹野 (@tan2) です。とてもうれしいお知らせがありました。

ITエンジニア本大賞 技術書部門ベスト10に選ばれました

「ITエンジニア本大賞」はこの1年を振り返っておすすめしたい技術書・ビジネス書をITエンジニアのみなさんの投票によって選ぶというイベントです。2014年からスタートして今回の「2021」で8回目の開催となります。
 そんな素晴らしいイベントで、2020年8月に出版された「Engineers in VOYAGEー事業をエンジニアリングする技術者たち」(ハッシュタグ #voyagebook) が「技術書部門ベスト10」に選ばれました!

f:id:tan2jpn:20210121151004p:plain
ITエンジニア本大賞2021 技術書部門ベスト10

www.shoeisha.co.jp

 これまでにも本書についてBlogやTwitter、Facebookなどで多くの反響をいただいていましたが、こんなにも多くの方々から投票いただいて嬉しい限りです。

大賞を決定するプレゼン大会へ

 そしてなんと 「ベスト10の中で特に投票の多かった以下の技術書3冊」 にも選ばれており、2/18 17:15 に行われる「Developers Summit 2021」【18-A-9】「ITエンジニア本大賞 2021」プレゼン大会 へ進出することなりました。
 プレゼンの後にオンライン視聴したみなさんによる投票で「技術書部門大賞」が決定となります。

 ITエンジニア本大賞 技術書部門の近年の大賞を見ると 「レガシーコードからの脱却――ソフトウェアの寿命を延ばし価値を高める9つのプラクティス」「エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング」 など名著揃いで震えますね...。

さらにパネルディスカッションへ登壇

 またプレゼン大会の翌日に、同じく「Developers Summit 2021」の 2/19 10:00 の枠で、本書に関わったメンバーがパネルディスカッションで登壇します!
 本書のインタビュアーを務めていただいた 和田さん(@t_wada)をモデレータに迎え、インタビュイーたちが「エンジニアリングで負債を返済するための勘所 ― 事業特性にあわせたリファクタリング/リアーキテクチャ/リプレイス」と題してお話しします。こちらも是非ご視聴いただると嬉しいです。

event.shoeisha.jp

書籍プレゼントのお知らせ

 今回のITエンジニア本大賞2021 技術書部門ベスト10を記念して本書を 「ブログやSNSに感想を書いてくれる方」10名にプレゼント させていただきます。簡単なものでも構いません、是非ご感想をいただけると幸いです。

以下のGoogleフォームからのご応募お待ちしております。

ITエンジニア本大賞2021 技術書部門ベスト10記念 書籍プレゼント応募フォーム

  • 応募多数の場合は抽選とさせていただくことをあらかじめご了承ください。
  • 2020年2月1日(月) 12:00を締め切りとさせていただきます。

2016年から2020年の5年間、VOYAGE GROUPで変わったこと・変わらなかったこと

これは VOYAGE GROUP Techlog Advent Calendar 2020 の25日目のエントリです。

2015年に2010年からの5年間の話を書いたので、今年はその後の5年間について書きます。

techlog.voyagegroup.com

目次

5年間で変わったこと

1. クルーが成長し、高いグレードの割合が増えた

VOYAGE GROUPはグレード(等級)制度を導入しており、高いグレードの人が増えると経営戦略が実現する確度が上がると考えています。エンジニア職は4段階になっておりE4が一番高いグレードです。

E3/E4は既存の仕組みにのって改善できるだけではなく、既存の仕組みを根本から見直し、チームを巻き込んで抜本的な改善を進めていけるエンジニアと定義してます。

f:id:voyagegroup_tech:20201224214832p:plain
グレードの割合:2015年と2020年

2015年に比べるとE3/E4という高いグレードの割合が増え、E1グレードの割合が減りました。これは、毎年8−15人採用してきた新卒達が、入社後に能力が向上し、着実に成果を積み上げ、グレードが上がっていった結果だと思います。

グラフでみるとあまり差が大きくないように見えるかもしれませんが、E1が減りE3/E4が増えたということはシニアなエンジニアがプロダクトに向き合う時間が増えるということで、成果を生み出す力や改善を進める力が確実に上がっています

クルーが成長し、高いグレードの割合が増えたことで、プロダクトが改善され、価値を生み出し、経営戦略の実現につながっていきました。

2. 「考えられる」から「実践できる」ようになった

2015年の記事では「その時点で技術的に当たり前なことをちゃんと考えられるチームが増えた」と書きましたが、それから各チームが開発プロセスを改善し、開発・運用環境に投資し、今ではほとんどのチームが実践できるようになりました。

f:id:voyagegroup_tech:20201224224711p:plain
その時点で当たり前のことをちゃんとやる。2015年12月

そのおかげで「デプロイ頻度の増加」「平均復旧時間の短縮」につながり、仮説検証のサイクルが早くなったと思います。

3. 負債を大きく返済し、攻めに使える開発力が増えた

2015年時点で、10年以上続いているメディアがあり、その他にも7,8年続いているメディアが複数ありました。広告プラットフォームも5年運営しているものを筆頭に複数運営していました。当時は負債*1がそれなりに溜まっていて、開発スピードが上がらないシステムがいくつかありました。

そこからの5年間でエンジニアが成長し、負債を返済する力が上がっていったチームが増え、2020年12月現在では攻めに使える開発力がかなり増えたと思います。

そのあたりの詳細は書籍『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』に書いてありますのでぜひご一読ください。

また、事業特性にあわせたリファクタリング/リアーキテクティング/リプレイスについてはDevelopers Summit 2021の2日目にセッションがありますので、ぜひご視聴ください。

event.shoeisha.jp

5年間で変わらなかったこと

1. お互いをリスペクトする

そーだいなるVOYAGE GROUPの裏側 #SPZ 事業の成長を止めない手段としてのシステム刷新 - VOYAGE GROUP techlogというオンラインイベントには、エンジニアだけではなく、サポーターズでプロダクトオーナー的な立ち位置の取締役が参加し、下記のような話が出ていました。

専門性が異なるメンバーで構成されたチームでは、他のメンバーの専門性が深く理解できないとしても、お互い歩み寄り話し合うことが重要だと思います。

この発言だけではなく、要所要所でチームの信頼関係が感じられるいい話が語られていました。動画のアーカイブもありますので、興味をもった方はぜひ視聴ください。

ここではサポーターズを取り上げましたが、どのチームも、職種に関係なく、お互いをリスペクトできていると思います。

2. 技術が好きで学びあう

今年はCOVID-19の影響でオフラインでの勉強会やAJITOでの交流がほとんど開催されませんでした。

そんな状況でも下記の読書会がオンラインで開催され、新卒、若手、シニアなエンジニアが学び合っていました。技術コーチである@t_wadaさん、著者であるそーだいさんを交えて深い話が聞ける機会もあり、1人で学ぶよりも理解が深まったと思います。

3. 主体性をもって発言する

VOYAGE GROUPでは技術力評価会というちょっと変わった能力評価制度を9年間実施しています。

私が評価会自体に参加することは今はないのですが、被評価者が書いた評価対象の資料と評価者が書いた評価結果レポートは全員分読んでいます。

そこから感じられることは、個々人が主体性をもって事業をエンジニアリングしているということです。チームでの方針や意思決定に対し、自分の言葉で語っています。

これは10年前から大事にしていきたいと思っていたことですし、文化として定着していると思います。

おわりに

さて、2016年から2020年の5年間で変わったこと・変わらなかったことをいくつか紹介しました。 さらに5年経った2025年にはもっとたくさんの変わったこと・変わらないことを紹介できるように、エンジニア一人ひとりが主体性をもって挑戦し続けられる文化をみんなで醸成していきたいと思います。

よいクリスマスを!

*1:t-wadaさんのこの記事を読んでない方はぜひご一読ください https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor

VOYAGE GROUPの主要な事業たちとそれぞれのカラー

VOYAGE GROUPの成長と事業開発

 VOYAGE GROUP は1999年の創業から、様々な事業に挑戦し続けることで成長してきており、継続的な新領域への挑戦、それを実現できる人・組織・文化が強みであると考えています。
 現在は、アドプラットフォーム、メディア、インキュベーションと大きく3つの事業領域に分かれており、その中に事業会社たちが含まれていますが、それぞれ歴史や規模や事業特性も違うため各々のチームのカラーは多少異なります。
 VOYAGE GROUPを横断したエンジニアリング文化 はありつつ、事業会社ごとにもカラーがあるというのが「事業開発会社」ならではの文化と言えるのではないでしょうか。
 ここではVOYAGE GROUPを構成する主要な事業会社とともに、それぞれのチームの雰囲気がわかる動画や技術的な挑戦の例となる記事やスライドをご紹介します。

アドプラットフォーム領域

 きっとほとんどの方がインターネット上で広告を見たことがあると思いますが、一方、その仕組みや歴史的変遷、用語などについては馴染みが薄い方も多いのではないでしょうか。以下の記事に、インターネット広告に取り組む意義やアドテクノロジーの変遷、よく使われる用語などについてににまとめていますので、興味のある方は是非ご覧ください。

techlog.voyagegroup.com

 アドプラットフォーム領域という広告配信のエコシステムを支える事業たちに共通するのは、ハイトラフィック、増え続けるデータ、低レイテンシ、日々進化するオペレーションは人手では回らない、そんなビジネスであるということです。技術的な面白さは、まさにこういった課題をソフトウェアエンジニアリングの力で解決可能にすることにあります。

株式会社fluct

 スマートフォンアプリ・ウェブメディアの収益最大化を実現するSSP(Supply-Side Platform)「fluct」を提供しています。 広告を出稿する側で利用される「DSP」、もしくは「アドネットワーク」といった別のシステムと連携して「いい感じ」に広告を出すことがfluctの主な仕事です。
 1万サイト以上に利用されていて、それらのトラフィックを真正面から受け、月間広告配信300億imp以上を処理する日本最大級のSSPとなっています。

fluctの人や文化、エンジニアリングを語るパネルディスカッション

そーだいなるVOYAGE GROUPの裏側 #fluct 編 広告配信の舞台裏の技術者たち - VOYAGE GROUP techlog

この事業の技術に関する記事

株式会社Zucks

 日本最大級のスマートフォン特化型アドプラットフォーム「Zucks Ad Network」「Zucks Affiliate」を提供しています。「DSP」や「アドネットワーク」、「アフィリエイト」などの仕組みを組み合わせ、広告主のプロモーション効果を最大化するのが主な仕事です。
 fluctなどのSSPとも連携し、アドネットワークは月間270億imp、DSPは月間1700億リクエストを処理しています。また機械学習などデータサイエンスの力によって、人手では回らないような運用を自動化し、さらに日々進化させています。

Zucksの人や文化、エンジニアリングを語るパネルディスカッション

そーだいなるVOYAGE GROUPの裏側 #Zucks 編 フルサイクル開発者の文化 - VOYAGE GROUP techlog

そーだいなるVOYAGE GROUPの裏側 #DS エンジニアによるビジネスのための機械学習 - VOYAGE GROUP techlog

この事業の技術に関する記事

メディア領域

 BtoCの様々なメディアを中心として基盤としながらBtoB向けのソリューションも展開しています。実はVOYAGE GROUPのアドプラットフォーム事業もこういったメディアたちの広告配信システムを他社へも展開するところから始まっています。
 移り変わりゆく環境の変化を感じながら、仮説を立て、MVP(Minimum Viable Product) を作り、小さく検証しながら、時代にあったメディアを成長させていきます。様々な利用者からフィードバックを得ながらプロダクトを育て、改善し続けていくことに醍醐味があります。

株式会社VOYAGE MARKETING

 ポイントメディア、コンテンツメディア、BtoBソリューションなど様々なサービスを提供しています。 事業領域が幅広いのが特徴であり、会員やコンテンツなど様々基盤を活用しながら新しい領域への挑戦も続けています。

VOYAGE MARKETINGの人や文化、エンジニアリングを語るパネルディスカッション

そーだいなるVOYAGE GROUPの裏側 #VM 編 レガシーシステムといい感じに付き合うスキル - VOYAGE GROUP techlog

この事業の技術に関する記事

VOYAGE Lighthouse Studio

 現在はゲーム攻略サイト「神ゲー攻略」をはじめとし、ゲーム攻略に役立つスマートフォンアプリや関連サービスの開発や運営をおこなっています。  VOYAGE GROUPの中では比較的新しい事業で、ゲーム攻略メディアとしては最後発に近いスタートでしたが、少数精鋭でマネージドサービスを使い倒しながら、高速なフィードバックループを回すことでゲーム攻略メディア業界のトップグループまで成長してきています。

VOYGE Lighthouse Studioの人や文化、エンジニアリングを語るパネルディスカッション

そーだいなるVOYAGE GROUPの裏側 #VLS 数十万記事のメディアをゼロから立ち上げる - VOYAGE GROUP techlog

この事業の技術に関する記事

インキュベーション領域

VOYAGE GROUPとして、第三の柱となる事業領域をつくるべく、既存領域に囚われず幅広く展開し、積極的に先行投資をしている分野です。

株式会社サポーターズ

 学生と企業に出会いの場を提供し、両者の良いマッチングを生み出すことを目指しています。学生の就職活動資金の一部を企業が「支援金」としてサポートするサービスとして2012年に始まりました。
 特にエンジニアを志望する学生さんたちが多く利用してくれており、そんな未来の優秀なエンジニア候補たちを応援できるということもやりがいの一つです。

サポーターズの人や文化、エンジニアリングを語るパネルディスカッション

そーだいなるVOYAGE GROUPの裏側 #SPZ 事業の成長を止めない手段としてのシステム刷新 - VOYAGE GROUP techlog

この事業の技術に関する記事

共に事業をエンジニアリングする仲間を積極大募集しています。

 VOYAGE GROUPには今回ご紹介した事業会社だけでなく様々な事業とチームがあります。VOYAGE GROUPでエンジニアリングすることに興味がある方は是非ご応募ください。いきなり選考でなくカジュアル面談でという方も歓迎です。 hrmos.co

面接時に見ているポイント

VOYAGE GROUP CTO @makoga による「面接時に見ているポイント」です。 techlog.voyagegroup.com

VOYAGE GROUPのエンジニアリング文化

挑戦し続けるためのエンジニアリング

 VOYAGE GROUPには、経営理念である「360°スゴイ」を体現し、様々な領域の事業に挑戦し続けていく上で、

  • ADAPTABLE TO RAPID CHANGE急激な変化にも適応できるチームであり続ける
  • GROW OUR BUSINESS WITH ENGINEERING事業をエンジニアリングする

の2つの「エンジニアリングの大方針」を掲げています。

急激な変化にも適応できるチーム

1つ目の「ADAPTABLE TO RAPID CHANGE(急激な変化にも適応できるチームであり続ける)」とは、CTOメッセージ | 株式会社VOYAGE GROUPでご紹介している、

  • 本質を見きわめ、柔軟に考える。
  • 小さく挑戦し続け、早く失敗する。
  • フィードバックし、継続的に成長する。

ができるチームとしてアップデートし続けるということです。
VOYAGE GROUPでは、そのためにエンジニアリングするための環境に継続的に投資してきました。 パフォーマンスが良好な組織にみられる、

  • デプロイ頻度が高い
  • コミットからデプロイまでのリードタイムが短い
  • 平均復旧時間(MTTR)が短い
  • 変更失敗率が低い

のような指標を改善し続けており、DevOpsの考え方が浸透しています。

事業をエンジニアリングする

2つ目の「GROW OUR BUSINESS WITH ENGINEERING(事業をエンジニアリングする)」とは、当事者として事業を理解し、ビジネスとシステムを改善するということです。
 VOYAGE GROUPのエンジニアは、聞いた要件のままにつくることはしません。 事業の遠い未来の予想や課題ではなく、その時点での仮説を元に必要最低限なものをつくります。
そして、それを象徴するのが、

  • バイアスに囚われない技術選定
  • フルサイクル開発
  • 仲間と相互にフィードバックしあう

の3つの考え方です。

バイアスに囚われない技術選定

 VOYAGE GROUPでは、原則として技術を固定化していません。 技術を固定化して、事業の選択肢が狭めてしまうことを避け、事業毎の特性、ビジネスのフェーズ、あるいは技術的な要件に適した技術を選定していく方針です。
 そのために、常にバイアスを疑い、常に複数の仮説と選択肢を持つということを心がけ、都度最適な解決策をゼロベースで考え、結果としてバラエティのある技術選択になっています。

フルサイクル開発

VOYAGE GROUPの開発姿勢のイメージを端的に表しているのが「フルサイクル開発」です。 「フルサイクル」とは「アイディアをお客さまに届けるまで」の「ヒアリング → 調査 → 意思決定 → 実装 → テスト → デプロイ → モニタリング → 改善」 といったシステム開発のライフサイクルを、誰かに依頼するのではなく、一人の開発者でも滑らかに回せるようにしよう、というイメージです。
 これは専門性を否定するものではなく、滑らかに課題を解決するために役割を限定しないという考え方です。専門性の高いメンバーを中心に、環境やツール、自動化などへ技術的な投資も継続的に続けています。

参考記事

仲間と相互にフィードバックしあう

 成長を加速させるためには自らの経験だけではなく、客観的なフィードバックをが重要です。チームを横断して仲間と相互にフィードバックしあい、お互いに継続的に成長することを大切にしています。
 VOYAGE GROUPでは、技術力評価会というエンジニアによる組織を越えた能力評価の仕組みがあります。2011年から継続しており、毎回みんなで振り返りを行って仕組み自体を改善し続け、共につくる評価制度となっています。

参考記事

様々なステージの事業にチャレンジする

 VOYAGE GROUPにある様々な事業会社たちは、それぞれステージや特性が異なります。プロダクトマーケットフィットを目指す新規事業を1人目のエンジニアとして立ち上げたり、20−30人規模のチームで市場環境の変化へ適応しながら、プロダクトを成長させていきます。
 挑戦の場は多様でありながら、VOYAGE GROUPを横断してご紹介してきたエンジニア文化を共有できていることで、事業会社を横断してお互いの能力やプロダクトを高めていける組織になっています。

VOYAGE GROUPのエンジニアリング文化をもっと知りたい方へ

この記事でご紹介したのは、エンジニアリング文化の概要に過ぎません。
個々の組織や人、プロダクトについて、さらに深く知りたいという方におすすめのコンテンツをご紹介します。

『Engineers in VOYAGE 事業をエンジニアリングする技術者たち』 テスト駆動開発でおなじみの和田( @t_wada )さんに、VOYAGE GROUP内の5つの事業会社に在籍する主要なソフトウェアエンジニアに対してインタビューしていただき、その内容を本としてまとめたものです。
 VOYAGE GROUPにおけるビジネスとソフトウェア開発の在り方を濃縮した一冊になっています。各々の事業会社というステージでそれぞれのチームが事業をエンジニアリングしてきたお話だけでなく、VOYAGE GROUP全体を通して感じられる文化を読み取っていただけるものになっていると思います。

参考記事

VOYAGE GROUPで働くことに興味を持っていただけた方へ

カジュアル面談お待ちしてます

 VOYAGE GROUPでは、「Ask the Engineers in VOYAGE」と題して、働くエンジニアの仕事内容や働き方・文化など、実際に応募する前に聞いてみたいことなどについて、ざっくばらんにお話ししていただく機会を作っています。すぐに選考を希望する方でなくとも問題ありませんし、情報交換からという方も歓迎です。
hrmos.co

オープンポジション

 ポジションに関係なくVOYAGE GROUPでエンジニアリングに興味があり選考を受けてみたい方はこちらから。
 「事業をエンジニアリングする技術者」として様々な事業に挑戦しながら、仲間と共に成長したい方からのご応募をお待ちしております。
hrmos.co

役に立たないチャットボット2020 〜あの社内ボットは今……そして slack-wrench〜

※ この記事は VOYAGE GROUP Techlog Advent Calendar 2020 15 日目の記事です。

こんにちは!fluct でインターネット広告配信のお手伝いをしている @jewel_x12 です。今日は社内チャットボットの話を書いていきます。

VOYAGE GROUP は 2014 年から Slack を使用していて、コロナ禍における在宅勤務で重要な役割を果たしています。その社内 Slack ワークスペースでは 2014 年から今日に至るまで jewelpet というボットが元気に動いています。

f:id:jewel12:20201216111127p:plain

mint.hateblo.jp

あの社内ボットは今……

Slack 使い始めの頃の jewelpet の様子は

  • 機能実装の方針
    • 有用なものを極力作らない
    • かわいいバグは放置する
  • ボットのフレームワーク: Hubot
  • 使用言語: CoffeeScript
  • コード管理とデプロイ: jewelpet の作者に Direct Message でコードを送るとマージしてデプロイしてくれる(古風)

という感じでした。機能実装の方針を見てもらえば分かるのですが、jewelpet は結構ゆるいボットで、便利に使ってもらうと言うよりも社内コミュニケーション促進の立ち位置が強いです。

そんなこんなで jewelpet は今も動いているのですが、この 7 年間、同じ構成でずっと動いていたわけではなく、Slack が公式に提供している Bolt へ 2019 年に移行しています。 移行理由は関連ライブラリのバージョン管理をしっかりしておらず、あるライブラリがバージョンアップしたときにライブラリの依存解決が難しくなり、デプロイ不能になったことでした。ボットの方針だけでなく、システム運用もゆるっとしてたんですね。

移行してからはこういう構成になりました。

  • 機能実装の方針は変わらず
  • ボットのフレームワーク: Bolt
  • 使用言語: TypeScript
  • コード管理とデプロイ: GitHub でコード管理・メインブランチへマージするとデプロイされる

おお、少しはナウくなりました!

コード管理が GitHub になったのが大きいですね。今や社員みんなが jewelpet の作者になったわけです*1

この移行に関してはもっと詳しいスライドがあるので、興味のある方はご覧になってください。

speakerdeck.com

ボットの動作テストと slack-wrench

さて、クリスマスカラーといえばレッドとグリーン、レッドとグリーンといえばテストです。誰でも jewelpet の作者になれる時代がやってきたのですが、動作テストをしづらいという声を聞くようになりました。ある言葉に反応するような機能を作ったとき、デプロイして Slack から入力するまで本当に動くか分からない状態だったんですね。トライアンドエラーしにくいので、動作テストをもう少し簡単にしたい。

Bolt の動作テストパターンとしては ngrok を使ったものがあります。ngrok はローカルマシンのポートに対して外部からアクセスできる URL を作れます。ローカルマシンで Bolt を起動したあと Slack のイベント通知先を ngrok で作った URL に向けることで、Slack アプリから動作テストできます。

slack.dev

このやり方は End to End のテストとしては本番環境に近くて良い方法なんですが、ngrok を無料で使う分には URL の固定ができないので Slack アプリケーション設定がテストの度に必要です。また、Slack アプリから入力する手間もあります。

理想的には Hubot Shell adaptor のようにローカルマシンからメッセージを入力して、出力を見れると良いのですが、Bolt にはそのような機能がありません。Bolt は起動すると Events API を listen するモードに入るので、ダミーイベントを Bolt へ通知することができれば……と考えていたところ、まさにそのようなことをしているツールを見つけました。

github.com

slack-wrench は Slack のテストに便利なパッケージ群で、IBM さんから提供されています。今回、主に使うパッケージは jest-bolt-receiverjest-mock-web-client になります。これらを使うと下記のように、Bolt アプリケーションに対する入出力のテストを Jest で書けます。

describe("ジュエルペット", (): void => {
    it("返事をする", async () => {
        await receiver.send(events.message("ジュエルペット"))
        expect(botMessages()[0]).toBe("なんや")
    })

    it("メッセージ中にジュエルペットが含まれていても返事をする", async () => {
        await receiver.send(events.message("吾輩はジュエルペットである"))
        expect(botMessages()[0]).toBe("なんや")
    })
})

Hubot Shell adaptor のようにしたかった意図とはずれますが、テストをコードに落とし込むことで何度も入力しないで済みますね。

Bolt は Events API を受け付ける部分(receiver)を変更できるのですが、任意のイベントを送信できるようにした receiver が jest-bolt-receiver になります。イベントの構築には fixtures を使うと便利です。 receiver の差し替えは以下のようなコードでやっています。

import JestRceiver from '@slack-wrench/jest-bolt-receiver'
import {
    MockedWebClient,
    MockWebClient,
  } from '@slack-wrench/jest-mock-web-client'
import { App } from '@slack/bolt'

import { setup, Config } from "../app"

export const receiver = new JestRceiver()

export const botUserId = "JEWELPET"
const app = new App({receiver, token: '', botUserId: botUserId, botId: "ジュエルペット"})
const conf: Config = {}
setup(app, conf) // リスナー等を設定する

export const client = MockedWebClient.mock.instances[0]

jest-mock-web-client は Bolt 内で Slack へのメッセージ送信を司るクライアントを Manual Mock するもので、例えばこのクライアントがどう呼び出されているかを見ることで、ボットから送信されるメッセージを確認することができます。メッセージを得る部分は以下のようなヘルパーを用意しました。

export const botMessages = (): string[] => {
    return client.chat.postMessage.mock.calls.map(arg => arg[0].text)
}

テスト例

Jest で入出力のテストができるようになりました!

これで有休が大量にあるか確認するコマンドをテストできるようになったし

describe("jewcan_holidays", (): void => {
    it("有休があること", async () => {
        await receiver.send(slashCommand("/jewcan_holidays"))
        const msgs = botMessages()
        expect(msgs.length).toBe(2)
        expect(msgs[0]).toMatch(/有休残確認してきます$/)
        expect(msgs[1]).toMatch(/有休残日数は\d{3,}日です/) // 有休は3桁以上あること。たくさんあったほうが嬉しい。
    })
})

昔からあったかわいいバグがちゃんと実装されているかも確認できます!便利だ!やったー!

describe("タイ料理屋", (): void => {
    it("おすすめしてくれる", async () => {
        await receiver.send(events.message("<@JEWELPET> タイ"))
        expect(botMessages()[0]).toMatch(/.+に行くパカ$/)
    })

    it("タイマーを使いたいときもおすすめしてくれる(旧バージョンのバグの再現)", async () => {
        await receiver.send(events.message("<@JEWELPET> タイマー"))
        expect(botMessages()[0]).toMatch(/.+に行くパカ$/)
    })
}) 

まとめ

VOYAGE GROUP は社内コミュニケーションツールとして Slack を利用しています。コミュニケーションを(たぶん)支えているボットは今も健在で、入出力のテストができるようになったりと開発しやすくなりました。これからも役に立たない機能をどんどん追加していきたいです!

この記事を読んで、役に立たないボットを交えつつ働いてみたい!という方がいらっしゃいましたら、VOYAGE GROUP では仲間を募集しているので、是非声をかけてください!

hrmos.co

voyagegroup.com

*1:理解にコンテキストを要する文。名前は似てるけど jewelpet の作者は僕ではなく、僕の知人で詳細は不明という設定になっていました。これはボットが失礼な発言をしても怒られの対象をウヤムヤにするプラクティスです。(ボットが変なこと言った程度では怒られるような雰囲気じゃないですが)

アドテクノロジーの変遷とよく使われる用語

こんにちは。技術広報の丹野 (@tan2) です。

今年は書籍『Engineers in VOYAGE 事業をエンジニアリングする技術者たち』が発売され大きな反響をもらったことが一番印象に残っています。そこでVOYAGE GROUP Techlog Advent Calendar 2020の9日目として、書籍からの抜粋を掲載したいと思います。

VOYAGE GROUPの事業の柱の一つにアドプラットフォーム事業があります。 ほとんどの方がインターネット上で広告を見たことがあると思いますが、一方、その仕組みや歴史的変遷、用語などについては馴染みが薄い方も多いのではないでしょうか。

今回は、VOYAGE GROUPのインターネット広告への取り組みと合わせて、ラムダノートさんの許可を得て書籍から2つのコラムを引用する形で、アドテクノロジーと言われる技術の変遷やよく使われる用語を解説したいと思います。

ツイートする際には、ハッシュタグ #voyagebook を使っていただけると嬉しいです。

なぜインターネット広告に取り組むのか

人々は仕事でもプライベートでも多くの時間をスマートフォンアプリの利用やウェブページの閲覧に費やしています。そのため多くの自社製品をマーケティングしたい企業にとってそのインターネット広告のチャネルは年々重要度を増しています。また広告収益がメディアの大事な収益源の一つになっていることで、人々は一部のアプリやサービスを無料で利用することができています。

このように、現在のインターネット産業を支えている大きな柱の一つは、広告とそのエコシステムです。この市場は毎年成長を続けている一方、まだまだ課題も多く、この領域を改善していくことには大きな意義とチャンスがあると考えています。

アドプラットフォーム事業とは

VOYAGE GROUPにおけるアドプラットフォーム事業とは、インターネット上に広告を出して人々にマーケティングしたい「広告主」と、広告を掲載して広告収益を得たい「メディア」の間に存在しており、アドテクノロジーを駆使することで「広告主」と「メディア」双方の利益を最大化しながら、「人々」に価値の高い広告を表示することでユーザー体験の向上にも寄与する事業です。

アドテクノロジーの変遷とよく使われる用語

「第1章 fluct:広告配信の舞台裏の技術者たち」より

アドテクノロジーの変遷

 インターネット広告における広告配信は「純広告」から始まりました。純広告配信では、メディアが広告主や広告代理店に広告枠を直接販売します。

 メディアの広告枠が増え、配信される広告案件も増えていくと、それらの組み合わせの数が多くなります。 それに伴い広告価格の算出時に考慮が必要な条件も徐々に増えました。 そして、CPM(Cost per mille)と呼ばれる「1000回の広告表示あたりの費用」を計算したり、1日あたりの配信単価に上限を設定するルールに対応したりするために、 メディアにおける広告配信および管理のための仕組みが必要になってきました。そのための仕組みは「アドサーバー」などと呼ばれるようになります。

 さらに2010年代に入ると、「運用型広告」が盛り上がり始めます。ここで普及したのが> 「アドネットワーク」および「RTB」(Real Time Bidding)という仕組みです。

 アドネットワークは、複数のメディアおよび複数の広告主と契約することで両者を取り持つ仕組みです。アドネットワークと契約することで、メディアは毎回すべての広告主と契約しなくてもよくなります。 その代わり、アドネットワークが広告主から配信手数料を受け取り、メディアに広告掲載料を支払います。 アドネットワークがメディアから広告枠を預かり、複数の広告主から依頼された複数の広告案件を、従来の広告効果を保ちながら効率よく配信する役割を担います。

 もう一方のRTBは、ユーザーが広告枠のあるウェブサイトを閲覧するたびに、リアルタイムに広告を表示する権利が売買される仕組みです。 RTBでは、広告枠の管理をSSP(Supply Side Platform)が担当し、広告案件の管理をDSP(Demand Side Platform)が担当します。 ユーザーによるウェブサイトへのアクセスを契機に、広告枠に対する「入札」が自動的にサーバーにより実施され、その入札を勝ち取った広告が最終的にユーザーのブラウザに表示されます。

 RTBでは、ユーザーがウェブサイトを閲覧するたびに入札が実施されるので、それをさばくサーバーには高いトラフィックを高速に処理する能力が要求されます。 また、広告を出稿する広告主があらかじめ「どのような条件を満たした広告枠に、いくらで入札するか」などの条件を決めて設定する必要があるので、 入札を実施する「ビッドサーバー」だけでなく、その設定を行う「管理画面」の機能性も重要になります。 さらに、実際に「どの広告がいくらで入札を勝ち取ったのか」をあとからログとして「集計」できる機能も必要です。

f:id:tan2jpn:20201208101459p:plain

「第2章 Zucks:フルサイクル開発者の文化」より

アドテクノロジー業界でよく使われる用語

 インターネット広告の世界では、ほかの業界ではあまり馴染みがない概念や頭字語がいくつか用いられます。 いくつかは第1章にも登場していますが、ここで改めて概略をまとめます。

  • CPI(Cost Per Install): アプリなどのインストールを1件獲得するのに必要なコストを指す
  • CPC(Cost Per Click): クリックを1件獲得するのに必要なコストを指す - 純広告:広告主または代理店が直接メディアの広告枠を買い取って広告を表示させるもの
  • コンバージョン:広告配信の成果を指す。何を成果とするかは広告商材によって異なり、ECサイトであれば商品の購入、アプリの広告であればインストールが成果となる
  • :広告を配信する対象のメディアのこと。ここでメディアとは、ウェブメディアやアプリのことを指す
  • :広告枠のことを指す。面には複数の枠が存在する
  • 案件:日常的な意味では課題事項全般を指すが、広告業界では特に広告の注文や発注などのオーダーを指す

インターネット広告をエンジニアリングする

VOYAGE GROUPのアドプラットフォーム事業領域では、fluctやZucksといったチームがそれぞれの立ち位置からインターネット広告をエンジニアリングしています。そしてその様子を書籍『Engineers in VOYAGE 事業をエンジニアリングする技術者たち』で生々しく語っています。ご興味ある方は是非手にとってみてください。

書籍「第1章 fluct:広告配信の舞台裏の技術者たち」

第1章のfluctは、インターネット広告配信でメディア側の基盤となる「SSP」と呼ばれるシステムを開発運用している会社です。老舗SSPのシステム開発の軌跡をたどりつつ、アドテクを支える技術、オンプレミスとクラウドの双方におけるSREやDevOpsの考え方、技術的負債の返済に必要な腕力、オブザーバビリティ、広告とプライバシーの問題といった、インターネットで働く多くの人が気になっている要素が語られます。 https://www.lambdanote.com/blogs/news/engineers-in-voyage

  • 目次
    • 広告配信システムひとめぐり
    • 「2010年に広告配信システムを作る」ということ
    • とりあえず使ってみる文化
    • クラウドとの向き合い方
    • インフラと開発は最初から分離しない方針だった
    • 技術的負債との闘い
    • オブザーバビリティ
    • これからのfluct
  • コラム
    • アドテクノロジーの変遷
    • オンプレミスかクラウドか
    • VOYAGE GROUPの「グレード」と「技術力評価会」
    • インプレッションとそのカウント方式
    • SREに対する考え方
    • リファクタリングと作り直しの違い
    • オブザーバビリティ
    • 広告におけるプライバシーの課題
書籍「第2章 Zucks:フルサイクル開発者の文化」

第2章のZucksは、アフィリエイトやアドネットワークと呼ばれる仕組み、それにfluctが担うSSPと対をなす広告主側のシステム「DSP」を開発運用する会社です。広告配信という点だけを見るとfluctと似ていますが、最初からフルクラウドで実装されたこと、さらにはビジネス上の要件がまったく異なることもあって、開発者の文化もだいぶ様子が異なります。その開発文化を横軸にしながら、「フルサイクル開発者」というソフトウェア開発者の働き方が語られます。 https://www.lambdanote.com/blogs/news/engineers-in-voyage

  • 目次
    • アドネットワークとしてのZucks
    • DSP開始
    • Zucksのエンジニア文化
    • ドキュメントがまったく存在しないシステム
    • 新しくジョインしたら初日に機能をリリースする
    • 重要なのは切り戻しできるかどうか
    • チームの文化はスケールできるのか
    • 広告業界の変化に向き合う
  • コラム
    • アドテクノロジー業界でよく使われる用語
    • MVP(Minimum Viable Product)
    • フルサイクル開発者とは
    • Zucksのシステム構成
    • XPとケント・ベック

本書の購入について

PR

【22卒就活生向け】VOYAGE GROUPエンジニア情報まとめ

こんにちは!VOYAGE GROUP新卒エンジニア採用担当のさとみんです。

VOYAGE GROUP Techlog Advent Calendar 2020の8日目の記事です。 今回は人事らしくエンジニアの就活学生さん向けにVOYAGE GROUPの情報をまとめてみました!

22卒本選考もオープン中なので、一緒にミチを切り拓く仲間を募集しています!

voyagegroup.com

目次

VOYAGE GROUPとは?

VOYAGE GROUPを一言で表すなら「人を軸にした事業開発会社」。 世界を変えるようなスゴイことをやろうという創業時の想い「360°スゴイ」をもとに事業を展開しています。

voyagegroup.com

事業や人まわりの詳細はこちら

VOYAGE GROUPの概要や事業内容について、クルーの声とともに解説しています。

voyagegroup.com

※VOYAGE GROUPでは同じ船に乗り、インターネットの海を航海(VOYAGE)する仲間として社員のことをクルーと呼びます。

エンジニアリング文化

VOYAGE GROUPでは、事業部ごとにエンジニアの人数や使用技術は若干異なりますが大切にしている考え方は全社で共通しています。

CTOメッセージ

voyagegroup.com

事業をエンジニアリングする

『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』という本がラムダノートさんから出版されました。事業部ごとに主要なエンジニアにインタビューを行い、エンジニアリングに対するリアルが濃縮された1冊です!Twitterでは #voyagebook で本の感想やイベントの様子がまとまっています。

techlog.voyagegroup.com

フルサイクル開発者

VOYAGE GROUPのエンジニアは、フロントエンドやバックエンドなどの役割に縛られず、要件定義から設計・開発・運用まで、価値あるサービスをスピーディーに届けるため全方位でエンジニアリングを行うことを目指す「フルサイクル開発者」の考え方を大切にしています。役割を限定せず、メンバー同士がフォローして、チームとして前に進むように心がけています!

techlog.voyagegroup.com

技術力評価会

VOYAGE GROUPは半期に1回、チームや部署を超えてエンジニアがエンジニアへ技術フィードバックを行う技術力評価会を設けています。エンジニアの技術力をエンジニア同士で評価し合うため適切なフィードバックをもらうことが可能です。

speakerdeck.com

就活生向け記事一覧

ここからは就活生のみなさんが、VOYAGE GROUPでの働き方をイメージしやすいような記事を中心にまとめていきます!

インタビュー集

techlog.voyagegroup.com

techlog.voyagegroup.com

techlog.voyagegroup.com

focus.voyagegroup.com

focus.voyagegroup.com

focus.voyagegroup.com

面接で見ていること

techlog.voyagegroup.com

もっと情報を知りたい方はこちらをチェック!

VOYAGE GROUPの各種情報はこちらからチェックしてみてくださいね!

22卒のエンジニアの仲間も募集中!エントリーもお待ちしております!

voyagegroup.com