アフィリエイトを日本で最初にスタートさせた企業のバリューコマースが11月26日、「バリューコマース ビアバッシュ Night」を開催しました。ビールなどを飲みながら気軽な雰囲気で行われました。第1回目の開催となる今回はバリューコマースが開発したアフィリエイトシステムや広告効果を最適化する仕組み、さらにはエンジニアのキャリアアップに役立つデューデリジェンスなどについて語られました。

「まずは乾杯！」和やかな雰囲気でセッションを開始

オープニングトークを務めたのは、バリューコマースで採用を担当している岩井孝至さん。オープニングではバリューコマースの簡単な会社紹介が行われました。

バリューコマースは1996年に設立された一部上場会社。現在、アフィリエイトを中心とした「マーケティングソリューション事業」と、Yahoo!ショッピングをはじめとするオンラインモール向けにクリック課金型広告やCRMツールを提供する「ECソリューション事業」という2つの事業を展開しています。

「平均年齢は35.8歳。みんな長く働いてくれています。残業も少なく、産休・育休復帰率は100％。非常に働きやすい会社だと思います」（岩井さん）

▲バリューコマース株式会社 コーポレート本部 人事部 人財開発チーム 岩井孝至氏

アフィリエイトシステムの仕組み、技術的負債との向き合い方

会社紹介が終わったところで乾杯！なごやかな雰囲気の中でセッションが開始されました。最初のセッションを行ったのは貝川満さん。現在、広告配信機能の開発と保守を担当しています。「アフィリエイトシステムの技術的負債と向き合い方」についてセッションを行いました。

▲バリューコマース株式会社 技術開発本部 開発1部 貝川満氏

アフィリエイトとは、あるメディアにユーザーがアクセスしてそこに表示された広告をクリックし、遷移先の広告主サイトでユーザーが商品の購入や申込みをすると、そのデータがASPに反映され、その成果に応じて広告主からメディアに報酬を支払う仕組みのことです。

これをシステムで表したのが次の図です。枠で囲っている部分が、バリューコマースが担当するアフィリエイトの配信機能です。

当社の広告配信の仕組みに使っている技術はJavaとOracle。一日約2億のインプレッションを処理しています。

広告配信に必要な情報は次の3つです。

• メディアサイトと広告主が提携している情報
• メディアサイトの広告表示の設定情報
• 広告主の広告情報

これらのデータは管理画面から登録は可能です。これらのデータがなければ、広告表示もリダイレクトもできない作りになっています。

最新情報はすべてOracleに入っているので、Oracleから取得すればよいのではと思うかもしれませんが、次のような問題があります。

• リクエストごとにOracleにアクセスしていたら処理が遅くなる
• Oracleにつながらないだけで配信ができないのはよくない

「RDBがボトルネックになってはいけない」、そこで「Oracleとは別にデータを持った方がいい」という考えになったといいます。広告情報の更新は図のような流れで行っています。

当時からデータベースの設計は配信に適したものになっていました。またRDBを直接参照することがないように設計されており、RDBがボトルネックにならないような考慮がなされています。だから新しい機能も追加しやすく、2017年に新機能としてリリースした「おまかせ広告」の配信にはKVS、共有メモリを利用しています。

いくらモデルに優位性があるとはいえ、リリースして20年も経つと、技術的負債も増えます。2015年にはCIが動かなくなり、CIが動かないことによる品質低下の可能性、テストの負荷が増加しました。また、コードレビューは仕様を知っている人に依頼していましたが、バージョン管理にSubversionを使っていたため、コードレビューがしにくいという問題もありました。デプロイは手作業が多く無駄に時間がかかるという状況だったのです。

これらの技術的負債を解決するため、まずバージョン管理ツールをGitHub Enterpriseに移行し、GitHub Flowを利用することにしました。CIが動かないという問題は、まだ解決できていませんが、テストコードは書くようになりました。またコードレビューはGitHub PRベースで行うことに。デブロイの手動作業は、Ansibleで構成管理とデプロイまで行うようになっています。

現在の環境の改善点としては、自動化できることはすべて自動化することです。「CIツールの導入、またデプロイもAnsibleコマンド実行なので、その自動化」、「割れた窓（悪いコード、悪い設計など）は放置しない」ことが重要です。

広告の費用対効果を最適化する自動入札の仕組み

