Slide 1

Slide 1 text

限られた予算・時間の中でいかにプロジェクトを成功させたのか データ利活用を見据えた 分析基盤リニューアルの進め方 株式会社キュービック テクノロジーエキスパートセンター Tech Lead 尾﨑勇太 2023.4.27 開示範囲:公開ドキュメント
 1

Slide 2

Slide 2 text

株式会社キュービックとは? 2 株式会社キュービック /CUEBiC Inc. 社名 事業 設立 資本金 拠点 2006 年 10 月 24 日 31,000,000円 人員 約 300 名(単体)※インターンを含む 約 484 名(連結) ※2022年3月現在 デジタルメディア事業、集客支援事業 ほか 東京、福岡

Slide 3

Slide 3 text

自己紹介 3 株式会社キュービック Tech Lead/データエンジニア 尾﨑 勇太(おざき ゆうた) 覚え方:尾崎豊(おざきゆたか)と一字違い 1990年和歌山県白浜町生まれ 生息地:千葉県松戸市 スキルセット 1. マネジメント/品質管理/データ分析 2. マイナスからゼロ、ゼロイチ 3. サーバーサイド(WEB/アプリ開発) @waichang111 経歴の詳細はこちらをご参照ください 和歌山県民の取扱説明書はこちらをご参照ください 最近解放しました はてなブログもやってます

Slide 4

Slide 4 text

セッション内容 4 1.データ分析基盤の概要と課題 2.Amazon Redshiftとtrocco®導入の経緯 3.導入後の変化・効果 4.今後の展望

Slide 5

Slide 5 text

データ分析基盤の概要と課題 5

Slide 6

Slide 6 text

導入時の課題/データウェアハウス構築の目的 6 ビジネスインパクト ・メディアの売上予測値に誤差が発生:10〜20%程度 ・集計パフォーマンスの劣化:集計時間が2時間以上 ・機能改善の費用対効果が低減:半年〜1年(EX コンバージョンアップロード) エンジニアリング課題 ・技術負債/メインメンバーの離脱:不具合以外は仕様凍結 課題:事業成長に分析基盤が耐えられなくなってきた データウェアハウス構築の目的 事業成長に耐えうるデータ基盤の構築 ・組織の売上目標のモニタリング精度向上 ・財務/管理会計データの統合管理ができる ・データを起点とした定量的な意思決定ができる

Slide 7

Slide 7 text

既存のデータ分析環境 7 広告/ASP 生データ 加工データ 集計データ 設定マスタ その他マスタ クライアント別売上データ 組織別売上データ メディア別売上データ 媒体別広告費データ 組織別広告費/成果データ 広告データ 成果データ CUEBiC Analytics

Slide 8

Slide 8 text

既存のデータ分析環境でのそれぞれの役割 8 CUEBiC Analytics ・設定情報の入力 ・広告レポートのインポート ・成果レポートのインポート ・広告レポートの集計 ・成果レポートの集計 CUEBiC Analytics ・設定情報の入力 ・広告データのインポート ・成果データのインポート ・広告データの集計 ・成果データの集計 ・データの保持 - 集計設定データ - 広告/成果の生データ - 広告/成果の集計データ ・データの加工 - 広告データ - データの加工 ・データのビジュアライゼー ション

Slide 9

Slide 9 text

リニューアル後のデータ分析環境 9 生データ 加工データ 集計データ 設定マスタ その他マスタ クライアント別売上データ 組織別売上データ メディア別売上データ 媒体別広告費データ 組織別広告費/成果データ ユーザーインターフェース(Oasis)
 
 広告集計設定 成果集計設定 転送設定 データマート trocco API 広告/ASP

Slide 10

Slide 10 text

リニューアル後のデータ分析環境でのそれぞれの役割 10 CUEBiC Analytics ・データ抽出 - 広告データ - 成果データ ・データ転送 ・データ整形 ・データの蓄積 ・データの加工 ・データの集計 ・データのビジュアライゼー ション ・集計設定 ユーザーインターフェース(Oasis) ・ビジネスサイド側が見るビ ジュアライゼーション

Slide 11

Slide 11 text

Amazon Redshiftとtrocco®導入の経緯 11

Slide 12

Slide 12 text

