データを武器に変える！エンジニアによるデータ活⽤のススメ

■タイトル⾃⼰紹介：⽥宮 直⼈

■タイトル⾃⼰紹介：⽥宮 直⼈Amazon検索「SQL」「ビッグデータ」両⽅のワードで表⽰順1位獲得！

Amazonカテゴリ1位獲得！「情報学・情報科学」「データベース処理」

新着ランキング、欲しいものランキングでも1位を獲得！

■タイトル

前置き

■タイトル

データ活⽤・分析の種類と成果

基礎分析

・推移の把握・内訳の把握・遷移の把握

問題解決

・離脱率改善・再訪率改善・EFO

価値の創造

・検索改善・レコメンド・ターゲティング

仕事で関わってきたこと、世の中のデータ活⽤の事例を⼤まかに3つのカテゴリ・フェーズに分けてみました。

■タイトル

分析の現場での作業の流れ

基礎分析 問題解決 価値の創造

売上⽬標が達成するかどうか、レポート作成し、経過を観察する

⽬標の不⾜分をどう補うか検討する

会社・組織のプレゼンスを⾼める

離脱率が⾼いページを集計する

ヒートマップやスクロール量を計測し、どこで離脱するか確認する

離脱しないよう、オススメ記事モジュールを設置する

オススメ記事モジュールがあまりクリックされない

記事も⼤量、多様化し、⼿動での管理ではなく、データから⾃動化、効率化を推進する

レコメンドする仕組みを作成し、ユーザーの潜在的ニーズを発掘する

検索結果⼀覧からの詳細画⾯遷移率が低い

⼈気のない商品が上位に表⽰されていることが判明

ランキングの並び順を様々なアルゴリズム、評価指標を⽤いて改善する

■タイトル

データ活⽤・分析の種類と成果

ディレクターの範囲

エンジニアの範囲

基礎分析

・推移の把握・内訳の把握・遷移の把握

問題解決

・離脱率改善・再訪率改善・EFO

価値の創造

・検索改善・レコメンド・ターゲティング

■タイトル

標準的なディレクターのお仕事・スキル• 関係各所の調整• 適切なサイト導線、UI/UXの設計• レポートを作成し、仮説を⽴てて、施策を検討する• 法令に従った運営指⽰

→景表法、個⼈情報保護法、特定電⼦メール法etc...

データまわりについて

ツールからデータは抜ける どんなデータがあれば分析できるか検討は付く

レコメンド、ターゲティングをやりたい

SQLはわからない そのデータを集めることが出来るかわからない どうやってやるのか曖昧…

■タイトル

データ活⽤・分析の種類と成果

ディレクターの範囲

エンジニアの範囲

基礎分析

・推移の把握・内訳の把握・遷移の把握

問題解決

・離脱率改善・再訪率改善・EFO

価値の創造

・検索改善・レコメンド・ターゲティング

ゴールに近いところにいるのはエンジニア

どのようにやればよいかゴールが⾒えているのも

エンジニア

■タイトル

ゴールに近いのはエンジニアどのようにやればよいか⾒えているのもエンジニア

データ活⽤を推進するには、エンジニアが必要不可⽋

必要不可⽋と⾔うよりも、エンジニアが主導して、データ活⽤を推進するべきでは？

と⾔うことで、みなさんの⽇頃のお仕事に【ちょい⾜し】できるデータ分析をご紹介します。

■タイトル

本編

メルマガ / Push配信システム 検索システム

⾏動ログ 購⼊データ

商品データ会員データ

保有するデータ

各種API

サービスを⽀えるシステム

既存システムの⾼精度化、⾃動化を推進する

ユーザーの状態・趣味嗜好に基づいた情報の出し分けをする

⾏動、トレンドの変化を数値化・可視化し、より旬な情報を届ける

データ活⽤の⽬的・効果

効果のあるユーザーに 適切なタイミングで ユーザーの求める情報を

