書籍「Engineers in VOYAGE 事業をエンジニアリングする技術者たち」が発売 #voyagebook

こんにちは。技術広報の丹野です。 2020年8月7日、『Engineers in VOYAGE 事業をエンジニアリングする技術者たち』という本が ラムダノートさん から出版されます。

テスト駆動開発でもおなじみの 和田(@t_wada)さん が、VOYAGE GROUPに在籍する主要なソフトウェアエンジニアにインタビューし、その内容をラムダノートの 鹿野(@golden_lucky)さん の協力のもと本としてまとめていただきました。 VOYAGE GROUPにおけるビジネスとソフトウェア開発の在り方を濃縮した1冊に仕上がっていると思います。

f:id:tan2jpn:20200806173146j:plain
Engineers in VOYAGE 事業をエンジニアリングする技術者たち 書影

さて今回は、この本ができた経緯や内容、雰囲気についてみなさんに伝えたいと思い、 和田さん と ラムダノートさん の許可を得て「はじめに」の内容を以下に掲載します。ツイートする際には、ハッシュタグ #voyagebook を使っていただけると嬉しいです。

author: 和田卓人 date: 2020年7月

はじめに

 今世紀に入ってから、ビジネスとITの関係は大きく変わりました。Marc Andreessenが"Why Software Is Eating The World"というタイトルの文章をウォールストリートジャーナルに寄稿してから9年が経ちます。世界を飲み込むソフトウェア化の波はインターネット企業から始まり、ソフトウェアから遠い伝統的産業にまで到達しました。新興企業はソフトウェアの力を活かして伝統的産業に参入し、既存の企業は新たな好敵手に対抗するためソフトウェアの力を獲得しようともがいています。ビジネスにとってITは、「あると便利」から「有効」、「不可欠」を経て「中核そのもの」になりつつあり、ソフトウェアのエンジニアリングを進める力は企業の競争力の源泉となりました。

 1999年創業のVOYAGE GROUPは、ソフトウェアの力を活かして成長してきたインターネット領域の事業開発企業です。20年間で100以上の事業やサービスを創出し、現在は広告プラットフォーム事業やメディア事業を中心に20以上の事業やサービスを運営しています。本書は、そのようなVOYAGE GROUPのさまざまな事業やサービスを牽引するエンジニアに2020年1月から2020年5月にかけて行ったインタビューを1冊の書籍としてまとめたものです。事業をエンジニアリングの視点で考えたり、さらにはエンジニアリングの視点で事業を作り出したりと、「ビジネス」と「エンジニアリング」を両輪にしてITシステムを開発・運用しながら実社会で活躍している技術者や技術者のチームの生の声をお届けします。

本書のきっかけ

 本書の企画は、もともと「VOYAGE GROUPのエンジニアをもっと多くの人に知ってもらいたい」というCTO小賀さんの想いから始まりました。同社のいくつかの事業会社のシステムを支えるエンジニアに取材した内容をインタビューとしてまとめ、それを技術同人誌のような形で頒布することが意図されていたようです。

  筆者は、同社の技術コーチを務めている関係から、この企画のインタビュアーを拝命しました。各事業会社のキーパーソンにインタビューを依頼し、ランチをともにしながら事前に聞き出したshow notesを手に本番に臨むと、そこで彼らが語ってくれたのは、現実の世界で次々に発生する問題やチャレンジングな目標を時には腕力、時には調整力、時には洞察力でもって解決していく、当事者意識と技術力を備えた技術者たちによる格闘の歴史でした。

 インタビューの内容を文章として書き起こす作業は、編集者である鹿野さんが引き受けてくれました。そうして生まれた文章は、一企業の技術者の認知度向上という当初の目標を遥かに超え、「事業をエンジニアリングしていく」というITシステムが事業の中核になった現代において普遍的なテーマについて当事者が語る貴重な証言を集めた内容になっていました。これは良い本になるという手応えを掴みました。「この本は多くの方にヒントを与える本であり、広く読まれるべきである」との想いから、鹿野さんの出版社であるラムダノートで書籍として発行するに至ったものです。

おすすめの読み方

 本書はさまざまな読み方ができる本です。すでに触れたように、本書のもともとの意図は「VOYAGE GROUPの名前は知っているものの、どんなエンジニアがどんなシステムを作っているかまでは知らなかった」という方に興味を持って手に取って読んでもらうことでした。もちろん、すでにVOYAGE GROUPに知り合いがいる方にも、一種のファンブック的に楽しんでもらえるでしょう。

 しかし筆者は、本書はそれ以上のものであると考えています。なぜなら、本書に登場するVOYAGE GROUPの複数のシステムには多くの方が「自分の扱っているシステムが置かれている状況に似ているな」と思えるような面がどこかにあり、したがって本書には「自分事としてとらえられる切り口」が必ずどこかに見つかるはずだからです。

 たとえば、大量のトラフィックをさばくためにエラスティックにスケールアウトしていく配信システムもあれば、複雑な情報を扱う管理画面もあります。オンプレミスで始まったシステムもあれば、最初からクラウドコンピューティング基盤を活用したシステムもあり、さらに最初からクラウドネイティブなマネージドサービスを使っているシステムもあります。散らかったデータの収集と前処理から着手して、現在ではデータサイエンスの力を活かしてリアルタイムの予測を導入しているシステムもあります。BtoBのシステムもBtoCのシステムもあります。ゼロから立ち上げて数年の若いシステムもあれば、20年もののレガシーシステムもあります。

 システムは事業の種類によっていろいろと姿形を変えます。そしてVOYAGE GROUPという会社では、さまざまなフェーズにある多様な事業を扱っており、強いエンジニアリング文化がそれを支えています。 したがって本書のどこかのページには、システムに携わっている方の多くにとってヒントとなる(あるいはアンチパターンとなる)逸話がきっとあるはずなのです。

 インターネット上で事業を営んでいる企業に属しているエンジニアの方々は、自社がこれまでに経験したことやこれから経験しそうなことについて、いろいろなステージの事業が登場する本書からヒントを見つけられるでしょう。アーキテクチャの変遷や技術的負債の返済の道のりなど、エンジニアリングの力によって問題を解決していくさまに共感しながら読めるのではないでしょうか。

 受託開発を行っているエンジニアの方々におすすめしたい本書のポイントは、インターネット企業のエンジニアたちの等身大の姿、事業に対する当事者意識、ビジネス上および技術上の意思決定のスピード感などを具体的に読める点だと考えます。それだけでなく、たとえば第3章のVOYAGE MARKETINGへのインタビューに顕著ですが、「SIの現場で培ったスキルのウェブ系のサービスでの活かし方」といった観点でも参考になると思います。

 さらに本書は、技術者だけでなく、ビジネスを営んでいる方々にもおすすめできます。それは、全編を通して「オーナーシップを持った技術者が事業をエンジニアリングする姿」を見られるからです。ビジネスとエンジニアリングが事業の両輪であるからには、エンジニアたちの考えを知り、彼らの気持ちを汲み取れることは、ビジネスにとって必須のスキルだといえるでしょう。

 特定の企業のエンジニアリング文化を解説する書籍はこれまでもありましたが、それらに登場するのはGoogle、Amazon、Facebook、Appleなど、技術者の数も多ければエンジニアリング的な体力もふんだんにあるメガプレーヤーたちです。VOYAGE GROUPは、それらメガプレーヤー企業に比べると遥かに規模が小さいにもかかわらず、強くしなやかなエンジニアリング文化を備え自分たちで問題を解決しながら日々前進している企業だと思います。その意味では、「あれらの企業はそもそも特別すぎるから」という先入観から離れ、より現実的で模倣可能なエンジニアリング文化を本書から読み取ってもらえるはずです。

