こんにちは！メディアのマネタイズを担当するメディア事業部でネットワーク広告の運用を行っているyattyoです。

以前公開された記事「pixivの新しいターゲティング広告とその目指す世界」では、pixivのターゲティング広告商材「pixiv Audience Targeting Ads」についてビジネスサイドからお話しました。
今回は、メディア事業部で広告周りのディレクターを担当しているyousanとエンジニアのcatatsuy,yasuにインタビューをして、エンジニアサイドの話をお伝えしていきます。

自己紹介

今回は、ターゲティング広告商材「pixiv Audience Targeting Ads」をリリースするための開発プロジェクトについて聞かせてください！まずは、それぞれ自己紹介をお願いします。

yousan：メディア事業部でディレクターをしているyousanです。メディア事業部では、セールスチーム・運用チーム・開発チームの3つに分かれて、広告周りに関する仕事をしています。今回メインの話になる開発チームでは、自社アドサーバーの管理や改修、また新規商材の開発や効果向上にも携わっています。
僕自身は今回のプロジェクトでは、プロダクトに必要な要件を技術面・ビジネス面で考え、すり合わせる役割をしていました。

catatsuy：エンジニアのcatatsuyです。今回のプロジェクトでは、開発を統括していく立場として、セールスチームからの要望を受けて、広告サーバーが何をすべきなのか仕様を整理し、広告配信サーバー側の実装を行っていました。

yasu：同じく、エンジニアのyasuです。今回は、管理画面の改修を担当していました。セールスチームが管理画面を操作するにあたって、どういうインターフェースにするかなどの管理画面周りの要件定義から実装までを行いました。

まず、今回のプロジェクトの概要と目的を教えてください。

yousan：広告の掲載場所となる「プレイスメント」を担保した上で、配信対象ユーザーである「オーディエンス」をベースにターゲティングできる広告商材「pixiv Audience Targeting Ads」をリリースする、というプロジェクトです。

これまでは、閲覧コンテンツを元にした趣味嗜好によるターゲティングをコンテンツページつまり「プレイスメント」に対して行っており、広告商材として十分なimpボリュームを確保できていませんでした。そこで、ユーザーつまり「オーディエンス」に対してターゲティングをすることでコンテンツページ以外のページにも広告を掲載し、impボリュームを確保しようというアイディアが起点になっています。

それを起点に、既存の年齢などのデモグラのターゲティングもより詳細にセグメントを分けを行い、広告のマッチング精度を高めることが、今回のプロジェクトの目的です。

pixivで使用されている広告サーバーについて

ではエンジニアの2人が広告サーバーにどう関わっているのか、またpixivがどういう広告サーバーを使っているのかを教えていただきたいです！

catatsuy： pixivで使用されている広告サーバーは、何度かフルスクラッチで作り直されています。今の広告サーバーは私が新卒1年目の時に開発が始まったもので、私が入社して初めて関わった新規サービスのリリースでした。リリース後の運用も担当しつつ、高速化や機能追加をした時の仕様策定や実装に関わっています。

yasu：私は、入社して3ヶ月後くらいから広告に携わるようになりました。
当時はフルコミットしていたわけではなく、pixivのバックエンドの改修を主に行いながら、配信サーバーの修正などを行っていました。
現在はpixiv Audience Targeting Ads のセグメントの開発など広告全般の実装を行っています。

catatsuy：現在の広告サーバーは「管理サーバー」と「配信サーバー」の大きく2つのシステムに分かれています。
管理サーバーはセールスチームが日常的に使用しているもので、Ruby on Railsを使って開発されています。

管理サーバーの役割は大きく3つあります。

セールスチームが、純広告や自社広告を入稿したり、配信広告のタグを入稿したりする機能
登録された広告が、それぞれどの程度のインプレッション・クリック数だったのかを確認するためのレポート画面の提供
現在配信する必要のある広告とその配信比率を配信サーバーにJSON APIによって渡す機能

です。

配信サーバーは、実際にpixivを見るとリクエストされるもので、アクセス量は社内でもトップクラスのサーバーです。非常に高いパフォーマンスを求められるので、Go言語を使って開発されています。

配信サーバーの役割は大きく2つあります。

管理サーバーのJSON APIを元に実際に広告を配信する機能
インプレッション・クリック数を一時集計して管理サーバーのMySQLの一時集計用のテーブルに書き込む機能

です。管理サーバーと配信サーバーはリポジトリも別になっていて、完全に別のサービスとして実装されていますが、今話したようにJSON APIとMySQLの一時集計用のテーブルだけ共有しています。それ以外は共有しないようにして疎結合な構成を保つようにしてあります。

