SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

特集記事(AD)

世界一「高速」「高精度」なネット広告配信システム作りに挑むRCOのエンジニアたち

バックグラウンドも個性もばらばらなメンバーを束ねる、飽くなき技術研鑽を支える企業文化

  • このエントリーをはてなブックマークに追加

精度を高めるロジックはエンジニアが自ら考え「トライ&エラー」で実装

――みなさん、アドテクノロジーを中心としながら、それだけでなく幅広い仕事に関わっている感じですね。入社1~3年の方が多いようなのですが、特にRCOでのDSP構築といった動きに関連して、自分なりの課題と考えている技術的なテーマはありますか。

 中村:私はまだ入社して1年ほどなのですが、その間は、まず「広告バナー」を「誰に出すか」というロジックを、どのように作るかというのをテーマにして取り組んでいました。一般的に、広告配信の効果測定は「クリックレート」(広告がクリックされた率)を中心に考えられているのですが、それだけでは不十分です。ネット上にはbotなども存在するため、たとえクリックレートが出ていたとしても、その広告が最もふさわしいユーザーに対して出て、どれだけの効果があったのかというのは不明確なんです。そこで、よりきちんとユーザーターゲティングをするためのロジックが必要になっているのです。

 ユーザーごとの特性とトラフィックデータの組み合わせから、どんなバナーが、どんな特長を持った個人と相性がいいのかを、機械学習をベースに予測して、より適合度の高い人に優先度を上げて広告を提示する仕組みというのを考えていました。

 機械学習に必要なデータは、インフラチームがうまく使えるように整えてくれています。では、そのデータをどう加工すればいいか。機械学習にあたってのチューニングをどうするか。機械学習用のデータをどうやって作るかという部分が結構難しいのですが、それを試行錯誤しながらやっていました。

 アドテクノロジーの分野で機械学習による分析を行うと、結果にはノイズも多く含まれるんです。例えば、「興味がある広告が出ているはずなのに、アクションに結びつかない」といった場合、その人を分析結果として「非適合」に分類してしまうこともあり、これを完全により分けることは難しいんです。サポートベクターマシンやニューラルネットなどを含む複数のアルゴリズムを比較検証した上で、現在は結果的にノイズに強かったランダムフォレストを使ってターゲティングを行っています。

 その後、より精度を高めるため、広告が出る各ページの大まかなカテゴリ分けだけでなく、そこに書かれている内容をきちんと把握する必要があるのではないかと考えました。そこで、ページ内のドキュメントの内容を形態素解析して、そのベクトルを分析に生かせるようなものを実運用に生かせるよう検証するというのが、今、最もやりたいテーマになっています。ドキュメントの解析に加えて、そのページにある画像の内容を判別して学習に反映させるようなこともできるだろうと考えています。

 これだけのことをやろうとすると、さらに大量のデータを処理しなければならないのですが、その部分については、自分の要望に合ったものをインフラチームがきちんと用意してくれる環境があるので、チャレンジにあたって非常に助かっています。

 上田:RCOのアドテクノロジーが他の企業のものと大きく異なる点の一つとして、クリックレートではなく、コンバージョンレート(実際に購買や問い合わせにつながった率)を最重要に考えて、広告配信の最適化を図っている点が挙げられます。そのための新しいロジックは、誰か、そのことだけを考えている人がいるわけではなく、すべてエンジニアが主体となって考え、実装していっています。できたらとりあえず入れてみて、結果を見る。うまくいきそうなら改良し、ダメだったら外して再検討……といった感じでスピーディーに試行錯誤しながら精度を高めていっています。

――ちなみに、中村さんは入社以前の大学院生のころから、機械学習が専門だったのですか。

 中村:交通シミュレーションの精度を高めるための研究をやっていました。モデルを作って、そのモデルを観測値で補正していくといった内容ですね。現在やっているアドテクノロジーの高精度化というテーマも、その分野の知識や技術を生かせる部分が多く、入社してすぐにいろいろやらせてもらえています。考えた仕組みが、迅速に実際のシステムに反映され、精度が向上すればそれがビジネス上の成果として目に見えるので、やりがいがありますね。

――専門の研究分野と、会社として注力しているテーマがうまくマッチしたというわけですね。では、上田さんの直近のテーマはどんなものだったのでしょうか。

 上田:先ほどお話ししたように、当初は「圧倒的に速いレスポンスプログラム」を作るというのがメインの仕事だったのですが、昨年春からは、広告のターゲットとなる属性に対して値付けを行うシステム、「誰」を「いくら」で買うという仕組みを実現することに、前任者から引き継ぐ形で取り組んでいました。

 そこで思ったのは、「もっと数学や統計学、ちゃんと勉強しておけばよかったなぁ」ということで(笑)。中村さんは、データサイエンティストとして特別な素養がある専門家なので、その点でいろいろ教わりながらやっています。

 中村:逆に分析を効率的に行ったり、システムを高いパフォーマンスで動かしたりするための技術的な知識、ノウハウなどは、上田さんをはじめ、インフラチームのみなさんの仕事を見ながら教わっています。ソースコードも見られますので。