書誌情報

書名: Engineers in VOYAGE 事業をエンジニアリングする技術者たち
著者: 株式会社VOYAGE GROUP 監修、和田卓人 編
サイズ: A5判、224ページ
ISBN: 978-4-908686-09-2
本体価格: 1,800 (+税) 円、電子版のみ1,000 (+税) 円
発行: 2020年8月7日

主要目次

第1章 fluct:広告配信の舞台裏の技術者たち
第2章 Zucks:フルサイクル開発者の文化
第3章 VOYAGE MARKETING:20年級大規模レガシーシステムとの戦い
第4章 VOYAGE Lighthouse Studio:数十万記事のメディアをゼロから立ち上げる
第5章 サポーターズ:事業の成長を止めない手段としてのシステム刷新
第6章 データサイエンス:エンジニアによるビジネスのための機械学習

購入について

ラムダノートさん で販売しています。

そのほか、ジュンク堂書店池袋本店をはじめ、書泉ブックタワー (秋葉原)、紀伊國屋書店新宿本店、amazon.co.jp などの書店およびオンライン書店でも順次販売予定となっています。

最後に

この本を通して、インタビュイーを務めてくれたエンジニアたち、そしてVOYAGE GROUPの文化や考え方について共感していただけたら幸いです。

FluctSDKのドキュメントをリニューアルした話

こんにちは。新卒2年目エンジニアのchocovayashiです。 普段は、fluctでiOS / Android / Unity向けに広告SDKの開発をしています。

広告SDKはSDK自体の機能開発も大事ですが、使い方をわかりやすく説明するためのドキュメントの存在も大事です。 今回はFluctSDKのドキュメントを新しく作り変えたので、そのアプローチやどういうツールを使ったのかご紹介します。

新しいドキュメントはこちらです。

https://voyagegroup.github.io/FluctSDK-Doc

f:id:chocovayashi:20200716110520p:plain

目次

ドキュメントが抱える課題

作り変える前のドキュメントは、各プラットフォーム(iOS, Android, Unity)ごとにGitHubのWikiで管理していました。

iOS, Android, Unity (Wikiでの記述は既に消しているので、現在はHomeだけしか見れません。リンクは過去の編集履歴へのリンクです。)

1. 商材が増え、見たいドキュメントに辿り着くことが面倒になった

iOSの例を挙げると、私が入社した1年ほど前は、動画リワード広告JavaScriptタグによるバナー広告しか商材がなく、見たいドキュメントをすぐ見つけることができました。しかし、ここ1年で商材が増え全て画像のように箇条書きにしていたので、見たいドキュメントを探し出すのに苦労するようになりました。画像はiOSの商材で、iOSだけでも画像の倍の商材があり、またAndroid, Unityにもほぼ同じ数の商材がありました。

f:id:chocovayashi:20200716110331p:plain

視覚的に商材を選べるUIにできれば簡単にたどり着けるようになりそうだなと思いました。

2. 同じ記述になる部分を重複して管理している

FluctSDKのUnity Pluginの実態は、iOS, Androidの各プラットフォームへのbridge機能を有しているだけで、ロジック部分はiOS, AndroidのSDKがそれぞれ有しています。 なので、FluctSDKのUnity PluginにおけるiOSやAndroidの最低要求OSバージョンは、FluctSDKの要求するiOS,Androidの最低要求OSバージョンと同じになります。 各プラットフォームごとにドキュメントを公開している(内部的にも各プラットフォームごとにドキュメントを管理していました)制約上、各プラットフォームを跨いで情報を共有できなかったので、共通の情報であっても重複した記述をする必要がありました。その影響で、変更漏れが発生することがありました。

3. おしゃれじゃない

個人的にはこれが最も重大な課題でした。デザイナーではないのでおしゃれの細かい定義はしていませんが、左に目次があったり、複数の言語の実装例をタブで選択できるようにしたいなと思っていました。

他に意識したところ

  • gitなどでバージョン管理ができる
    • チーム内でのレビューをしやすくしたい
    • 変更履歴がわかるようにしたい
  • ドキュメントの構成をツールに依存させない
    • ツールのサポート終了などで将来他のツールに移行する可能性は十分にあるので、ドキュメントの書き方がツールに依存しすぎないようにする