データウェアハウスを構築する目的 12 SaaS>分析基盤>DWH>Tableauのデータ連携フロー確立 ● 複数SaaSに散らばったデータを統合管理する ● 管理/財務会計データをDWHに継続的にデータの蓄積を行う ● BIツールにて各部門がファクトの確認、戦略戦術策定を行う ユースケースと期待される効果 ● 企業課題の可視化/早期課題解決 ● ビジネスサイドの定量データ把握/戦略実行(KPI/KGI/売上予測) ● バックオフィス業務の合理化/効率化/ミスの低減 ※管理会計:自社の経営に活かすために作成する、社内向けの会計 ※財務会計:企業外部の利害関係者に対して、企業の財務状況を報告するために行う会計

Slide 13

Slide 13 text

データ分析リニューアルの背景 13 1.DX戦略の一環としてDWH化が計画されていた 2.CBAはメディアの収益を集計していたが、老朽化が進んでいた 3.そこでCBAの刷新とDWHのR&Dを並行で行うことに 13 尾﨑く〜ん なんとかできない? えっ?! CBA?ETL?DWH? ※CBA:CUEBiC Analytics と思われたが、メイン推進担当が急遽離脱!!

Slide 14

Slide 14 text

CUEBiC Analyticsを分解 14 14 広告/成果インポート 広告/成果集計 集計設定 データ収集を外部SaaS化 代替できそう! 集計ロジックはローコード化 CUEBiC Analytics 成果エクスポート BIツール側でローコード化 爆速キャッチアップ

Slide 15

Slide 15 text

RDSからデータウェアハウスへの移行を検討 15 15 データ整形/蓄積 データ活用 データ収集 ETL DWH BI

Slide 16

Slide 16 text

R&Dでデータ連携フローを検証 16 16 広告媒体と親和性のあったtroccoをフロントに設定 データフロー/サービスは検証を行いつつ確定

Slide 17

Slide 17 text

データウェアハウス導入前後比較 17 CUEBiC Analytics Oasis
 データ抽出 集計設定 集計ロジック データ蓄積 データ分析 手動

Slide 18

Slide 18 text

導入後の変化・効果 18

Slide 19

Slide 19 text

導入後の解決状況 19 ビジネスインパクト ・メディアの売上予測値に誤差が発生:10〜20%程度 ・集計パフォーマンスの劣化:集計時間が2時間以上 ・機能改善の費用対効果が低減:半年〜1年 エンジニアリング課題 ・技術負債/メインメンバーの離脱:不具合以外は仕様凍結 課題:事業成長に分析基盤が耐えられなくなってきた データウェアハウス構築の目的 事業成長に耐えうるデータ基盤の構築 ・モニタリング数値の精度向上 ・財務/管理会計データの統合管理ができる ・データを起点とした定量的な意思決定ができる 事業成長に耐えうるデータ基盤の構築 ・組織の売上目標のモニタリング精度向上 ・財務/管理会計データの統合管理ができる ・データを起点とした定量的な意思決定ができる ▲部分的に改善 ▲管理会計はスコープ外 ▲基盤構築のみ ⭕5〜10%に改善見込み ⭕集計時間が1時間以内に ⭕1〜2ヶ月に ⭕並行して取り込みが可能に

Slide 20

Slide 20 text

導入後の変化 20 DWHのポテンシャルを認識し、機械学習のR&Dにも前向きに 業務内の課題が顕在化(分析フローの自動化依頼など) エンジニア/DX推進 先端技術検証の社内整備/仮説検証を開始 ローコードを武器にBPRを推進(顕在化していないマスタの統制など) 経営層/事業部

Slide 21

Slide 21 text

導入後の効果試算 21 運用ミスによる集計誤差を自動化により40%低減 単価情報の精度向上により20%〜30%向上 コミュニケーション負荷20%〜30%軽減 8人月→4人月 Rubyエンジニア工数の64%をノーコード/SQLで代替 DXエンジニアの工数の37.5%を自動化により削減 エンジニアリング工数 集計誤差

Slide 22

Slide 22 text

リニューアル前後の利用技術
 データ設定 データ整形/集計 アウトプット データ収集 Rubyエンジニア工数の64%をノーコード/SQLで代替 前 後 運用保守/技術負債返済 運用保守/機能追加

Slide 23

Slide 23 text

