技術・デザイン

エンジニアのパフォーマンスを最大化するために
新卒2年目の開発責任者がチャレンジしたこと

Profile

  • 後藤 紳 (ゴトウ シン)

    アドテク本部 AirTrack
    明治大学大学院出身、2017に新卒で入社以来、AirTrack bidder の開発を担当。
    新卒2年目で開発責任者となり、AirTrackのエンジニアリングマネージメントを担当

産学連携とインターンを通して見たサイバーエージェントのエンジニア

ー 何がきっかけでアドテクノロジーに興味を持ったんですか?

大学の学部の時、ある授業で同級生がアドテクノロジーにおける RTB(Real-Time Bidding) の役割について発表したのがきっかけです。もともと広告には興味があったのですが、テクノロジーと組み合わせることで広がる市場に、将来性を感じたのをよく覚えています。その後「広告 ? テクノロジー」の研究をしたくて大学院に進学しました。

ちなみに、授業で発表していた同級生は学部卒後、サイバーエージェントに2015年卒で入社し、アドテクスタジオに配属されました。今では 「Dynalyst」 の開発に欠かせない開発責任者(※) となりました。

月間数千億のリクエストを処理するアドテクのサーバーサイド

ー 在学中にサイバーエージェントを知る機会はありましたか?

実はアドテクスタジオは、私が所属していた明治大学の高木研究室と共同研究をしていました(※)。一緒に研究する AI Lab のエンジニアを見ていると「(技術的に)やたら尖ってるなぁ」と思ったことが印象的でした。

同時期、サイバーエージェントの内定者アルバイトにも参加しました。配属先はアドテクスタジオが手がける「AirTrack」 というデジタルSPソリューションです。社内の開発プロジェクトに入ってみると、チームの人たちが職種を問わず尖っている事に驚きましたし、その環境がすごく好きになりました。

ちなみに、研究室で共同研究をしていた後輩2人も、2018年新卒としてサイバーエージェントに入社してアドテクスタジオに配属されました。新卒で東北大学とチャットボットのロジック開発の産学連携を行うなど、1個下の後輩ですが活躍しています。(※)

人工知能をアドテクノロジーに活用し最先端のAI研究を行う「AI Lab」、明治大学と産学連携 ~明治大学教授 高木氏と広告クリエイティブ最適化技術の共同研究を開始~

誰とでも・どんな言い方でも 応えられる「理想のチャットボット」を AIメッセンジャー  友松 祐太

ー どんな様子を見て「尖っている」と感じたのですか?

チームメンバーの志向が多様性に溢れていました。データサイエンスを専門分野にしているエンジニアもいれば、エンジニア マネージメントを社内ゼミで研究している人もいました。パフォーマンスチューニングが大好きな先輩もいれば、数学が好き過ぎて気づいたら機械学習エンジニアになっていた先輩も。

また職種の垣根がなく、事業成果につながるとわかればすぐにプロトタイプを作って動かしている人が多かったです。あるデータサイエンティストの先輩は、自分で考えた仮説の検証のために、アプリケーションをサクッと開発して自ら検証することを当たり前のようにやっていました。

そんな環境で働いていたので先輩からの学びが多くて、2017年に入社後、「AirTrack」に配属希望を出し本格的にジョインしました。

アドネットワークには SSP や DMP や DSP など様々なアドテク製品が流通しています。

SSPやDSPに特化特価した会社は多数ありますが、アドテクスタジオではあらゆる種類のアドプロダクトを開発しています。例えば DSP なら 「Dynalyst」、SSPなら「ProfitX」 、DMPなら「AirTrack」、アドネットワークなら「AMoAd」など、全てのポジションにプロダクトを提供しているので、俯瞰して会社を見てみるとデータやお金の流れを含めて、広告マーケットの全貌が把握できます。

「広告 ? テクノロジー」をやりたくてデジタルマーケティング分野に入った僕にとって、マーケットを俯瞰して見れるアドテクスタジオや「AirTrack」の環境は最適でした。