「やりたいこと」「やりたい人」が優先される企業文化

――新たなロジックで常に進化していくDSPを実現するにあたって、インフラとしてAWSの「S3」や「Redshift」を活用するというのは、どのような経緯で決まっていったのでしょうか。

DSPを支えるインフラ構造
DSPを支えるインフラ構造

 小林:もともとRedshiftについては、クラウドデータウェアハウスとして発表された当初から注目していました。東京リージョンでリリースされたタイミングで研究開発的に導入をスタートし、2014年の3月までに、完全に移行したという感じですね。それまではHadoopを使っていたのですが、実際にRedshiftを使えるようにしてみたら、エンジニアがみんな「こっちのほうがいい!」と移ってしまい、そのまま普段使いになったという感じです。

 丸山:Hadoopだと、どうしてもリアルタイム性の面で弱かったんですね。Redshiftは、やはりそこが強い。あと普通にSQLを使えるという点でも、エンジニアにとっては使い勝手が良かったようです。集計分析に向いた列指向(カラムナー)の高速なデータベースを持ち、クラウド上で柔軟にリソースを確保できる仕組みとして、Redshiftは大きなパラダイムシフトだったと思っています。個人的に、AWSの技術では「Lambda」や、キューイングサービスの「Kinesis」なども、ターゲティング広告のリアルタイム性や精度の向上に生かせる部分があるのではないかと関心を持って見ています。

 こういった新たな技術や製品に対して、RCOは下手なベンチャーより、ベンチャーらしい感覚でチャレンジしています。良いと思ったものは、どんどん使ってみて、過剰にリスクを意識しないで投資をしていく。エンジニアの登用についてもそうですね。下手なリスクを考えず、できる人、やりたい人にどんどんやらせてみるという社風があるなと感じています。

 小林:一般的な企業のように、ニーズが生まれた後で、経営を説得して、承認をとって、ようやく導入できるというプロセスをとることはあまりないですね。エンジニアの「やってみたい」が優先されるので、「やってみたい」技術に対して、その理由のファクトが説明できれば、比較的スムーズに予算がつけられます。研究開発の費用はつけてもらいやすい組織ではあると思います。

 そして、導入してダメだったときには、いつまでも固執せずにすぐに手放してしまう。「スクラップ&ビルド」が当たり前の社内文化としてあります。

 阿部:RCOの場合は、小林さんをはじめとするインフラチームが、業務のための環境をしっかりと守ってくれているというのが、さまざまなチャレンジをする上で大きいかもしれませんね。そうした守りの環境があるからこそ、開発チームは新たなロジックや技術に対して積極的に挑戦できる。例えば、データベース構成なんかは、現場でわりと自由に変えてしまえたりします。勝手に変わると影響が大きくトラブルにつながりかねないところに関しては、小林さんがきっちり監視していて、何か問題が起こるとすぐに対応してくれる。これは本当にありがたいですね。安心して無茶ができます。(笑)

 特にアドテクノロジーのチームについては、この「オフェンス」と「ディフェンス」のバランスが良くとれているんじゃないかと思います。

 小林:ただ、この会社の場合、ディフェンスだけやっていても評価はされません。そのあたりは、本当にバランスなんだと思います。「システムをトラブルなく動かし続ける」という「守り」の仕事をするにあたっても、それをいかに自動化し、効率化して、少ないコストで実現できるようにするか。それに取り組んでうまくいけばそれは「オフェンス」の仕事として評価されるという面はありますね。

 あと、実際には、個々のエンジニアも「オフェンス」と「ディフェンス」の両方の資質を持っていて、自分の得意なほうを普段は前面に出しているけれど、いざというときには総掛かりであっという間に対処できてしまうというのも強みですね。基本的には全体を見て、必要に応じて「オフェンス」にも「ディフェンス」にもなれる人が集まっているチームだと思います。

 阿部:アドテクノロジーチームについては、自分たちが作っているサービスに対してのコミットがものすごく強いです。むしろ「愛情」といっていいレベルだと思います(笑)。普通なら「ここまでが仕事だから」と割り切ってしまうケースでも、愛情ゆえにきちんと対応する。自分たちの作ったものが自分たちの手を離れるときは、子どもをヨメに出す辛さを感じるような、そんなチームです(笑)。

次のページ
互いのスキルを高め合う壮絶な闘い

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
特集記事連載記事一覧

もっと読む

この記事の著者

高橋 美津(タカバシ ミツ)

PCやネットといったIT分野を中心に、ビジネスやゲーム分野でも執筆を行うフリーランスライター。Windowsユーザー。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/8570 2015/03/26 16:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング