Slide 1

Slide 1 text

データウェアハウス構築時の アンチパターンを克服した サクセスストーリー 株式会社キュービック テクノロジーエキスパートセンター CTO 加藤彰宏 テックリード 尾﨑勇太 2023.2.10 ։ࣔൣғެ։υΩϡϝϯτ 1

Slide 2

Slide 2 text

商号 株式会社キュービック 設立 2006年10月24日 所在地 本社 〒169-0074 東京都新宿区北新宿2-21-1 新宿フロントタワー16階 福岡支社 〒810-0001 福岡県福岡市中央区天神2-8-38 協和ビル3階 代表 世一 英仁 資本金 31,000,000円 従業員数 社員: 178人 インターン: 137人 業務委託・派遣:76人 (2022年6月末現在) 事業内容 デジタルメディア事業 SNSアニメ事業 通販事業者向け集客支援事業 プラットフォーム事業 有料職業紹介事業(厚生労働大臣許可番号 13-ユ-311579) גࣜձࣾΩϡʔϏοΫͱ͸ ࣾһ ਓ 2

Slide 3

Slide 3 text

$6J$"OBMZUJDT ϝσΟΞʢ޿ࠂʣ ϝσΟΞʢ4&0ʣ 広告媒体 サーチエンジン "41 ސ٬ αΠτ ૹ٬਺ ޿ࠂ੒Ռ σʔλ $7਺ ച্ σʔλ #*πʔϧ ϝσΟΞ ΦϖϨʔλ ϝσΟΞ੒Ռ ޿ࠂ੒Ռ ച্؅ཧ ޿ࠂඅ؅ཧ ૹ٬ ૹ٬ $7 $7 σʔλ ෼ੳ %8) ϓϥοτϑΥʔϜ ޿ࠂ੒Ռ؅ཧ $7੒Ռ؅ཧ ച্؅ཧ ޿ࠂඅ؅ཧ Ϛελσʔλ &31 メディア事業基幹システム 3 Ϣʔβʔ Ϣʔβʔ

Slide 4

Slide 4 text

ηογϣϯ಺༰ 4 1.本日お伝えしたいこと 2.概要 3.実際の取り組み内容のご紹介 4.Q&A

Slide 5

Slide 5 text

ຊ೔͓఻͍͑ͨ͜͠ͱ 5 データウェアハウス構築時のアンチパターンと解決策 今後の取りくみ

Slide 6

Slide 6 text

ຊ೔͓࿩͢Δൣғ 6 本日は③の開発フェーズを「検討/導入/改善」の 3つの工程に分けて説明します ニーズ/課題分析・定 義及びデジタル技術 把握 コンセプト構築 (初期仮説) 要求定義とPoc 開発・実装・試験 保守・運用・評価 解決すべき課題の定義 課題の解決方法検討 ①構想策定フェーズ 課題解決時の価値創出の検 証 技術的解決策の検証 ②PoCフェーズ コンセプト実現に向けた システム/サービス開発 ③開発フェーズ コンセプト実現に向けたシス テム/サービス開発 ④運用フェーズ 1. 業務でデータを使って改善でき そうなところを探す 2. 改善のための仮説を立てて提案 を作る 3. 社内で整理してプロジェクト化する 4. データを収集する・データを受け取る 5. データをクリーニングする 6. データを可視化する 7. データを集計する 8. データマイニングや機械学習を用い る 9. 結果を元に再調整や再実験を繰り返 す 10.結果を可視化してレポートにまとめ る 11.レポートを関係者を共有する 12.結果を元に有効と思われるビジネスアク ションを取る 13.ビジネスアクションの効果を測定して検 証する 14.PDCAサイクルをまわす 自社データ分析基盤 データウェアハウス化 データ利活用ステップ

Slide 7

Slide 7 text

データウェアハウス構築時の アンチパターンを克服した サクセスストーリー 株式会社キュービック テクノロジーエキスパートセンター CTO 加藤彰宏 テックリード 尾﨑勇太 2023.2.10 ։ࣔൣғެ։υΩϡϝϯτ 7

Slide 8

Slide 8 text

