Slide 1

Slide 1 text

まだレポーティング業務で 疲弊してるの? アドテクノロジーにおけるデータ活用の実態 近森淳平 @pei0804 CARTA HOLDINGS (旧VOYAGE GROUP) Zucks アドプロダクト事業本部

Slide 2

Slide 2 text

レポーティング業務、 手作業でエクセル作ってますか?

Slide 3

Slide 3 text

それやめましょう!が、 今日の話したいことです。

Slide 4

Slide 4 text

事業成長機会を増やしたいなら、 注力すべきは、レポーティング業務ではない。 ネクストアクションを生む分析。

Slide 5

Slide 5 text

今日はレポーティング業務の 倒し方とその実態についてお話します。

Slide 6

Slide 6 text

今日話さないこと ● テック寄りな話

Slide 7

Slide 7 text

アジェンダ 1. 自己紹介 2. レポーティング業務とは 3. 退屈なことはプログラムにやらせよう 4. 効率化した先の世界 5. まとめ

Slide 8

Slide 8 text

アジェンダ 1. 自己紹介 2. レポーティング業務とは 3. 退屈なことはプログラムにやらせよう 4. 効率化した先の世界 5. まとめ

Slide 9

Slide 9 text

自己紹介 ぺい @pei0804 近森淳平(チカモリ ジュンペイ) CARTA HOLDINGS (旧VOYAGE GROUP) Zucks アドプロダクト事業本部 エンジニア

Slide 10

Slide 10 text

What’s about CARTA HOLDINGS.

Slide 11

Slide 11 text

VOYAGE GROUP と CCI が経営統合し誕生しました 多くの事業・サービスを運営しています(下記は一部を抜粋) 2019年に経営統合 CARTA HOLDINGS

Slide 12

Slide 12 text

私たちは「進化」を生み出す。 変わろうとするすべての組織に。 知ってもらえずにいる商品たちに。 力を眠らせたままのあらゆる産業に。 よくする、だけでは足りない。 次のステージへのジャンプを起こす。 つながりえなかったものをつなぎ、 停滞していたものを動かす。 そんな進化を、あらゆる場所につくっていく。 そのためには、「多様な力」が必要だ。 違う才能がぶつかりあい、 自分だけでは想像もできなかった方法に 辿りつく必要がある。 だから私たちは、意志を持って、様々な人間が共存す る。 挑もうとする人と進化を起こすために。 私たちは進化推進業、 CARTA HOLDINGSです。 MISSION

Slide 13

Slide 13 text

https://engineering.cartaholdings.co.jp/

Slide 14

Slide 14 text

アジェンダ 1. 自己紹介 2. レポーティング業務とは 3. 退屈なことはプログラムにやらせよう 4. 効率化した先の世界 5. まとめ

Slide 15

Slide 15 text

レポーティング業務とは、 データを情報化する業務である。

Slide 16

Slide 16 text

そもそも、データとは?情報とは? 考えたことはありますか?

Slide 17

Slide 17 text

データとは 意味を成さない。(know-nothing)。 ただの記号(シンボル)や信号(シグナル)や事実(ファクト)。 例 ● 1,000人が洗濯機を購入した。 ● 3人が洗濯機を返品した。

Slide 18

Slide 18 text

情報とは 意味の成す。(know-what, description) 意思決定と行動に使える状態。目的で関連付けられたデータ。 例 ● 先週に購入された商品の売上金額を、種別かつ店舗ごとに出したい。

Slide 19

Slide 19 text

情報化は想像以上に大変(非エンジニア) 人の数だけ見たい情報がある。 情報出せる土壌が整っていない状態で、需要に応えようとすると、 労働集約的になることは、火を見るより明らか。 そして、この問題をさらに困難にするのは、レポーティング業務に 従事してる人は、往々にして非エンジニアであり、 全く効率化されないまま、運用でカバーされ続けることがよくある。 一方で、エンジニアは・・・