エンジニアも課題発見から仕様決めまで行う

チームとしての開発方法を伺いたいのですが、今回のプロジェクトはどのような経緯で始まったのでしょうか？

yousan：メディア事業部では四半期に一度、セールスチームも開発チームも全員が参加し、丸々一日を使って今後の戦略を考える「ストラテジーミーティング」というものを行っています。そのミーティングで今回のプロジェクトの元となる「プレイスメント」から「オーディエンス」に対してターゲティングすることでimp量を確保しようというアイディアが起案されました。そのアイディアを起点にチーム全員でブラッシュアップし、本格的に動き出す事になりました。

なるほど、課題発見の段階からチーム全員で行っているんですね！出てきた案をどのように仕様に落とし込んでいったのですか？

catatsuy：「オーディエンスにターゲティングできる広告商材を作ろう」という案の内容は最初はざっくりとした曖昧なものでした。

具体的には

pixiv Audience Targeting Adsのリリース前にも一部枠に特別な実装を加えることで可能になっていた、性別などのセグメントをすべての枠で行えるようにする
ユーザーの嗜好に応じた新しいセグメントを追加する
色々なセグメントを掛け合わせた設定を登録しても、impの管理が破綻しないように配信比率を自動調整する

という内容でした。

この案を仕様に落とし込んでいくためには、「管理サーバーの管理画面にどのように設定をすると、どのように配信されて欲しいのか？」、「何ができる必要があって、何ができなくても良いのか？」を明確にする必要がありました。

そこで、それらをセールスチームから聞き出すために毎日のようにミーティングを行いました。話している最中にも、認識の齟齬が生まれないようにするために、私が「多分こういうことだろう」と推測できる部分も、確実に質問するようにしていました。

”縛り”を作る言葉が仕様を鮮明にする。

仕様に落とし込む際に、曖昧だった案が鮮明になったタイミングはありますか？それとも徐々に鮮明になっていったのでしょうか？

catatsuy：いくつか起点となるミーティングがありました。例えば「1つのセグメントに対して1つの広告グループしか紐付かなくて良い」というような縛りを作る言葉が出てきたミーティングですね。

そういった縛りがなく”なんでもできる”という状態だと、「その機能をどのように管理画面上で提供すればいいのか？」「どの形式でデータベース上に保存すればいいのか？」「配信サーバー側には何の情報を渡せばいいのか？」などが決められなくなってしまいますし、工数も増え続けてしまいます。

これらを決めなければ仕様も決められなくなってしまうので、そういった”縛り”を引き出すような質問をたくさんしました。縛りがある程度できてくると、実装のイメージも鮮明になってきましたね。

実装のイメージをしていく上で留意した点はありますか？

catatsuy：話し合いがスムーズに進み、ふわっとした案が明確化されていく一方で、ミーティングの中では話題にあがらない「今の運用で困っていない広告枠」が存在すること、また配信を行っていることも踏まえ、どう扱うべきかを平行して考えていました。

仕様を変更しすぎると、pixiv側の変更の工数が大きくなりすぎることや、管理サーバーの移行作業の工数や手間が増えること、配信サーバーの切り替えの難易度が高くなるなど、様々な課題があります。そういったことがないように、今回の話し合いの中ではクローズアップされていない他の広告枠と共存させても破綻せずに、かつ移行の工数も大きくならないような仕様にできないかを考えていました。

セールスチームとのコミュニケーションについて

セールスチームとのコミュニケーションについて気をつけたことはありますか？普段使っている用語なども違い、苦労する面などありませんでしたか？

catatsuy：一般的に、専門分野が違うチームでの話し合いは上手くコミュニケーションが取れないという話を聞きます。確かに広告周りの用語、開発周りの用語はどちらも専門性が高く、思うようにコミュニケーションが取れなくなってしまうのも納得できます。ピクシブでは、セールスチームもエンジニア関連の知識をつける努力をしてくれているので、コミュニケーションはかなり取りやすいと思います。僕たちエンジニアも、広告に関する専門用語と出会った時には、検索して意味を調べたり、広告関連の本を読んだりして、日頃から知識のキャッチアップを行っています。

お互いのチームが歩み寄ってるんですね！

catatsuy：そうですね、かなり前から実践しています。

yousan：確かに、「開発側は◯◯がわかってくれない」とか「営業は技術について全然わかっていない」などの対立構造ができることも少なくない、と聞くこともありますが、このプロジェクトではそういったことが一切ありませんでした。
両チームがお互いに歩み寄っていて、先程のcatatsuyの話のように開発チームが広告の勉強をする一方で、セールスチームも技術的な事柄について勉強している。橋渡しの役割としてはすごくやりやすい環境でした。

