こんにちは！

LOGLY lift 開発グループの田中です。

今回のインタビューは、エンジニアとして広告技術（アドテク）に関わる魅力というテーマについて、当社CTOの井口 毅昭さんをインタビュイーに迎えました！

草創期から現在まで、テクノロジーでログリーを支え続けるCTOに、広告に携わることの魅力について聞いてみます。

・インタビューされる人

井口 毅昭　執行役員　CTO

ログリーの社員番号4（CTO）です。二人の男児の父です。家族で旅行やキャンプに行くのが休日の楽しみです。

・インタビューする人

田中 玄伍　lift事業部 開発グループ 主任

カレーを食べ歩くのが好きなソフトウェアエンジニア。

清流が流れる田舎でのんびり暮らすのが夢。

ーはじめに

田中：

今日はお時間を頂きありがとうございます。

今回のインタビューでは、井口さんが考える「エンジニアとしてアドテクに関わる魅力」について色々お伺いしたいと思います。

井口：

よろしくお願いします。なるほど、アドテクに関わる魅力・・・ですか。

田中：

はい。というのも「広告が大好き！」っていうエンジニアはそう多くないと思うんです。むしろネガティブなイメージを持っている人の方が多い印象です。

井口：

そうですね、ブラウザにアドブロッカーを入れている人もいるでしょうし。

田中：

ええ、入社する前は普通に入れてました（笑）

でもそんな私でも気付けば2年以上広告に携わってますし、ログリーの他のエンジニアも元々は広告業界経験のない人がほとんどです。

これは技術者として魅力に感じる部分があるからこそ続いているんだろうなと思い、「広告の魅力とはなんぞや」をログリーの広告事業とともに歩んできた井口さんに伺いたいな、と。

井口：

なるほど、そういうことですか。

どこまでご期待に添えるかわかりませんが、やってみましょう。

ーロマン溢れる大規模トラフィック

田中：

早速ですが、広告配信の魅力として思い浮かぶのはどんなことでしょうか？

井口：

そうですねー、エンジニアリングの観点から言うと、やっぱり規模感が最初に挙がりますね。

広告の領域にもよりますけど、非常に多くのリクエストが来るというのは広告配信システムの特徴と言えると思います。

田中：

やっぱりそこですよね。

具体的にはどういう点でしょうか。

井口：

具体的にはリクエストの数ですね。LOGLY liftだと月間200億超のインプレッションがありますから、単純計算しても秒間8000件近いリクエストです。一般的なWebサービスと比べると桁違いに多い数字と言えます。

また、広告配信システムでは効果測定のためにさまざまなログを出力しますから、リクエスト数に比例して溜まっていくログの量も膨大になっていきます。

田中：

Webサービスとリクエストの規模が違ってくる理由としては、広告がサイトを横断して提供されるからでしょうか？

井口：

そうですね。例えば、単体のWebサービスを運用する場合だと、サーバにはそのサービスの利用者からのリクエストしか届かないのが普通です。

でも、広告はインターネットの様々なメディアに掲載されていますから、リクエスト元のサービスやWebサイトもひとつに限らないことになります。

もっと言えば、潜在的にはインターネットの全ユーザが広告のユーザになり得ると考えることもできます。

そうすると当然トラフィックが大きくなり、でっかいものを扱うことにはロマンがあるという魅力が・・・（笑）

田中：

ロマンですか（笑）

井口：

まあロマンはさて置き、こういった規模感のシステム運用は挑戦しがいがありますし、経験としても得難いものだと思います。

ー広告配信はミッションクリティカル

井口：

規模の大きさに近い話として、広告配信は24時間365日止まらない、ミッションクリティカルなシステムである、というのもポイントかもしれません。

田中：

確かに、広告配信が止まってしまうと広告主の売上毀損に繋がりますし、配信先のWebメディアにもデザインの崩れや広告収入が入らなくなるなどの問題が起きてしまいますね。

井口：

はい、計画停止という概念がないのはもちろんのこと、どんなトラブルやメンテナンスがあろうと広告は配信し続けなければいけませんからね。