Slide 20

Slide 20 text

情報化は想像以上に大変(エンジニア) 運用でカバーでは、引き出せない情報が必要になった場合、 エンジニアが手を動かす必要が発生する。 多くの場合、場当たり的な対応が採用される。 それが、またカオスを生む。

Slide 21

Slide 21 text

レポーティング業務の辛い実例 ● 自分の興味関心を解決するレポート画面がないので、 お手製の重厚長大なエクセルを作成する。 そこに入力する値はもちろん手作業のコピペ。 ○ システムの都合でレポートに1列を追加するのが、かなり大変。 追加出来ればいいけど、大体は運用でカバーすることになる。 ● レポートって名前で、実は信用できない参考値が出ている。 ● 色んな値を見るために、様々な画面へ遷移しなければならない。 ● 裏側の仕組みも大体辛いことになっている。

Slide 22

Slide 22 text

小さな辛みが積み重なって、 膨大な時間を失う。

Slide 23

Slide 23 text

大変で、退屈。 それがレポーティング業務。

Slide 24

Slide 24 text

退屈なことは、 プログラムにやらせよう。

Slide 25

Slide 25 text

アジェンダ 1. 自己紹介 2. レポーティング業務とは 3. 退屈なことはプログラムにやらせよう 4. 効率化した先の世界 5. まとめ

Slide 26

Slide 26 text

安心してください。 AIってやつでどうにかなりません。

Slide 27

Slide 27 text

レポーティング業務は!!!終わらねェ!!! レポーティング業務は、絶対になくならない。 そして、それを遂行したとしても、特に付加価値はない。 例えば、「広告が表示された」が可視化されることに、感動する人居ない。 何故なら出来て当たり前だから。どうせ同じことをやるなら、楽しよう。 レポーティング業務は、扱っているビジネスによって十人十色。 これさえやればなんとかなるというものはない。

Slide 28

Slide 28 text

真っ直ぐに仕事に向き合う。 それしかない。

Slide 29

Slide 29 text

レポーティング in 弊社

Slide 30

Slide 30 text

時は、2021年

Slide 31

Slide 31 text

Zucksは、レポーティング業務の温かみに包まれた。数値 は揃わない。運用でカバー。終わらないバッチ。人類は半 ば諦めていたように見えた。 だが・・・ ※温かみは、弊社では手作業が必要な業務のことを指す。

Slide 32

Slide 32 text

色々頑張った結果、 関心事が決まり、簡単なSQLが書ければ、 情報は引き出せるようになった。 ※SQLはデータベースからデータを取ってくる時に使う言語です。

Slide 33

Slide 33 text

過去発表紹介 過去に発表したものにまとめているので、 興味あればどうぞ。 https://speakerdeck.com/pei0804/hokufalsekankaeruzui-gao-false rehoteinkuji-pan-at-awsdeshi-jian-analytics-modernization

Slide 34

Slide 34 text

全てのレポーティング業務が 効率化したかのように見えた。 だが、レポーティング業務は、 効率化していなかった。

Slide 35

Slide 35 text

再掲 情報化は想像以上に大変(非エンジニア) 人の数だけ見たい情報がある。 情報出せる土壌が整っていない状態で、需要に応えようとすると、 労働集約的になることは、火を見るより明らか。 そして、この問題をさらに困難にするのは、レポーティング業務に 従事してる人は、往々にして非エンジニアであり、 全く効率化されないまま、運用でカバーされ続けることがよくある。 一方で、エンジニアは・・・

Slide 36

Slide 36 text

クエリが書ければ、情報引けるではだめ。 万人がSQLを書けるわけではない。

Slide 37

Slide 37 text

SQLが書けなくても、関心事だけ決まれば、 情報を引き出せるを便利な画面が必要。

Slide 38

Slide 38 text

そもそも関心事とは何か? レポーティングに何を期待しているのか?

Slide 39

Slide 39 text