セールスチームに対して、話し合いの時にもっとこうして欲しい！などの要望はありましたか？

catatsuy：特にありませんでした。開発側の人間であれば共感する人も多いと思うのですが、よく挙げられる困ることとして、「ある程度実装を行った後に仕様変更が加えられること」があります。今回は、事前にしっかりと要件定義を行えたことで、最初から最後まで仕様変更もなくスムーズに進めたと思っています。

シンプルな実装を徹底する

yousan：仕様変更が起こらなかったことに加えて、「不足する要件」と「余分な要件」のどちらもなかったことも非常に今回のプロジェクトがうまくいった理由だと思っています。「後々に必要になるのではないか？」と考えて本来不要な機能をつけてしまうこともよくあることですが、今回のプロジェクトではそういったものはほとんどありませんでした。

catatsuy：その点はかなり強く意識していました。「絶対に必要な機能以外は一切実装しない」という意識を強く持ち、少しでも必要かどうかを迷う機能に関しては、全て仕様から外していきました。リリース後に「こんな機能欲しかったね」という声もごく少数聞こえてはきましたが、そういうものは気にしない方針で進めていたので、しょうがないと割り切りました。

yousan：私は前職でも受託開発から自社サービスまでいろんな開発案件を見てきましたが、両チームがお互いに専門性の高い複雑なプロジェクトで、ここまで完璧な要件定義が行えたのは僕の経験上でもかなり珍しい経験でした。

catatsuy：正直、実際にリリースするまで相当怖かったんですけどね(笑)

実装する機能を最小限にする一方で、今後のスケール（機能追加など）についても考慮しながら実装したのでしょうか？

catatsuy：そうですね。シンプルな実装を徹底することで、「今後また広告サーバーの大きな改修があるだろう」という考えのもと、将来の拡張性を想定した実装にしています。

エンジニアの中には「YAGNI」という考え方があります。「You ain’t gonna need it」の略なのですが、つまり「機能は実際に必要になるまで追加しない方がいい」という考え方です。実装をシンプルにすることで、大改修をするときもスムーズに行えると想定しています。

以前の広告サーバーの中には、エンジニアが必要だろうと勝手に考えて追加したものの、全く使われていないコードがいくつか存在していました。今回の改修では、そのように使われていないコードの削除も同時に行い、必要最低限のコードにしました。

yousan：サーバー改修を行ってから2~3ヶ月たった今でも、いろいろな追加実装をする際に根本から実装を見直す必要が出てきていないのは、そういった実装方法のおかげですよね。

catatsuy：そうですね。実際に広告の配信対象を分けるためのセグメントは今後も増えると予想していてます。

実際の例として、イラストの投稿者と非投稿者を分けるセグメントの内容として、「投稿者」と「指定なし（投稿者と非投稿者の区別がない全体）」の2つに分けられれば良い。というものがあったのですが、今後「非投稿者」というセグメントの必要性も感じたため、DBへの保存形式をブーリアン型（true/false）ではなく整数型(1.2.3...)を採用しています。将来的にセールスチームが必要になりそうな機能への拡張性は常に考えています。

エンジニア自らコミュニケーションを取り、UIを改善する。

続いて管理画面のUI改善を行っていた、yasuに質問したいのですが、管理画面はセールスチームが操作することになるため、より多くの意見が寄せられたと思うのですが、齟齬が起こらないように気をつけたことはありますか？

yasu：広告サーバー側の仕様が確定した段階で、大枠のやるべきことは決まっていましたが、そもそもどういう画面が必要なのか決まっていませんでした。そのため、セールスチームが実際にどういう画面遷移をしながら広告の配信設定をするのかを気にしながら要件定義を行いました。

具体的にはどのように要件定義を進めていったんでしょうか？

yasu：手法としては、プロトタイピングツールを使用し実際の画面に近いものを見ながら、ミーティングを行いました。セールスチームに同席してもらいながら、どういう画面遷移をするか確認していきました。「必要なページに漏れはないか」、逆に「余分な画面遷移を行っていないか」など、UIの細かいところまで何度もミーティングを行いながら決めていきました。

どのミーティングも密度が高く疲れるものでしたが、チームをまたいで良いものを作ろうという意識を持って臨みました。

仕様やUIの変更によりセールスチームが行う既存の操作や設定方法も変わったかと思いますが、何か問題は起きましたか？