ツールの選定

まずは選択肢を挙げ、それぞれについて考えました。

GitBook

f:id:chocovayashi:20200716110420p:plain

トップページから溢れ出るおしゃれ感には心を揺さぶられました。また、Analyticsも見れるのでとても魅力的でした。ただ、localでの開発が非推奨であったり(https://github.com/GitbookIO/gitbook )、お金がかかるというのはデメリットだと考えました。

HUGO

f:id:chocovayashi:20200716110440p:plain

HUGOはタイトルからもわかるように、staticなsiteを作れるオープンソースのframeworkです。テーマが多彩でその1つにドキュメントっぽいテーマもあったので十分活用できそうでした。また、hot-reloadもあるので、快適に開発できそうだなと印象を受けました。

中身はgoで書かれているので、デプロイする時は例えばCIでhugoコマンドを使い、MarkdownをHTMLへ変換し、その HTMLをデプロイする必要がありました。またドキュメントの公開という観点からすると、少しオーバースペックな気がしました。

docsify

f:id:chocovayashi:20200716110502p:plain

まず見た目がとても可愛いので良いですね。docsifyはJavaScriptで書かれたドキュメント生成ツールです。静的ファイルとして置いたMarkdownをdocsifyが表示時にHTMLへ変換するので、build不要で公開できるのが魅力的でした。HUGOと同様にhot-reloadもあり開発には困ることはなさそうです。また、pluginの開発もできるので、独自拡張もしやすそうでした。

ただ、テーマが4種類しかないので、もし凝ったデザインを作りたくなったら0から考えないといけないのが大変だなと思いました。

ツールの選定結果

候補の中から、docsifyを採用することにしました。docsifyはCover pageという機能があり、トップページをHTMLで自由にカスタマイズすることができます。今回は見たい商材へすぐに辿り着けるようなデザインへとカスタマイズしました。

f:id:chocovayashi:20200716110520p:plain

ドキュメントの埋め込み機能がありコンテンツを再利用できるので、重複する情報の管理を1箇所で行うことができるようになりました。例えば、iOSの最低要求OSバージョンをiOSのドキュメントに書いていてもそれをFluctSDK Unity Pluginで再利用することが可能になりました。

デザインの面では、Tab機能で見た目を簡単にリッチにできる点も採用の決め手になりました。

f:id:chocovayashi:20200716110542p:plain

docsifyを使う上でちょっとした工夫

SDK本体のリリースサイクルの弊害にならないようにしたい

ドキュメント内にSDKのversionを記述してる箇所があり、それはSDK本体のリリース毎に修正する必要がありました。これを手動で毎回変更する運用にすると、変更を忘れたり、変更をするのが面倒で細かくリリースを行う弊害になりかねませんでした。なので、GitHub Actionを使い自動でversion upする仕組みを作りました。

GitHub Actionには特定のリポジトリにjsonの情報付きで通知を送る仕組みがあるので、それを利用しSDK本体がリリースされるタイミングで、ドキュメントを更新する仕組みを作りました。

ただ、version情報は各所に点在していて、GitHub Actionがその全ての場所を修正しようとすると、ドキュメントの可用性が低下してしまいます。なので、version情報などをyamlファイルで一元管理できるpluginの独自開発を行いました。plugin自体はMarkdownの埋め込みとほぼ同じ実装かつ後述するので、ここでは省略します。

低コストでデプロイを自動化する

ドキュメントの中身以外のメンテナンスは極力したくないのでCIは使いたくありませんでした。というのも、実際に価値を生むのはSDK本体なのでそこの開発の邪魔にならない立ち位置で運用したかったからです。またドキュメントの性質上、大量の同時アクセスなどを考慮する必要もありませんでした。なので、今回はGitHub Pagesを採用しました。さらに、buildする必要もないので、masterへmergeするだけでデプロイすることが可能になりました。

GitHub Pagesをホスティング先にすることにより、CIを使わずにデプロイすることが実現できました。

docsifyを使う上でちょっと困ったこと

Tab機能とドキュメントの埋め込み機能を併用で使えない

docsifyはMarkdownをHTMLに変換してドキュメントを表示しています。ドキュメントの埋め込み機能はHTMLへ変換する前に別のMarkdownを読み込み、展開させる機能です。一方でTab機能はドキュメントの埋め込み機能がMarkdownの展開をする前に処理が行われており、2つの機能を共存させることができませんでした。

なので、Tab機能とドキュメントの埋め込み機能を共存させるために、ドキュメントの埋め込み機能をpluginとして独自で開発し、タイミングを制御できるようにしました。簡単にpluginが作れるところもdocsifyの良いところですね。

まずはdocsifyにPluginを登録します。

window.$docsify.plugins = [].concat(
  embedMarkDownPlugin,
  window.$docsify.plugins || []
);

window.$docsify.pluginsへpluginを追加します。embedMarkDownPluginはpluginの中身です。

function embedMarkDownPlugin(hook, vm) {
  hook.beforeEach(function (content, next) {
    embedMarkdown(content, next);
  });
}

hook.beforeEachはdocsifyで定義されたライフサイクルのコールバックです。他にも様々なコールバックが用意されています。 embedMardownはMarkdownを埋め込む実態の関数です。

function embedMarkdown (content, next) {
  const regex = '\\[embedded-markdown\\]\\(([a-zA-Z0-9!-/:-@¥[-`{-~]+)\\)';
  const embeddedDescriptions = content.match (new RegExp (regex, 'gim'));
  if (!embeddedDescriptions) {
    next (content);
    return;
  }
  const embeddedFiles = embeddedDescriptions.map (desc => {
    return desc.match (new RegExp (regex, 'im'))[1];
  });

  Promise.resolve ()
    .then (function () {
      return Promise.all (
        embeddedFiles.map (desc => {
          return fetch (desc).then (res => (res.ok ? res.text () : ''));
        })
      );
    })
    .then (responses => {
      responses.forEach ((res, index) => {
        const escapedEmbeddedDescription = embeddedDescriptions[index].replace (
          /[\\^$.*+?()[\]{}|]/g,
          '\\$&'
        );
        const regex = new RegExp (escapedEmbeddedDescription);

        // 指定されたmarkdownが存在しない場合
        if (!res) {
          content = content.replace (regex, '');
          return;
        }

        // markdownを入れ替え
        content = content.replace (regex, res);
      });
      embedMarkdown (content, next);
    });
}

このように定義し、Markdownに以下のような記述をすると、指定したMarkdownを埋め込むことが可能になりました。

[embedded-markdown](path/want-to-embed-markdown.md)

まとめ

いくつかのツールを検討して、最初に挙げた課題を最短で解決してくれそうなdocsifyを採用しました。

広告SDKの開発においては、どうしても広告の機能開発に目を向けがちですが、お客さん目線に立つとドキュメントの見易さも非常に重要になってきます。地味な作り変えかもしれませんが、少しでもお客さんの開発の助けになればなと思います。

今さら聞けないオークション理論とDSP入札ロジック

こんにちは。DSP(Demand-Side Platform)配信ロジックの開発に携わる新卒2年目の若手エンジニアohyan(@ohyan)です。

DSPはその名の通り、広告主や広告代理店など広告を配信したい側が使うインターネット広告配信プラットフォームです。媒体社(メディア)の広告枠を持つプラットフォームも存在していてSSP(Supply-Side Platform)と呼ばれます。DSPとSSPはRTB(Real-time Bidding; リアルタイム入札)で広告枠と広告のエクスチェンジを行っています。

この記事は、RTBの土台であるオークション理論および当社のDSPの入札ロジックについて説明します。

目次

RTBについて

まずはRTBについて簡単に説明します。

f:id:koki_ohyan:20200714181221p:plain

  1. メディアが広告表示リクエストをSSPに送ります。
  2. SSPが複数のDSPに広告枠に対する入札リクエストを送ります。
  3. DSPが表示したい広告と入札金額をSSPに返します。
  4. 一番入札金額の高い広告を広告枠に表示させます。

オークション理論

財の価値

入札者にとっては、オークション対象(オークション理論では財と呼ばれる)の価値を正しく見積もることが重要であり、その価値は3種類に分類できます。

  • 私的価値
  • 共通価値
  • 相互依存価値(相関価値)

それぞれの価値について簡単に説明します。

私的価値

各入札者が財に対して独自の評価基準で見積もりし、競合者の評価価値に左右されません。

例
* 財:ゲーム攻略サイトの広告枠
* 入札者A:自社化粧品の認知を高めるために広告を出したい入札者
* 入札者B:ゲームアプリの新規ユーザーを獲得するために広告を出したい入札者

入札者AとBは各自の基準で枠の価値を評価し、相手の評価基準を考慮する必要がありません。上記の状況であれば、おそらく入札者Bにとってこの広告枠の価値が高いであろうことが推測できます。

RTBの場合、DSPの保有する商材によって、広告枠に対する価値の見積もりが大きく変わります。適切な広告枠に適切な広告を出すことで広告配信効果と資金効率があがります。ここで財の評価基準として、広告配信効果を表すCTR(Click Through Rate)やCVR(Conversion Through Rate)が良く使われます。

共通価値

共通価値はすべての買い手において財の価値が一致するものです。石油や木材といったような自然資源はすべての入札者にとって、同等な価値があります。入札時に真の価値が判明できていないケースであれば、推定する必要があります。

相互依存価値(相関価値)

私的価値と共通価値の間に相互依存価値が存在します。自分の評価基準で財を評価しますが、他の入札者の評価基準も参考にして価値を推定します。

オークションタイプ

自分の評価価値に他の入札者の入札情報を使うことが可能かどうかについては、競売プロセス(オークションタイプ)に依存しています。概ね、オークションタイプは4種類に分けられます。

  • 公開入札
    • 公開競り上げ式
    • 公開競り下げ式
  • 封印入札
    • ファーストプライスオークション
    • セカンドプライスオークション

よく知られているのはおそらく「公開競り上げ式オークション」でしょう。最も低いレベルから価格が釣り上げていき、入札者がどのタイミングでオークションから降りてもよく、最終的に入札者が1人になる時点でオークション終了となります。約定金額(支払う金額)が最後の入札金額となります。

一方、インターネット広告のRTB市場は封印入札となっています。つまり、競争者の入札金額を知らずに自分の入札金額を提示することです。封印入札の中には、一番入札金額の高い入札者が自分の入札金額で支払う(ファーストプライスオークション)と、2番目の高い入札金額で支払う(セカンドプライスオークション)の2種類のプロトコルがあります。RTB市場は、セカンドプライスオークションが利用されてきましたが、ここ数年海外のSSPをはじめファーストプライスオークションが中心になりつつあります。

RTB入札戦略・ロジック

DSPは各自の保有している商材を広告枠に表示する価値が、私的価値に当てはまります。

RTBにおけるDSPの最適な入札戦略とは、利得が最大になる入札行動を取ることです。そしてこの場合の利得とは、私的価値とSSPへ支払う金額の差を指します。

セカンドプライスオークション

セカンドプライスオークションの場合、他の入札者の金額を考慮する必要がなく真の私的価値で入札すれば最適な戦略になります。

ここでは、なぜ最適な戦略になるかについて簡単に説明します。

パラメータは下記通り表記します。

  • v を私的価値
  • v - s を私的価値より低い金額
  • v + s を私的価値より高い金額
  • p を他の入札者の一番高い入札金額

まずは、私的価値より低く入札する場合を考えましょう。2番目高い入札金額は、図に示した通り3パターンがあります。

f:id:koki_ohyan:20200714000928p:plain

  1. p > v:負けます。入札金額がvかv-sか、とは関係ありません。
  2. v > p > v - s:負けます。vで入札していたらオークションに勝っていました。v-pの利得も得られたでしょう。
  3. v - s > p:勝ちます。入札金額がvかv-sか、とは関係ありません。

つまり、私的価値より低く入札するのは、私的価値そのままでの入札と同じ結果をもたらすか、それより悪い結果をもたらします。

次は私的価値より高くする入札する場合を考えます。同じく、3つのパターンがあります。

f:id:koki_ohyan:20200714000933p:plain

  1. p > v + s:負けます。入札金額がvかv+sか、とは関係ありません。
  2. v + s > p > v:勝ちます。約定金額は私的価値より高いpになるため、p-vの損失が発生します。
  3. v > p:勝ちます。入札金額がvかv+sか、とは関係ありません。

つまり、私的価値より高くに入札するのも、私的価値そのままでの入札と同じ結果をもたらすか、それより悪い結果をもたらします。

このように私的価値そのままで入札することが最適解となります。

セカンドプライスオークションの場合には、入札者にとって期待される収益に応じて財を正しく見積もることが重要です。

具体例 として、当社DSPがインプレッションの価値をどうやって評価するかについて、CPC(Cost per Click)を目標KPIとする案件を例として説明します。

  • 1クリックの価値は広告主が決めますが、その価値は目標CPCと呼びます。
  • インプレッションからクリックに至る確率も必要とされて、CTRと呼びます。
  • 広告主にとって、1インプレッションにあたる期待収益は目標CPC * 予測CTRになります。

これらを踏まえると、DSPにはその価値をリアルタイムで推論するためのCTR予測器を作るという課題が設定できます。そして、広告枠Xに広告yを出す時のCTRは、広告主の属性広告枠の属性オーディエンスの属性で決まります。 CTR予測器では、これらの属性を含んだ過去の配信実績データを使って学習し、DSP配信サーバーへの広告表示リクエストに対して、リアルタイムでCTR予測値を求めていきます。

ファーストプライスオークション

ファーストプライスオークションの場合はセカンドプライスオークションとは違い、私的価値のままで入札すると利得が0になります。このような場合において、他の入札者の入札金額を推定することが最適な行動を取ることにつながります。このような状態はナッシュ均衡とも呼ばれます。

また、ファーストプライスオークションでは1つの広告枠に対して複数回の表示権利をオークションで売買します。このような繰り返しオークションでは、財の価値(他社の最高入札金額)を統計的に推定することができます。最高入札金額分布が分かれば、利得を最大化する入札ロジックが可能になります。

ここでは、この入札戦略について説明します。

パラメータは下記通り表記します。

  • v を私的価値
  • x を入札金額
  • z を競合者の最高入札金額

ファーストプライスオークションの利得 Profitは、私的価値と入札金額の引き算結果になります。他社の入札金額より低い場合は、広告を表示する権限が得られなくて利得が0になります。

\begin{align*} Profit= \begin{cases} v - x & \text(x > z) \\ 0 & (\text{otherwise}) \end{cases} \end{align*}

入札金額に対するオークション勝率と期待利得の概念を導入します。他社の最高入札金額の分布が分かれば、それの累積分布関数は勝率関数となります。そして、利得と勝率の掛け算結果は期待利得です。1つの例をあげます。

私的価値 := 200円 
Case1: 入札金額 := 200円 → 利得0円、勝率100%、期待利得0円 
Case2: 入札金額 := 150円 → 利得50円、勝率80%、期待利得40円 
Case3: 入札金額 := 100円 → 利得100円、勝率50%、期待利得50円 
Case4: 入札金額 := 50円 → 利得150円、勝率10%、期待利得15円

ここで、入札金額に対するオークションの勝率は w(x)  \rightarrow [0, 1] として定義すると、最大化したい期待利得は  w(x)(v - x)になります。定義された勝率関数が微分可能な関数であれば、期待利得も微分可能で高速に最適化計算が行えます。

このようにファーストプライスオークションの場合、入札金額決定ロジックではCTR予測器やCVR予測器以外に、競合者の最高入札金額を推定できるように事前に勝率関数の推定パラメータが必要とされます。

具体例 として、当社DSPがどのように分布を求めるかについて例をあげたいと思うのですが、実際のところSSPによってファーストプライスオークションで得られる情報が異なることがあります。

例えば、SSP Aはオークションに負けたときの最高入札金額を送ってくれ、SSP Bは広告枠ごとの最高入札金額を集計し、中央値と平均値を送ってくれます。SSP Aの場合だと、事前に何を対象にして(枠の種別やオーディエンスタイプなど)、どのような分布(正規分布や対数正規分布など)を作るのかを実験で決めておく必要があります。SSP Bの場合のように枠ごとの中央値と平均値がすでにわかる場合は、分布の種類を決めれば配信サーバーが広告表示リクエストに乗せている情報を用いて最高入札金額の分布を推定できます。このように各SSPの特性も踏まえたロジック開発が必要となっています。

ファーストプライスオークションの入札ロジックに関して詳しくは需要があればまた書きたいと思います。

入札ロジックの開発

前述の通り、広告表示リクエストに対して私的価値を正しく評価(予測)することはDSPのロジック開発における大事な仕事です。一方、RTBというような繰り返しオークションでは他のDSPの入札金額を推定することができるので、利得を最大化するロジックを作っています。予算・目標KPI(CPCやCPAなど)の制約の元で入札ペースを調節し、配信ボリュームを最大化する事もしています。そして、予測器によって広告表示価値を予測しているので、予測が期待通り動けば実績KPIが設定した目標値に着地できます。

しかし予測値の誤差によって、広告案件の実績KPIが目標KPIと乖離する場合があります。このような場合、KPIの乖離を埋めるために運用上は入札金額を上げ下げするオペーレションが必要となりますが、このオペレーションを自動化するためにフィードバック制御を用いた入札金額の調節を行なっています。

そしてDSPは膨大な広告枠の在庫を保有しているため、広告案件と広告枠の組み合わせパターンは極めて多くなります。それはDSPを運用する人たちが各パターンを把握して調整することはほぼ不可能な量なので、入札ロジックの開発は極めて重要になるのです。

まとめ

この記事はRTBの土台となっているオークション理論を紹介し、オークションプロトコルに応じて求められる適切な入札戦略が異なることと、当社DSPがオークションプロトコルごとに設計した入札ロジックの例について説明しました。

当社DSPの入札ロジックはまたまた発展途上ですが、これから配信データを駆使し広告主の訴求に応じてより良い配信ロジックを作っていきたいですね。

より深い内容に興味があるならこれらの文献が参考になります。

技育祭にCTO小賀、fluctCTO鈴木が登壇&企業ブース出展します!

こんにちは!人事のさとみん(@satomin35y)です。

サポーターズが主催するエンジニアを目指す学生向けテックカンファレンス「技育祭(ぎいくさい)」にVOYAGE GROUPよりCTOの小賀、fluct CTOの鈴木が登壇します!また、VOYAGE GROUPとしても企業ブースを出展するのでこの場を借りて告知させてください!

技育祭とは?

f:id:satomin35y:20200625115840j:plain

学生の就活支援をするVOYAGE GROUPグループ会社のサポーターズが主催する、エンジニア学生のための日本最大級のオンラインカンファレンス。「技術者を育てる」ことを目的とし、7/4(土)・7/5(日)の2日間開催されます。

落合陽一氏、まつもとゆきひろ氏などIT業界を代表する技術者や、IT企業のCTOなど出演者も豪華です!お申し込みは、6/28(日)までなのでまだの人は要チェックです!

talent.supporterz.jp

7/4(土)15:50〜 『Goライブコーディング』

f:id:satomin35y:20200625095216j:plain

fluct CTO / 「みんなのGo言語」共著者の鈴木健太(@suzu_v)によるライブコーディング。トップエンジニアのコーディング風景が見える貴重な機会かつ、VOYAGE GROUP CTOの小賀による解説付きです!

久々にライブコーディングの機会を頂きわくわくしています!学生の皆さんに楽しんでいただけるよう、なるべく普段の雰囲気で、コーディングの楽しさが伝わる時間にしたいと思っています。技育祭、一緒に楽しみましょう!

7/5(日)13:30〜 『400人以上のインターン生を受け入れ成長させてきたCTOが考える若手エンジニアが成長するコツ』

f:id:satomin35y:20200625095232j:plain

VOYAGE GROUP CTO 小賀昌法(@makoga)が登壇します!エンジニア向けのインターンシップ「Treasure」などの事例を基に若手のスキルアップのコツを公開します!

2006年から毎年学生インターンを受け入れてきました。短期間で驚くほど成長する人を何人もみてきました。ちょっとしたコツを身につけて、成長し続け、生涯現役のエンジニアになりましょう。

7/4(土)・7/5(日) 12:20〜 企業交流ルーム『社内Barがある!?VOYAGE GROUPオンラインオフィスツアー』

f:id:satomin35y:20200625095117j:plain

VOYAGE GROUPのオフィスは航海(VOYAGE)をモチーフに、経営理念の「360°スゴイ」を体現した設計になっています。オンライン上でリアルタイムにVOYAGE GROUPのオフィスメッセージを読み解きながら、私たちと一緒に25分間の航海を体感しませんか? (※チャットでのリアル参加型を想定しております!)

技育祭のお申込みは6/28(日)!

技育祭は6/28(日)までのお申込みとなります!ほかにも興味深いコンテンツがたくさんあるのでぜひチェックください!

VOYAGE GROUP一同、当日お会いできることを楽しみにしています!

talent.supporterz.jp

Privacy Sandboxのイベントを開催しました。 #TechMar

2020年6月17日(水)に電通デジタル、サイバー・コミュニケーションズ、VOYAGE GROUPの3社でTech x Marketing meetup #2 Privacy Sandboxというオンラインイベントを開催しました。

techxmarketing.connpass.com

VOYAGE GROUPからは @makoga が登壇し「ChromiumのPotential uses for the Privacy Sandboxを読む」というタイトルで発表しました。

speakerdeck.com

もともとはタイトルにあるブログ記事の紹介の予定でしたが、それだけだと全体像がつかみにくいということで最初のパラグラフにリンクされているアウトラインとプロジェクトサイトについても紹介しています。

f:id:voyagegroup_tech:20200624215631p:plain

2つめのセッションではサイバー・コミュニケーションズ(CCI)田中さんが「デジマ担当必見!?Privacy Sandboxをデジマ視点で読み解く」を発表しました。

speakerdeck.com

Click Through Conversion Measurement Event-Level API、Aggregated Reporting API、2種類の広告リクエストから表示する広告をブラウザ内で決定する機能であるTURTLE-DOVE、類似する閲覧履歴を持つユーザー同士をブラウザ内でグルーピングするFLoCについてフロー図などを交えて説明しました。

f:id:voyagegroup_tech:20200624220406p:plain

3つ目のセッションでは電通デジタル 神田さんが「Web Privacy Survival Guide」を発表しました。

www.slideshare.net

匿名化、After 3rd party cookie、フィンガープリント、アンチフィンガープリントについて、シーケンス図などを交えて説明しました。

f:id:voyagegroup_tech:20200624221042p:plain

すべてのセッションが終わったあとはオンライン懇親会も開催し、飲みながらPrivacy Sandboxやリモートワークなどについて語りました。

今後もTech x Marketing meetupを開催していく予定です。ご興味ある方は Tech x Marketing - connpass のメンバーに登録ください。

BigQuery定額料金モデルの導入と権限分離 - CTOが聞く Vol.2

VOYAGE GROUPのエンジニアにCTOが「最近は何やってるの?」と聞いていく連載の第2弾です。今回はVOYAGE GROUP全体のインフラを担当しているともかつさんに話を聞いてみました。

目次

定額料金モデルとは

(CTO) 最近は何やってるの?

(ともかつ) BigQueryの料金モデルを定額に変更しました。

(CTO) おー、コスト下がったって言ってたやつね。定額料金モデルってどんな内容なのか教えて。

(ともかつ) 公式サイトには「BigQuery では、処理データの TB あたりオンデマンド料金よりもクエリの固定料金をご希望のお客様向けに定額料金をご用意しています。」と書いてあります。うまく使えばオンデマンド料金より安くなると思います。

f:id:voyagegroup_tech:20200522164838p:plain
クエリの料金 - BigQueryの料金

(CTO) 単価が安いってことは何か制約があるってことだよね?

(ともかつ) クエリ処理に使用するスロットを、500スロット単位で購入する必要があります。ただし効率よくスロットを使えなければ、オンデマンドより高くなります。

(CTO) まあ、ただ単に安くなるなんてうまい話はないよね。

最初は苦戦した

(CTO) どう進めていったの?

(ともかつ) VOYAGE GROUPは多くのプロダクトでBigQueryを利用しています。その中で1番利用料の多いプロジェクトから導入を進めました。

(CTO) お、いきなり1番多いとこから? 少ないプロジェクトからって手もあったんじゃない?

(ともかつ) 一番多いところで導入することがメリットを享受しやすいので。ただ、スロットを使い切る可能性も十分考えられる利用状況だったので、何かあればすぐオンデマンドに切り替えられることを事前に検証し、事業リスクも低いと結論づけて実行に移しました。

f:id:voyagegroup_tech:20200522180101p:plain
料金モデルの選択: オンデマンドと定額

(CTO) なるほどね。順調だった?

(ともかつ) それが、懸念していたようにスロット上限を利用した状態で張り付いてしまい、クエリの実行に遅延が発生しうる状態になってしまって・・・。いったんオンデマンドに戻しました。

(ともかつ) そこから新規のGCPプロジェクトを作成し、処理に時間が掛かるクエリをそのプロジェクトに移設しました。もう大丈夫だろうと改めて定額に切り替え、一旦は問題ないように見えました。

(ともかつ) ところが、アドホックの調査用のクエリで重たいものがいくつかあり、何回か上限に張り付く事象が発生しました。

(CTO) 運用に載せると見えてないものが見えてくるよねw

(ともかつ) はい。。。

管理の一部を権限移譲した

(ともかつ) オンデマンドと定額を切り替える権限はシステム本部(VOYAGE GROUP全体に関わるインフラやCorporateITに責任を持っている部署)だけが持っていました。なぜかと言うと、この権限を渡すと別の部署の設定も変更できてしまうからです。

(ともかつ) とはいえ、1次アラートを受け取ったチームメンバーがすぐ対応できない状況はシステム本部にとっても各部署のチームにとっても良い状態ではないので、なんとかしたいと思っていました。

(CTO) アラートを受け取った人がすぐ対処できるようにしたいよね。

(ともかつ) マニュアルを調べつつ権限の調整と検証をしていると、GCPコンソール画面からはできないけど、API経由であれば細かく設定できることを発見しました。

(ともかつ) これを使うことで各部署は自分たちのリソースだけを操作できるようになりました。

f:id:voyagegroup_tech:20200522175825p:plain
容量コミットメントをワークロード、チーム、および部門に分割

(CTO) 上記画像にあるAssignments単位でオンデマンドと定額を切り替えることができるようになったということか。これはGUIでも設定できると嬉しいやつだ。

今後やっていきたいこと

(CTO) まずは1つの部署で導入し、安定運用までいきました。今後やっていきたいことは?

(ともかつ) 現在の使いかただとスロットにまだ余裕があるので、今後は定額の利用部署を増やしていきます。

(ともかつ) そのためには各部署ごとにスロットの最低限の確保をする必要があると考えています。

(CTO) ある部署が一気に使って他の部署のサービスに影響が出ないようにするには最低保証は欲しいよね。

(ともかつ) そうなんです。そしてそれをやろうとするとまたAPI経由での設定になるようなので、そのあたりを調査、構築、テストしていきます。

(CTO) いいね。

まとめ

(CTO) 料金モデルの変更にあたり、事前の試算から初期導入までを良いスピードで進めたこと、今後の全社展開など、いい話が聞けました。

さて、次回は誰に聞こうかなー


バックナンバー techlog.voyagegroup.com

新卒1年目を終えて、若手エンジニア座談会

こんにちは!VOYAGE GROUPでエンジニア新卒採用を担当するさとみん(@satomin35y)です。

VOYAGE GROUPでは4月に24名の新入社員が入社しました!(うち9名がエンジニア)

今回は、新卒1年目をどう過ごしたのか、2年目で活躍する先輩エンジニアにインタビューをしたのでその様子を座談会形式でお届けします。

お話してくれた2年目エンジニア

f:id:satomin35y:20200512120441j:plain

にっしー(上)株式会社VOYAGE Lighthouse Studio所属。ゲーム攻略メディア『神ゲー攻略』のシステム開発を担当。システムの保守からサイトの機能開発、ライター業務効率改善のためのツール開発など幅広く担当。

まっしゅ(左下)株式会社fluct XDC(Experience Design Center)に所属。フロントエンドを担当。現在、新入社員のOJTも担当中。

しょーた(右下)株式会社fluct 開発本部SREチームに所属。主にAWSやCI/CD、システム監視周りを担当。

ーVOYAGE GROUP(以下VG)に入社しようと思ったきっかけは?

まっしゅ: VGを初めて知ったのは1dayインターンで、その後サマーインターンのTreasureにも参加し出会う人みんながいい人ばかりで、人の部分で魅力を感じ入社を決めました。

しょーた:きっかけはSunriseというインターンで、VGがアドテク方面で強いインフラ基盤を持っていることを知りました。学生時代はインフラを触ってはいなかったけれどVGでなら楽しくインフラに取り組めそうと思い入社しました。

にっしー:僕は2人の経歴を足した感じですが(笑)、1dayとTreasureとSunriseに参加しVGのクルーと関わる機会が多く、会社の事業に興味があったというよりは「いい人ばかりしかいない」という人の部分に魅力を感じて入社しました。

voyagegroup.com voyagegroup.com

※1dayインターンは今年は現時点で開催予定はありません。

ー入社前と入社後でギャップはあった?

全員:ギャップかー…(悩む)

まっしゅ:いい意味でのギャップならありました!入社前は、たとえば管理画面の担当になれば管理画面だけという風に、ずっと1つの領域を任されるのかなと思っていました。でも実際に入社すると、やりたいことをどんどん任せてもらえ、バッチや広告配信のJavaScript、管理画面などfluctにあるもの全般を半年間で触りました。現在は、新サービスの「DATA STRAP」に関わるなど幅広く携わっています!

しょーた:僕は思ってたより、みんながちゃんと仕事をしているというギャップがありました(笑)

にっしー:それ言おうと思った(笑)

しょーた:入社前からカジュアルにコミュニケーションをしてくれたので仕事もそのイメージだったのですが、いざ仕事になるとみんなしっかり考えて仕事をしてるという、いいギャップがありました。

にっしー:僕もほぼ同じなんですが、フランクにコミュニケーションを取る人が多いイメージでしたが、議論の場ではみんなしっかりと自分の考察を持ってくるのが印象的でした。 開発のアプローチを取るときも明確な理由を求められることが多く、ユーザーやプロダクトを中心にして考える必要があるんですが、逆にロジックがしっかりしていれば年次関係なく受け入れてくれる点で、組織構造のフラットさにも驚きました。

しょーた:たしかにそう思う!

にっしー1年目でも筋が通った考えであれば自分の意見が通る雰囲気があるよね。

しょーた:僕はまっしゅを見ていて思うことがあって。fluctは歴史が長いサービスなので技術的にも過去の遺産があって凝り固まってるのかなと思っていたんですよ。でも、まっしゅは新しいことをしているし、fluctの開発自体も新しい技術をどんどん取り入れる雰囲気が強いです。そこも入っていい意味でのギャップでした。

まっしゅ:たしかにもっとレガシーだと思ってた(笑)

ーまっしゅは新しいことをしてるの?

まっしゅ:fluctは2010年に開発が始まったので管理画面のフロントだと古いjQueryだけかと思っていたんですが、モダンなReactも使い始めています。最初は知見がある人がいればReact化したいという感じだったんですが、ちょうど僕が触った経験があったのでReact化していくことも採用され、さらに新サービスのDATA STRAPではモダンな技術のみでの開発に挑戦しています。

にっしー:Reactをメインで書けるのがまっしゅだけの状態でよくそっちに意思決定できたよね。柔軟ですごい。

まっしゅ:たしかに。fluctの中でもフロントメインの人がいないのは課題としてずっとあって、ある日のキックオフ会でfluct CEOのもっちーさんに「まっしゅがフロントチームのリーダーね!1人だけど!」と誰もいないなら自分でやってみようの精神で指名されたのが始まりだった(笑)

全員:すごい(笑)

ー1年目で成長したなと感じるポイントは?

まっしゅ人に聞かず自分で意思決定ができるようになった部分ですね。最初の3ヶ月は、自分のやりたいことがあっても周囲の人に都度伺いを立てていたんですが、1on1の振り返り面談で上司に進め方を相談したら「もっと自分で意思決定していいよ」とアドバイスをもらい、それからは自分で決めてその理由を周囲に伝える姿勢に切り替えました。DATA STRAPでも、自分が1番知っている立場で決める人は自分しかいないので、意思決定の部分で成長できたと思います。

全員:いい話だ…!

にっしー:僕はWebメインの事業部なんですが、入社前まではアプリメインにしか開発してこなかったんです。なので、1年間でJavaScriptの開発力がかなりついたなと思います。また、ユーザーやプロダクト中心に考える姿勢も1年間で育ってきたなと感じます。

しょーた:僕もにっしーと似てるんですが学生時代はサーバーサイドをメインにしてたので、AWSやLinuxの知識はない状態でSREチームに入りました。インフラをメインにやりたい気持ちは強い一方で、業務上どうしてもインフラの知識がないと話し合いにすらならないことも最初は日常的に起き、なので最初は知識の吸収をひたすら行いました。今では管理画面のフロントのCI/CDをまるっと作り変えることができ成長した気がします。

まっしゅ:2年分の負債を取り除いてくれたやつね!最初は僕がやろうとしたけど自分の知識では無理で、しょーたに助けを求めたら全部作り変えてくれました(笑)

しょーた:まっしゅの痕跡も消して作り変えました(笑)あとは試験環境も作ったり、監視周りもできるようになりましたね。

ーどうやって1から知識をつけていったの?

しょーた:問題に対してなにが問題かをひたすら調べ、調べる中でわからないことが出てくるとその瞬間にまた調べ、という繰り返しで進んでいきました。

にっしー:しょーたは今年Treasureのインフラ講師にも選ばれたもんね!すごいよ! voyagegroup.com

しょーた:初めてで不安もあるけど頑張ります(笑)

ー最後に、2年目で挑戦していきたいことは?

まっしゅ:技術面では、SSRとPWAですね。DATA STRAPでも最初からSSRをやってみたいと提案はしていたのですが、SEOを気にしないプロダクトの性質やデプロイフローが難しくなることもあり、自分でプロダクトを立ち上げるのが初なので今回は見送りにしてました。ただ、プロダクトが無事ローンチできたので、次の挑戦としてはちょうどいい課題かなと思っています。

にっしー:Webの知識はついてきた実感があるので、次はAWSやGCPのクラウド周りの知識をキャッチアップしたいです。あとは、課題を解決するための自分の手札を増やすために使える技術の幅も広げていきたいですね。最近はNext.jsを勉強中です。

しょーた:インフラ知識のインプットはできてきたので、次はアウトプットの比率をあげて会社に対して貢献していきたいです。技術的には、最近GCPの勉強を始めたので使っていきたいのと、グローバル展開がきているのでAWS上でのUSなどのマルチリージョン化に取り組みたいです!

まっしゅ・しょーた・にっしーありがとうございました!