KDD 2019, AdKDD 参加レポート

こんにちは @hagino3000 です。去年に引き続き今年もデータマイニングの国際会議であるKDDに参加してきました。本稿は主にアドテク及びマーケティング関連の発表に焦点を当てたレポートです。

www.kdd.org

Index

なぜKDDに参加するのか

私は研究職では無くエンジニアですが、広告配信システムの開発業務で参考にする論文の多くはKDDに投稿されたものです。去年のKDDで見聞きした発表もいくつかは自社サービスのビジネス設定にあわせてプロダクトに適用しました。さらにインターネット広告に関するワークショップであるAdKDDが毎年開催されるため、広告配信システムに関る者として効率良くインプットと議論ができる事が挙げられます。

広告分野以外の発表についても、Applied Data Science Trackは問題をどう解決したかのソリューション設計が肝であるため分野を問わず学ぶところが多くあります。

Tutorial Day

KDD 2019 | Lecture-style Tutorials

初日はTutrorial Day。去年はガラガラだったA/B Testのセッションが2つもあり、かつ部屋から人が溢れる程の人気ぶりに驚きました。A/B Testはメトリクスの選定からオンライン多重検定におけるFDR(False Discovery Rate)の制御[1]まで様々な話題があり、知れば知るほどその奥の深さに気づかされます。

Challenges, Best Practices and Pitfalls in Evaluating Results of Online Controlled Experiments Fundamentals of large-scale sequential experimentation

AdKDD 2019

2日目はWorkshop Day、私は目当てのAdKDDに参加しました。

2019 Papers and Talks | AdKDD 2019

AdKDD Workshopはインターネット広告に関する招待講演と論文発表で構成されます。SSPからDSPまで様々なプレイヤーの持つ課題、例えばオークションメカニズムの設計・RTB入札ロジック・コンバージョン予測・広告クリエイティブ審査の自動化・広告効果の因果推論・オーディエンス属性推定とトピックは多岐にわたります。全ての発表の紹介は書ききれないので、いくつかピックアップします。

Tencent Ads: Interesting Problems and Unique Challenges

最も印象が強かったのは、Tencentの広告プラットフォームにおける取り組みをまとめた発表でした。広告クリエイティブの自動審査や人間の手によるターゲティング設定を自動化するといった地味な運用の話があったと思えば、動画の中に広告オブジェクトをレンダリングするVideoIn Adsの紹介が始まると会場の空気が一変します。

f:id:hagino_3000:20190815142953j:plain
Tencent Ads: Interesting Problems and Unique Challengesより

これには私も凄すぎて言葉を失いました。光源処理等で広告オブジェクトがシーンに馴染むようにしているとはいえ、現段階ではまだ違和感があります。しかし後から差しこまれた広告かどうか見分けが付かなくなるのも時間の問題だろうと感じました。トーク全体を通して現代のフルスペックな広告配信プラットフォームはこうなると、甚大な研究リソースが投入された結果であろうその姿に圧倒されました。

From the Clouds to the Trenches: Learning to Manage the Marketplace

因果推論ネタで新しかったのは Microsoft Advertising, AI & Research が広告配信のパフォーマンス結果(e.g. ROI)が広告主の行動にどの様な影響を与えるかの実験です。上手くいけば広告主の広告予算が増えるようなポリシーを広告主毎に見つけて適用できます。CPAが低く取れている時は予定よりも早く予算消化して増額提案した方が儲かるんじゃないか、みたいな反実仮想を考えるわけですね。

実験にはセンシティンブなサンプリングが必要で、反応が似ているペアを作ってTreatment群とControl群に割りふる必要があるとの事でした。負の副作用も起りうる、非常に挑戦的な実験で手に汗握りました。

f:id:hagino_3000:20190815143546j:plain
From the Clouds to the Trenches: Learning to Manage the Marketplaceより

In-app Purchase Prediction Using Bayesian Personalized DwellDay Ranking

大企業の発表が目立つ中で、京大鹿島研とサイバーエージェントの共同研究「未インストールユーザーのうちアプリ内課金をするユーザーを推定する」が地味ながらも「これはゲームアプリの広告を配信する時に欲しいと言われる奴だ……」と思いながら聴講。アプリ滞在時間を使ったBayesian Personalized Ranking。

アプリ内課金データは少なくLTV予測の難易度が高いため、課金しそうな人ランキングの問題に帰着している所が使いやすく見えました。現場のニーズっぽいネタが研究テーマになり成果として出てくる所がリスペクトポイントです。

本会議

3〜5日目は本会議。私はApplied Data Science Trackを中心に聴講しました、その中で印象に残った発表を紹介します。

マーケティングにおける逆強化学習・逆最適化

NECの TV Advertisement Scheduling by Learning Expert Intentions はTVCMのスケジューリングを行なうシステムを作った話です。配置の制約が複雑だったりフィードバックが得られない事から、配置職人の作業結果ログを元に組合せ最適化の目的関数を学習して最適化するのが面白かったです。有識者の行動を正とする所だったり、結果の説明性が高い階層クラスタリングを利用している点は伝統的な日本企業を相手にする時に役立ちそうです。

SMOILE: A Shopper Marketing Optimization and Inverse Learning Engine は小売業における実店舗内のプロモーション、デモやフライヤー配布や値引きといったマーケティング活動のプランニング最適化フレームワークです。プロモーション自体の効果(Lift)の推定値は得られるものの、プロモーション効果値と実際のプランニング(シーケンシャルな意思決定)を繋ぐ部分は複雑であるため、意思決定の部分は逆強化学習を用いて過去のプランナーの配置結果から学習するとあります。

人間の意思決定を模倣するパラメータを学習する方策は様々な応用が利きそうで注目しています。

マーケットデザイン

