役割について発表したのがきっかけです。広告には興味があったのですが、テクノロジーと組み合わせることで広がる市場に、将来性を感じたのをよく覚えています。テクノロジー」の研究をしたくて大学院に進学しました。ちなみに、授業で発表していた同級生は学部卒後、サイバーエージェントに2015年卒で入社し、アドテクスタジオに配属されました。在学中にサイバーエージェントを知る機会はありましたか?実はアドテクスタジオは、私が所属していた明治大学の高木研究室と共同研究をしていました(※)。エンジニアを見ていると「(技術的に)やたら尖ってるなぁ」と思ったことが印象的でした。同時期、サイバーエージェントの内定者アルバイトにも参加しました。いうデジタルSPソリューションです。社内の開発プロジェクトに入ってみると、チームの人たちが職種を問わず尖っている事に驚きましたし、その環境がすごく好きになりました。ちなみに、研究室で共同研究をしていた後輩2人も、2018年新卒としてサイバーエージェントに入社してアドテクスタジオに配属されました。新卒で東北大学とチャットボットのロジック開発の産学連携を行うなど、1個下の後輩ですが活躍しています。どんな様子を見て「尖っている」と感じたのですか?チームメンバーの志向が多様性に溢れていました。マネージメントを社内ゼミで研究している人もいました。パフォーマンスチューニングが大好きな先輩もいれば、数学が好き過ぎて気づいたら機械学習エンジニアになっていた先輩も。職種の垣根がなく、事業成果につながるとわかればすぐにプロトタイプを作って動かしている人が多かったです。あるデータサイエンティストの先輩は、自分で考えた仮説の検証のために、アプリケーションをサクッと開発して自ら検証することを当たり前のようにやっていました。そんな環境で働いていたので先輩からの学びが多くて、2017年に入社後、「AirTrack」に配属希望を出し本格的にジョインしました。様々なアドテク製品が流通しています。SSPやDSPに特化特価した会社は多数ありますが、アドテクスタジオではあらゆる種類のアドプロダクトを開発しています。DMPなら「AirTrack」、アドネットワークなら「AMoAd」など、全てのポジションにプロダクトを提供しているので、俯瞰して会社を見てみるとデータやお金の流れを含めて、広告マーケットの全貌が把握できます。テクノロジー」をやりたくてデジタルマーケティング分野に入った僕にとって、マーケットを俯瞰して見れるアドテクスタジオや「AirTrack」の環境は最適でした。先輩から得た学びの中で印象的なエピソードをおしえてください広告や技術について妥協が一切ない人たちの集まり。当時、先輩からよく言われたのが「イメージで語るな」です。エンジニアはプロダクト開発の殿(しんがり)だからこそ、エンジニアの言葉がそのプロダクトの機能的な可否を決めてしまいます。「思います」などのイメージで語るなと言われました。「エンジニアなんだからファクトと数字で言葉にしなさい。」とよく叱られました。サーバーの障害レポートの書き方も「どうとでもとらえられるような言葉を使わないこと。誤解されるような書き方をしないこと。Slackなどチャットに慣れてしまうと、主語とか述語を抜いたりしてなんとなくで書いてしまうのですが。結局、イメージでなんとなく使った言葉って、放っておくとコミュニケーションのコストになるんです。この学びは、入社2年目に「AirTrack」の開発責任者になってからも気をつけるようにしています。言葉がコミュニケーションコストになるのですか?コミュニケーションコストは言葉の解釈の違いから生まれてくると思っています。広告マーケットの最前線にいると、日々新しい概念や言葉が産まれてくるので、ついプロジェクト内で使う単語も増えていきがちです。言葉の定義を明確にしておかないと、認識や解釈のズレを生みますし、エンジニアリングにおいてはソースコード上にも見てとれます。広告キャンペーンという概念に対して、Campaignと書くのかServiceと書くのかAdGroupと書くのかでもソースコード上に解釈の差異が発生しますよね。これはエンジニア間の仕様の齟齬につながったり、バグの温床になる可能性もあります。「AirTrack」では、ビジネスやエンジニアなど職種間で使う言葉を統一するようにしていました。チーム内で知らない言葉や単語が発生しないよう共有を徹底していました。「同じ言葉をつかう」というのはドメイン駆動開発の基本で「エリック・エヴァンスのドメイン駆動設計」という技術書では、第2章に「ユビキタス言語(共通言語)を統一する」と書いてあります。「AirTrack」の開発責任者になってからも、コミュニケーションコストについてはすごく気をつけています。エンジニアのパフォーマンスを最大化させたい。開発責任者の定義は?「AirTrack」には開発責任者と技術責任者の2つのポジションを設けています。自分は開発責任者でチームのやる気やモチベーションの底上げを担っています。エンジニアの目標設定を一緒に考えたり、1on1を通じてモチベーションに関わっていったり、プロジェクトへのアサインなど人事的なこともやります。逆に、技術選定やアーキテクチャなどは技術責任者の方にお願いしています。エンジニアの評価は技術責任者も交えて行っています。時に意見がぶつかることもありますが、エンジニアとして尊敬しているので、意見を言い合える関係性がすごく良いです。開発責任者になろうと思ったのですか?エンジニアと一緒に仕事するのが大好きなんですよ。エンジニアが楽しく開発しているのを見るのも本当に好きなんです(笑)。逆に、辛いことやしんどいことはチームのエンジニアにさせたくないんです。辛いことは僕がやるので、とにかく楽しく開発してもらいたい。開発責任者になったのも、エンジニアが楽しく開発をするために、しんどいことを全部引き受けるつもりで手をあげました。そんな動機で開発責任者になりましたが、プロジェクトを任されると、見える世界が変わってきたことに気が付きました。「アドテクスタジオという組織の中にプロダクトがあって、マーケットや組織にこんな課題があって、自分の立ち位置は今ここで、事業成果のためにはこういう動き方や役割が求められている」といった俯瞰した目線で自分やチームを見れるようになってきました。俯瞰した目線でチームメンバーも見れるようになってきました。マネジメント、パフォーマンスチューニングや数学やデータ分析。技術志向がバラバラのエンジニアをまとめあげて、事業の成功という一点にフォーカスさせて事業の成功を目指していくのが、開発責任者の楽しさです。メンバーの得意領域はみんなバラバラだからおもしろいです。チームの目指すものに値するものを作った時の感覚は、開発責任者ならではのやりがいです。開発責任者という役割を果たすために、日頃から意識してる習慣はありますか?2年目で開発責任者という立場になり経験が圧倒的に足りなかったので、他のプロダクトの開発責任者の人たちに話を聞く機会を意識的に増やしました。いろいろな成功例や失敗例を聞きましたが、わかったことは自分のプロジェクトに合うやりかたもあれば、あわないやりかたもあること。チームメンバーにあわせてやりかたは自分で模索する必要があることです。正解がないんですよ(笑)。辛くなる瞬間もあります。いう時は「褒めてください!」って周りに言うようにしています(笑)。開発責任者というと、思わず構えてしまいそうな印象ですが、私は意図的に内面をさらけだすようにしています。失恋して仕事に行きたくなくなったことや、好きなアイドルのことでひとりで盛り上がったり、チーム内でもくだらない話でみんなで笑い合ったり。チームメンバーが同じ目的に向かって仕事をするためにも、ある程度の自己開示は必要だと思っていて、そのためにはまず自分が心をさらけ出そうと心がけています。あと、細かいようですがエンジニアの席替えとかも気を配っています。「このエンジニアは熱い想いを内心もっているのでビジネス職の人の隣にして、語り合ってもらおう」とか、「技術力の高い人の近くに座ってもらうことで若手エンジニアとしての成長が更に加速しそうだな」とか。ところで、マネジメントをやると自分がコードを書けなくなるなどの葛藤はありませんか?コードは書きたいですよ。プレイングマネージャー的な立ち位置をとっているということですか?どちらかというと、権限を移譲することでコードを書く時間を確保しています。エンジニアリング以外のマネジメント業務を自分が全部やろうとすると、それこそコードを書く時間なんてとることはできません。「AirTrack」内に機能別のプロジェクトを作って、そのプロジェクトリーダーをチーム内のエンジニアにお願いしました。1on1の対話の時に「ちょっとやってみない?」といった感じで相談したところ、快く引き受けてくれました。その結果、開発責任者だけがマネジメントしなくても、機能別のプロジェクトで自立してチームがワークするようになりました。他のメンバーにも裁量を持ってもらうことで、チーム内にマネジメントできる人が増える。その結果、自分が自由に動ける時間が増えるので、コードを書く時間に充当することができる。開発責任者のおもしろいところは、自分がコードを書くか書かないかも裁量権のうちなので、そこから決めることができることです。コードを書くと決めたら、どこからどこまでをメンバーに任せるかも自分で決められるんですね。長期的にどんなビジョンを目指していますか?「AirTrackがまたあんなことやりやがった!」と言われたいですね。これまで「AirTrack」で何本かプレスリリースを出す発表をしてきました。マーケットやクライアントの反応が良くて「こんなことが技術的に可能なんだ」という声を多数もらいました。エンジニアとしては、マーケットにインパクトを与えるようなチャレンジしたいじゃないですか。「AirTrack」はそういうエッジのきいたプロダクトにしていきたいです。プロダクトとして利益を出すためには成功しているモデルを真似をすることも大事です。「これを導入したら一体どうなるんだろう」ってワクワクしながらデータを眺める気持ちって大事だと思うんです。そんなプロダクトを作り上げるチームを、開発責任者として支えていきます。技術的な要素や志向性はなんでも良いんです。みんなバラバラだからこそ、開発責任者がみんなの強みを事業に生かすことができれば、ワクワクする未来につながると考えています。