σʔλ΢ΣΞϋ΢εΛߏங͢Δ໨త 8 4BB4ʢΫϥ΢υαʔϏεʣ SaaS>CUEBiC Analytics/ERP>DWH>Tableauの一気通 貫 1. 現在利用しているSaaS(クラウドサービス)のデータ をCUEBiC Analytics/ERPに統合しバックオフィス系 業務の集中的に管理する。 2. CUEBiC Analytics/ERPのデータをBIツールで解析可 能なようにデータ抽出・加工しDWHに書き出し継続的 にデータの蓄積を行う。BI(Tableau)ツールにて経営 企画・事業企画・各事業部担当・バックオフィス部門 がそれぞれ必要な情報を解析し、各部門のファクトの 確認、戦略戦術策定を行う。 ユースケースと期待される効果 ● 経営ダッシュボード 重要施策・KPI・進捗の把握と打ち手 ● ビジネスダッシュボード 事業本部KPI/KGI/FCTの把握と打ち手 ● バックオフィス業務の合理化/効率化/ミスの低減 ૊৫Ϛελ ैۀһ Ϛελ ސ٬Ϛελ ࡒ຿σʔλ ʢࡒ຿؅ ཧձܭʣ ࢢ৔σʔλ 4&0Ξυ σʔλ ࣗࣾڝ߹ ച্ૈར σʔλ $#" Ξυίϯ ੒Ռσʔλ %8) σʔλͷநग़ɾՃ޻ɾॻ͖ग़͠ CUEBiC Analytics ʢ޿ࠂ4&0੒Ռσʔλॲཧʣ &31ʢਓࣄɾ࿑຿ɾܦཧɾڅ༩ɾ੥ٻ؅ཧʣ -JHIUIPVTF είΞ (" 4FBSDI$PO ޿ࠂ؅ཧ (PPHMF'#ͳͲ ֤੒Ռ σʔλ )3.04ΧΦφϏ૊৫αʔϕ ΠϖΞΤϯήϢχϙε೔ใ #*πʔϧ 5BCMFBV CJH 2VFSZ ച্ɾ੥ٻσʔλ &5- USPDDP &5- 5#%

Slide 9

Slide 9 text

ߏங͢Δ্ͰͷΤϯδχΞϦϯά՝୊ 9 CUEBiC Analytics キュービックのCVメディア事業の広告費/成果情報を集計し、売上をモニタリングするための社内ETL ASP 広告媒体 CUEBiC Analytics 外部ツール 成果 マスタ 実績 売上 広告 費 技術負債によりビジネス要求に耐えられなくなった ・ビジネス理解を必要としイニシャルコストが高い ・組織情報などドメインに持つべきでない責務の保持 ・初期開発メンバーの離脱 ・数値誤差などの品質の低下 ・コードの老朽化

Slide 10

Slide 10 text

σʔλ΢ΣΞϋ΢εಋೖલ 10 広告 ASP クライアント別売上データ 組織別売上データ メディア別売上データ 媒体別広告費データ メディア別広告費/成果デー タ 組織別広告費/成果データ 運用者 CUEBiC Analytics ޿ࠂ੒Ռ؅ཧ $7੒Ռ؅ཧ ޿ࠂඅ؅ཧ Ϛελ৘ใ ੜσʔλ Ճ޻σʔλ ूܭσʔλ ͦͷଞϚελ

Slide 11

Slide 11 text

2022年2月〜2022年4月 事例1:検討フェーズ 構築時に目指していたものは? 11

Slide 12

Slide 12 text