例えばある財を配布するのに「早い者勝ち」にするのか「抽選」にするのか「オークション」にするのか様々な手続きが考えられます。この様な手続きの中で効率が良く・生み出される価値が大きくなるものを追求する分野がマーケットデザインです。Two-Sided Fairness for Repeated Matchings in Two-Sided Markets: A Case Study of a Ride-Hailing Platform はライドシェアリングにおけるドライバーと乗客のマッチングアルゴリズムで公平性を考慮するものです。マッチングアルゴリズムは参加する人々に与えるインセンティブを変え、人々の行動を望ましい姿にする力があります。私は業務設計や値付けの際に役立つので好きな分野の1つです。

羅生門効果 (Rashomon effect)

講演を聞くまで知らなかったのですが、機械学習の分野で同じ予測を行えるモデルが複数存在する事をRashomon effectと呼ぶそうです。同じ予測性能が得られるのならばより単純なモデルを見つけて採用したい、これを行なうための方法論が最終日のKeynoteセッションに登場しました。

参考:A study in Rashomon curves and volumes: A new perspective on generalization and model simplicity in machine learning

PID制御でRTB入札最適化

DSPの広告配信システムで Bid Optimization by Multivariable Control in Display Advertising が制約にクリック1回あたりのコスト(CPC)を持つ入札金額最適化問題をシンプルなソリューションにしていました。クリック1回あたりのコストというのはオークションに入札して勝利して広告が表示された後さらにクリックが発生してようやくわかる値、遅れて得られる値です。行動(オークション入札)の後しばらくして充足しているか違反しているかわかる制約のためソルバーで静的に解ける問題ではありません。

f:id:hagino_3000:20190815144902p:plain
クリックあたりのコストと予算制約の元で獲得コンバージョン数を最大化する

これをPID制御で行なう事で非常にシンプルなソリューションになっています。オークションの入札最適化にはよく「いくらで入札したら何%で勝てるか」の勝率関数を利用します[2]。これを求めるタスクを入札ランドスケープ予測と言いますが、彼らのソリューションには登場しません (勝率無しでモデリングしている)。またこれだけで予算消化額の制御とCPCの制御が同時に出来る所が凄いなと思いました。

f:id:hagino_3000:20190815143424p:plain
Bid Optimization by Multivariable Control in Display Advertisingより

ランダムに出現しては消える蟹

四日目夜の懇親会では蟹が出ました。蟹が無くなると補充されるものの、補充された途端に人が集り蟹が消えてしまうので観測が非常に困難でした。

f:id:hagino_3000:20190807200206j:plain

全体の感想

強化学習の実用例が増えたなという印象です。Cost Per Clickの様な短期指標ではなく、広告主の長期的な指標に寄与する意思決定を行なうのに適しているとされます。自分のチームでもシミュレーターの開発からになりますが取り組みたいです。

あと開催地のアラスカは非常に涼しく、昼が長く22時を越えても明るかったので快適に滞在できました。


[1] サンプルサイズと有意水準を事前に固定して行なう古典的な仮説検定の設定とは異なるため

[2] 約定金額の分布を連続な確率分布で近似すると目的関数が扱いやすくなる。また約定金額の分布の累積関数は入札金額に対する勝率になる。

Treasure、10年間で変えたこと・変えなかったこと

こんにちは、CTOの @makoga です。

2019年5月にオフィスが移転します。新しいビルなので綺麗だし、社内バーAJITOもリニューアルするのでとても楽しみ。

でも、イベントなどの思い出が詰まった場所と離れるのは寂しいものです。

VOYAGE GROUPでは2006年から毎年夏にエンジニア向けインターン「Treasure」を開催しています。 オフィスが移転するということで過去の参加者たちと「さよならパンゲア・AJITO」というイベントを開催しました。