ミッションクリティカルなシステムを運用するには可用性を担保する設計が不可欠ですから、そのあたりの課題解決に携われることは魅力と言えそうです。

ー時に生き物のような動きをするシステム

井口：

これは魅力と言えるか怪しいんですが、広告のシステムって時々生き物のような動きをすることがあるんです。

田中：

生き物・・・ですか（なんか難しい話が出てきたぞ）

井口：

えっと、言い方を変えると「システム全体が複雑系かのように振る舞う」でしょうか。

個別のロジックが複雑というのもあるんですが、そのロジックが複数絡み合っていたり、配信に関わる変数が多岐にわたることなどが、全体の動きに影響しているんですよね。

時々、自然を観察しているかのようにシステムを見ている自分がいたりします。

田中：

なんとなくわかってきました。

あるWebメディアに広告を出そうとした時に、どの広告案件を配信するかって、過去のクリック率をはじめ、その時の入札単価や競合案件の状況など、様々な要因によって決定されますものね。

井口：

はい、その結果として「なんだか調子が悪い」みたいなことも起きたりします。

広告がまったく配信されない、というような0と1で区別できる調子の悪さではなく、例えるなら「身体は動くけどなんだか腰が痛いぞ」みたいな。

いったい何を言ってるんだ？って顔してますね

田中：

（あ、バレた）

井口：

広告配信って決定論的な動きをあまりせず、確率的に動くケースが多いんですよ。

例えば、「この広告枠ではこの広告を出すと実績から見てクリック率が高そうだ」という場合でも、その広告が100%配信されるということはなく、あくまで配信される確率がちょっと増える程度だったりします。

田中：

確率的に動くという話だと、事象の再現が難しいことはたまにありますね。

「○月○日の実績が変だから見てほしい」という問い合わせを受けて調査するんですが、どう頑張ってもその時の状況が再現できずに迷宮入りするなんてことも。

井口：

そうそう、魅力とは少し違うのかもしれませんが、神秘的ではありますね（笑）

田中：

神秘的・・・

ーインターネット広告に社会の縮図を見る

井口：

そうそう、「自然を観察しているかのようにシステムを見ることがある」とお話ししましたけど、実際広告システムが社会の縮図のように感じられる時があります。

田中：

おお、今度は社会ですか。

井口：

世の中でなにかが起きると、リアルタイムにトラフィックに反映されるんですよね。社会とダイレクトに繋がっていることを実感できる気がします。

田中：

あー、芸能人のスキャンダルだったり、結婚報道が出た時はCloudWatchのグラフが跳ね上がりますね。

井口：

はい、最近ではアプリのプッシュ通知によって世の中の人が一斉に記事にアクセスする事も多いので、サーバのスケールアウトが追いつかない難しさもあります。

別の角度ですが、すべてのトラフィックが数字化されるので、良くも悪くも注目度がわかってしまうのも面白いところかもしれません。あの人の結婚よりこの人の不祥事の方が反応が大きいのかとか、真面目なニュースはあまり反応が大きくないんだなとか。

田中：

ログリーの広告は様々なWebメディアに導入頂いていますから、それぞれのメディアでの反響が伝わってくることもあり、より世の中の縮図感がありますね。

井口：

トラフィック以外にも、利用ブラウザやOSなどがリクエスト情報からわかったりするのも技術的には興味深かったりします。「こんな昔のブラウザがまだ残っていたのか」みたいな。

ブラウザでいうと後方互換性を維持することの難しさというのもあるので悩ましいですが。

ー広告業界の技術トレンド

田中：

ちょっと話が変わりますが、インターネット広告の業界って技術トレンドの移り変わりが激しいように思うのですが、そのあたりについてお話伺えますか？

井口：

そうですね、RTBのように技術革新からトレンドが生まれる場合もあれば、アドフラウドや昨今のプライバシー問題からのポストCookieのように、社会の流れから生まれるトレンドもあったりします。

ただ、技術が移り変わっているように見えて、実際本質的なところは変わっていないと思います。

