アイスタイルのデータ契約に向けた取り組み ～今までとこれから～

Transcript

1. © istyle Inc. 1 アイスタイルのデータ契約に向けた取り組み ～今までとこれから～ No.1 株式会社アイスタイル データ分析システム部　今井 孔明 2024/11/20
2. © istyle Inc. 自己紹介 No.2 
 名前 今井 孔明 株式会社アイスタイル　データ分析システム部　 データエンジニア 旧データ分析基盤から新基盤（統合データ分析基盤） へのデータ移行 水泳、飼い猫を撫でること 所属・職業 現在の業務 趣味
3. © istyle Inc. アジェンダ No.3 # アジェンダ 内容 1 会社紹介 アイスタイルとは 2 アイスタイルのデータ基盤について データ基盤の紹介 3 アイスタイルのデータ契約の取組み データ契約の現在位置 失敗事例 4 今後やっていきたいこと データ生成、提供側共通 データ生成側 データ提供側
4. 会社紹介　～アイスタイルとは～ © istyle Inc. No.4
5. 
 
 
 アイスタイルとは No.5 を運営している会社です。 国内最大のコスメ・美容の総合サイト © istyle Inc.
6. 
 
 
 アイスタイルとは No.6 コスメの商品データベースとクチコミ検索機能や新商品情報などを備えた 
 日本最大のコスメ・美容の総合サイト 
 日本人女性の2人に1人が利用しています。 月間 ユニークユーザー 1,800 万人 @cosme クチコミ数 2,000 万件＋ @cosme 会員数 850 万人 ブランド数 42,000 ブランド 商品数 370,000 © istyle Inc.
7. アイスタイルとは No.7 （オンラインの購買体験） 取り扱い美容商品数国内No.1のEC。
 @cosmeのデータベースを活用し、ドラッグストア
 ブランドから百貨店ブランドまで、
 流通チャネルの垣根を超えた幅広い品揃えで展開。
 化粧品専門店として、日本で最大規模の33店舗を展開。
 2020年1月、原宿駅前にオープンの
 フラッグシップショップ「＠cosme TOKYO」は、
 取扱い商品2万5000点、来客数日本No.1の化粧品専門店。
 2023年9月には「＠cosme OSAKA」がオープン。
 （オフラインの購買体験） © istyle Inc.
8. アイスタイルのデータ基盤について © istyle Inc. No.8
9. アイスタイルのデータ基盤について No.9 統合データ分析基盤の概要図 © istyle Inc.
10. アイスタイルのデータ基盤について No.10 モデリング標準の作成と DWHの構築 データ品質 権限管理・セキュリティ データ収集のクラウド移行 dbtの導入 モデリング標準の作成 データ検証機能の導入 統合監視の導入 新しい権限管理ルールの 策定 権限管理ツールの実装 Data Observabilityの 導入 データカタログの導入 個人情報のマスキング Airbyteの導入 運用業務の標準化 開発ガイドラインの策定 外部接続性 ReverseETL機能の実装 APIの提供 導入済み・導入中 今後導入を検討 統合データ分析基盤が備える機能 データ品質管理 © istyle Inc. No.10
11. アイスタイルのデータ基盤について No.11 モデリング標準の作成と DWHの構築 データ品質 権限管理・セキュリティ データ収集のクラウド移行 dbtの導入 モデリング標準の作成 データ検証機能の導入 統合監視の導入 新しい権限管理ルールの 策定 権限管理ツールの実装 Data Observabilityの 導入 データカタログの導入 個人情報のマスキング Airbyteの導入 運用業務の標準化 開発ガイドラインの策定 外部接続性 ReverseETL機能の実装 APIの提供 導入済み・導入中 今後導入を検討 統合データ分析基盤が備える機能 データ検証機能の導入 データ品質管理 © istyle Inc. No.11
12. アイスタイルのデータ契約に向けた取り組み © istyle Inc. No.12
13. アイスタイルのデータ契約の取り組み No.13 そもそも、何故データ契約が必要か？？ © istyle Inc.
14. アイスタイルのデータ契約の取り組み No.14 • ①スキーマ変更などを影響度外視で変更されてしまうことが あった ◦ 影響調査の依頼はあるが、ソース側の把握している部署に限 られているため、変更後に障害が発生することがあった • ②社内文化としてデータ品質の価値の認識が薄い ◦ データオーナー制を引けていない ◦ 障害時にデータ基盤側の責任として対応せざるを得ない ◦ 改善も限定的な物になってしまう © istyle Inc.
15. アイスタイルのデータ契約の取り組み No.15 データ
 ソース 統合データ分析基盤 データ利用者 データ生成者 データ生成側との データ契約 データ提供側との データ契約 アイスタイルのデータ契約の現在位置 データ
 提供側 © istyle Inc.
