この記事では、マイクロアドの広告配信アプリ開発を担うチーム RDU について新卒入社者の視点から分かりやすく書いていきます。どうぞお付き合いください。

はじめに

高橋と申します。昨年マイクロアドに新卒入社し、現在は広告配信アプリ開発チームでアプリケーションエンジニアとして働いております。部署には他にも高橋さんが多いため、名前で呼ばれています。

自己紹介
RDU歴：6ヶ月 
趣味：将棋(三段)／AtCoder(水)／ピアノ／ポケモンカード／フットサル部・テニス部・麻雀部所属など 
最近の目標：Scalaをサラサラっと書けるようになること

マイクロアドのシステム開発部には、BDU / RDU / UDU / DSU / Infra などのチームがあります。これらのチームを簡単に説明すると、次のようになります。

BDU （Big-Data Development Unit: バッチ開発）
RDU （Real-Time-Bidding Development Unit: 配信アプリ開発）
UDU （UI/UX Development Unit: アプリの画面開発）
DSU （Data Science Unit: 機械学習関連）
Infra （Infra Team: インフラ関連）

私が所属しているチームは RDU 、つまり Real-Time-Bidding Development Unit です！なんて言われても全然ピンと来ませんよね。

そこで、この記事では、マイクロアドの広告配信アプリ開発を担う RDU でどんな人がどんな業務をしているのか、新卒入社者の視点から分かりやすく書いていきます。

RDUについて

本題に入りましょう。RDUではどんな人がどんな業務をしているのでしょうか？

どんな業務がある？

まずは業務内容を紹介します。RDUは名前通り、 Real-Time-Biddingというオークションの仕組みを使った広告配信アプリを開発するチームです。そのため、メインの業務はアプリの開発です。次のような定番の開発案件があります。

DSP側での新規SSP接続
DSP側でのターゲティング追加
SSP側でのDSPレスポンス掲載可否対応

んー、これも何のことだか分かりません！こういう時はチームの先輩に助けてもらいます。教えてもらった結果がこちら！

DSP側での新規SSP接続

新規SSP接続タスクは、他社のSSPとマイクロアドが持つDSP「UNIVERSE Ads」を接続する開発案件になります。ほとんどの場合、SSPとDSPはOpenRTBという規格に準拠したリクエスト・レスポンスを送り合うことで通信しており、そのためOpenRTBに準拠しているサービスが多いです。とはいえ、サービスによって仕様は異なります。その違いを先方とコミュニケーションを取って擦り合わせたり、プログラム上でうまく表現したりする必要があります。先方との擦り合わせやRTBの処理を全体的に追っていくコーディング体験は、難しくて大変ではありますがとても刺激的です。

DSP側でのターゲティング追加

広告主の望む属性を持つユーザに広告を出す処理を、マイクロアドではターゲティングと呼びます。例えば、年齢／性別／家族状況に応じたターゲティングをする機能を追加することで、「30代男性で家族がいる人」を狙って車の広告を出せます。ターゲティング機能追加も、SSP接続ほどではありませんが、比較的規模の大きい開発案件になります。この案件では、他のタスクに比べてゴリゴリとロジックを書けるのが特徴です。

SSP側でのDSPレスポンス掲載可否対応

マイクロアドは自社SSP「COMPASS」を持っており、これもRDUが開発しています。マイクロアドでは自社DSP「UNIVERSE Ads」の他にもさまざまな DSP と連携しており、開発内容は多岐にわたります。例えば、 DSP に送った広告リクエストのレスポンスが表示サイトに適したものかを判定する機能の開発があります。

なるほど、定番の案件がよく分かりました。（ありがとうございます） DSPとSSPのどちらも開発しているなんて、まさに Real-Time-Bidding Development Unit ですね。私は今月から初めてターゲティングの案件を担当するのですが、ゴリゴリとロジックを書けるとのことで、プログラミング力の見せどころです。

さて、以上がRDUの主な業務内容ですが、ここで触れられていない大事な業務があります。それは、アプリの監視とアラート対応です。

アプリの監視とアラート対応

アプリの監視には Kibana, Grafana, ElasticSearch, ElastAlert を用いています。リクエストの傾向などが閾値を超えたタイミングでSlackに通知が送られるので、そのアラートをその日の担当メンバーが対応するという監視体制です。

ただ、アラートが送られてきても、アプリの内部が分かっていないとエラーの根本の原因が分かりませんよね。そのため、エラー対応にはアプリへの深い理解が必要です。正直、新卒の私にはハードルが高く、今は先輩に任せきりです。早く戦力になるためにも、もっとアプリを理解しないといけませんね。

以上の内容をまとめると、RDUの主な業務は次のようになります。

DSP側での新規SSP接続
DSP側でのターゲティング追加
SSP側でのDSPレスポンス掲載可否対応
アプリの監視やアラート対応

どんな人が多い？

業務内容のイメージがついてきたところで、次はどんな人が働いているかを紹介します。と言っても、RDUのメンバーは現在6人しかいないので、ここではメンバーに「RDUに所属するきっかけ」や「RDUが求める人物像」をアンケートした結果を紹介します。アンケート結果から、RDUにどんな人が所属しているかを想像していただきたいです。

高橋(新卒1年目)のコメント

