Download as PDF, PPTX
Uploaded byToshiaki Ishibashi
広告プラットフォームの開発(ScaleOutの場合)
SmartNews Tech Night Vol.1の勉強会資料。 ScaleOutでの作るものの優先度の決め方とかリリース方法についてとか。
広告プラットフォームの開発(ScaleOutの場合)
- 1. 広告プラットフォームの 開発(ScaleOutの場合) SmartNewsTech Night Vol.1 ScaleOut 石橋稔章
- 2. 自己紹介 • 石橋稔章(いしばし としあき) • ScaleOut DSP/DMPのプロダクト責任者をしてい ます。 • SSP(AdGeneration)のコアエンジン部分のPMも してます。 • 趣味でスマホアプリ作り
- 3. SOを知らない人のために *「ScaleOut AdPlatform」というエコシステムの 上に様々なプロダクトを構築している。 * ビジネス的には、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.
- 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.
- 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.