弊社におけるレポーティング業務とは ZucksのDSP(Demand Side Platform)の広告レポートを提供する。 例えば、以下のようなものが見れることが期待されている。 ● 「昨日、何回広告表示されましたか?」 ● 「今月の広告掲載費用は?」 ※今日は詳しいアドテクの話をしません。

Slide 40

Slide 40 text

弊社におけるレポーティング業務とは ZucksのDSP(Demand Side Platform)の広告レポートを提供する。 例えば、以下のようなものが見れることが期待されている。 ● 「昨日、何回広告表示されましたか?」 ● 「今月の広告掲載費用は?」 ※今日は詳しいアドテクの話をしません。 残念ながら、現実はこんなシンプルではない。

Slide 41

Slide 41 text

レポーティングだけでも、 そのユースケースは多岐にわたる。

Slide 42

Slide 42 text

ヒアリングしていくと、 共通点があることがわかった。

Slide 43

Slide 43 text

関心事を連続して観測する。

Slide 44

Slide 44 text

つまり、定点観測。

Slide 45

Slide 45 text

定点観測とは 1. ある一定の地点で、気温や気圧、降水量などの気象要素を連続して観測 すること。「定点観測カメラ」 2. 変化のある事象について、一定期間、観察や調査を続けること。「家電の 価格の定点観測」 引用:コトバンク

Slide 46

Slide 46 text

もっと掘り下げていくと 2種類の定点観測に分類出来た。

Slide 47

Slide 47 text

● DSPにおいて重要なKPIを監視したい。 ○ 異常があればすぐ気づきたい。 ● 役割ごとの関心事で実績を見返したい。 ○ 広告の運用者なら、細かい粒度で見たい。 ○ マネージャークラスなら、俯瞰して見たい。 ○ 社外の人から求められる場合もある。 2種類の定点観測

Slide 48

Slide 48 text

それぞれに求められていることは、 全く違うこともわかった。

Slide 49

Slide 49 text

● DSPにおいて重要なKPIを監視したい。 ○ 異常があればすぐ気づきたい。 ● 役割ごとの関心事で実績を見返したい。 ○ 広告の運用者なら、細かい粒度で見たい。 ○ マネージャークラスなら、俯瞰して見たい。 ○ 社外の人から求められる場合もある。 2種類の定点観測 リアルタイム性が重要 柔軟性が重要

Slide 50

Slide 50 text

無数のユースケースに見えた レポーティング業務も、 2種類に収まることがわかった。

Slide 51

Slide 51 text

難しく見える課題も掘り下げていけば、 実は簡単なことがある。

Slide 52

Slide 52 text

解決したいことを言語化しよう。

Slide 53

Slide 53 text

実装したもの ● 定形レポート(Fixed format report) DSPで重要なKPI監視に使う。 ○ フォーマットは固定。 ○ データの発生から数秒で実績が反映される。 ● カスタムレポート(Custom report) 利用者の関心事に合わせて情報を引ける。 ○ フォーマットは自由(軸、指標を切り替えできる)。 ○ データの発生から約1時間で反映される。

Slide 54

Slide 54 text

実装したもの ラムダアーキテクチャで実装した。それぞれの構成は以下の通り。 ● 定形レポート(Fixed format report) ○ ソースは、RedshiftとElastiCache for Redisをマージしたもの。 ○ 数秒で反映される。Redisの値は直近1時間のみ使う。 それ以降はRedshiftの値のみを参照する。 ● カスタムレポート(Custom report) ○ ソースは、Redshift。 ○ 約1時間に1回集計される。

Slide 55

Slide 55 text

No content

Slide 56

Slide 56 text

そもそも、なぜ、AWSで作るのか。

Slide 57

Slide 57 text