[f:id:voyagegroup_tech:20190425151343j:plain

このエントリはそこでLTした内容です。

10年間で変えたこと

VOYAGE GROUPで利用してる技術に合わせていった

10年前に用意したベースアプリケーションのプログラミング言語はPHPでした。モダンなフロントエンドのライブラリは使わず、シンプルなWebページを表示していました。

当時のサービスインフラはオンプレだったので、インターンではさくらのレンタルサーバを利用しました。

そこから、実際に利用している技術をインターンに取り入れていき、昨年はGo, React, AWSなどになりました。

1人では学びにくいことを講義に盛り込んでいった

学生が1人で学べることはこの10年でものすごく増えたと思います。チュートリアルは充実してるし、ビデオで学習できるし、データも提供されているし。

そこで、Treasureでは1人では学びにくいことを盛り込んでいきました。例えば、チーム開発の進め方、チームでのアイデアの練り方、などです。

講師をペアやチームにした

初期の頃は1人の講師が全テーマを担当していました。

その後、テーマごとに講師を割り当てました。プログラミング、Web API、データベース、セキュリティなど。

今は、テーマごとにメイン+サブだったり、チーム全体で1つのテーマを担当したりしています。

これにより、実践によるスキルトランスファーが行え、講師陣に厚みができたと思います。

10年間で変えなかったこと

講義+チーム開発

いきなりチーム組んで開発してもらってアウトプットだけを評価することもできます。

でも、それでは私たちが大事にしていることを伝えるのは難しいと思っています。

私たちは毎年新卒を採用しています。そこで培ったナレッジを活かして、インターンに参加した学生を圧倒的に成長させたいと考えています。

そのためには講義+チーム開発が必要と考え、この形式を続けています。

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

参加した学生より多くのクルーが関わっています。2018年は学生30人に対して44人が関わりました。

講義をする講師がいて、つまづいた人をフォローするTAがいる。チーム開発時には、チームごとにエンジニア2名+1が張り付き、議論が必要なのか、まずは手を動かしたほうがいいのか、最終日に間に合わせるための優先順はどう付ければいいのかをサポートします。

1人では学びにくいことを学べる環境にしています。

切磋琢磨できる雰囲気

チーム開発の最終日には成果発表があり、順位が付けられます。

単に勝ち負けを競ってもらいたいわけではありません。

このTreasureで出会った仲間と、この3週間はもちろんのこと、その後も切磋琢磨できる関係でいられるような雰囲気を目指しています。

まとめ

今回のイベントでは「Treasureが人生の転機になった」的なことを言ってくれた人が何人かいました。これからも学生の3週間という貴重な時間が、参加した人たちのTreasure(宝)になるよう全力でやっていきたいと思います。

おまけ

去年のTreasure様子はこちら → VOYAGE GROUPエンジニアインターンシップ Treasure2018 を開催しました #voyage_intern - VOYAGE GROUP techlog

春のエンジニア向けインターンシップ2019開催のお知らせ~第二弾~

こんにちは、VOYAGE GROUP人事の @saxsir です。
VOYAGE GROUPでは、21卒エンジニア学生向けに春のインターンシップを開催します!

3月にも開催していましたが、今回はその第二弾となる4,5月イベントのご案内です。※ベースは3月に開催したものと同内容になります


Goで学ぶWebアプリケーション開発とチーム開発

GoでWebアプリケーションを書いてみよう!
サーバサイドをメインにクライアントサイドとの連携、そしてチームでの開発についても学びます。

今回の内容は、VOYAGE GROUPで開催する夏のインターンシップ「Treasure」を少しだけ体感できるものとなっております。 (Treasureの詳しい内容については、過去のブログ にまとめています)

1dayインターンシップ当日は、サーバーサイドはGo, クライアントサイドはHTML, JavaScript(Vue.js)を利用し、クライアントサイドとサーバーサイドの連携、DBとの接続など、Webアプリケーションの開発に必要な技術を広く触ります。今自分が何を知っていてこれから何を学んでいけばいいのか?これからインターンシップを探していく上で参考になることをもって帰ってもらえれば嬉しいです!

当日はハンズオン形式で知識のインプット、個人でのアウトプットを通して学んでもらい、最後はチームで機能を実装してもらう予定です。

※ 当日のタイムスケジュール(予定)

11:00 開始
11:00~12:00 チュートリアル
12:00~13:00 ランチ
13:00~15:30 講義・実装
15:30~18:30 チーム開発
~ 21:00 懇親会

1日に詰め込んでいるので、とても消化しきれない量のインプットがあると思いますが、できるだけ多く経験、知識を持って帰ってもらえたら嬉しいです。

Treasureにおいて大切にしているチーム開発の楽しさを一足先に体感してみませんか?

f:id:saxsir256:20190313161750j:plain

こんな人にオススメ

  • プロのエンジニアがどのようにWebアプリを書いてるか学びたい!
  • チームで開発してみたい!
  • 同世代の中で自分のレベルを確かめたい!
  • 春からスタートダッシュしたい!!

前回参加者の声

Aさん

短時間ながらインプット、アウトプット共にとても密度の高い経験をすることができました。一人で黙々とやっていても得られないチーム開発の難しさや楽しさを学ぶいい機会になった

Iさん

1日であるため参加もしやすく,それでいて濃密な1dayインターンは他に類を見ないと思います.後輩や友人にもおすすめしたいので,今後もぜひ開催してください!

【2019/03/22 11:12追記】3月に参加してくれた学生さんがブログを書いてくれました!

medium.com

日程

  • 2019年4月13日(土) 11:00 - 21:00(18:30~は懇親会)@東京(VOYAGE GROUP渋谷本社)
    • 応募締切: 2019年4月8日(月) 9:30
  • 2019年5月6日(月・祝) 11:00 - 21:00(18:30~は懇親会)@京都(サポーターズ京都オフィス)
    • 応募締切: 2019年4月25日(木) 9:30

※どちらか片方の日程のみ参加可能です

場所

東京開催

VOYAGE GROUP本社(渋谷ファーストプレイス)8F セミナールーム https://voyagegroup.com/company/profile/#wrap_map

京都開催

サポーターズ京都オフィス セミナールーム
https://supporterz.jp/kyoto-rental/

持ち物

  • PC
    • 推奨: macOS 10.13 (High Sierra) 以降が動く Mac もしくは Ubuntu 18.04 LTS 以降が動く PC (仮想環境も可)
    • ※Windows環境は当日サポートしていませんので、VirtualBox等の仮想環境でLinuxが動く環境を用意しておいてください
  • 元気な身体とできるだけ吸収していくぞ!という気持ち

エントリー

下記フォームから登録してください!
エントリーフォーム

応募資格

  • 2021年4月以降に入社可能な方(文理不問)
  • プログラミングが好きな方!
  • (必須ではありませんが) サーバーサイドの開発経験があると良いです

その他

  • 交通費は自己負担となります
  • 懇親会では軽食と飲み物(アルコール・ソフトドリンク)がでます
  • 服装は自由ですが、できるだけ私服でお越しください!

※ 夏のインターン、Treasureの様子は下記ブログにまとまっています techlog.voyagegroup.com

お問い合わせ

  • 人事本部: インターンシップ担当
  • メールアドレス: new-recruit@voyagegroup.com

それでは、たくさんのご応募お待ちしております!

『VOYAGE GROUP エンジニアの公開ガチ評価会』を開催しました!評価資料・評価結果すべてお見せします!

こんにちは。

ポイントメディア事業本部エンジニアの、あっきー(@akkiihs)です。

2019/01/30(水)に開催した『VOYAGE GROUP エンジニアの公開ガチ評価会』の評価資料・評価結果を公開します!

(大変おまたせしました、、!)

voyagegroup.connpass.com

イベント経緯

その前に、イベントを開催するにあたった経緯など簡単に書いておきます。

もともと、このイベントを開催した経緯として、PHPカンファレンス2018がありました。

VOYAGE GROUPは、PHPカンファレンス2018のスポンサーであり、セッションやブースにてエンジニア評価制度である『技術力評価会』について話をしました。

ただ、話をしただけでは、概念としては伝えられても「実際のところ、どんな感じなの?」ってところが、まだ伝わりきりません。

そこで、実際の技術力評価会をイベント形式で見てもらおう!公開してしまおう!というのが『公開ガチ評価会』のイベントを実施するキッカケとなりました。

かなり思い切ったイベントだったのでは、、

イベント当日の様子

イベントの公開時から、思っていた以上に参加申し込みがあり定員が溢れ、当日は70名近くの方が参加くださいました!

当日は、Twitterハッシュタグ「#vg_tech_assessment」で、つぶやいてもらいました。

Togetterでまとめたので、ご覧ください。

togetter.com

イベントでは、最初にCTOである、小賀さん(@makoga)から、『5分でわかる技術力評価会』の話がありました。

『技術力評価会』を制度として導入した経緯や、評価会の内容、毎回改善が繰り返されていることなどが濃縮されてます!

speakerdeck.com

そして、実際の評価会へ。

今回は、以下の被評価者・評価者で、本来90分かけて実施するところを、60分に短縮し実施していただきました!

被評価者: やんうぇい さん(@yangwei21

評価者: すずけん さん(@suzu_v

   : ねこや さん(@nekoya

イベント後の懇親会では、評価制度についての交流もあり、

後日ブログで書いてくださる方もいて反響が大きかったんじゃないかなあと思います。

評価資料

当日、参加者にも公開していた評価資料です。

gist.github.com

評価結果

気になる評価結果はこちらです。

技術力評価会 評価結果

評価者 @suzuken

総評

管理画面のフロントエンドのツールやライブラリ類を入れ替えていくという話でした。うまくやっていたと思います。

このチームの話をきいて強みであると思ったのは、ほぼ毎日リリースされている画面でありかつほぼ全員で管理画面を触るということです。フロントエンド専任のメンバーが2,3人だけであれば話をして同意すればごっそりと既存スタックからの移し替えも含めて進めることができるでしょう。しかし今回はそうではなく、数年運用されてきていて多くの人が開発に関わっているフロントエンドの多様な実装を今あらためて置き換えていくという試みでした。結果として、段階的にかつ整備しやすい環境に向けての一歩が着実に踏めていると感じました。

次のあたりは安定した判断ができていると思った箇所です。

  • 無理にSPAにせず複数ページのアプリケーションに分けた
  • UI Frameworkを統一(ルールをシンプルに)
  • 静的な画面、簡単なフォームではひとまずさくっとSymfony Formを使う

ともすればフルリプレースですべてモダンな構成にと考えてしまいがちではありますが、現状のチームの知見や既存コードの運用を踏まえると、手堅く課題を解決できるプランとなっていました。

また評価会でも触れましたが、Reactをより全面に導入していくことにより、返って既存のスタックが複雑化してしまうのではないかという懸念もあります。これについては現在も既存画面を置き換えつつも、既存の技術スタックから移るメリットをチーム内のメンバーにも共有しペアプロなどを通じながら巻き込んで行けているのは良い進め方でした。

成長へのアドバイス

プロダクトを着実に前進させるための施策を適切なタイミングで実行できていたと思います。とはいえ決めてからが頑張りところです。がっつり改善していってください!

  

ねこやからやんうぇいへ

時間も短く多数のギャラリーのいる中、必然的にプロレスの様相を帯びる公開評価会ではありましたが、それも込みでいい会でした。

まず感心したのは、そうした場の作り方もひっくるめて、やんうぇいが「今日はこういう会にしよう」という線を言外に、極めて自然に引いてくれたことです。もしかしたらあまり自覚してないかもしれないけど。

そういう器用さも持ち合わせていることは不思議でもなんでもないけど、それをあの場でさりげなくやってのけたのは大人の立ち回りでかっこよかった。

具体的には

  • 時間とギャラリーの関係で見せるコードは限定的に
  • チームの誰それがみたいな個別の人の話はしない

あたりをメッセージとして受け取りました。

技術選定

そうするよねー、というセレクトで特に違和感ありません。1年前、2年前ならこのへん議論のしどころだったろうけど、今はそういう時勢じゃない。

TypeScriptの設定は自分ならもう少し堅くするし、実際にそうしている。既存のアーキテクチャからハードルを低くするという狙いも分かるけど、型に関する理解が薄いまま書いてしまう場面が出てこないかという懸念はあります。

投資判断

主眼に置いていると感じられたのは以下の2点です。

  • Developer experienceの向上
  • 既存アーキテクチャが抱えるセキュリティリスクの解消

いずれも理解はできるし、後者は具体的な事業リスクなので、そこを改善できるのは意義がありそうに思えます。

いろいろな要素がちょうどよく出揃ってきたタイミングで、シュッと新しいものを滑り込ませることが出来たんだろうなと見て取れました。

既存のものを置き換えるとしたら、もう少し材料を揃える必要があったかもしれないけど、新しいところに部分的に投入するなら「やっちゃいました」でいいのかな。そういう状況を作れていたならそれでよさそう。

チームへの普及、定着

最初の方に「チームの中で技術的な担当範囲での役割分担はしていない」という話があったけど、今回の取り組みの普及度合いはまだそこまででもなさそうに見えています。

書ける人を増やす取り組みを怠っているわけではなさそうなので、継続的に普及させていってください。

次の一手

既存のものを一気に置き換えないというのは現段階の選択としてありだけど、未来永劫それを併存させるのかは気になるところです。複数のアーキテクチャが混在していて、両方を理解していないと管理画面の開発ができないみたいになると効率が悪くなりそう。そこにどう立ち向かっていくのかが次の課題かと思います。

現段階ではそこはあまり意識していなそうに受け取れたし、まだその時期ではないかもしれないけれど、そこでどういう決断をするのかは気になります。

  

VOYAGE GROUPの、エンジニア評価制度である『技術力評価会』では、

準備、評価会そのもの、評価結果(フィードバック)、振り返りを時間をかけて取り組んでいます。

それだけ、評価する・評価されるに関係なく、エンジニアが納得感を得られるかが大切であり、

それによって組織全体としての育成・評価の共通基準が生まれやすくなるのかなと個人的に思います。

  

  

次回、同様なイベントを開催するかどうかは、、未定です!

  

  

最後に、VOYAGE GROUPではキャリア採用を募集しております(ちゃっかり宣伝)

voyagegroup.com

デブサミ2019講演「レガシーとのいい感じの付き合い方」の資料を公開します。

ポイントメディア事業本部の福田です。

Developers Summit 2019にて、「レガシーとのいい感じの付き合い方」と題して、ECナビの4年に渡る改善事例を発表しました。 講演資料を公開します。

セッション詳細

event.shoeisha.jp

公開資料

当日の反響(togetter)

togetter.com

発表を終えて

ネタが地味目なので、当日どれくらい来ていただけるのか少し不安でしたが、満員+立ち見の盛況でした。

当日ご参加いただいた方、ありがとうございました。

アイスブレイクとして、会場のみなさんには「何年もののレガシーシステムに取り組んでいるか?」について質問させていただいたところ、「10年以上」という方が半数超え(※壇上からの主観です)で、レガシーシステムの問題は顕在化していることを実感しました。

目立たずに水面下でじわじわと苦しめられてる問題だと思うので、私達のような”課題先進国”の事例が共有され、この問題を議論する機会が増えていくといいですね。

私達もまだまだ改善途上なので知見を深めていきたく、「レガシーシステムについて語り合いたい」という方がいれば、お声がけください。

あわせて読みたい

「老舗メディアが改善に取り組んでる話」 techlog.voyagegroup.com 2016年11月ごろの、PHPカンファレンスでの事例紹介。事始めが終わって、ECナビAWS移行を進めていた時期です。

「インフラチームと開発チームの垣根をなくすためにAWSのCI環境を構築した話」 techlog.voyagegroup.com 2017年2月ごろの記事。ECナビAWS移行を無事完了させた直後の話。CloudFormationとTravis CIあたりがくわしく説明されています。

最後に

ポイントメディア事業本部では、カイゼンを一緒に進めていくエンジニアを募集中です。

サービス開発エンジニア voyagegroup.com

システム基盤エンジニア voyagegroup.com

春のエンジニア向けインターンシップ2019開催のお知らせ

こんにちは、VOYAGE GROUP人事の @saxsir です。
VOYAGE GROUPでは、21卒エンジニア学生向けに春のインターンシップ(& 勉強会)を開催します!

まずはその第一弾となる、3月開催イベントの紹介です。

  1. Goライブコーディング(3h)
  2. 実践Webアプリケーション開発(1day)

の2コースを開催します。


1. Goライブコーディング

VOYAGE GROUPのエンジニアがペアプロでプログラムを組み上げていく様子をライブコーディングします!

使う言語はGo。プロのエンジニアがどう考えてコードを書いていくのか?どんなツールを使っているのか?当日はエンジニア2名によるペアプロスタイルで実装を進めていきます。

お酒もご用意しますので、最高のコードをつまみに、食べて、飲める、イベントとなっております。 お酒を飲みながら、プロの技術に酔いしれましょう。
(未成年の方、お酒が苦手な方向けにソフトドリンクも用意してあります)

ライブコーディング終了後はそのまま懇親会もあるので、直接VOYAGE GROUPのエンジニアに話を聞くこともできます!

※ ライブコーディングとはエンジニアが皆さんの目の前でコーディングを行うイベントです。 画面の分割や切り替えのテクニック、エディタの設定やプラグインなど、どんな環境でやっているのか トップエンジニアが扱うLinuxコマンドなどをライブで学ぶことができます!

f:id:saxsir256:20190208111306j:plain

こんな人にオススメ

  • プロの開発環境を見てみたい
  • Goでなにか書いたことがある/書いてみたい
  • 春、夏のインターンを探している

日程

2019年3月1日(金) 18:00 - 21:00

場所

VOYAGE GROUP本社(渋谷ファーストプレイス)8F セミナールーム https://voyagegroup.com/company/profile/#wrap_map

持ち物

  • 特になし

エントリー

下記フォームから登録してください!
エントリーフォーム

応募締め切り: 2019年2月26日(火) 23:59まで

応募資格

  • 2021年4月以降に入社可能な方(文理不問)

その他

  • 交通費は自己負担となります
  • 懇親会では軽食と飲み物(アルコール・ソフトドリンク)がでます
  • 服装は自由ですが、できるだけ私服でお越しください!

2. 実践Webアプリケーション開発コース

GoでWebアプリケーションを書いてみよう!
サーバサイドをメインにフロントエンドとの連携、そしてチームでの開発についても学びます。

今回の内容は、VOYAGE GROUPで開催する夏のインターンシップ「Treasure」を少しだけ体感できるものとなっております。

具体的にはフロントサイドはHTML, CSS, JavaScript, React, npm, webpack等々...サーバーサイドはGo, dep, MySQLに加えて、開発環境ではdocker等。

当日はGoでのアプリケーション開発がメインとなる予定ですが、Webアプリケーションを開発するために必要な知識が詰まったものになっているので、今自分が何を知っていてこれから何を学んでいけばいいのか?これからインターンシップを探していく上で参考になることをもって帰ってもらえれば嬉しいです!

当日はハンズオン形式で知識のインプット、個人でのアウトプットを通して学んでもらい、最後はチームで機能を実装してもらう予定です。

Treasureにおいて大切にしているチーム開発の楽しさを一足先に体感してみませんか?

f:id:saxsir256:20190208114339j:plain

こんな人にオススメ

  • GoでWebアプリケーションを書いてみたい
  • チームでの開発を体験してみたい
  • 夏のインターンを探している/Treasureでどんなことをやるのか気になる
  • 春からスタートダッシュしたい!

日程

  • 2019年3月10日(日) 10:00 - 18:00, 18:00 - 21:00(懇親会)
    • 応募締め切り: 2019年3月3日(日) 23:59まで
  • 2019年3月18日(月) 10:00 - 18:00, 18:00 - 21:00(懇親会)
    • 応募締め切り: 2019年3月11日(月・祝) 23:59まで

※どちらか片方の日程のみ参加可能です

場所

VOYAGE GROUP本社(渋谷ファーストプレイス)8F セミナールーム https://voyagegroup.com/company/profile/#wrap_map

持ち物

  • PC
    • 推奨: macOS 10.12 (Sierra) 以降が動く Mac もしくは Ubuntu 16.04 LTS 以降が動く PC (仮想環境も可)
    • ※Windows環境は当日サポートしていませんので、VirtualBox等の仮想環境でLinuxが動く環境を用意しておいてください

エントリー

下記フォームから登録してください!
エントリーフォーム

応募資格

  • 2021年4月以降に入社可能な方(文理不問)

参加者の声

"グループ開発ならではの面白さや難しさを知ることができた。 Goの自分の知るよりも大きなアプリケーションを触ることができて良い経験になった。"

"参加学生のレベルの高さを感じることができた"

"チーム開発経験に乏しかった為、チーム開発の時間があったのは良かった。 Githubを使った開発の流れを知ることができて、今後に活かせそうだと感じた。"

その他

  • 交通費は自己負担となります
  • 懇親会では軽食と飲み物(アルコール・ソフトドリンク)がでます
  • 服装は自由ですが、できるだけ私服でお越しください!

※ 夏のインターン、Treasureの様子は下記ブログにまとまっています techlog.voyagegroup.com

お問い合わせ

  • 人事本部: インターンシップ担当
  • メールアドレス: new-recruit@voyagegroup.com

春休み、なにか新しいことに挑戦してみませんか?
それでは、たくさんのご応募お待ちしております!

Netflixにおけるフルサイクル開発者―開発したものが運用する

こんにちは。fluctでiOS/Android向けSDKの開発をしているarimuraです。この記事ではPhilip Fisher-Ogden、Greg Burrell、Dianne MarshによるFull Cycle Developers at Netflix — Operate What You Buildを私が翻訳したものを著者の許可のもとに掲載しています。元の記事は弊社の技術力評価会のインプットの一つとして共有されており、そこで興味を持ったのが翻訳するきっかけとなりました。

以下、2018年5月時点における情報を記載したものであり Netflix TechBlog「Full Cycle Developers at Netflix」より引用したものである。

Netflixにおけるフルサイクル開発者―開発したものが運用する

2012年―Netflixでの重要なサービスの運用は骨の折れるものだった。デプロイは湿った砂の上を歩くように感じられた。カナリアリリースは機能ではなく忍耐力を検証するものとなっていた(「1週間何も壊れなかったからプッシュしよう!」)。問題の調査はチーム間でゴムボールを弾ませているようだし、原因の解明は難しく、次々と跳ね返ってくるボールを止めるのはさらに難しかった。これらの全ては変化が必要なサインだった。

そして2018年。Netflixは世界中の会員1億2500万人が1日に1億4000万以上の時間を楽しむまでのサービスに成長した。私たちはエンジニアリングチームの開発と運用の改善のために莫大な投資を行った。サービスの開発と運用を様々なアプローチで試した。その中からNetflixでよく使われているあるアプローチを、その良い点と悪い点を含め紹介したい。私たちの試みを共有することでそこから議論が発展し、何かを学んでもらえれば幸いだ。

1つのチームでの旅

エッジエンジニアリングのチームはNetflixのストリーミングを動かすためのAWSサービスの第一レイヤーを受け持っている。過去にはエッジエンジニアリングに運用専任のチームとデプロイ+運用+サポートを担当するSREが存在していた。新機能リリース時は開発チームと運用チームがメトリクス、アラート、キャパシティープランニング等についての調整を行い、その後デプロイと運用のため開発チームから運用チームにコードが手渡されていた。コードの運用とパートナーのサポートを効果的に行うために、運用チームは新機能やバグフィックスについての継続的なトレーニングが必要だった。開発チームとは分離した運用チームを持つことの主な利点は、物事が上手くいっているときは開発チームへの割り込みが少ないことだ。

しかし上手くいかなくなるとコストは積み上がっていく。開発チームと運用チーム間でのコミュニケーションや知識の移転はロスが多く、デバッグやパートナーからの質問に回答するためには余計な往復を必要とした。また、運用チームがデプロイされる変更点についての直接的な知識を持っていないため、デプロイ時の問題の検知と解決にはより多くの時間がかかった。コードの完成からデプロイまでの時間は今よりずっと長く、リリースは日ではなく週単位で行われた。アラート/監視の欠如や性能問題やレイテンシーの増加といった問題で実際に苦しむのは運用チームで、開発チームはそれを運用チームから間接的に伝えられるだけだった。

この状況を改善するため、エッジエンジニアリングでは開発チームも必要なときにコードをプッシュでき、業務時間外の本番環境での問題やサポートも行うというハイブリッドモデルが導入された。これにより開発者のフィードバックと学習のサイクルは改善された。しかし部分的に責任を負うだけでは、チーム間の溝は埋まらなかった。

例えば、開発チームがデプロイをしたりパイプラインの破損をデバッグできたとしても、多くの場合彼らはリリースの専門家である運用チームの指示に従うことが多かった。また運用チームにとっては、日々の仕事を行うモチベーションはあっても、他チームから自身への依存をなくすための自動化を優先させるのは難しかった。

より良い方法を探し求め、私たちは一歩戻って第一原則から考え直した。何を達成すべきで、なぜそれができてないのか?

ソフトウェアライフサイクル

ソフトウェアライフサイクルの目的はtime to valueの最適化、つまり効果的にアイディアを実際のプロダクトやサービスに変換することだ。ソフトウェアサービスを開発し運用することは一連の責任から構成される。


ソフトウェア開発ライフサイクルのコンポーネント

私たちはこれらの責任を分割していた。極端な例ではそれぞれの機能が全く別の個人/役割によって担当されていたのだ。


ソフトウェア開発ライフサイクルの専門家

これらの専門化された役割はそのセグメント内では効率的だが、ライフサイクル全体の非効率性を潜在的に作り出す。専門家は自分の分野での専門性の獲得や物事の最適化を行う。彼らは自分のパズルを解くことにより効果的になっていくのだ。しかしソフトウェアで顧客に価値を提供するためにはライフサイクル全体が必要となる。ライフサイクルの一断面のみを担当する専門家チームを持つとサイロ化が進み、最終的な顧客への価値提供を遅らせることになる。異なる分野の専門家を1つのチームにすることでサイロを減らすことができるかもしれない。しかし1つのチームで別々の専門家が自分の仕事を行うような状況では、コミュニケーションのオーバーヘッドの増加、ボトルネックの発生、フィードバックループの非効率性に繋がってしまう。

開発したものが運用する

devopsの原則は私たちのアプローチを考え直す際にインスピレーションを与えてくれた。サイロを解体しフルソフトウェアライフサイクルの共同所有を奨励することで、学習とフィードバックを最適化することができる。


devopsの原則を取り入れたソフトウェア開発ライフサイクル

"開発したものが運用する"というアプローチでは、システムを開発するチームが運用とサポートにも責任を持つことでdevopsの原則を実践する。責任を外部化するのではなく開発チームに与えることで、ダイレクトなフィードバックループと共通のインセンティブを持つことができるのだ。運用に苦痛を感じているチームにはシステムの設計やコードを変更することでそれを治癒する力が与えられる。彼らは開発と運用の両方に対して責任を持っている。各開発チームは開発上の課題、パフォーマンスのバグ、キャパシティープランニング、アラートの欠如、パートナーサポートといったものを受け持っているのだ。

開発者ツールによるスケール

一連の開発ライフサイクルに対するオーナーシップによりソフトウェア開発者に求められることは大幅に増えるが、開発上の共通する要求を単純化したり自動化するツールによって負荷を軽減できる。例えばソフトウェア開発者がサービスのロールバックの管理することになる場合、ロールバックができるだけでなく問題の検出やアラート通知ができる高機能なツールが必要になる。

Netflixでは、多くの開発チームが持つ共通の課題を解決するためのツーリングとインフラの開発をミッションとする複数の集中型チーム(e.g. クラウドプラットフォーム、パフォーマンス&リライアビリティエンジニアリング、エンジニアリングツール)が創設された。このチームは専門化された知識を再利用可能なビルディングブロックにすることにより他のチームの力を高める。


専門家が再利用可能なツールを作る

これらのツールを手中にして、開発チームはプロダクトのドメインの問題解決に集中することができる。新しいツールへの必要性が生じたとき、集中型チームは、複数の開発チーム間で共通のニーズがないか見極める。そして共通のニーズと認められたら、共同作業が進められる。開発チームからの要望が特殊すぎて共通の投資としては認められないこともあるだろう。その場合、開発チームはその課題が自分たちで解決するほど重要なものかを判断することになる。

類似した課題への対応を共通投資とするかしないかを判断することは、私たちのアプローチで最も困難なことの1つだ。私たちの経験では、複数のグループが最終的に1つになるような解決策を並行して作ってしまうリスクを冒してでも、開発者からの要望に対して新しい解決策を発見することは価値がある。コミュニケーションと目的の共有は成功への鍵だ。まずは要望を理解しそれが汎用的あるのか判断することで、Netflix全体の開発チームにとってより良い投資をすることができる。

フルサイクル開発者

これら全てのアイディアをまとめることで、私たちは1つのモデルに到達した。驚くべき開発ツールを持ち、設計、開発、テスト、デプロイ、運用、サポートといったフルソフトウェアライフサイクルへの責任を持つ開発チームだ。


エンパワーされたフルサイクル開発者

フルサイクル開発者はソフトウェアライフサイクルの全ての分野において知識があり効果的であることが期待される。多くのNetflixの新入社員は自分が経験の浅い分野にも挑戦することになる。そのため知識の習得やスキルアップのための開発ブートキャンプと継続的トレーニングが用意されている。しかし知識だけでは十分ではない。容易に扱うことができるデプロイパイプラインツール(e.g. Spinnaker)やモニタリングツール(e.g. Atlas)も効果的なフルサイクルオーナーシップには必須なのだ。

フルサイクル開発者はエンジニアリングの原則をライフサイクルのあらゆる分野に応用する。開発者の視点で問題を評価し、「このシステムを動かすために必要なものをどう自動化できるか?」「どのようなセルフサービスツールがあればパートナーが開発者の手を借りずに自分の疑問に答えることができるだろうか」と問う。人間中心よりもシステム中心に考え、手動で行われていたものを自動化することによって、チームはスケールする。

フルサイクル開発者モデルを取り入れるには考え方を変えることが求められる。ある開発者が活躍の場として主に設計と開発、そして時々はテスト、と考えたとしよう。この見方は運用を邪魔者とみなし、"本当の仕事"に早く戻るために運用やサポートの問題に対して短期的な視点での対応をすることに繋がる。しかし、フルサイクル開発者の"本当の仕事"はライフサイクル全てにわたる問題を解決することだ。フルサイクル開発者はSWE(Software Engineer)としてもSDET(Software Development Engineer in Test)としてもSREとしても振る舞うのだ。あるときはビジネスの課題を解決するソフトウェアを開発し、またあるときはテストケースを書き、そしてまたあるときはシステム運用の自動化を行う。

このモデルを成功させるためには、チームはそれが価値あるものになるよう真剣に取り組む必要があるし、コストについても意識的でなければならない。ビルドとデプロイを管理し、本番環境での問題に対応し、パートナーからの依頼に応えるために、チームは余裕を持って配置される必要がある。トレーニングするための時間やツールへの投資も必要だ。再利用可能なコンポーネントやソリューションを生み出すために集中型チームとのパートナーシップも構築されなければならない。計画と振り返りではライフサイクルの全ての分野について検討しなくてはならない。アラート対応の自動化やパートナー向けのセルフサービスツールの開発は、ビジネス上の要望と同じレベルで優先順位付けされる必要がある。十分な人員と優先順位付けとパートナーシップによって、チームは自分のビルドしたものを運用することができる。それなしにはチームは過度な負担や燃え尽きのリスクに晒されることになる。

Netflix以外でこのモデルを採用するには調整が必要だ。開発チームによくある課題は似通っている。例えば継続的デリバリーのためのパイプラインが必要だったり、モニタリングだったりするだろう。多くの企業ではNetflixのように集中型チームに対して人員を配置できないだろうし、Netflixの規模が必要とするような複雑性も不要だろう。Netflixの多くのツールはオープンソースだし、手始めに試してみるにはちょうどいいだろう。まずは潜在的な価値やコストの分析から始め、続いて考え方を変えてみよう。何が必要かを評価し、最小のコストでどう実現するかを考えよう。

トレードオフ

テック業界には開発と運用上の要求を解決するための多くの方法が存在する(devopsトポロジーを参照)。ここで記述したフルサイクルモデルはNetflixでは普通のものだが、マイナス面もある。あるモデルを選択する前にそのトレードオフを知ることは成功の確率をあげることになるだろう。

フルサイクルモデルにおいては、ツールによって拡大されたより広い分野でのオーナーシップや有効性に対して優先順位付けがなされる。仕事の幅広さは多様なテクノロジーへの興味や適性を求めることになる。あるエンジニアは狭い分野での世界的な専門家になることを好むし、そのような専門家が必要とされる分野もある。このような専門家にとっては、広い分野でそれなりのスキルを求められることは居心地の悪いことであるし、時には虚しいと感じるかもしれない。Netflixでも、幅のあるスキルではなく特定の分野での深い専門性を好む人々も存在するし、私たちもそのような働き方をサポートしている。そして別の人たちはより幅広い職務を楽しみながら働いている。

クラウドシステムの開発と運用を行う中で、私たちはフルサイクルであることを重視する開発者が如何に効果的に働くかを知った。しかし、その幅広さは開発者の認知的負荷を増大させるし、チームは1つの分野にフォーカスしてる場合より頻繁な優先順位付を行うことになる。これはデプロイ+運用+サポートを順番に担当するオンコールのローテイションを組むことで緩和することができた。上手くいっているときは集中してフロー状態で仕事をすることが可能になるし、上手くいかないときは割り込みだらけの環境でなり、それは結局燃え尽きにつながることになる。

ツールと自動化は専門知識をスケールすることができるが、開発者の生産性と運用についての全ての問題を解決するツールというのは存在しない。Netflixには集中型チームにより正式に管理された一連の"舗装された(paved road)"ツールとプラクティスがある。私たちはこれらの"舗装された"ツールを採用することを強制はしないが、これらのテクノロジーを使うことでずっと良い開発と運用を行えることを確認しているので採用を推奨している。しかし、私たちのアプローチのマイナス面として「最も重要な要求のための全ての機能を積んだ全てのツールを全てのチームが使ってる」という理想が殆どの実現不可能だということがある。私たちの集中型チームへの投資に対するリターンを実現するのには、努力と共通理解と継続的な適応が必要なのだ。

結論

2012年から今日までの道のりは実験と学習と適応の連続だった。エッジエンジニアリング——その早期の実験はより良いモデルの探求に繋がった——は今日のフルサイクル開発モデルに応用されている。デプロイは頻繁に繰り返されるルーティンになり、カナリアリリースは数日ではなく数時間で行われ、開発者はチーム間で責任を押し付け合うのではなく素早く問題の調査をして解決することができる。他の組織でも同様の恩恵が期待されるだろう。しかし、私たちは異なる場所から適用と学習によってここに到達したことを忘れてはならない。明日の要望がさらなる進化を導くだろう。

このモデルが実際に動いているところが見たい?未来に向けてこのアプローチがどう進化するかについての探求に参加したい?応募お待ちしています。

Philip Fisher-Ogden, Greg Burrell, and Dianne Marsh

arimura

この記事は社内のGitHubに共有された下書きに対して、有志のメンバーがフィードバックするという形で翻訳されました。 翻訳に協力してくれたアミン、海老原さん、小橋さん、 t-wadaさんに感謝!