#技育祭 「400人以上の...若手エンジニアが成長するコツ」の動画が公開されたので、口頭で回答したことのいくつかをこちらにも記載しておきます

2020年7月4日、5日の2日間で開催された技育祭 2020では3つのセッションに登壇した @makoga です。

CTOパネルディスカッション

初日のオープニングセッションとなるCTOパネルディスカッションでは、『エンジニアリング組織論への招待』の著者であり株式会社レクター 取締役 広木さん、ビジョナル株式会社 取締役CTO 竹内さん、 合同会社DMM.com CTO 松本さんの3人をパネラーに迎え、私はモデレータとして参加しました。

www.youtube.com

このパネラーで面白くならなかったらモデレータの責任だなと思っていたので、たくさんの人が視聴してくれてホッとしました。

Goライブコーディング

午後には、すずけんのライブコーディングの解説役として参加しました。

※動画が公開されたらここに追記します。

こちらも多くの人が視聴してくれました。ライブコーディングはみんな真剣にみるのでイベント中はすごい静かだけどアンケートの結果をみるといつも満足度が高いイベントなんですよね。

400人以上の...若手エンジニアが成長するコツ

2日目には、『400人以上のインターン生を受け入れ成長させてきたCTOが考える若手エンジニアが成長するコツ』という長いタイトルの単独セッションに登壇しました。

www.youtube.com

このセッションは200人以上の学生が視聴してくれたようです。とても嬉しい。

初日に2つ登壇し、他のセッションを視聴したところ、技育祭に参加する学生はたくさん質問してくれることが分かりました。そこで、最後の質疑応答だけではなく、区切りのいいところで質問ピックアップの時間を2回とりました。

f:id:voyagegroup_tech:20200912104628p:plain
アジェンダ - 若手エンジニアが成長するコツ

これは成功だったと思います。たくさん質問をもらえましたし、視聴者の理解も深まったと思います。

このプレゼンで使った資料は公開していますので、若手エンジニアが成長するコツに興味がある人はぜひ読んでみてください。

speakerdeck.com

このエントリでは、当日にもらった質問やコメントに対して、口頭で回答したことのいくつかを記載しておきます。

当日にもらった質問やコメントと回答

  • 学生:ダニングクルーガー曲線の完全に理解したまでいくのが最初のハードル
    • 回答:自分だけで学べるところまでいくのは簡単ではない。勇気を出して周囲のできる人に支援を求めよう。
  • 学生:筋トレみたい
    • 回答:そうですね。コンフォートゾーンの少し外側で負荷を掛けながら力をつけていくのは似てますね。
  • 学生:研究だけに頼らずいろんなものに手を出すべきか?
    • 回答:好奇心を持って脇目をふらず集中できることがあるならそれでいい。壁にぶち当たっていたり、伸び悩んでいるのであれば、周囲に目を向けることも悪くない。
  • 学生:目標に到達し、次の目標を出す方法は?
    • 回答:一歩引いて視野を広げ目標を探索する目標を立てる。もしくは、到達したものにつながる周辺のことに目を向けてみる。
  • 学生:自分の上位互換みない人がたくさんいる中で競争しなければならない場合、どんなことを意識するといいか?
    • 回答:いきなり同じようになれないし、個性が違うのでなる必要もない。上位互換の人の良いところを1つ選び、それを身に着けるようにする。いろんな人の1つをいくつか身に着けると自分の個性につながる。
  • 学生:目標設定が難しい
    • 回答:繰り返しになるが、他の人が持っているもので自分も身につけたいというものがあればそれを目標にしてみるといい。
  • 学生:分からないことを1人で無限に調べてしまう癖がある
    • 回答:調べることは悪いことではないが、時間的な制約があるなら信頼できる人にすぐ聞くのがいい。その場合、答えを教えてほしいではなく、ここで詰まっているので次の1手を教えてほしいという聞き方がおすすめ。
  • 学生:ただ作るだけなら速いが、凝り性なので時間が掛かる
    • 回答:早い段階で、他の人に見せることを意識するのがおすすめ。
  • 学生:質問の仕方に悩む
    • 回答:分からないことを質問するのもスキルである。ファクトを伝えることを意識しよう。やりたいこと、やったこと、結果を区別して伝えよう。
  • 学生:何か作りたいけど、作りたいものがない
    • 回答:普段使っているツールを模倣したものを作ってみるのがおすすめ。そうすれば仕様を考える時間を最小限にし、技術的なチャレンジに集中できる。
  • 学生:これほど育成に力を入れているのはなぜですか?
    • 回答:ソフトウェア開発力、プロダクト開発力がビジネスの競争力の源泉だと思っているから。