CBA 
 リニューアル前後の業務フロー
 データ設定 エクスポート 分析 インポート DXエンジニアの工数の37.5%を自動化により削減 前 後 CBA 
 CBA 
 Oasis


Slide 24

Slide 24 text

今後の展望 24

Slide 25

Slide 25 text

今後の課題 25 現状 CUEBic Analyticsのデータ収集/集計対象のメインはメディアの広告と成果データ であり、その範囲内でデータウェアハウスへのリニューアルを実施中 あるべき姿 サイトの動向や売上といったモノの分析ではなく、 カスタマーを分析し最適なユーザ体験を提供できる状態 問題(現状とあるべき姿のGAP) ユーザーの一次情報などは蓄積/分析できていない 課題(問題の解決策) 中長期計画としてCubic Analyticsではリーチできていない 情報収集+機械学習などの分析基盤構築を推進する 問題が解消されることで あるべき姿に近づく

Slide 26

Slide 26 text

今後は本格的なデータ利活用フェーズへ 26 広告/ASP 成果集計 集計結果 モニタリング ユーザー行動 一次情報 推論結果 施策統計 広告/ASP

Slide 27

Slide 27 text

27 ご清聴、ありがとうございました

Slide 28

Slide 28 text

対談 28

Slide 29

Slide 29 text

29 R&Dから導入までの予算承認 検証のゲートウェイが3ヶ月起き・・・ 経営へのレポート提出回数はトータルで5回・・・・ 💡リプレイスの過程で一番苦労したこと 4月 R&D ①trocco導入計画 ②troccoトライヤル導入 ③リアーキテクト1回目 ④リアーキテクト2回目 ⑤運用リプレイス計画 ⑥運用リプレイス始動 イベント 7月 10月 導入/開発 1月 ⑤ ④ AWS社 POC ① 2022年 2023年 1月 2月〜9月 ② ③ ⑥ ★経営レポート1回目 ★経営レポート2回目 ★経営レポート3回目 ★経営レポート4回目 ★経営レポート5回目

Slide 30

Slide 30 text

30 💡導入時にやっておいてよかったこと 1.社外で有識者を探そう ・他社事例を取りに行こう 2.社内データ利活用ステップを進めよう ・DWH構築のその先は・・・? 3.2年先までのアーキテクチャーを引こう ・リプレイス中に事業フェーズが変わっても大丈夫? ・運用者目線じゃなくてエンジニアで恣意的に進めていない?

Slide 31

Slide 31 text

31 💡社内データ利活用ステップを進めよう 4月 R&D ①trocco導入計画 ②troccoトライヤル導入 ③リアーキテクト1回目 ④リアーキテクト2回目 ⑤運用リプレイス計画 ⑥運用リプレイス始動 イベント 7月 10月 導入 開発 1月 ⑤ ④ AWS社 POC ① 2022年 2023年 1月 2月〜9月 ② ③ ⑥ ★経営レポート1回目 ★経営レポート2回目 ★経営レポート3回目 ★経営レポート4回目 ★経営レポート5回目 データ 利活用 ⑦等級/役割定義 ⑧人材育成要件 ⑨データ利活用概要策定 ⑩データロードマップ策定 ⑪データ利活用戦略策定 ⑫先行仮説検証 ⑦ ⑧ ⑨ ⑩ ⑪ ⑫

Slide 32

Slide 32 text

32 💡削減された工数で今度は何に時間を使っていきたいか R&D データエンジニア 初期構築 1.Post CBAをベースに機械学習基盤を構築 2.機械学習基盤を通したデータの利活用分析 1.機械学習前の課題抽出 /定義 2.分析データの収集 3.仮説をプレ分析にて検証 4.有効仮説を元に機械学習を追加開発 5.データの分析 6.分析のレポート off-jt+先端技術検証 データサイエンティスト 新規開発/運用 機械学習基盤を構築 スペシャリスト登用

Slide 33

Slide 33 text

33 💡やり直すなら気をつけたいこと 33 1.本当に解決したい課題を打ち明けよう ・アップセルの営業を警戒しすぎていない? ・課題を打ち明けてフォロワーなってもらおう 2.社内調整 ・R&Dをやりながら運用計画って実際難しい ・でも引いちゃえ。予算承認も一気に取っちゃえ 3.泥臭さを忘れない ・全部自動化を目指さない。急がば回れ ・無理ならスクリプトを仕込んでしまえ