なぜAWSで作ったか ● インフラを気にせず開発が出来るフルマネージドサービスの サービスレベルが高いため、作り始めの負荷が軽減されるのと、 その後の運用面で楽が出来る。 そのため少人数のエンジニアで十分運用が可能。 ● AWSのサポートが手厚い。例えば、今回紹介した基盤を作る時に、 元々持っていた基盤のレビュー、新しく採用を考えている サービスのレクチャーなど、本当に手厚いサポートが受けられる。 ※弊社のサポートプランはエンタープライズ

Slide 58

Slide 58 text

なぜAWSで作ったか 欲しいと思っていた所に、新しいソリューションが出てくる。 例えば、最近だとKinesis Data StreamとRedshiftの連携。 今回紹介したスピードレイヤー部分を、丸ごとに新機能で 置き換えれるとかが、普通に起きるのがAWS。

Slide 59

Slide 59 text

アイデアさえあれば、 あとは実行するだけになるのがAWS。

Slide 60

Slide 60 text

だから、私はAWS。

Slide 61

Slide 61 text

こうして関心事に対して、 そこそこ簡単に、 情報が取れる世界になった。 ※もちろん、まだまだ効率化の余地はある

Slide 62

Slide 62 text

そして、時間が生まれる。

Slide 63

Slide 63 text

アジェンダ 1. 自己紹介 2. レポーティング業務とは 3. 退屈なことはプログラムにやらせよう 4. 効率化した先の世界 5. まとめ

Slide 64

Slide 64 text

レポーティング業務が改善され、 生まれた空き時間で人々はどうなる?

Slide 65

Slide 65 text

さて、昨日のレポート見るか。 あれ?ここなんでこうなってるんだろ。 もうちょい掘り下げて調べたいな。 つまり、 分析 をしたくなる。

Slide 66

Slide 66 text

分析とは、能動的な業務である。

Slide 67

Slide 67 text

分析とは何か?

Slide 68

Slide 68 text

分析とは レポーティングは、生データを情報に変える。 そして、それらは決められた形(Push型情報)で、ユーザーに提供される。 一方で分析は、レポーティングの結果を見た上で、何が起きているか?を 知りたいことがある。そこで、情報にアクセスすることで(Pull型情報)、 状況を把握するのが分析になる。

Slide 69

Slide 69 text

分析はレポーティングなくして成立しない。 分析は、レポーティングあってこそ。 レポーティングがまともに回ってないと、分析に辿りつかない。 身近なところで例えると、家計改善しよう!となって、 家計の収支把握せずに、改善なんて出来ない。 収支把握して、ようやく改善計画が立案可能になる。

Slide 70

Slide 70 text

レポーティング業務が効率化された世界 レポーティング業務 レポートを確認する 分析 何が起きているか調べる ネクストアクション 新しい施策を実行する

Slide 71

Slide 71 text

レポーティング業務が効率化された世界 レポーティング業務 レポートを確認する 分析 何が起きているか調べる ネクストアクション 新しい施策を実行する 現状把握がすぐ終わる。 色々調べたくなるので、 分析需要が高まる。

Slide 72

Slide 72 text

レポーティング業務が効率化された世界 レポーティング業務 レポートを確認する 分析 何が起きているか調べる ネクストアクション 新しい施策を実行する 分析が進む。 新しい施策が どんどん試される。

Slide 73

Slide 73 text

分析から、新しい行動は生まれる。

Slide 74

Slide 74 text

アジェンダ 1. 自己紹介 2. レポーティング業務とは 3. 退屈なことはプログラムにやらせよう 4. 効率化した先の世界 5. まとめ

Slide 75

Slide 75 text

とにかくレポーティング業務から、 人々を解放しよう。

Slide 76

Slide 76 text

分析がスムーズに進むと、 ネクストアクションも生まれやすくなる。 つまり、事業成長機会が増える。

Slide 77

Slide 77 text

レポーティング業務は、 出来て当たり前で、新たな価値を生まない。 新たな価値を生むのは分析である。

Slide 78

Slide 78 text

まだレポーティング業務で疲弊してるの?