16. 
 • 現状、「データ契約」というレベルでは取り組めていない。
 • ソースシステム側にヒアリングして、提供されるデータを確認するという内容で進めて いる
 ◦ データ内容のヒアリング
 • ヒアリング内容はスプレッドシートで管理している
 
 
 • 提供側とのデータ契約はまだ着手できていない
 ◦ 将来的に提供側とのデータ契約の取り決めも目指す
 アイスタイルのデータ契約の取り組み データ生成者側 データ生成側 データ提供側 アイスタイルのデータ契約の現在位置 © istyle Inc. No.16
17. • ヒアリング内容はスプレッドシートで管理 
 • データベース単位、テーブル単位、カラム単位で質問事項を細分化 
 
 • 質問事項（一部抜粋）
 
 
 アイスタイルのデータ契約の取り組み データ生成側 データベース単位 テーブル単位 カラム単位 • 担当部署・メンション先
 • ER図の有無 • 物理削除の有無
 • 更新日時として使用でき るカラムの有無
 • 完全重複するレコードの 有無
 • データのフォーマット ルール
 • 個人情報の有無
 • 空文字の有無
 © istyle Inc. No.17
18. アイスタイルのデータ契約の取り組み データ生成側 データベース単位 テーブル単位 カラム単位 © istyle Inc. No.18
19. アイスタイルのデータ契約の取り組み データ生成側との課題：失敗事例 データ品質の重要性やデータ基盤の共通理解が出来ていなかったため、調 査の工数を確保できなかった 普段の業務に加えて追加の調査工数を割けない・・・ そもそもデータヒアリングの目的や背景は何になるの？ © istyle Inc. No.19
20. アイスタイルのデータ契約の取り組み データ生成側との課題：失敗事例 「データ契約にはデータ生成側とデータ基盤側の相互理解が必 要であり、生成側の認識・理解度合を基盤側でも把握してい なければいけない」 →この事を理解できておらず、データ基盤側中心で進めてしまっ た © istyle Inc. No.20
21. アイスタイルのデータ契約の取り組み データ生成側との課題：失敗事例からの学び 1. 目的、背景をしっかり伝えることが大事 a. データ生成側にとって工数を割く価値を認識してもらえなけ れば、データ契約を進めていくことはできない 2. PJT起案時・開始時にソース側の工数を確保してもらう 3. 説明資料の作成＆データ生成側との説明MTGの実施 目的・理由もはっきりしたので、 工数を割くことができます！！ © istyle Inc. No.21
22. アイスタイルのデータ契約の取り組み データ品質の課題 • スキーマ変更が告知なく行われる • 区分値の変更を検知できていない ◦ →スキーマ変更時にエラーが生じてしまうという課題があった データ検証の必要性 © istyle Inc. No.22
23. • データ品質管理ツール Great Expectationsを用いてデータバリデーションを行う
 アイスタイルのデータ契約の取り組み データの検証方法 データ
 ソース データ基盤到着前とメタデータ付与後の 2 工程でバリデーションを行う データ
 レイク DWH データ マート © istyle Inc. No.23