続いて登壇したのは、現在「アイテムマッチ」を担当している佐藤遼さん。「広告の費用対効果を最適化する自動入札」についてセッションを行いました。

▲バリューコマース株式会社 技術開発本部 開発2部 佐藤遼氏

佐藤さんが担当するアイテムマッチとは、Yahoo!ショッピングの出店ストア限定のクリック課金型広告サービス。Yahoo!ショッピング上部の「ストアのイチオシ」に表示されている広告がアイテムマッチの広告です。Yahoo!ショッピング内のカテゴリに対して、商品1クリック当たりの広告費を入札し、入札金額の高い順に表示しています。

このサービスが抱えていた課題は大きく2つ。

• 入札自体の手間。商品数が万単位になってくると、管理画面を操作するのに手間がかかる
• 入札金額をどう決めるか。商品一つ一つのクリック単価が高すぎても費用対効果が悪く、低すぎても露出の少ない広告になってしまう

この2つの課題について解決するため、費用対効果のよい入札を自動計算することにしました。

自動計算の仕組みを紹介する前に、まずはROASについて説明すると、ROAS（Return On Advertising Spend）とはかけた広告費に対して得られた広告経由での売上の割合のことです。それを計算式にすると

売上高÷広告費用×100％＝ROAS

となります。

ROASの値が高いほど、広告効果が高く、コストに対して売上が高くなります。逆にROASの値が低いほど広告効果が低く、コストに対して売上が低くなります。

ではROASをどう最適化するかというと、入札金額の計算式は、ROASの計算式から逆算することで求められます。

広告費用＝売上高/ROAS×100

アイテムマッチはクリック課金型のサービスなので、広告費用はクリック単価×クリック数に置き換えることができます。

クリック単価×クリック数＝注文数×注文単価/ROAS×100

またCVRは1クリック数あたりの注文数なので、

クリック単価×クリック数＝クリック数×CVR/100×注文単価/ROAS×100

という式になります。

最後にクリック単価の式を導き出します。

クリック単価＝CVR×注文単価/ROAS

計算式のCVRは過去実績のものです。商品に過去の実績がない場合もあります。その場合は商品に関連する売主や属性の実績を参照することができます。

商品は複数の属性に属しています。「そのどの属性が信頼できるのか？」「カテゴリの場合であれば、階層の近いものが信頼できるかもしれない」──しかしカテゴリ内で売れている商品もあれば、売れていない商品もあります。そのような実績のバラツキを比較する必要があります。そこで属性ごとに実績値のバラツキを標準偏差で数値化し、変動係数（バラツキを相対的に評価するための数値。標準偏差を平均値で割ることで得られる）を算出、比較することを行っています。

バラツキを比較後、バラツキの低い（変動係数の低い）属性の実績を使うこととしました。そうすれば、比較的過去実績の通りの成果を期待できるからです。

変動係数により、比較的信頼度の高い実績を得たとはいえ、商品自体の実績とは違い、大小バラツキがある実績値。信頼できる値の範囲を算出する必要があります。

標準偏差はデータが正規分布の場合、平均±標準偏差の範囲がデータ全体の68％に該当するという性質があります。得られる実績は変動係数によりバラツキの少ない実績を得ているので、比較的正規分布に近い分布となります。

実際に用いるCVRは68％の下限値です。「平均CVR-標準偏差」をCVRとして入札額算出の計算式に使うことで、約85％の商品が目標とするROASを下回らないことが期待できるようになるのです。

システム構成は次の図の通りです。

●システムの課題をどう解決したのか？

1. バラバラの1億点以上の商品へのアクセスが非効率
   → 商品をストアごとにまとめることで解決

2. ストアやカテゴリの情報など入力データが多く、多くのI/Oが発生していた
   → MySQLから取得する情報はメモリと組み込みDBにキャッシュすることで解決

3. 処理件数自体の多さ
   → ストアごとに分割し、並列実行にした

4. 誤操作による大量処理
   → ストアの操作をすべて処理せず、タスクが溜まった場合、最新の情報だけを取得して処理することで解決

入札金額計算バッチシステムはJavaで開発、フレームワークはSpring Batch、Spring Bootを使っています。前商品の入札金額を計算し、KVSに保存。1日1度の全件更新。ストア操作により入札の設定変更があれば都度更新、入札の予定設定により、入札額を更新するという仕組みになっています。

会社選びに失敗しないためのファイナンス系の知識