yasu：今回は、大幅な機能改修を行ったため、過去使用していた機能との互換性が無い機能が多数存在しました。セールスチームにあらかじめ「この機能は使えなくなります」と伝えていたので問題にはなりませんでした。

また、新しい管理画面へ完全移行する前に、古い機能と新しい機能が一時的に同居する時期を作り、混乱や問題が起こらないように注意しました。

セールスチームとのコミュニケーションについて

yousan： yasuは管理画面というセールスチームにより近い範囲を担当していることもあり、セールスチームとのコミュニケーションを多く取ってくれていました。例えば、セールスチームの朝会にも積極的に参加してくれていました。

yasu：かなり多くのミーティングを行ったので、そのスケジュール共有を頻繁に行いたいという意図がありました。実際に管理画面を使用しているセールスチームが何をしたいのかがわからないと実装ができないので、より簡単にコミュニケーションを取れるように出来る限り顔を出しておきたいという気持ちもありました。

そういったコミュニケーションの中で、開発に役立つ発見はありましたか？

yasu：コミュニケーションの流れで「操作を見せてほしい」と頼んだことがきっかけで、思いがけない発見がありました。管理画面の使い方については以前から何度も議論をしていたんですが、操作している様子を見せてもらった際に、私の想定している画面遷移と違うことに気づいたんです。それによりセールスチームがより使いやすい管理画面を作れたと思います。

このような軽いコミュニケーションの中で発見したものが重要な場合もあるので、朝会や日々のコミュニケーションは大事にしています。

yousan： yasuが自分からコミュニケーションを取りに来てくれるのはすごく助かりました。「説明してくれ」とか「連携してくれ」というように、情報を要求してしまうことも多くあると思うのですが、yasuが自ら情報を取りに来てくれたおかげでチームのコミュニケーションが円滑になったと思います。

yasu：実際の作業時は、各エンジニア個人が担当する範囲はきれいに分担されていて、重複するところもほとんどなかったので、特に苦労することなく進みました。

catatsuy：仕様が決まってからは、私からはエンジニアに「全体の仕様」、「それぞれの担当範囲」、「ファーストアクション」を伝えた上で「わからないことがあれば聞きに来てね。」というスタンスで担当範囲での作業に関しては各エンジニアに任せました。基本的に干渉せず、質問が来た時に答えていただけですね。

yasu：あとは、実際に作業する上で、catatsuyが仕様をまとめたドキュメントを作成してくれたことが非常に助かりました。ほとんどの作業がドキュメントを読めばわかるほど、わかりやすく書かれていて、設計図のように使用していました。もし仮にわからないところがあってもcatatsuyに質問すれば良いので、すごく作業しやすい環境でした。

ピクシブで開発する良さ

最後に今回のプロジェクトを通して、改めてピクシブで開発する良さを教えてください！

yousan：先ほどの話にもでてきましたが、ビジネス職とエンジニア職の距離が近い点だと思っています。隣の席で密にやり取りをして受託のような依頼という形ではなく一緒にプロダクトを作れるところは良い文化だと思います。

またその文化を活かして自らプロダクトをどうするべきかを考えられるエンジニアがいることも、ピクシブの強みだと考えています。

catatsuy：エンジニアとして色々学べる環境にあることと、あとはyousanと重なりますが、セールスチームとの距離が近いところだと思います。今回の改修では仕様策定から始まり、それをどうすれば現実的な工数で作れるのかを考えて、実際にそれを実装するというところまでの全部を担当することができました。もちろん求められる要求もそれだけ高くなりますが、問題無くリリースができて、セールスチームの運用が軌道に乗ったのを見届けられた時の達成感はすごかったです。

yasu：僕は、「自分の提案が通りやすいこと」だと思っています。セールスチームの朝会に参加すればもっと開発しやすくなるという提案もすぐに受け入れられ、参加させてもらえました。セールスチームと一緒に管理画面について考えるときも、開発チームの提案をベースにより良い画面を開発することができました。

開発チームとセールスチームのどちらも、より良いものを作ろうという意識が強く、良いものを作るためであれば先輩後輩関係なく誰の意見でも取り入れるところがピクシブでの開発の良いところですね。

セールスチームと開発チームが、同じチームの一員として一緒にプロジェクトを進められるのですね。良いプロダクトをつくりたい、という意思を叶えられる環境だと僕自身も感じます。それに、自分の提案が通るとモチベーションも上がりますよね。インタビュー、ありがとうございました！

今回ご紹介した「pixiv Audience Targeting Ads」を含む、各種広告のお問い合わせは
こちらから。

また、ピクシブでは一緒に働ける仲間を募集中です！