SmartNews Tech Night Vol.1の勉強会資料。 ScaleOutでの作るものの優先度の決め方とかリリース方法についてとか。

1. 広告プラットフォームの
開発(ScaleOutの場合)
SmartNews Tech Night Vol.1
ScaleOut 石橋稔章

2. 自己紹介
• 石橋 稔章(いしばし としあき)
• ScaleOut DSP/DMPのプロダクト責任者をしてい
ます。
• SSP(AdGeneration)のコアエンジン部分のPMも
してます。
• 趣味でスマホアプリ作り

3. SOを知らない人のために
*「ScaleOut Ad Platform」というエコシステムの
上に様々なプロダクトを構築している。
* ビジネス的には、DSP,DMPの販売がメイン。
* 最近、adgenがSO名義に変わったのでそちらも

4. ScaleOut Ad Platformとは
複数のXX DSP(非開示) AppBank SSP
ScaleOut
タグマネScaleOut Syn.ad
DMP
ScaleOut Ad Platform
ScaleOut
DSP
Ad Generation
(SSP)
配信エンジン, API
管理画面
APIで構築
OEM提供

5. 今日は、ScaleOutがどのよう
にプロダクトを開発している
か紹介します。

6. アジェンダ
何を作るかをどう決めているか
どういう風に作っているか
どうやってリリースしているか

7. アジェンダ
何を作るかをどう決めているか
どういう風に作っているか
どうやってリリースしているか

8. プロダクトのポリシー
みんなが幸せになることを優先する。
(特定のお客さん向けの開発もやるけどね)

9. 作るものの優先度の決め方
- 多くの人に喜ばれる機能が優先
- 会社として、力を入れる分野のものが優先
- 簡単に作れるものが優先
- 営業の要望でも本当に必要だと判断出来ない
ものはやらない。もしくは優先度低

10. メリットが大きいが、リスク
がある機能
- 大きなトラブルになる可能性があるので、
同時に複数やらない
→安全第一

11. 作るものの決め方
- 影響が大きいものは同時に複数やらない。
- 小回りが利かなくなるので、全員が期間が長く
かかるものを担当しないようにする。
- システム系のタスクも一定量やる。(ライブラリ
のversion up、ciの高速化、バッチや画面の高速
化、リファクタリングなど)

12. 作る時期への考え方
広告は途中で負荷対策や速度改善、予定外のより優
先した方がよさそうなものが発生する事が多い。
!
そのため、いつまでに何かを必ずやる的な目標はざっ
くりとしか立てない。
→月単位で何を作るかなど細かく決めたがる人
がいるが実際には難しいのでやらない。

13. お客さんからの要望について

14. 広告システムを作っていると
個別の相談が非常に多い。

15. 素直に全部受けてしまうとプロ
ダクト自体の開発より、個別案
件がメインになってしまう。

16. 結果的にプロダクトの競争力
がなくなってしまい、みんな
が不幸になる。

17. どうしているか

18. 1. サクッと作る
エンジニアが優秀なので、ちょっとした要望
ならサクッと作ってリリース。

19. 2. 実現方法を工夫する
時間がかかりそうなもの場合、あまり手間が
掛からず、要望を実現出来る方法を考える。

20. 3. よく要望が上がるものは汎
用的にしてある。
- データ連携
- コンバージョン連携
etc

21. 4. 断る
明らかに開発と運用に時間がかかって、かつ
プロダクト全体としてメリットがない場合は、
お断りする。

22. 広告のプロダクト開発では、
取捨選択を如何にするかと
どう実現するか
が非常に重要

23. プロデューサー採用の
こだわりについて

24. SOでは、どういう人材が担当
しているか
広告と技術が両方分かる人
例えば、git の特定のブランチからpullして、
デプロイ出来たり、hiveqlを投げて、ログを
自分で漁って調べごとが出来る人。
エンジニアとしても作業が出来る人。

25. 主な仕事
新しい機能を何をどう作るか考える
広告会社(sspとか)との連携
営業からの問い合わせ
→どれも広告と技術が分からないと効率が悪い

26. 広告は、技術との結びつきが強
いので、エンジニアドリブンで
プロダクトを作った方が効率が
いい。

27. アジェンダ
何を作るかをどう決めているか
どういう風に作っているか
どうやってリリースしているか

28. JIRAでチケットドリブン
画面系だとチケットの内容は結構ゆるふわで、
詳細部分はエンジニアにおまかせ。
!
例えば、タイトル「標準レポートのグラフをも
う少しいい感じにする」、詳細「なし」とか

29. なぜ「ゆるふわ」で大丈夫な
のか
一緒に働いている期間が長いことによる信頼感。(明ら
かに想定したものと違うとかがない)
!
画面系だと中途半端に細かく指定するより、作ってもら
いつつ、細かい部分は相談するくらいの方が効率がいい。

30. 画面のみで完結しないもの
担当者と相談しながら、ホワイトボードに書
いたりしながら詳細を詰める事が多い。

31. アジェンダ
何を作るかをどう決めているか
どういう風に作っているか
どうやってリリースしているか

32. ライバル企業が多いため、ス
ピード感を持って機能追加、
改善をしていく必要がある

33. 安定して稼働し続ける事が非
常に重要

34. アドシステムは、開発スピー
ドを兼ね備えつつ、安定して
いること必要がある

35. ではあるが、配信や集計など
ちょっとのミスで重大な問題
になりがち

36. ScaleOutのリリース種類
- hotfix
- クローズドリリース
- 定期リリース
- サーバ限定リリース

37. hotfix
- hotfixは、深刻な問題の修正を指すイメージがある
が、軽微なものや、ダッシュボードに変更がない追加・
変更は、頻繁にhotfixでリリースしている。
- 数回/dayくらい。
- ciが通っていないとデプロイ出来ない。

38. hipchatでci結果の通知

39. クローズドリリース
新しい配信ロジックやターゲティングの検証のために
利用者を限定して行うリリース。
hotfixでリリースして、徐々に適応範囲を拡大させる。
例. SOでテスト→特定の代理店の特定の案件でテスト
→特定の代理店にリリース→全代理店にリリース

40. organization role機能
特定の代理店のみに機能を解放するための機能
定義ファイルに以下のように定義する。
define_feature(:enable_monthly_budget)
!
viewで以下のような感じで表示を制御する。
if has_feature?(:enable_monthly_budget)
!
!
リリースが終わったら定義を :releasedにすると全解放される。
define_feature(:enable_monthly_budget, :released)

41. 定期リリース
2ヶ月に1回程度行っているリリース。画面に修正が入るも
のが中心。代理店などのお客さんに事前にリリース内容を
メールで連絡する。
!
クローズドリリースを全体に公開する場合は、このタイミ
ング。
リリース2週間前からcodefixしてリリースブランチには、
pushしない。
何かあると面倒なので、日曜日に行う。

42. サーバ限定リリース
主にadserverのリリース方法で、負荷や機能的に
問題がないかを確認するためにサーバの台数を
限定してリリースする。
1日様子をみて、問題がなければ全体に適応す
る。

43. 他社がどういう風にプロダクト
を作っているのか気になるので、
他の会社の方もどこかで発表
してくれると嬉しいなと。

44. おわりです。