田中：

実は変わってるわけではないと。

井口：

移り変わりというよりも関心事の範囲が広がっていってるイメージですね。

黎明期は純広告といってWebメディアに広告を直接貼り付けていたのが、やがて複数のメディアに配信できるアドネットワークが生まれて、その後リアルタイムに入札したいニーズからRTBができたりですね。DMPやアドベリフィケーションも大きな流れで見るとその延長線上で生まれているものです。

田中：

確かに言われてみると、使われなくなっている技術ってあまり見かけないですね。付属の概念がどんどん増えていったみたいな印象です。

井口：

アプリケーション開発の世界だと、昨今のフロントエンドのフレームワークの移り変わりは激しいですが、広告というのは単体ではアプリケーションではないので「トレンドに乗って広告配信をReactにします」みたいなことは起こらないわけです。

Webメディアから見れば、広告はあくまで3rdパーティのスクリプトという身分なので、色々な環境で期待通り動くお作法で作り続けてます。

そういう意味ではトレンドというより古臭さが残る領域もありますね。

ーアドテクエンジニアに求められる技術水準

田中：

最後にお伺いしたいのですが、技術者としてアドテクに関わる上で必要な素養、みたいなものってあるんでしょうか。

井口：

広告技術特有の要求水準があるわけではないと思っています。

現に中途でログリーに入ってきたエンジニア職は広告業界未経験の方がほとんどですから。

あえて言うとすれば、道具の技術的な背景を理解した上で活用できること、でしょうか。広告に限らずではあると思いますが。

田中：

浅いふわっとした理解で物を扱わない、ということですかね。

井口：

何を扱うにしても、正しく理解した上で使う。

正しく理解するために適切な調べ方をする。

表面だけをなぞらずに本質を理解することが大事だと思います。

例えば、Cookieという仕組みがどういう成り立ちで、どんな特長や技術的制約があるのか。そういったことを理解した上で、応用として制約を乗り越える方法を考えていく。

この応用できる力を伸ばしていくと、広告業界に限らず技術者としての糧になっていくでしょうね。

田中：

ちょっと耳が痛いですね・・・自戒します。

井口：

難しく言っちゃいましたけど、今までの経験をきちんと積み上げて来られた方であれば、業界固有の知識がなくても十分に対応可能ということはお伝えしたいです。

ーおわりに

田中：

今日はお忙しい中ありがとうございました。

最後に、ブログに載せる写真撮らせていただいてもいいですか。

井口：

ああ、いいですよ、どんな風にすればいいです？

田中：

えーっと、IT業界の写真撮影といえば・・・「ろくろ回し」ですかね。

井口：

えっ、ろくろ・・・

うーん・・・

こうですか？

井口さん、ありがとうございました！！！

ー編集後記

アドテクに関わることの魅力について、弊社CTOに色々聞いてみました。

アドテクそのものにスポットライトを当てて話をする機会というのは今までなかったので、とても楽しくインタビューさせていただきました。

特に印象深かったのは「生き物のような動きをする」という話。色々な要素が絡み合って複雑な動きを見せるシステムというのは、扱うのが難しいですがその分面白みもあると感じます。

ログリーに入る前の自分を思い返してみると「正直アドテクってよくわからないなー」と思っていたので、同じように感じている方に少しでも魅力が伝えられれば幸いです。

*****************************************

注釈

RTB:

Real-Time Biddingの略。1インプレッションごとにリアルタイムで広告枠の入札を行う仕組み。

アドフラウド:

ボットを使って不正に広告クリックを発生させるなどの広告費を不正に搾取する行為。

アドベリフィケーション:

掲載された広告が適正に見られているか、不適切なサイトに掲載されていないかなどを測定して配信コントロールを行う取り組み。

DMP:

Data Management Platformの略。インターネット上のビッグデータやログ情報などを一元管理し、広告配信などに利活用するプラットフォーム。

React:

シングルページアプリケーションやモバイルアプリケーション開発のベースとして使われるJavaScriptライブラリ。