商品探している 検索語句を間違って⼊⼒

まだ買っていない

それでもヒットする

商品をカゴに追加した 割引きクーポンを送る

しばらく使ってなければお得意様が メールで嗜好にあう情報を

抱える問題点

⼀律同じ対応

ユーザー毎に趣味嗜好や状態が異なるが、どのように分類すればいいかわからない

⼈⼿による限界

⼈⼿による運⽤が存在し、何パターンもデータを準備できない

サービス運⽤におけるアクターと改善までのストーリー

■タイトル

セグメント・ターゲティング

変化・状態の可視化

⾃動化・⾼精度化

■タイトル

セグメント・ターゲティング

変化・状態の可視化

⾃動化・⾼精度化

■タイトル

セグメント・ターゲティング

デシル分析

RFM分析

■タイトル

セグメント・ターゲティング

デシル分析

RFM分析

■タイトル

デシル分析

ユーザーを10段階に分割して、重要度を分割する（デシル分析の「デシ」は1/10を表す）

⼿順：ユーザーを購⼊⾦額の多い順に並び替える上位10%ずつ、デシル1〜デシル10のグループに割り当てる

→ntileウィンドウ関数を使⽤

■配信対象者

売上集計期間

〜

配信対象者

デシル1デシル2デシル3デシル4デシル5

デシル6デシル7デシル8デシル9デシル10

確認画⾯へ

配信ツール

■タイトル

デシル分析