データウェアハウス ? ? ΞʔΩςΫνϟʔ 12 広告 媒体別広告費データ %BUB$BUBMPH (VMF4UVEJP 生データ 加工データ 集計データ (VMF+PC

Slide 13

Slide 13 text

ӡ༻՝୊͕ϦΞʔΩςΫτޙʹղফ͞ΕΔ͔ʁ 13 2.ブラックボックス化 ・データカタログと取得データの紐付けが煩雑 →人員交代時にアーキテクト崩壊のリスクが高い 1.必要スキルセットの難化 ・設定/更新にインフラの知見が必要 →エンジニアリング工数が増加 Glue Studio ログとかバックアップ ぐらいしか使わないよ 連携時にテーブルを 自動生成できない 取得したのに結果はGlue 単独で見れないの? データフォーマット 違い過ぎ

Slide 14

Slide 14 text

৽ͨͳӡ༻՝୊ΛੜΈग़͍ͯ͠ͳ͍͔ʁ 14 DWH本稼働時の問題 現在はCUEBiC Analyticsの代替として、データレイクに特化 →S3やAWS Glueを介さないデータが増えると調査/改善工数が増加 %8) その他 データレイク(整形済み) データマート(生データ) 広告 成果 その他 設定されてないなぁ・・・ 数字ずれてる??

Slide 15

Slide 15 text

൓লϙΠϯτͱղܾࡦ 15 反省ポイント 原因:AWS様、Primnumber様の解像度が低い状態で進んでしまった 結果:社内スキルセットとの乖離や新たな運用課題ができてしまった 解決策 💡関係者で共通認識を持つ 事例:進捗レポートを両社にもFBし、目指したい姿や課題感を明確に伝えた 結果:サービス間競争がなくなり、合理的なアーキテクチャが協議できた

Slide 16

Slide 16 text

2022年5月〜2022年10月 事例2:導入フェーズ 歴史は繰り返される 16

Slide 17

Slide 17 text

ݕ౼࣌ͷ՝୊Λߟྀͯ͠ΞʔΩςΫνϟΛߋ৽ 17 広告 ASP 生データ 加工データ 集計データ 同期データ ・除外条件 ・不明成果 ・名寄せ マスタ情報 ・広告アカウント ・広告媒体 ・メディア ・成果収集元 ・組織 クライアント別売上データ 組織別売上データ メディア別売上データ 媒体別広告費データ メディア別広告費/成果デー タ 組織別広告費/成果データ 運用者 CUEBiC Analytics ޿ࠂ੒Ռ؅ཧ $7੒Ռ؅ཧ ޿ࠂඅ؅ཧ Ϛελ৘ใ

Slide 18

Slide 18 text

しかし、ここで思わぬ落とし穴が 18 ワークフロー機能 取得データを後続処理に渡せない 【回避策】 さっき送った広告のデ ータ頂戴 どぞ〜 OK〜 広告の関連データ頂戴 ごめん無理やった 二人ともありがとう 合わせてRedshiftに送 る!! 広告関連の情報もらっ て良い? OK〜 どぞ〜 さっき送った広告のデー タ情報と、RDSからもら った広告関連のデータ貸 して ありがとう! 集計結果送る!! ありがとう! Redshiftに事前に同期しておく

Slide 19

Slide 19 text

さらに・・・ 19 どうぞ〜 DB1のA広告の生デー タ一つください 異なるDBのデータの加工は 無理やわ。 統合してもらって良い? 【回避策】 統合してくれたから、 整形したデータを送れる! DB2のA成果の生デー タ一つください えっ・・・ データマート機能 複数のDBを跨いだデータ取得/転送ができない A広告主データ B広告主データ C広告主データ D広告主データ RedshiftのDBはドメインごとに統合し DBを跨いだ整形はtroccoの責務としない

Slide 20

Slide 20 text

Ξϯνύλʔϯ͸͜͜ʹ 20 困ったポイント 場当たり的なアーキテクチャの更新 要件とサービスのトレードオフ 解決策 ・2年先までのアーキテクチャーの変遷を仮置きで引く 事例:16期下期の段階で19期までのアーキテクチャーを設計した 結果:運用から逆算した全体計画/社内調整が可能に ・やらないことを決める 事例:アーキテクチャをFIXさせる上で「やらないこと」を決めた 結果:事業成長とデータの不確実性の切り分けができた

Slide 21

Slide 21 text

やらないことを決めたこと 21 1.今後収集するデータが増えた場合 ・データ整形は同一DB内で完結し、DB間でデータの依存関係ができないようにする 2.分析対象の情報はRedshiftに集約する ・関連会社/プロダクトの成長フェーズに合わせて連携方法をパターン化 3.troccoでデータ加工を行なわない ・データ設定用のインターフェースを実装 ・加工処理に関してはエンジニア責務(Redshiftのプロシージャー)とする 4.独自のスクリプティングを追加しない ・trocco API経由でインターフェースから集計ができるようにする

Slide 22

Slide 22 text

2022年11月〜2022年1月 事例3:改善フェーズ エンジニアリングだけじゃダメ 22

Slide 23

Slide 23 text

ΤϯδχΞϦϯάͷ՝୊͸ղܾͨ͠ʹݟ͕͑ͨɾɾɾ 23 既存システムの停止を運用者に理解してもらう必要があった 開発チーム 運用者 元の方に機能追加 できませんか? 移行後のメリットは〇〇 デメリットとして〇〇に なります 行ったこと 要求の分類と アーキテクチャの更新 対応できそうなもの ・業務フローの再設計 ・不要なデータの整理 ・優先度説明・調整 対応できないもの ・削れない機能の停止 ・部分最適となる諸課題 この機能が使えなくなるなら ダメ!!使いません

Slide 24

Slide 24 text

ΤϯδχΞϦϯάͷ՝୊͸ղܾͨ͠ʹݟ͕͑ͨɾɾɾ 24 業務フローも一緒に再設計することで部分最適を最小限に 開発チーム 運用者 OK!!期限までに 移行しますね 並行稼働期間を設けつ つ既存運用は◯月に停 止します この機能は要らない ですね 分かったこと 過去に応えらなかった要求 ・既存の業務フローの不足 ・既存の集計情報の不足 BIツールのその先 ・スプシ地獄 ・チームごとの独自集計

Slide 25

Slide 25 text

運用՝୊Λߟྀͯ͠ɺΞʔΩςΫνϟʔΛߋ৽ 25 広告 ASP 生データ 加工データ 集計データ 同期データ ・除外条件 ・不明成果 ・名寄せ マスタ情報 ・広告アカウント ・広告媒体 ・メディア ・成果収集元 ・組織 ユーザーインターフェース(Oasis) 広告集計設定 成果集計設定 その他マスタ クライアント別売上データ 組織別売上データ メディア別売上データ 媒体別広告費データ メディア別広告費/成果デー タ 組織別広告費/成果データ 運用者

Slide 26

Slide 26 text

վળޙͷۀ຿ͷ෼ྨ 26 データ設定/収集 データ整形/集計/アウトプット D X 推 進 エ ン ジ ニ ア データ活用 Oasis 事 業 部 Oasis 加工/分析 整形データ登録 EXインポート除外設定 運用管理 ・アカウント管理 ・転送設定/エラー解消 成果/広告レポートを格納 概念検証 ・検証/実装 ・トラブルシュート 運用保守開発 ・機能追加 ・trocco API実装 運用保守 ・データ再取り込み ダッシュボード設計 ・ワークブック/クエリ設定 運用保守 ・カスタムクエリ実装 運用保守開発 ・エンティティ設計 ・データ疎通

Slide 27

Slide 27 text

վળϑΣʔζͰ௧ײͨ͜͠ͱ 27 泥臭い作業も時には必要 💡業務フローの再設計>既存運用 ・無理に自動化をしない ⇨手動で最適化できないかも検討する 💡運用ミス>データ品質 ・無理にデータ品質を上げない ⇨運用ミスをいかに救済するかを考える

Slide 28

Slide 28 text

まとめ 28

Slide 29

Slide 29 text

ΞϯνύλʔϯΛࠀ෰͢ΔͨΊͷ޻ఔผϙΠϯτ 29 検討 導入 改善 要件とサービスで トレードオフは発生する 本当に運用者視点? ・泥臭いことも必要 自動化が目的ではない ・運用改善も一緒に ・2年先を考える ・やらないことを決める ・共通認識を持つ 得たい成果を明確に ・課題は何だったか? ポイント ポイント 解決策

Slide 30

Slide 30 text

今後の展開 30

Slide 31

Slide 31 text

࢒՝୊ 31 現状 既存のCUEBIC Analyticsがまだ停止していない あるべき姿 成果集計を全てデータウェアハウスに移行し、Cubic Analyticsを停止する 問題 運用課題に関して並行開発が必要なタスクや救済措置が残っている 課題 2023年4月までに問題をクリアし、 2023年7月をターゲットに成果集計基盤の停止を行う。

Slide 32

Slide 32 text

ࠓޙͷ՝୊ 32 現状 Cubic Analyticsのデータ収集/整形業務の移行がメイン あるべき姿 サイトの動向や売上といったモノの分析ではなく、 カスタマーを分析し最適なユーザ体験を提供できる 問題 広告と成果に関するデータに特化している ユーザーの一次情報などは蓄積/分析できていない 課題 中長期計画としてCubic Analyticsではリーチできていない 情報収集+機械学習などの分析基盤構築を検討する

Slide 33

Slide 33 text

ࠓޙ͸ຊ֨తͳσʔλར׆༻ϑΣʔζ΁ 33 ΧελϚʔ෼ੳ ޿ࠂ੒Ռूܭ ಉظσʔλ ɾআ֎৚݅ ɾෆ໌੒Ռ ɾ໊دͤϚελ৘ใ #*πʔϧ ੜσʔλ Ճ޻σʔλ ूܭσʔλ είʔϓ &5- 広告媒体 ASP 0BTJT ޿ࠂूܭઃఆ ੒Ռूܭઃఆ ͦͷଞϚελ ࣍৘ใ Ϣʔβʔߦಈ ɾભҠݩ ɾࢀরܦ࿏ ɾӾཡ৘ใ ɾૹ٬ޙΞΫγϣϯ Z Redshit ML ػցֶश Ϟσϧ ਪ࿦݁Ռ ࢪࡦ౷ܭ %8)

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Q&A 35

Slide 36

Slide 36 text

Copyright © 2022 CUEBiC All Rights Reserved. 36 &01