【キュービック】データ利活用を見据えた分析基盤リニューアルの進め方
by
CUEBiC Inc.
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
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.泥臭さを忘れない ・全部自動化を目指さない。急がば回れ ・無理ならスクリプトを仕込んでしまえ