ビッグデータ分析・活⽤のためのSQLレシピChapter5-1-6 (P.155）

session | user_id | action | category | products | amount | stamp---------+---------+----------+----------+-----------+--------+---------------------989004ea | U001 | view | | | | 2016-11-03 18:00:00989004ea | U001 | favorite | drama | D001 | | 2016-11-03 18:05:31989004ea | U001 | add_cart | drama | D001 | | 2016-11-03 18:07:34989004ea | U001 | add_cart | drama | D002 | | 2016-11-03 18:09:51989004ea | U001 | purchase | drama | D001,D002 | 2000 | 2016-11-03 18:19:09989004ea | U001 | review | drama | D003 | | 2016-11-03 18:23:09762afcd3 | | view | | | | 2016-11-03 18:31:29

■タイトルWITHuser_purchase_amount AS (

SELECTuser_id

, SUM(amount) AS purchase_amountFROM

action_logWHERE

action = 'purchase'GROUP BY

user_id), users_with_decile AS (

SELECTuser_id

, purchase_amount, ntile(10) OVER (ORDER BY purchase_amount DESC) AS decile

FROMuser_purchase_amount

)SELECT *FROM users_with_decile;

user_id | purchase_amount | decile---------+-----------------+--------U019 | 17800 | 1U006 | 16700 | 1U013 | 15700 | 1U021 | 14700 | 2U029 | 14600 | 2U004 | 14400 | 2

■タイトル

セグメント・ターゲティング

デシル分析

RFM分析

■タイトル

RFM分析

Recency：最新購⼊⽇最近購⼊に⾄ったユーザーほど優良顧客として扱う

Frequency：購⼊回数ユーザーが購⼊した回数をカウントし、回数が多いユーザーほど優良顧客として扱う

Monetary：購⼊⾦額合計ユーザーの購⼊⾦額の合計を集計し、⾦額が多いユーザーほど優良顧客として扱う

下記の3つの指標をもとにユーザーをグループ化する

ランク R:最新購⼊⽇ F:累計購⼊回数 M:累計購⼊⾦額

5 14⽇以内 20回以上 30万円以上

4 28⽇以内 10回以上 10万円以上

3 60⽇以内 5回以上 3万円以上

2 90⽇以内 2回以上 5000円以上

1 91⽇以上 1回のみ 5000円未満

デシル分析 RFM分析デシル１

過去に1回⾼級時計(30万）を買った（⼀度きり）

毎週、毎⽉、ちょくちょく買い物して30万円使った

同じように扱われてしまう

Monetary

過去に1回⾼級時計(30万）を買った（⼀度きり）

毎週、毎⽉、ちょくちょく買い物して30万円使った

Frequency

過去に1回⾼級時計(30万）を買った（⼀度きり）

毎週、毎⽉、ちょくちょく買い物して30万円使った

■タイトルRFMを3次元で捉える RFMを1次元で捉える

RFMを2次元で捉える

WITHpurchase_log AS (SELECT

user_id, amount, substring(stamp, 1, 10) AS dt

FROMaction_log

WHEREaction = 'purchase'

), user_rfm AS (SELECT

user_id, MAX(dt) AS recent_date, CURRENT_DATE - MAX(dt::date) AS recency -- ミドルウェアによっては、DATE_DIFF / DATEDIFF関数を⽤いる, COUNT(dt) AS frequency, SUM(amount) AS monetary

FROMpurchase_log

GROUP BYuser_id

)SELECT *FROMuser_rfm

;

user_id | recent_date | recency | frequency | monetary--------+-------------+---------+-----------+----------U040 | 2016-12-03 | 2 | 7 | 22340U140 | 2016-11-23 | 12 | 11 | 27640U128 | 2016-11-23 | 12 | 6 | 18550U203 | 2016-11-06 | 29 | 3 | 10430U058 | 2016-12-03 | 2 | 2 | 2970U144 | 2016-10-31 | 35 | 5 | 13360U213 | 2016-11-29 | 6 | 4 | 15300U014 | 2016-11-03 | 32 | 6 | 17160U154 | 2016-10-25 | 41 | 6 | 15230U120 | 2016-10-31 | 35 | 4 | 10020U251 | 2016-10-06 | 60 | 2 | 6580

ビッグデータ分析・活⽤のためのSQLレシピChapter5-1-7 (P.159）

WITHuser_rfm AS ( 省略 ), user_rfm_rank AS (SELECT

user_id, recent_date, recency, frequency, monetary, CASE

WHEN recency < 14 THEN 5WHEN recency < 28 THEN 4WHEN recency < 60 THEN 3WHEN recency < 90 THEN 2ELSE 1

END AS r, CASE

WHEN 20 <= frequency THEN 5WHEN 10 <= frequency THEN 4WHEN 5 <= frequency THEN 3WHEN 2 <= frequency THEN 2WHEN 1 = frequency THEN 1

END AS f, CASE

WHEN 300000 <= monetary THEN 5WHEN 100000 <= monetary THEN 4WHEN 30000 <= monetary THEN 3WHEN 5000 <= monetary THEN 2ELSE 1

END AS mFROM

user_rfm)SELECT * FROM user_rfm_rank;

user_id | recent_date | recency | frequency | monetary | r | f | m--------+-------------+---------+-----------+----------+---+---+--U040 | 2016-12-03 | 2 | 7 | 22340 | 5 | 3 | 2U140 | 2016-11-23 | 12 | 11 | 27640 | 5 | 4 | 2U128 | 2016-11-23 | 12 | 6 | 18550 | 5 | 3 | 2U203 | 2016-11-06 | 29 | 3 | 10430 | 3 | 2 | 2U058 | 2016-12-03 | 2 | 2 | 2970 | 5 | 2 | 1U144 | 2016-10-31 | 35 | 5 | 13360 | 3 | 3 | 2U213 | 2016-11-29 | 6 | 4 | 15300 | 5 | 2 | 2U014 | 2016-11-03 | 32 | 6 | 17160 | 3 | 3 | 2U154 | 2016-10-25 | 41 | 6 | 15230 | 3 | 3 | 2U120 | 2016-10-31 | 35 | 4 | 10020 | 3 | 2 | 2U251 | 2016-10-06 | 60 | 2 | 6580 | 2 | 2 | 2U043 | 2016-11-22 | 13 | 2 | 3200 | 5 | 2 | 1U129 | 2016-09-21 | 75 | 2 | 8830 | 2 | 2 | 2U057 | 2016-11-22 | 13 | 6 | 22480 | 5 | 3 | 2U085 | 2016-11-13 | 22 | 6 | 15660 | 4 | 3 | 2U290 | 2016-09-20 | 76 | 2 | 8490 | 2 | 2 | 2

■タイトル

セグメント・ターゲティング

デシル分析

RFM分析

データからセグメントを定義して、対応を変える⼿法を⽤いれば、マーケティングオートメーション系の施策の⼀つとして軸になり得ると考える。

■タイトル

セグメント・ターゲティング

変化・状態の察知

⾃動化・⾼精度化

■タイトル

変化・状態の察知

ある時点の状態or

あるアクション

良い状況に変化した

悪い状況に変化したor 変化しなかった

・売上が伸びてる商品→注⽬する

・離脱した、継続しなかった→回復を狙う

■タイトル

変化・状態の察知

ファンチャート

カゴ落ちユーザー

■タイトル

■タイトル

オススメ枠に何を表⽰するか⼈気ランキング 新着情報

急上昇 レコメンド

⼈⼿ ◯

⼈⼿ ×

⼈⼿ △集計 楽

集計 ？

集計 楽

⼈⼿ × 集計 ？

■タイトル

変化・状態の察知

ファンチャート

ある基準となる時点を100%とし、以降の数値の変動を⾒るグラフ

⾦額の少ない項⽬は変化を読み取りにくい 成⻑・衰退が捉えやすい

売上推移 ファンチャート

WITHmonthly_category_amount AS (SELECT

concat(year, '-', month) AS year_month, category, SUM(amount) AS amount

FROMdaily_category_amount

GROUP BYyear, month, category

)SELECT

year_month, category, amount, FIRST_VALUE(amount)

OVER(PARTITION BY category ORDER BY year_month, category ROWS UNBOUNDED PRECEDING)AS base_amount

, 100.0* amount/ FIRST_VALUE(amount)

OVER(PARTITION BY category ORDER BY year_month, category ROWS UNBOUNDED PRECEDING)AS rate

FROMmonthly_category_amount

ORDER BYyear_month, category

;

year_month | category | amount | base_amount | rate-----------+---------------+--------+-------------+--------2014-01 | ladys_fashion | 263945 | 263945 | 100.002014-01 | mens_fashion | 349012 | 349012 | 100.002014-01 | book | 135020 | 135020 | 100.002014-01 | game | 213263 | 213263 | 100.002014-02 | ladys_fashion | 404849 | 263945 | 153.382014-02 | mens_fashion | 188667 | 349012 | 54.052014-02 | book | 143322 | 135020 | 106.142014-02 | game | 197948 | 213263 | 92.812014-03 | ladys_fashion | 386651 | 263945 | 146.482014-03 | mens_fashion | 263634 | 349012 | 75.532014-03 | book | 214231 | 135020 | 158.662014-03 | game | 191777 | 213263 | 89.92

ビッグデータ分析・活⽤のためのSQLレシピChapter4-2-3 (P.119）

■タイトル

カゴ落ちユーザー

ビッグデータ分析・活⽤のためのSQLレシピChapter5-3-2 (P.233）

スライド上ではクエリが⻑いので省略とさせていただきます。

■タイトル

変化・状態の察知

ファンチャート

カゴ落ちユーザー

変化・状態を察知できる状態を作ることで、旬な情報を届けることが出来たり、ユーザーの状況に応じた施策が検討可能になる

■タイトル

セグメント・ターゲティング

変化・状態の可視化

⾃動化・⾼精度化

■タイトル

⾃動化・⾼精度化

検索システムの⾼精度化

レコメンドの⾼精度化

システムの改善はエンジニアしか出来ない！

■タイトル

⾃動化・⾼精度化

検索システムの⾼精度化

レコメンドの⾼精度化

■タイトル

検索システム

商品DB 検索エンジン

同義語辞書

ユーザー辞書

AQUOS ＝ アクオスバイト ＝ アルバイト

激おこぷんぷん丸ビルゲイツ

■タイトル

検索におけるユーザー⾏動

検索ワードに検索エンジン最適化のヒントがある

・絞り込みドラゴンボール → ドラゴンボールZ

→並び順の最適化

・異なる語句マトリックス２ → マトリックス・リローデッド

→同義語辞書に追加

・離脱ワード / 検索結果0件→異なる語句、検索結果0件のワードから

同義語辞書・ユーザー辞書への追加可能なものがあれば、対応する

■タイトル

検索結果0件の時の検索ワードは？

検索結果から離脱した時の検索ワードは？

再検索した時、何から何に検索ワードを変えたのか

検索結果が0件だったから変えたのか

前の検索ワードから、条件を追加して変えたのか

前の検索ワードから全く違うワードを⼊れたのか

この辺のワードが集計出来れば、同義語辞書、ユーザー辞書、サジェスト等に活かせられるのではないか

再検索ワードってどう取得するの？

■タイトル

LAG、LEAD関数product_id | category | score

------------+----------+-------A001 | action | 94A002 | action | 81A003 | action | 78A004 | action | 64D001 | drama | 90D002 | drama | 82D003 | drama | 78D004 | drama | 58

product_id | score | lag1 | lag2 | lead1 | lead2------------+-------+------+------+-------+-------A001 | 94 | | | D001 | D002D001 | 90 | A001 | | D002 | A002D002 | 82 | D001 | A001 | A002 | A003A002 | 81 | D002 | D001 | A003 | D003A003 | 78 | A002 | D002 | D003 | A004D003 | 78 | A003 | A002 | A004 | D004A004 | 64 | D003 | A003 | D004 |D004 | 58 | A004 | D003 | |

SELECTproduct_id

, score-- 現在の行より前の行の値を取得する

, LAG(product_id) OVER(ORDER BY score DESC) AS lag1, LAG(product_id, 2) OVER(ORDER BY score DESC) AS lag2

-- 現在の行より後の行の値を取得する, LEAD(product_id) OVER(ORDER BY score DESC) AS lead1, LEAD(product_id, 2) OVER(ORDER BY score DESC) AS lead2

FROM productsORDER BY score

ビッグデータ分析・活⽤のためのSQLレシピChapter3-3-2 (P.61）

■タイトル

ビッグデータ分析・活⽤のためのSQLレシピChapter8-1 (P.368〜）

スライド上ではクエリが⻑いので省略とさせていただきます。

■タイトル

⾃動化・⾼精度化

検索システムの⾼精度化

レコメンドの⾼精度化

■タイトル

レコメンドシステム

モジュール 内容 表⽰例

リマインド ユーザーの過去の⾏動から、再度アイテムを提案する

・最近⾒た商品・もう⼀度買う

ランキング 閲覧数、購⼊数等に基づき、⼈気のあるアイテムを提案する

・⼈気ランキング・急上昇ランキング

コンテンツベース アイテムに付属する情報を元に、別のアイテムを提案する

・この俳優が出演している他の作品

レコメンド サービスを利⽤するユーザー全体の⾏動履歴から、次に⾒るアイテム、関連するアイテムを推測し、提案する

・この商品を⾒ている⼈はこんな商品も⾒ています。

パーソナライズレコメンド

ユーザー個⼈の⾏動履歴から趣味嗜好を推測し、興味のありそうなアイテムを提案する

・あなたへのオススメ

■タイトル

レコメンドに関する記事を⾒てみると…

U001 U002 U003 U004 U005

P001 1 1 1 0 0

P002 1 1 0 0 0

P003 1 1 0 0 0

P004 1 0 0 0 1

P005 0 1 1 1 0

データのイメージ

RDBで扱う形式と異なるので、直感的に

理解できない⼈はいませんか？

（僕はそうでした）

DB上でのイメージ商品ID ユーザーID 値

P001 U001 1

P001 U002 1

P001 U003 1

P002 U001 1

P002 U002 1

P003 U001 1

... ... ...

こんな形で保存されているイメージが頭の中で描ければ、⼤丈夫！

２つのベクトルのなす⾓→コサイン類似度

コサイン類似度-1 <= 0 <= 1となる値を取る。1に近づけば近づく程、正の相関がある

商品A

商品B

1

1

cos 𝜃

商品C

アイテム同⼠の関連を導くためには

■タイトル

数式を⾒てみると…

cos 𝜃 =𝐴 ( 𝐵𝐴 |𝐵|

⾼校で数Ⅱまでしかやっていないから多分習ってない…。⾒たことない…。おぇぇぇ…

𝐴 商品Aに関して、ユーザーA、ユーザーB、ユーザーCの値

B 商品Bに関して、ユーザーA、ユーザーB、ユーザーCの値

|𝐴|

0 1 0

1 1 0

商品Aに関して、ユーザーA、ユーザーB、ユーザーCの値をそれぞれ⼆乗して、全部⾜して、ルートをかぶせる

0 1 0

0- + 1- + 0-�

𝐴 ( 𝐵

分⺟

分⼦

𝑎2×𝑏2＋𝑎-×𝑏- …+𝑎6×𝑏6(0×1) + (1×1） + （0×0）

商品AとBの関係を各ユーザーの値から導く

U001 U002 U003 U004 U005P001 1 1 1 0 0

P002 1 1 0 0 0

P003 1 1 0 0 0

P004 1 0 0 0 1

P005 0 1 1 1 0

P001とP003の相関係数は？

cos 𝜃 =𝐴 ( 𝐵𝐴 |𝐵|

cos 𝜃 =1×1 + 1×1 + 1×0 + 0×0 + (0×0)1×1 + 1×1 + 1×1� × 1×1 + 1×1�

cos 𝜃 =2

3� × 2� 0.8164... 出来た！！！！

■タイトル

実はもう少し計算を楽にすることが出来る

cos 𝜃 =𝐴 ( 𝐵𝐴 |𝐵|

cos 𝜃 = 𝐴 ÷ 𝐴 × 𝐵 ÷ 𝐵

cos 𝜃 = <<

× ==

■タイトル

U001 U002 U003 U004 U005P001 1 1 1 0 0P002 1 1 0 0 0P003 1 1 0 0 0P004 1 0 0 0 1P005 0 1 1 1 0

item_id user_id scoreP001 U001 1P001 U002 1P001 U003 1P002 U001 1P002 U002 1P003 U001 1... ... ...

データのイメージ

DB上でのイメージ

1×1 + 1×1 + 1×1�

𝐴 scoreA SQRT(SUM(score * score) OVER(PATITION BY item_id))

item_id user_id score calc1 calc2P001 U001 1 √3 1/√3P001 U002 1 √3 1/√3P001 U003 1 √3 1/√3P002 U001 1 √2 1/√2P002 U002 1 √2 1/√2P003 U001 1 √2 1/√2... ... ...

cos 𝜃 = 𝐴 ÷ 𝐴 × 𝐵 ÷ 𝐵

■タイトル

item_id user_id score calc1 calc2P001 U001 1 √3 1/√3P001 U002 1 √3 1/√3P001 U003 1 √3 1/√3P002 U001 1 √2 1/√2P002 U002 1 √2 1/√2P003 U001 1 √2 1/√2... ... ...

商品A→商品Bとの相関、商品A→Cとの相関 ....商品B→商品Cとの相関…と⾔うように、全商品の組み合わせを作ってレコメンドリストを作りたい

SELECTuser_id,t1.item_id,t1.calc2,t2.item_id,t2.calc2,

FROM左記表 t1

JOIN左記表 t2

ON t1.user_id = t2.user_id）

WHEREt1.item_id <> t2.item_iduser_id t1.item_id t1.calc2 t2.item_id t2.calc2

U001 P001 1/√3 P002 1/√2U001 P001 1/√3 P003 1/√2U001 P001 1/√3 P004 1/√2U001 P002 1/√2 P001 1/√3U001 P002 1/√2 P003 1/√2U001 P002 1/√2 P004 1/√2... ... ... ... ...U002 P001 1/√3 P002 1/√2

■タイトル

SELECTt1.item_id,t2.item_id,SUM(t1.calc2 * t2.calc2) as score

FROM左記表

GROUP BYt1.item_id,t2.item_id

user_id t1.item_id t1.calc2 t2.item_id t2.calc2U001 P001 1/√3 P002 1/√2U001 P001 1/√3 P003 1/√2U001 P001 1/√3 P004 1/√2U001 P002 1/√2 P001 1/√3U001 P002 1/√2 P003 1/√2U001 P002 1/√2 P004 1/√2... ... ... ... ...U002 P001 1/√3 P002 1/√2

t1.item_id t2.item_id scoreP001 P002 ***P001 P003 ***P001 P004 ***P002 P001 ***P002 P003 ***P002 P004 ***

... ... ***P001 P002 ***

あとはこの結果に対して、t1.item_id、t2.item_idの商品カテゴリや価格の情報をJOINすれば

・同じカテゴリでのレコメンドリスト・近い価格帯でのレコメンドリスト

など、⾊々作れる

途中省略

■タイトル

ビッグデータ分析・活⽤のためのSQLレシピChapter8-3-2 (P.410）

■タイトル

⾃動化・⾼精度化

検索システムの⾼精度化

レコメンドの⾼精度化

システムの改善はエンジニアしか出来ない！

■タイトル

まとめ

■タイトル

ディレクターの範囲

エンジニアの範囲

基礎分析

・推移の把握・内訳の把握・遷移の把握

問題解決

・離脱率改善・再訪率改善・EFO

価値の創造

・検索改善・レコメンド・ターゲティング

ゴールに近いところにいるのはエンジニア

どのようにやればよいかゴールが⾒えているのも

エンジニア

■タイトル

セグメント・ターゲティング

変化・状態の可視化

⾃動化・⾼精度化

■タイトル

ゴールに近いのはエンジニアどのようにやればよいか⾒えているのもエンジニア

データ活⽤を推進するには、エンジニアが必要不可⽋

必要不可⽋と⾔うよりも、エンジニアが主導して、データ活⽤を推進するべきでは？

わかっていつつも、⾏動に移せない⼈も…

エンジニア

経営層・役員

ディレクター

マーケ担当者

法務

インフラ

CS

個⼈情報利⽤の範囲に記載が〜

リスクってどうなの？

他の施策を優先で

クーポンの原資は？ そんなに

捌けない

クレームが…

オペレーションが増える

効果あるの？

コストは？

ビッグデータチームの成り⽴ち

トップダウン

・予算は取れる・強制⼒がある

ボトムアップ

・予算はない・強制⼒がない

主導を持ちつつも、⼆⼈三脚でやるような形で持ちかける

各事業部、個⼈にどんなメリットがあるのか説明する

⼩さく始めて、効果を可視化して投資回収が成功することを⽰す

1,000万かけて、1%の改善があるかも？追加予算なしで、0.7%の改善があるかも？

既存の仕組みに【ちょい⾜し】

データを武器にする

組織作り⼩さなところ、やりやすいところからやってみて、効果を可視化し、説明可能な状態を作り、巻き込んでいく。

エンジニア主導で

ご清聴ありがとうございました。Amazon ビッグデータ SQL

検索

Amazon ⽥宮直⼈

検索