アルメニア、ジョージア、アゼルバイジャンのニアショアのチームが本当にリアルタイム入札(RTB)のシステムを運用してきたのかをどう確かめるか、UTC+4 が勤務時間にとって何を意味するのか、そしてどのアドテクの仕事が固定スコープに向いているのか。
アルメニアやほかのコーカサスの国のチームは、そのエンジニアがビッダー、サプライサイドプラットフォーム(SSP)、アドエクスチェンジ、イベントパイプラインを構築して本番で運用した経験があり、あなた自身のログにある実際の入札リクエストを順を追って説明できるなら、アドテクの仕事について話を聞く価値がある。
短い答え:共有できる勤務時間は、中欧とは6〜7時間、ロンドンとは5〜6時間、ニューヨークとは多くて1時間と見込み、トラフィックのピーク時に誰が当番をするかを決めておく。契約前に、エンジニアが話すのを聞く。固定スコープは、仕様と受け入れテストがある仕事にだけ与え、落札率やクラウド費用のような目標はそこに含めない。
ここでは会社のランキングはしない。チームを候補に入れるのは、必要としている種類のシステム、つまりビッダーやリアルタイム入札(RTB)で広告を買うデマンドサイドプラットフォーム(DSP)、SSP、アドエクスチェンジ、アドサーバー、インプレッションとクリックを数えるパイプラインを構築し、本番で運用した経験がある場合に限る。各社に、稼働中のシステムと、自社のエンジニアが構築した部分を挙げてもらい、営業担当だけでなく、そのエンジニアと話をさせてもらう。
その一部は公開情報で確かめられる。Prebid は、パブリッシャーが多数の SSP やエクスチェンジに一度に入札を求めるために使うオープンソースのソフトウェアで、その接続の一つひとつが Prebid の公開コードの中のビッダーアダプター(bidder adapter)であり、誰がそれを変更したかの履歴も公開されている。Prebid のドキュメントは、Prebid.js の各アダプターに「アダプターのメンテナーの連絡先メールアドレス」を記載するよう求めている。そのメールがどのドメインのものかを確かめ、ある会社が、あるプラットフォームのアダプターを書いたと言うなら、そのプルリクエストへのリンクを求める。
機密保持契約で顧客の名前を出せない場合は、代わりにその顧客と話せる場を設けてもらう。
自社のログにある実際の入札リクエストから個人データを取り除いてエンジニアに渡し、順を追って説明してもらう。デッドラインから話し始めるかどうかに注目する。IAB Tech Lab の入札リクエストの標準である OpenRTB 2.6 は、tmax というフィールドを「タイムアウトを避けるために、インターネットのレイテンシを含めて、エクスチェンジが入札の受信を許容する最大時間(ミリ秒)。」と定義している。
次に、入札がどうなったかをビッダーに伝える通知について尋ねる。OpenRTB 2.6 には三つの通知がある。エクスチェンジは「入札が勝った場合(配信された、視認された、または課金対象になった広告を必ずしも意味しない)」に落札通知を送る。「勝った入札が、エクスチェンジ固有のビジネスポリシーに基づいて課金対象になったとき」には課金通知を、「入札が負けたと分かったとき」には落選通知を送る。エクスチェンジの請求書と自社の支出を突き合わせたことのあるチームなら、自分たちのシステムがどの通知を数えていたのか、数字が食い違ったときにどうしたのかを説明できる。
ほかに尋ねるべき四つの質問:
いちばん時間をかけるべきはインシデントの話だ。フィールドについての質問なら、仕様書だけで答えられるからである。
一年を通じて UTC+4 である。IANA のタイムゾーンデータベースによれば、三か国とも時計を変えないが、ヨーロッパと米国は変える。双方が9時から18時まで働くとすると、エレバン、トビリシ、バクーのチームが共有できる時間は次のとおりだ。
オークションは夕方6時で止まるわけではない。トラフィックのピークが米国東海岸の午後8時から11時なら、それはエレバンではおよそ午前4時から8時にあたる。ピーク時に誰が当番をするのか、どれだけ早く対応するのか、あなたの側の誰にどう連絡するのかを、書面で取り決めておく。
OpenRTB も Prebid のドキュメントも英語で公開されているので、アドテクのエンジニアは英語を十分に読めなければならない。プレッシャーの下で英語を書いたり話したりするのは別の技能であり、誰がそれを持っているかは、会社のウェブサイトを見てもわからない。
プロジェクトのエンジニアとそのチームリーダーが、チケット、コードレビュー、インシデントレポート、通話でどの言語を使うのかを確かめ、契約前にビデオ通話で実際に使うのを聞く。そのうえで、チームが書いたインシデントレポートを、顧客の情報を除いたうえで見せてもらい、自社の社員が書いたものを読むつもりで読む。
固定スコープがうまくいくのは、三つの条件がそろうときだ。仕事に書面の仕様があること、双方が実行できる受け入れテストがあること、そして結果がパートナーの予定に左右されないことである。
これらの条件を満たすことが多いアドテクの仕事:
それでも、固定スコープに入れるのはコードとテストであって、パートナーがそれを受け入れる日付ではない。たとえば Prebid のメンテナーは、新しいアダプターを自分たちのペースでレビューする。Prebid.js について、ドキュメントは、新しいアダプターのコードは「数日以内に」レビュー担当の開発者に割り当てられ、マージ後は「次のリリースに含まれる」と述べている。
固定スコープに向かない仕事もある。落札率を上げる、クラウドの請求額を決まった割合だけ減らす、十分に速くなるまでビッダーをチューニングする、といった仕事だ。結果は市場、パートナー、自社のトラフィックに左右されるので、会社が約束できるのは作業であって、数字ではない。こうした仕事には、専任チームやタイム・アンド・マテリアル契約が向いており、作業を始める前に、双方が合意した測定方法を決めておく。
スコープがどうであれ、変更の価格をどう決めるかは契約に書いておく。
通常の条件に加えて、次のことを書いておく:
登記、制裁、支払いの確認は、東欧やコーカサスで会社を選ぶ方法についての記事で扱っている。
このブログを発行している amBrain は、アルメニア・エレバンのソフトウェアエンジニアリング企業である。そのサイトは、アドテク分野のサービスを「DSP開発、RTBプラットフォーム、アドエクスチェンジのエンジニアリング。」と記している。RTBBidder は、amBrain がある顧客のために Rust と Go で構築したデマンドサイドプラットフォームである。
この記事で扱うほかのシステムも、amBrain は構築している。本人たちの言葉では、「amBrain は、パブリッシャー向けのサプライサイドプラットフォーム(SSP)を構築する。」そして「amBrain はアドテク向けのイベント分析パイプラインを構築する。インプレッションとクリックのイベントの収集、処理、レポーティングである。」amBrain は2019年からソフトウェアを作っており、働き方には三つの形態がある:フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。
所有権についての一文はこうだ:「顧客は、プロダクトとコードの完全な所有権を保持する。ただし、私たちの再利用可能なコンポーネントは除く。」ほかのどのチームとも同じ質問を amBrain にもすること。あなたの作業のどれかを固定スコープで引き受けるかどうか、引き受けるならどんな受け入れテストでか、そしてそこでいう再利用可能なコンポーネントがどれを指すのか。
この記事は法的助言ではない。署名する前に、弁護士に契約書を読んでもらう。