こんにちは。メディアプロダクト開発部の我妻謙樹です。サーバーサイドエンジニアとして、広告配信システムの開発・運用を担当しています。入社以来広告領域を担当するグループに所属しています。
クックパッドと広告
クックパッドでは、PS に次ぐ売上高を占める主力事業として、広告事業があります。
過去にも、"クックパッドの広告エンジニアは何をやっているのか"（公開日：2015-11-26）という記事が公開されたことがありますが、当時とは技術要素やチーム構成はもちろん、事業をめぐる環境が大きく変わっています。
しかし、上記記事でも述べられている、以下の原則は変わっていません。
クックパッドの広告は、昔から、ユーザさんと広告出稿企業さん、そして私たちクックパッドの3者ともが幸せになる形を模索し続けてきています。 クックパッドを通して、最終的には広告も「価値ある情報」としてユーザさんに届けば、それは広告単価の上昇にも繋がるからです。
広告は、広告を出稿してくださる企業の課題を解決するために存在し、ユーザーにその価値を届けるために存在しています。いわゆるアドネットワークを支える DSP/SSP を開発するのではなく、自社で配信システムを内製し、貴重なユーザーのデータを保持するからこそできる独自の広告事業の面白みが、クックパッドにはあります。
本記事を通して、クックパッドにおける広告事業、及びそれを支える私達の部・グループについて少しでも理解の一助となれば幸いです。
運用保守対象のサービス一覧
私達のグループでは、広告が入稿されてから配信されるまで一貫した自社システムを保守・運用しています。細かいシステムは多数ありますが、主要なコンポーネントのみを表示させたシステムアーキテクチャ概観は以下の図の通りです。
Ad creative admin service
- いわゆる「入稿」システム
- 弊社の業務推進チームが、受注に従ってクリエイティブを入稿
- 純広告とネットワーク広告の配信比率の調整、ターゲティングの設定、広告枠のリアルタイムレポートなど多機能
New ads delivery service
- いわゆる「配信」システム
- 新世代。クックパッド アプリケーション自体に内在されていた配信ロジックを別アプリケーションとして切り出したシステム
- 初期は Rails アプリケーションだったが、機能の肥大化及びインフラコストの削減＆開発速度の向上を目指し、一部の機能を Go に Microservices として切り出し
Legacy ads delivery service
- いわゆる「配信」システム
- 旧世代。初期は Cookpad アプリケーション自体に配信ロジックが内在されていた
- 現在はほとんどの機能が新世代に移行済み、新規開発することは殆どない。旧バージョンアプリの互換性のために残していたが、物理削除含めて近日中に完全廃止予定。
Machine Learning services
- いわゆる「最適化」システム
- Ruby/Rails で実装された入稿システムにおいて、別言語ランタイムである Python と機械学習ライブラリを利用し、配信比率の最適化や在庫予測を行うため、AWS APIGateway + Lambda を利用した Microservices として実装されている
Logging (Lambda Architecture)
batch layer
- いわゆる「DWH（Data Warehouse）」
- すべてのログが格納されており、配信比率の最適化、レポーティング用集計など、入稿システムのあらゆる箇所で利用されている
- サービスオーナーは DWH チーム
- 業務推進チームやディレクターは、Tableau を利用しダッシュボードで可視化して業務に利用している
speed layer
- サービスオーナーは我々のグループ
- ストリーミングパイプラインによるリアルタイムログ基盤
- 入稿システムにおけるリアルタイムレポートや、配信比率の最適化処理における精度向上に利用されている
Tracking service
- いわゆる「DMP（Data Management Platform）」
- サービスオーナーは DMP チーム
- EAT（Extreme Audience Targeting）を始めとし、エリアターゲティングや検索キーワードターゲティングといった機能も提供している
技術スタック
先ほど紹介した各サービスで利用されている技術スタックは、以下の通りです。
技術選定
前節で技術スタックについてご紹介しました。私達のチームでは、以下の図に表される評価軸に沿って、プロジェクトや事業の成果を達成するために最適な技術スタックを選択することを心がけています。
「会社がこの技術を押すから」といった会社目線での観点や、「チームでこの技術を使っている人が多いから何となく・・・」といったチーム目線での観点、「この技術を使いたいから」といった技術的成長目線の観点だけで技術を選択することは有りません。以下の三点を総合的に判断することを心がけています。もちろん、技術選定に失敗したこともありますし、この評価軸が完璧ではありませんが、考える軸にはなります。
Tech - 技術的観点
技術自体の正しさを評価する軸です。例えば、ある課題に対して奇想天外な技術を選択することは、どれだけその技術を導入する難易度が高かったとしても、優れた設計では有りません。適切な「課題」に対して適切な技術を「解決」策として適用することこそが求められています。
そのために、数多くのミドルウェア、クラウドサービスに対しての知識を深め、少しでも引き出しを増やし、純粋に比較検討できるスキルが、技術選定に責任を持つテックリードに求められています。
その他にも、以下の観点を評価します。
- 技術が開発されているエコシステムの発展性
- 開発をサポートするツールの充実生
- グローバル及び日本における技術トレンド
- その技術を支える日本でのコミュニティ
Company - 会社的観点
次に、会社全体のその技術への関わり方を評価します。
例えば、クックパッドは Ruby/Rails をヘビーに利用する会社です。Ruby コミッターの方々も働いており、サポートも手厚いです。しかし、だからといって全てのサービスが Ruby であるべきか、Rails であるべきかというと違います。「技術的観点」および「チーム的観点」の比重を優先し、Ruby/Rails 以外の技術を選択することは往々にしてあります。
その他にも、以下の観点を評価します。
- 会社のミッションに対する適合性
- その技術を選択すると事業の成功にどれだけ貢献できる可能性が高いのか
- 会社全体（他のチーム）で利用されている技術とは親和性が高いか
- 会社のエンジニアカルチャーと適合するか
- 採用の観点から、その技術を選択する優位性はあるか
Team - チーム的観点
最後に、チーム的観点から評価します。具体的には、部およびチームがどのような技術方針を持っているかという観点に加え、新卒からシニアメンバーまでそれぞれのメンバーの現在のスキルセットや目指すキャリアパスを考慮して総合的に判断します。
具体的には、以下の観点で評価します。
- チームメンバーのその技術に対する成熟度
- チームメンバの現在のスキルセットから想定できるその技術の吸収力
- 各メンバーが目指すキャリアパスへの貢献具合
- チームがスケールしたときに対応できる学習コストやサポート体制
- その技術を選択することへのモチベーション
チーム体制
「領域：マーケティングサービス領域」を担当する部署が 4 つ存在しています。
- マーケティングサポート事業部
- 国内におけるマーケティングサービスの企画、開発、運用及び営業に関する業務を担当する。営業グループの他、社内のデータを検証して新商品開発や営業提案資料を作成するデータチーム、日々の入稿作業やレポーティングを支える業務推進チームが所属
- マーケティング企画制作部
- マーケティングサービスの企画立案・制作・進行に関する業務を担当する。タイアップ広告を企業とともに作り上げる制作グループが所属している。
- マーケティングプロダクト開発部
- 国内に置ける広告事業及び企業向け事業に関する企画、商品開発に関する業務を担当する。主にディレクターが所属。
- メディアプロダクト開発部
- 国内の行ける企業向けプロダクト開発に関する業務を担当する。私達が所属している部署。
メディアプロダクト開発部
メディアプロダクト開発部では、以下の 3 つのグループから成立しています。9 割がエンジニアの組織です。広告領域を担当する私が所属しているのが、「マーケティングサービス開発グループ」通称 msdevです。
- マーケティングサービス開発グループ（通称：msdev）
- 広告領域を担当しています
- プロダクト開発グループ（通称：pdev）
- 動画領域を担当しています
- プロダクトデザイングループ
- デザイナーとディレクターが所属しています
プロダクト開発グループとの協同体制
プロダクト開発グループでは、動画領域を中心とし、数多くのサービスを開発しています。最近の開発については、以下の発表やブログが参考になるでしょう。
- クックパッド動画事業開発のチャレンジ
- クッキングLIVEアプリ「cookpadTV」が大幅リニューアル！人気のLIVEコンテンツを大幅に拡充した「cookpadLive」としてスタート
- 「cookpad storeTV」、北海道・東北地域でスーパーを展開するアークスグループ８社への導入を開始。全国のスーパーマーケット88チェーン、4500店舗で展開する料理動画サイネージへ
グループは違いますが、msdev と pdev は席も近く、部署も同じですので、頻繁にコミュニケーションがあります。プロジェクトによっては、片方のグループメンバーが片方のグループのプロジェクトを手伝う、といったこともあります。
これによって、広告領域に携わりながらも動画領域で利用されている技術に触れることができる、という大きなメリットがあります。例えば、私も広告領域のプロジェクトを担当する傍ら、過去に以下のプロジェクトに携わらせていただいたことがあります。
また、msdev/pdev それぞれのグループで勉強会を開催しています。もちろん横断して参加が可能です。過去には、以下のような内容で勉強会が開催されています。
- 基礎技術詳解
- TCP/IP, SQL, Rails, Go, Design Patterns, モダンブラウザの仕組み, TypeScript
- AWS 各サービス詳解
- DynamoDB. Parameter Store, API Gateway+Lambda, AWS IoT, CloudFront, etc.
- 利用サービス詳解
- terraform, Stripe, Tableau Desktop, etc.
- カンファレンス参加報告
- RubyKaigi 2019
- 自分たちの保守運用するシステムのアーキテクチャ詳解
- 動画配信サーバー, 広告配信サーバー, etc.
まとめ
広告領域は、技術的にチャレンジングな課題も多く、かつ事業の売上貢献に直結することが多い、非常にエキサイティングな領域です。また、アドネットワークではなく、自社の事業で専用の配信サーバーとユーザーデータを保持するからこその事業の面白さもあるため、事業開発に興味・関心が高い人にとっても活躍の可能性が大いにある場です。
メディアプロダクト開発部では、一緒に働いてくれるメンバーを募集しています。少しでも興味を持っていただけたら、以下からエントリーをしてください。