所属のきっかけは？
- 大学では競技プログラミングにハマっていて、修士では物理シミュレーションの高速化をしていた。そういった経緯もあり、効率の良いプログラムやアルゴリズムに興味があった。
- 効率的な方法を見つけるセンスをアプリ開発で生かせるのではないかと思い、RDUへの配属を希望した。
RDUが求める人物像は？
- 求める人物像は分からないが、何でも楽しもうとする人が多い印象。そういう人と一緒に仕事がしたい！

ユニットリーダ(Sさん)のコメント

所属のきっかけは？
- アルゴリズム等で処理を高速化するのが好きで、RDUであればそういう事ができると思った。
- オンプレで多くのサーバを扱っている点に興味があった。
RDUが求める人物像は？
- Scalaやストリームといった初めての技術に臆することなく挑戦できる人
- プログラム書くときに綺麗に設計することにも目を向けられる人
- 広告関連のドメイン知識の勉強も嫌がらずにできる人

先輩(Sさん)からのコメント

所属のきっかけは？
- 大学時代に少し競技プログラミングをやっていて、高い処理速度が求められるRTBに興味を持った。
RDUが求める人物像は？
- 論理的な思考力
  - コードの読み書き、仕様作成、トラブル対応をするため
- コミュニケーション能力
  - 伝えるべきことを的確に伝えるため
  - 仕事に必要な情報をヒアリングするため
- 丁寧さ
  - 分からないことをきちんと解決するため
  - コーナーケースに気を配るため

このような回答結果になりました。RDUでどんな人が働いているか、イメージできそうでしょうか。

チームの写真も紹介します。この日はみんなで新宿に行き、斧を投げてストレス発散！

RDUの働き方をもっと知る

RDUの概要は以上になります。ここからはRDUの実際の働き方のイメージを掴んでいただくために、次の3つの内容を紹介します。

RDUのチームマネジメント
RDUの業務フロー
RDUの1日のスケジュール

RDUのチームマネジメント

チームを運営するために以下のような制度を取り入れたり、ミーティングを実施したりしています。

トレーナー／トレーニー制度

新卒メンバーの成長を促進させるためにトレーナー／トレーニー制度を設けています。直属の上司となるユニットリーダーとは別で、技術面やキャリア面のサポートが受けられます。

朝会

毎日11時にRDUメンバーが全員参加し、今日やる業務を共有します。業務で詰まっていることがあれば、この場でアドバイスをもらいます。

定例

毎週末にRDUメンバーが全員参加し、今週の業務の振り返りをします。成果があればみんなでお祝い！

1on1

上司／トレーナーと1対1で行う雑談形式のミーティングです。ずっと雑談してる時もありますが、何か悩みがあれば相談に乗ってもらえます。ちなみに、私は自分のトレーナーと1on1でこんな話をしています。

長期目標・短期目標の進捗具合
業務で困っていること
趣味の話（将棋や麻雀の話）

勉強会

毎週合計2時間ほど時間をとって勉強会を開いています。現在は以下2つを行っています。

「CleanArchitecture」輪読会
「なっとく！納得関数型プログラミング」勉強会

RDUの業務フロー

マイクロアドのシステム開発部では、主に下記のフローに則って業務を遂行しています。それぞれについて説明します。

承認 -> 実装 -> テスト -> 受入 -> 試験導入 -> リリース

承認

案件にアサインされた開発者は、「実現したい機能・その機能を保証するテストケース・実装方針」をユニットリーダーやプロダクトマネージャー（ディレクター）に説明し、承認を得ます。プロダクトの責任者（ドメインエキスパート）に問題ないかを確認してもらうフェーズです。

実装

承認を得たら、いざ実装です。チームによって技術スタックは異なりますが、RDUでは主にScala言語を用いて開発します。機能だけでなく単体テストも実装します。ここでは先輩にScalaのイロハを叩き込まれます。これらを実装し、内容が問題ないかをチーム内レビューしてもらうフェーズです。

テスト

プログラムが適切に動作するかを開発用サーバーにデプロイして確認します。概ね実装できた段階で開発用サーバーに上げてみることもあるため、フェーズは厳格に分かれているわけではありません。

受入

開発用サーバーでテストして適切に動作することを確認したら、ディレクター（プロダクトマネージャー）にキャプチャした内容やテストケースをパスした証拠をまとめて確認してもらいます。

試験導入

リリースの前に、一度本番稼働しているサーバーのいくつかに試験デプロイを行います。本番サーバーに飛んでくる大量のリクエストにアプリを晒し、入札の傾向といった諸データに変化がないか（場合によってはあるか）をモニタリングします。ここで期待通りの結果を確認できれば、満を持してリリースに進みます。

リリース

リリースでは本番サーバー全てにデプロイを行います。リリース後も問題がないかを数時間にわたって注視します。何かあったときのために、リリースが行えるのは月曜から木曜までになっています。

RDUの1日のスケジュール

その月に担当する案件、所属チーム、役職などによって1日のスケジュールは異なりますが、今回は、新卒1年目の私の、ある日のスケジュールをご紹介します。

時間	イベント	一言コメント
10:30	出勤	オフィス出社は週2回前後の人が多いです
11:00	朝会	RDUは朝会が部署内で一番遅いです
12:00	ランチ	「京香」という唐揚げ弁当屋さんによく行きます
13:00	仕様書・テストケース作成	実装機能の要件をまとめます
15:00	勉強会	この日は輪読会でした！
16:00	実装	調子が上がってきます
19:30	退勤	退勤の打刻漏れに注意しましょう（現在25敗）