まとめ

技育祭はとても盛り上がりましたし、面白いセッションがたくさんあったと思います。

次の機会があれば #voyagebook 『Engineers in VOYAGE 事業をエンジニアリングする技術者たち』をベースに「事業をエンジニアリングするコツ」の話をしようかなと思っています。

[イベントのお知らせ]

voyagegroup.connpass.com

#voyagebook の書評で頻出する3つのテーマ

こんにちは。技術広報の丹野です。 2020年8月7日に発売された『Engineers in VOYAGE 事業をエンジニアリングする技術者たち』(ハッシュタグ #voyagebook)ですが、その後多くの方々から素敵な感想/書評をいただきました。とてもありがたいですね。今回は本書の書評の中で取り上げていただく機会が多かったテーマについてまとめたいと思います。

f:id:tan2jpn:20200911165048j:plain

頻出する3つのテーマとその書評

生々しい、ここまで公開していいのか

blogやTwitter、Facebookなどでの反響で特に目立つのは、「ここまで赤裸々に公開して大丈夫?」という趣旨のものです。 いずれもVOYAGE GROUPの現役のサービスに関する話題なので、過去に直面した課題のことが話されていても、現時点では解決しているか、解決に向かって進んでいます。そういう観点では安心してお読みください。

​ 将来の状況の変化に伴う課題をあらかじめすべて想定して事業を始めることは、現実的には困難です。 そのなかで、開発者もまた事業の当事者として、システムの技術的な課題だけでなく事業の要請から生まれる課題にも取り組んできた結果が「生々しさ」につながっているのだと思います。 その生々しさがリアリティとして伝わったならうれしいです。 ​

いくつか印象に残った書評を下記に引用させていただきました。

珠玉のエンジニアリング冒険譚 〜 書評「Engineers in VOYAGE 事業をエンジニアリングする技術者たち」 : 小野和俊のブログ

そしてこれらの課題に対して、それぞれのプロジェクトでどんな風に考え、どんな文化を大切にし、どんな苦労に直面しながら、これらを乗り越えてきたのかが記されている。その内容は「企業の名前を入れた本で、ここまで書いていいのか」と思えるほどに赤裸々だ。興味深いのは、テーマの重さと対照的に、課題を乗り越えるためのアイデアはほとんどすべてがしなやかさや遊び心を感じさせる軽やかなものだということだ。

Engineers in VOYAGEを読んだ - Diary over Finite Fields

生々しさゆえ、読んでいても爽快感を覚えることはない。しかし、事業に向きあう開発者を美化せずに描いているし、そして課題解決の過程がとてつもなく面白い。

技術的負債との向き合い方:カッとなってやる短期決戦と腹を括ってやる長期戦

「技術的負債」というキーワードへの反応もたくさん頂戴しています。 インタビュワーの和田さん自身、本書の制作過程であらためてウォード・カニンガム氏による「技術的負債」のもともとの含意を手繰り寄せられたことからも、「技術的負債にどう取り組んでいくか」は本書の大きなテーマのひとつだったと言えるかもしれません。 ​

特に、第3章のVOYAGE MARKETINGや、第5章のサポーターズのエピソードは、数多くの歴戦のWeb開発者の方々の心に響いたようです。 また、第1章のfluctでの「腕力」をめぐる和田さんの話に共感いただいたという声もいくつか拝見しました。 技術的負債との対峙という観点で印象に残った反響を下記に引用させていただきます。

#voyage-book.md · GitHub

fluct の事例では、”技術的負債の返却には腕力が必要” という言葉が登場するのですが、これは非常によくわかるなぁと感じました。こういった過去の辛さを改善していく作業は、ついカッとなってやれる人がいると進んでいくことってあるなぁと振り返ってみても感じます。

一方、ECナビの事例では戦略的に改善していく事例が紹介されていて、これをコツコツやれるのはすごいと感じました。その中で複雑すぎるテーブルの関連性をツールを使って可視化したけど複雑すぎることがわかっただけで有効活用されなかったという話はあるあるで好きでした。複雑なシステムをツールなどを使って可視化してみたけど、どうすればいいのかわからずそこで満足して終わってしまうことはよくありますが、そこから別のアプローチで進めていったのはとてもいい事例だなと感じました。

事業会社の現場 - 「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」 - Shin x Blog

3 章は、それ以外にも、データベースのテーブル数を 1200 から 450 まで減らしたり、システムをスリム化していく流れでコード、機能、事業の削減(葬り)に分けて実施していくという骨太の内容でした。これを 5 年かけて通常業務と並行しながら除々に実施したというのは、大変ではありますが、粘り強く少しづつでも進めることで技術的負債を返却できるという一つの指針を見ることができました。

Engineers in VOYAGE - 事業をエンジニアリングする技術者たち - を読んだ

単に技術的な機能面だけはなく、事業ごと葬る、といったようにビジネスサイドとも合意を得て力強く進められていることがわかる。 このような経験・スキルは中で体験しているエンジニアでないと獲得しがたいものである。もちろん、書籍から得られる知見は表面上に限るかもしれないが、その内容について少しでも触れることができるという意味で、大変貴重な書籍である。

事業を作る人達の物語が最高だった #voyagebook - そーだいなるらくがき帳

要所でそれぞれの事業部がそれぞれの技術的負債に対して、どのように解決してきたかが書いてある。 そのアプローチは事業のフェーズ、規模によっても当然違ってくるが、それが各事業毎に違ったアプローチで書かれているのだが、それがとても参考になる。 リプレースなのか、リアーキテクチャなのか、リファクタリングなのか、それぞれ全く違うアプローチを1冊でそれぞれ見れる貴重な本だ。 今まさに技術的負債に立ち向かおうとしているのであれば一度は読んだ上で、アプローチの参考にしてほしい。

本:Engineers in VOYAGE - 事業をエンジニアリングする技術者たち|hidenorigoto|note

本書を読んで私が思うのは、VOYAGE GROUPは、負債の上手い乗りこなし方を身に付けているということです。事業開発という目的のためには、避けて通れない技術的負債の問題に対して、組織としての対応能力を磨いているように思います。

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

本書のサブタイトルにもある「事業をエンジニアリングする」という観点への反響もたくさん頂いています。 当初は『事業をエンジニアリングする技術者たち』のほうが本書のメインタイトルだと思われてしまう誤算もありましたが、 これはカバーの印象だけからくる勘違いではなく、やはり本書を実際に読んで感じて頂いたものが「事業をエンジニアリングする」というフレーズにとても合致していたからこそだと思います。 ​

頂いた反響のなかにも、下記に引用させていただいたもののように、このフレーズに込めたメッセージを的確に読み取っていただけたと感じられるものがたくさんありました。

珠玉のエンジニアリング冒険譚 〜 書評「Engineers in VOYAGE 事業をエンジニアリングする技術者たち」 : 小野和俊のブログ

正論だけではまかりとおらない、事業という複雑で壮大な冒険をVOYAGEのエンジニアたちはどんな風にして生き抜いてきたのか。 本書のサブタイトルは「事業をエンジニアリングする技術者たち」。 そう。ここで登場するエンジニアたちは、ソフトウェアだけでなく、事業そのものをエンジニアリングしているのだ。

「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」を読んだ #voyagebook | by Yuki Fujisaki / tnj | Aug, 2020 | Medium

この本の中では、事業方針や組織体制と、開発して生まれるソフトウェアの設計は切っても切り離せない、コンウェイの法則的な話が何度か登場します。また、出てくるチームは大きさもバラバラで、文化もそれぞれ異なりっているのですが、事業としてのエンジニアリングを全員が認識しているのが自分の中では印象的で、フルスタックエンジニアではなくフルサイクルエンジニアの考え方を軸に置いているのが組織文化に繋がっているように感じました。

事業を作る人達の物語が最高だった #voyagebook - そーだいなるらくがき帳

5年、10年、15年モノの事業との付き合い方や0から始める新規事業との付き合い方、そしてそれぞれのフェーズで新しいことにチャレンジしていくために如何にビジネスを犠牲にせずに立ち向かっていくか。 そんな物語の中に哲学がある。

「事業をエンジニアリングする技術者たち Engineers in VOYAGE」を読みました

エンジニアが勝手に考えた「キレイなシステム」とか「最強のシステム」ではなく、ビジネスと照らし合わせた上で解決すべき課題を定義して改善するという進め方が全体としてあるように感じました。

#voyage-book.md · GitHub

エンジニアリングは事業のために行われるものであり、本書では様々なシステムや様々な状況の話が出てくるのですが、事業のためにという点が全ての共通点としてブレてない点に企業としての強さを感じました。この点については技術力評価会に参加している中でも感じたことだったので、本書を読んだ改めて納得した部分です。

事業会社の現場 - 「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」 - Shin x Blog

インタビュイーである開発現場のエンジニアの方々が圧倒的な当事者意識を持って仕事に取り組まれているということです。これはシステムに対してだけでなく、事業に対しても同様です。事業会社で働くなら当たり前のことかもしれませんが、システム、さらにその目的である事業をいかに自分のこととして捉えられるかによって考え方も起こすアクションも変わってきます。

事業会社の現場 - 「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」 - Shin x Blog

こうした当事者意識は本人の心持ちだけではなく、それを後押しする環境、文化にも影響を受けます。もし、自分がこうした意識を持とうとしても、すぐにボールを取り上げられる環境や事業サイドの下請けのような立場になっている環境ではそれを継続することは難しくなります。本書で登場する 5 社では現場のエンジニアが当事者意識を持てるような、後押しするような環境になっているのだろうということを感じました。

本:Engineers in VOYAGE - 事業をエンジニアリングする技術者たち|hidenorigoto|note

ソフトウェアエンジニアのモチベーションの源泉というのは人によって様々ですが、「事業に貢献する」ことに強くモチベートされる方が、偶然私の周りには多くいます。「Engineers in VOYAGE - 事業をエンジニアリングする技術者たち」は、そういう種類のソフトウェアエンジニアが読むと、この会社で仕事したら楽しいだろうな!と思わせてくれる本だと思います。

書籍『Engineers in VOYAGE 事業をエンジニアリングする技術者たち』とは

本ブログによる発売エントリ

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

  • 本書内の「はじめに」を全文掲載しています。

本書の編者:和田さん (@t_wada)のブログエントリ

『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』ができるまで #voyagebook

  • 「はじめに」のはじめに、本書のきっかけ、インタビュー準備と本番、各章の読みどころ、本書へのさまざまな方からの感想などをまとめていただいています。

本書の編集者:鹿野さん (@golden_lucky) のブログエントリ

2010年代に日本のインターネットでいろんな事業をいい感じにやってきた会社から2020年代へのヒントをもらえる本を作った

  • なぜ VOYAGE GROUP?なぜ t_wada?なぜ宇宙船?で、結局のところどういう本なの?など、鹿野さんの視点から本書を振り返っていただいたアツいブログエントリ。

本書の購入について

最後に

VOYAGE GROUPのエンジニアたちやエンジニアリングの文化に興味を持っていただけた方は、本書のインタビュイーたちともカジュアルに質問や情報交換などができる機会を設定したいと思いますので、以下のリンクからご応募いただけると幸いです。

「Ask the Engineers in VOYAGE」

エンジニア向けサマーインターンシップ Treasure2020が終了しました!

こんにちは!VOYAGE GROUPの中田です。 Treasure2020ではサポーターをやってました!

8月1日より開催した『Treasure』が、8月28日に終了しました! 興奮が冷めないうちに、その様子をお届けしたいと思います。

目次

Treasureとは

2006年から毎年夏に開催しているエンジニア学生向けのインターンシップ。今年でもう15回目になります!

TreasureはVOYAGE GROUPのものづくりのエッセンスが詰まっており、それを現場のエンジニアから直接感じてもらえるようにデザインしています。

VOYAGE GROUPのエンジニアが普段やっていることや考えていることを講義で事前に伝え、それを元にチーム開発することで、チームでもの創りをする難しさや楽しさを感じてもらう内容にしています。

学生が1人では学びにくい「価値を生み出す考え方」「継続的にサービスを支える考え方」「チームで実践する考え方」を伝え、しっかりと学習と実践のサイクルを回していく場にしています。

Treasureのテーマは「価値のあるものづくり」と「Goを使って学ぶソフトウェアエンジニアリングとチーム開発」。 今年は8月1・8・15・17日を講義、18〜28日をチーム開発としました。

講師・サポーター陣がフルコミット!

Treasureの特徴は参加学生よりも講師やサポーターが多いこと。 今年は参加学生24人に対して講師・サポーターは32人でした!

Treasureでは、1人だと学びにくいことを学ぶ場として、学生が疑問に思ったことはすぐに講師やサポーターに聞ける環境にこだわっています。

前半の講義では講師や内定者TAが、後半のチーム開発では1チーム学生4人につきクルーが3~4人サポーターとしてフルコミットしました。

初のフルリモート開催

さて歴史あるTreasureですが、今年は世間の状況もあり、初めて全日リモートで開催しました。

元々、Treasureは今年の1月下旬には日程を告知しており、3月時点ですでにたくさんの学生の応募がありました。しかしCOVID-19の影響で学生の夏休みが変更になり、当初予定していた日程では開催しても学生が集まるか怪しく、オフラインで開催できる見通しも立たない状況でした。ただ、「Treasureを開催する!」という意思は変わらなかったので、オンライン前提で開催できるように意思決定をしました。

とはいえ、初のオンライン開催。コミュニケーションの取りづらさにより進行がスムーズに行かないのではないか、フォローが十分行き渡らないのではないか、熱気が作りづらいのではないか、などの懸念がありましたが、できる限りの対策を準備し、当日を迎えました。

f:id:carter_vg:20200907143254j:plain
機器もセットし、準備完了

参加学生は自宅からTreasureに参加。北海道から九州まで、全国各地の学生さんが参加してくれました。

f:id:carter_vg:20200907144058j:plain
気合いの入る一言でスタートします

前半:講義

講義内容

  • GoでWebアプリケーション開発
  • フロントエンド(JavaScriptの基礎でevent loopからWebRTC,Reactなど)
  • データベース設計・データベースモデリング
  • インフラ
  • アイデアソン

オンラインという特性上、例年と比べ個別での質問対応やフォローアップがやりづらい環境のため、参加学生の理解度に差が出てしまわないかという懸念がありました。

そこで、下記を実施しました。

  • インタラクティブになるように、講師が全体に質問を投げかけ、直接答えたりSlack上で回答してもらう
  • Zoomのブレイクアウトルームに分け、学生3人につき1人は講師か内定者TAがつき、その場で質問に答えられるようにする
  • 悩んでそうな学生へ内定者TAがDMで連絡をし、フォローアップする
  • 講義中に理解できなかった部分は後日講師が解説する補講日を作った
  • 講義や補講を録画し、自分でわからなかったところを後日、復習できるようにした

後日参加学生に取ったアンケートには、

  • DMで困ったことがないかときどき聞きに来てくれるのがとても助かった
  • わからないところをマンツーマンで教えてくれたのが良かった
  • Slackで質問しても丁寧に返信をくれたのが嬉しかった

というコメントをもらうことができました。講師や内定者TAのサポートのおかげで、講義の理解を深めていくことができたようです。

f:id:carter_vg:20200907150036p:plain
講義の様子
f:id:carter_vg:20200907144207j:plain
裏側ではこんな感じに

後半:チーム開発

講義で学んだことを基に、4人1組に分かれチーム開発を行いました。 社会構成や価値観の変化(=時流)に伴い生まれてきた課題や欲求を満たすものを開発しよう、という内容のものでした。

各チームは学生4人に、エンジニア2名がサポーターとしてフルコミット。まずはどのような時流があるかを各チームで議論し、価値のあるプロダクトのアイデアを固めていきました。 普段はホワイトボードや模造紙を用いて行うワークですが、今回はMiroというツールを使い、オンライン上でのアイデア出しや思考整理を行いました。

f:id:carter_vg:20200907144413j:plain
Miroでアイデアワーク

アイデアが固まったら開発。チーム開発においても、コミュニケーションの取りづらさから、議論や開発がスムーズに行きづらい懸念がありましたが、常にZoom等のWeb会議ツールを接続し声をかけあえる状態にしたり、画面を共有し合いながら開発をしていきました。

f:id:carter_vg:20200907144443j:plain
開発の様子

そして、随時サポーターとの個別面談を積極的に行い、個々人の不安を解消していきました。最初はぎこちなさもありましたが、日を追うごとにコミュニケーションが円滑に行え、例年と変わらないチームの結束が出来上がっていきました。

またチームでの取り組み以外にも、全体での朝会や夕会で進捗の共有や決意表明。時にはお誕生日会やajitingなどのイベントを設け、全員での共通イベントを開催しました。 *1

Treasureといえば、「同世代のイケてるエンジニアと仲良くなれる!」という口コミが広がっていますが、オンラインでどう作っていくのか試行錯誤しました。 しかし、上記のような全体で顔を合わせる機会を作ることで、オンラインでも「24人でTreasure生である!」という思いをみんな持てたのでは?と思っています!

f:id:carter_vg:20200907150135p:plain
サプライズで誕生日会を開催

最終発表

10日間の開発期間も終わり、いよいよ出来上がったものを披露する最終発表!発表の仕方も各々のチームの色が出ていました。

f:id:carter_vg:20200907144808p:plain f:id:carter_vg:20200907144818j:plain f:id:carter_vg:20200907145256p:plain f:id:carter_vg:20200907145308p:plain f:id:carter_vg:20200907145324p:plain f:id:carter_vg:20200907145335j:plain

発表の後はブースタイムを設け、講師の方を中心にさらに個別での質問を受けました。

最後に審査員による賞の発表。 「API設計賞」「UI/UX賞」「データモデリング賞」「DevOps賞」「ニーズ賞」「グランプリ」に分かれ、表彰されました。

そして最後にみんなで打ち上げを行い、Treasureは幕を閉じました!

f:id:carter_vg:20200907145453j:plain
打ち上げの様子。Treasureおつかれさまでした!

参加学生の感想

  • サポーターさんのサポートが手厚いという評判は聞いていましたが、想像以上にサポートしてくれてとてもありがたかったです。講義の日では1on1でコードをみてもらったり、チーム開発ではとてもいい助言やエラー解消の方法を的確に教えていただけました
  • webの面白さはもちろんですが、それ以上にプロダクトづくりの面白さを肌で実感することができました!自分の作りたいもの・価値あるものを作れるように今後も技術に貪欲にいたいと思いました!
  • 振り返ると本当に意味が分からないほど参加者を育てるための仕組みみたいなものがたくさん用意されていて、VOYAGE GROUPは良い環境なのだろうなということを思いました
  • オンラインだと熱が入るのかな、あるいは初対面のメンバーと打ち解けて開発できるのかなと不安でしたが、全然そんなことはなく、最高に熱い夏になりました!!!めちゃくちゃ楽しかったし、めちゃくちゃ勉強になりました!
  • ここまで本気で駆け抜けたのはTreasureが初めてでした。本当にお世話になりました

感想ブログ

早速、Treasure2020の感想ブログを書いてくださった方も。ありがとうございます!

hirocky86.hatenablog.com

ogijunchang.hatenablog.com

Treasureに参加した話 byたくりんとん

https://blog.takurinton.com/17

note.com

tokoroten-lab.hatenablog.com

最後に

オンライン開催ということで、不安を抱えながら開催した部分もありますが、多くのクルーに協力をいただきながら創り上げることができ、終わってみれば例年と変わらない熱気を生み出すことができました。

私も久しぶりのサポーターとしての参加でしたが、より良いプロダクトを作れるようどうサポートするか、参加学生の成長をどう支援していくかを、立場や職種関係なく関わっている全員が本気で考え取り組むから、この満足度を生むことができるのだなと感じました。 本気で向き合ってくれる人が多いところがVOYAGE GROUPの良さだなと感じますし、参加学生の皆さんには、ぜひ得たものをさらに自らの手で磨いていき、これからも成長していってもらいたいなと思います。

次回のTreasureは来年になると思います。 参加資格を持つ学生さん、ぜひご応募お待ちしております!

*1:ajiting…VOYAGE GROUPの社内バーAJITOでお酒などの飲み物とPCを片手に語り合う文化。今回はオンラインの仮想AJITOを設け、終わってからちょっと集まって雑談をしました。

書籍「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