なんとなくの言葉はコミュニケーションコストになる

ー 先輩から得た学びの中で印象的なエピソードをおしえてください

広告や技術について妥協が一切ない人たちの集まり。当時、先輩からよく言われたのが「イメージで語るな」です。

エンジニアはプロダクト開発の殿(しんがり)だからこそ、エンジニアの言葉がそのプロダクトの機能的な可否を決めてしまいます。だから「思います」などのイメージで語るなと言われました。「エンジニアなんだからファクトと数字で言葉にしなさい。」とよく叱られました。

例えば、サーバーの障害レポートの書き方も「どうとでもとらえられるような言葉を使わないこと。誤解されるような書き方をしないこと。」と教えられました。Slackなどチャットに慣れてしまうと、主語とか述語を抜いたりしてなんとなくで書いてしまうのですが。

結局、イメージでなんとなく使った言葉って、放っておくとコミュニケーションのコストになるんです。この学びは、入社2年目に「AirTrack」の開発責任者になってからも気をつけるようにしています。

ー なぜ言葉がコミュニケーションコストになるのですか?

コミュニケーションコストは言葉の解釈の違いから生まれてくると思っています。

広告マーケットの最前線にいると、日々新しい概念や言葉が産まれてくるので、ついプロジェクト内で使う単語も増えていきがちです。言葉の定義を明確にしておかないと、認識や解釈のズレを生みますし、エンジニアリングにおいてはソースコード上にも見てとれます。

例えば広告キャンペーンという概念に対して、Campaignと書くのかServiceと書くのかAdGroupと書くのかでもソースコード上に解釈の差異が発生しますよね。これはエンジニア間の仕様の齟齬につながったり、バグの温床になる可能性もあります。

「AirTrack」では、ビジネスやエンジニアなど職種間で使う言葉を統一するようにしていました。チーム内で知らない言葉や単語が発生しないよう共有を徹底していました。

「同じ言葉をつかう」というのはドメイン駆動開発の基本で「エリック・エヴァンスのドメイン駆動設計」という技術書では、第2章に「ユビキタス言語(共通言語)を統一する」と書いてあります。

「AirTrack」の開発責任者になってからも、コミュニケーションコストについてはすごく気をつけています。

エンジニアのパフォーマンスを最大化させたい。新卒入社2年目で広告プロダクトの開発責任者に

ー 開発責任者の定義は?

「AirTrack」には開発責任者と技術責任者の2つのポジションを設けています。自分は開発責任者でチームのやる気やモチベーションの底上げを担っています。例えば、エンジニアの目標設定を一緒に考えたり、1on1を通じてモチベーションに関わっていったり、プロジェクトへのアサインなど人事的なこともやります。逆に、技術選定やアーキテクチャなどは技術責任者の方にお願いしています。

エンジニアの評価は技術責任者も交えて行っています。時に意見がぶつかることもありますが、エンジニアとして尊敬しているので、意見を言い合える関係性がすごく良いです。

ー なぜ開発責任者になろうと思ったのですか?

エンジニアと一緒に仕事するのが大好きなんですよ。エンジニアが楽しく開発しているのを見るのも本当に好きなんです(笑)。

逆に、辛いことやしんどいことはチームのエンジニアにさせたくないんです。辛いことは僕がやるので、とにかく楽しく開発してもらいたい。開発責任者になったのも、エンジニアが楽しく開発をするために、しんどいことを全部引き受けるつもりで手をあげました。

そんな動機で開発責任者になりましたが、プロジェクトを任されると、見える世界が変わってきたことに気が付きました。

例えば「アドテクスタジオという組織の中にプロダクトがあって、マーケットや組織にこんな課題があって、自分の立ち位置は今ここで、事業成果のためにはこういう動き方や役割が求められている」といった俯瞰した目線で自分やチームを見れるようになってきました。

俯瞰した目線でチームメンバーも見れるようになってきました。マネジメント、パフォーマンスチューニングや数学やデータ分析。技術志向がバラバラのエンジニアをまとめあげて、事業の成功という一点にフォーカスさせて事業の成功を目指していくのが、開発責任者の楽しさです。