24. • スキーマ変更検知
 ◦ データ基盤到着前
 ▪ ソーステーブルのスキーマ情報
 • カラム名
 • データ型
 • データバリデーション
 ◦ メタデータ付与後
 ▪ Nullチェック
 ▪ 区分値チェック
 ▪ 正規表現によるチェック
 • など
 アイスタイルのデータ契約の取り組み データの検証方法 © istyle Inc. No.24
25. 今後やっていきたいこと © istyle Inc. No.25
26. • スプレッドシート管理からYAML管理に移行する
 ◦ YAML移行のメリット
 ▪ 構造化データとして管理できる
 ▪ プログラムとの統合性
 • CI/CDに組み込みやすい
 • データカタログに組込むことで提供側の内容確認が容易になる 
 
 今後やっていきたいこと データ生成側・データ提供側　共通 © istyle Inc. No.26
27. • Github管理
 ◦ YAML移行したデータ契約のバージョン管理を行う 
 ◦ プルリクエストを用いた承認フローの確立 ▪ データ契約の内容を変更する際、変更側・承認側双方の同意が必要となる 
 ▪ → この承認フローをプルリクエストが担う 
 
 今後やっていきたいこと データ生成側・データ提供側　共通 この箇所を変更したいです （PR送信） OKです！ （PR承認） © istyle Inc. No.27
28. SLOの制定 ◦ データ契約を目指す際、SLOの制定は責任を明確にするために必要となる 
 
 
 今後やっていきたいこと データ生成側・データ提供側　共通 
 • スキーマ変更時の通知時間
 • データ鮮度
 • etc…
 
 • データ可用性
 • データ提供頻度
 • etc…
 データ生成側 データ提供側 © istyle Inc. No.28
29. • データの価値を明確に伝えて、データ生成側にデータ契約の必要性を認識してもらう ◦ ソースシステム側にとっては、データ契約を結ぶメリットが少ない
 ◦ わざわざ自分の担当外の業務に関して、契約として責務を負うインセンティブがない
 ▪ データ基盤側で基盤が生み出している価値を認識し、ソース側に伝える必要がある
 今後やっていきたいこと データ生成側とのデータ契約 ◦ データ品質の向上に投資する価値は何？ 
 ◦ ビジネスにもたらされるポジティブな効果は？ 
 ◦ なぜ他のシステムではなくデータに投資する必要があ るの？
 © istyle Inc. No.29
30. • データの価値を明確に伝えて、データ生成側にデータ契約の必要性を認識してもらう ◦ データの価値を伝えることで、ソース側の工数を確保してもらえる
 ◦ データ生成者という意識を持ってもらうことで、ソース側・基盤側で共にデータの価値を高めてい くという文化を醸成できれば更にＧＯＯＤ
 ◦ 社内でのデータ基盤の広報活動の実施（エンジニア月次会での発表等）
 今後やっていきたいこと データ生成側とのデータ契約 データ基盤側 ソースシステム側 契約内容のデータを提供 データの価値を伝える © istyle Inc. No.30
31. • 第一に、提供側とのデータ契約に着手して運用まで持っていく
 ◦ 「契約」まで行けなくても、提供内容の取決めを行い、双方同意の状態まで進めたい 
 
 • スプレッドシート→YAMLへの自動変換
 ◦ 提供側はYAMLに慣れていない場合もある 
 ◦ データ基盤⇔提供側のインターフェースとしてはスプレッドシートを使用し、YAMLに自動変 換するプログラムを使用する
 
 • データカタログを使用して、提供側でも契約内容を容易に確認できるようにする
 
 今後やっていきたいこと データ提供側とのデータ契約 © istyle Inc. No.31
32. おわりに アイスタイルではデータエンジニアを募集しています！！ データエンジニア https://open.talentio.com/r/1/c/isytyle_career/pages/72525 データ基盤エンジニア https://open.talentio.com/r/1/c/isytyle_career/pages/98872 オープンポジション／データ領域 https://open.talentio.com/r/1/c/isytyle_career/pages/89136 データ系職種一覧 https://open.talentio.com/r/1/c/isytyle_career/homes/4344?group_ids=9069 © istyle Inc. No.32