最後に登壇したのは、CTOの伊藤信敬さん。伊藤さんのセッションタイトルは「エンジニアが知っておきたいデューデリジェンス」。デューデリジェンスとはM&Aの際、対象となる企業や投資先の価値やリスクを調査すること。「基本的には若手エンジニアが転職する際に、どういう点に注意して選べばよいかという話をします」と前置きし、語り始めました。

▲バリューコマース株式会社 CTO 伊藤信敬氏

「エンジニアは今、売り手市場です。しかし、それをうまく活かせず、会社選びに失敗している人も多いように感じる」と伊藤さん。そこで、このセッションでは伊藤さんから「最低限これくらいは知っていると役立つこと」を、主にファイナンス系の知識を中心に伝えました。

図はBS（バランスシート：貸借対照表）とPL（Profit & Loss statement：損益計算書）を表したもの。

Assetとは資産のことで、借金（Debt）もしくは自己資金（Equity）で作られます。この資金を使って資産を回し、収益（Revenue）を生み出します。収益からコスト（Expense）を引いたモノが利益（Profit）となり、自己資金に戻る。このサイクルをまわすことが経営であり、この図のようにBSで資産が増えていくのが黒字経営です。

一方次の図は赤字企業のBS/PLです。一般的に自己資金と借金が1対1だと、銀行はお金を貸してくれますが、1対1を切ると貸し剥がしをしてくるようになります。すると会社が立ちゆかなくなり、さらに赤字が続くようになります。自己資産がマイナスになった状態が債務超過です。そして、倒産に至ります。

バリューコマースは借金がありません。つまり自己資金100％で経営を行っています。こうした会社は自己資本比率が高いため安定しています。一方、借金が多い会社の代表例がソフトバンクです。M&Aをして買った会社を自分たちの資産にして、それを元に銀行から借金して買収することを繰り返しています。これを「レバレッジを利かせる」といいますが、ソフトバンクは借金の利息以上を儲けていくという、アグレッシブな経営をしています。BSではそういうことを見ることができるのです。

一方、PLは利益を見ることができます。プロフィットと一口にいっても、5種類あります。

• 売上総利益（粗利）
• 営業利益（粗利から人的コストなどを引いたもの）
• 経常利益（投資、損益を含めたもの）
• 税引き前利益
• 当期利益

PLでは営業利益は大きいのですが、経常利益は少なく、借金の利息で苦しんでいるということもわかります。またビジネスモデルも見ることができます。例えば営業利益率は低いが営業利益は高いという会社は、薄利多売でスケールを出していくというビジネスモデルという具合です。

次に会社の選び方について。次のフローチャートが使って、話しうことができます。

選択肢は2つ、「お金が欲しい」か「欲しくないか」。お金が欲しい人は右側となります。キャピタルゲインはベンチャーで一発当てることです。それを望んでいない場合はCです。一方、お金ではなくノウハウが欲しい人はBになります。ノウハウもベースアップも要らない、例えばある程度の規模でポジションを得てコントロールしたい、社長の思いに共感している、その会社が好きなど、という人はAの選択肢となります。Aは多種多様な理由によるので、人それぞれの理由で選ぶしかありません。

B：ノウハウが欲しい人は、マーケットリーティングカンパニーを目指そう。その業界のトップ企業は2位以下の企業と視野、視点、視座が違うからです。2以下の企業はトップの企業のパイをどうとるか、つまりその業界で自社のシェアをどう拡げるかを考えています。一方、1位の企業は業界自体をどう拡大するかを考えています。ナンバーワン企業なのでかけられるコストも違います。より挑戦的なことができます。ノウハウが本当に欲しい人はトップ企業に行くことをお勧めします。

C：ベースアップを求める人は、伸びる業界、伸びる会社を目指そう。今大きくてもシュリンクする業界にいるとベースアップは厳しいからです。

D：ベンチャーで一発当てること、そしてキャピタルゲインを求めるしかありません。ベンチャーは基本、経営的に苦しいものです。大手と違って余裕はありません。ベースアップやインプットを求めるところではなく、アウトプットしてマネタイズを狙うところだからです。

ちなみにバリューコマースは一部上場企業で、日本のアフィリエイトをけん引している存在です。しかもインターネット広告市場も年々、拡大しています。ぜひ、BやCの志向の人は、バリューコマースへの転職を検討してみてはいかがでしょうか。