メンバーの得意領域はみんなバラバラだからおもしろいです。そしてチームの目指すものに値するものを作った時の感覚は、開発責任者ならではのやりがいです。

ー 開発責任者という役割を果たすために、日頃から意識してる習慣はありますか?

2年目で開発責任者という立場になり経験が圧倒的に足りなかったので、他のプロダクトの開発責任者の人たちに話を聞く機会を意識的に増やしました。

いろいろな成功例や失敗例を聞きましたが、わかったことは自分のプロジェクトに合うやりかたもあれば、あわないやりかたもあること。そしてチームメンバーにあわせてやりかたは自分で模索する必要があることです。

正解がないんですよ(笑)。だから辛くなる瞬間もあります。そういう時は「褒めてください!」って周りに言うようにしています(笑)。

開発責任者というと、思わず構えてしまいそうな印象ですが、私は意図的に内面をさらけだすようにしています。失恋して仕事に行きたくなくなったことや、好きなアイドルのことでひとりで盛り上がったり、チーム内でもくだらない話でみんなで笑い合ったり。

チームメンバーが同じ目的に向かって仕事をするためにも、ある程度の自己開示は必要だと思っていて、そのためにはまず自分が心をさらけ出そうと心がけています。

あと、細かいようですがエンジニアの席替えとかも気を配っています。「このエンジニアは熱い想いを内心もっているのでビジネス職の人の隣にして、語り合ってもらおう」とか、「技術力の高い人の近くに座ってもらうことで若手エンジニアとしての成長が更に加速しそうだな」とか。

ー ところで、マネジメントをやると自分がコードを書けなくなるなどの葛藤はありませんか?

コードは書きたいですよ。だからコード書いています。

ー プレイングマネージャー的な立ち位置をとっているということですか?

どちらかというと、権限を移譲することでコードを書く時間を確保しています。

エンジニアリング以外のマネジメント業務を自分が全部やろうとすると、それこそコードを書く時間なんてとることはできません。

例えば、「AirTrack」内に機能別のプロジェクトを作って、そのプロジェクトリーダーをチーム内のエンジニアにお願いしました。1on1の対話の時に「ちょっとやってみない?」といった感じで相談したところ、快く引き受けてくれました。その結果、開発責任者だけがマネジメントしなくても、機能別のプロジェクトで自立してチームがワークするようになりました。

他のメンバーにも裁量を持ってもらうことで、チーム内にマネジメントできる人が増える。その結果、自分が自由に動ける時間が増えるので、コードを書く時間に充当することができる。

開発責任者のおもしろいところは、自分がコードを書くか書かないかも裁量権のうちなので、そこから決めることができることです。コードを書くと決めたら、どこからどこまでをメンバーに任せるかも自分で決められるんですね。それがおもしろい。

「あんなことやりやがった!」と言われるようなことをしたい

ー 長期的にどんなビジョンを目指していますか?

「AirTrackがまたあんなことやりやがった!」と言われたいですね。

これまで「AirTrack」で何本かプレスリリースを出す発表をしてきました。マーケットやクライアントの反応が良くて「こんなことが技術的に可能なんだ」という声を多数もらいました。

エンジニアとしては、マーケットにインパクトを与えるようなチャレンジしたいじゃないですか。「AirTrack」はそういうエッジのきいたプロダクトにしていきたいです。

もちろん、プロダクトとして利益を出すためには成功しているモデルを真似をすることも大事です。でも「これを導入したら一体どうなるんだろう」ってワクワクしながらデータを眺める気持ちって大事だと思うんです。

そしてそんなプロダクトを作り上げるチームを、開発責任者として支えていきます。

技術的な要素や志向性はなんでも良いんです。みんなバラバラだからこそ、開発責任者がみんなの強みを事業に生かすことができれば、ワクワクする未来につながると考えています。

オフィシャルブログを見る

Page Top