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

by ImaiKomei

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

会社紹介　～アイスタイルとは～ © istyle Inc. No.4

Slide 5

Slide 5 text

      アイスタイルとは No.5 を運営している会社です。国内最大のコスメ・美容の総合サイト © istyle Inc.

Slide 6

Slide 6 text

      アイスタイルとは No.6 コスメの商品データベースとクチコミ検索機能や新商品情報などを備えた   日本最大のコスメ・美容の総合サイト   日本人女性の2人に1人が利用しています。月間ユニークユーザー 1,800 万人 @cosme クチコミ数 2,000 万件＋ @cosme 会員数 850 万人ブランド数 42,000 ブランド商品数 370,000 © istyle Inc.

Slide 7

Slide 7 text

アイスタイルとは No.7 （オンラインの購買体験）取り扱い美容商品数国内No.1のEC。  @cosmeのデータベースを活用し、ドラッグストア  ブランドから百貨店ブランドまで、  流通チャネルの垣根を超えた幅広い品揃えで展開。  化粧品専門店として、日本で最大規模の33店舗を展開。  2020年1月、原宿駅前にオープンの  フラッグシップショップ「＠cosme TOKYO」は、  取扱い商品2万5000点、来客数日本No.1の化粧品専門店。  2023年9月には「＠cosme OSAKA」がオープン。  （オフラインの購買体験） © istyle Inc.

Slide 8

Slide 8 text

アイスタイルのデータ基盤について © istyle Inc. No.8

Slide 9

Slide 9 text

アイスタイルのデータ基盤について No.9 統合データ分析基盤の概要図 © istyle Inc.

Slide 10

Slide 10 text

アイスタイルのデータ基盤について No.10 モデリング標準の作成と DWHの構築データ品質権限管理・セキュリティデータ収集のクラウド移行 dbtの導入モデリング標準の作成データ検証機能の導入統合監視の導入新しい権限管理ルールの策定権限管理ツールの実装 Data Observabilityの導入データカタログの導入個人情報のマスキング Airbyteの導入運用業務の標準化開発ガイドラインの策定外部接続性 ReverseETL機能の実装 APIの提供導入済み・導入中今後導入を検討統合データ分析基盤が備える機能データ品質管理 © istyle Inc. No.10

Slide 11

Slide 11 text

アイスタイルのデータ基盤について No.11 モデリング標準の作成と DWHの構築データ品質権限管理・セキュリティデータ収集のクラウド移行 dbtの導入モデリング標準の作成データ検証機能の導入統合監視の導入新しい権限管理ルールの策定権限管理ツールの実装 Data Observabilityの導入データカタログの導入個人情報のマスキング Airbyteの導入運用業務の標準化開発ガイドラインの策定外部接続性 ReverseETL機能の実装 APIの提供導入済み・導入中今後導入を検討統合データ分析基盤が備える機能データ検証機能の導入データ品質管理 © istyle Inc. No.11

Slide 12

Slide 12 text

アイスタイルのデータ契約に向けた取り組み © istyle Inc. No.12

Slide 13

Slide 13 text

アイスタイルのデータ契約の取り組み No.13 そもそも、何故データ契約が必要か？？ © istyle Inc.

Slide 14

Slide 14 text

アイスタイルのデータ契約の取り組み No.14 ● ①スキーマ変更などを影響度外視で変更されてしまうことがあった ○ 影響調査の依頼はあるが、ソース側の把握している部署に限られているため、変更後に障害が発生することがあった ● ②社内文化としてデータ品質の価値の認識が薄い ○ データオーナー制を引けていない ○ 障害時にデータ基盤側の責任として対応せざるを得ない ○ 改善も限定的な物になってしまう © istyle Inc.

Slide 15

Slide 15 text

アイスタイルのデータ契約の取り組み No.15 データ  ソース統合データ分析基盤データ利用者データ生成者データ生成側とのデータ契約データ提供側とのデータ契約アイスタイルのデータ契約の現在位置データ  提供側 © istyle Inc.

Slide 16

Slide 16 text

  ● 現状、「データ契約」というレベルでは取り組めていない。  ● ソースシステム側にヒアリングして、提供されるデータを確認するという内容で進めている  ○ データ内容のヒアリング  ● ヒアリング内容はスプレッドシートで管理している      ● 提供側とのデータ契約はまだ着手できていない  ○ 将来的に提供側とのデータ契約の取り決めも目指す  アイスタイルのデータ契約の取り組みデータ生成者側データ生成側データ提供側アイスタイルのデータ契約の現在位置 © istyle Inc. No.16

Slide 17

Slide 17 text

● ヒアリング内容はスプレッドシートで管理   ● データベース単位、テーブル単位、カラム単位で質問事項を細分化     ● 質問事項（一部抜粋）      アイスタイルのデータ契約の取り組みデータ生成側データベース単位テーブル単位カラム単位 ● 担当部署・メンション先  ● ER図の有無 ● 物理削除の有無  ● 更新日時として使用できるカラムの有無  ● 完全重複するレコードの有無  ● データのフォーマットルール  ● 個人情報の有無  ● 空文字の有無  © istyle Inc. No.17

Slide 18

Slide 18 text

アイスタイルのデータ契約の取り組みデータ生成側データベース単位テーブル単位カラム単位 © istyle Inc. No.18

Slide 19

Slide 19 text

アイスタイルのデータ契約の取り組みデータ生成側との課題：失敗事例データ品質の重要性やデータ基盤の共通理解が出来ていなかったため、調査の工数を確保できなかった普段の業務に加えて追加の調査工数を割けない・・・そもそもデータヒアリングの目的や背景は何になるの？ © istyle Inc. No.19

Slide 20

Slide 20 text

アイスタイルのデータ契約の取り組みデータ生成側との課題：失敗事例「データ契約にはデータ生成側とデータ基盤側の相互理解が必要であり、生成側の認識・理解度合を基盤側でも把握していなければいけない」 →この事を理解できておらず、データ基盤側中心で進めてしまった © istyle Inc. No.20

Slide 21

Slide 21 text

アイスタイルのデータ契約の取り組みデータ生成側との課題：失敗事例からの学び 1. 目的、背景をしっかり伝えることが大事 a. データ生成側にとって工数を割く価値を認識してもらえなければ、データ契約を進めていくことはできない 2. PJT起案時・開始時にソース側の工数を確保してもらう 3. 説明資料の作成＆データ生成側との説明MTGの実施目的・理由もはっきりしたので、工数を割くことができます！！ © istyle Inc. No.21

Slide 22

Slide 22 text

アイスタイルのデータ契約の取り組みデータ品質の課題 ● スキーマ変更が告知なく行われる ● 区分値の変更を検知できていない ○ →スキーマ変更時にエラーが生じてしまうという課題があったデータ検証の必要性 © istyle Inc. No.22

Slide 23

Slide 23 text

● データ品質管理ツール Great Expectationsを用いてデータバリデーションを行う  アイスタイルのデータ契約の取り組みデータの検証方法データ  ソースデータ基盤到着前とメタデータ付与後の 2 工程でバリデーションを行うデータ  レイク DWH データマート © istyle Inc. No.23

Slide 24

Slide 24 text

● スキーマ変更検知  ○ データ基盤到着前  ■ ソーステーブルのスキーマ情報  ● カラム名  ● データ型  ● データバリデーション  ○ メタデータ付与後  ■ Nullチェック  ■ 区分値チェック  ■ 正規表現によるチェック  ● など  アイスタイルのデータ契約の取り組みデータの検証方法 © istyle Inc. No.24

Slide 25

Slide 25 text

Slide 26

Slide 26 text

● スプレッドシート管理からYAML管理に移行する  ○ YAML移行のメリット  ■ 構造化データとして管理できる  ■ プログラムとの統合性  ● CI/CDに組み込みやすい  ● データカタログに組込むことで提供側の内容確認が容易になる     今後やっていきたいことデータ生成側・データ提供側　共通 © istyle Inc. No.26

Slide 27

Slide 27 text

● Github管理  ○ YAML移行したデータ契約のバージョン管理を行う   ○ プルリクエストを用いた承認フローの確立 ■ データ契約の内容を変更する際、変更側・承認側双方の同意が必要となる   ■ → この承認フローをプルリクエストが担う     今後やっていきたいことデータ生成側・データ提供側　共通この箇所を変更したいです（PR送信） OKです！（PR承認） © istyle Inc. No.27

Slide 28

Slide 28 text

SLOの制定 ○ データ契約を目指す際、SLOの制定は責任を明確にするために必要となる       今後やっていきたいことデータ生成側・データ提供側　共通   ● スキーマ変更時の通知時間  ● データ鮮度  ● etc…    ● データ可用性  ● データ提供頻度  ● etc…  データ生成側データ提供側 © istyle Inc. No.28

Slide 29

Slide 29 text

● データの価値を明確に伝えて、データ生成側にデータ契約の必要性を認識してもらう ○ ソースシステム側にとっては、データ契約を結ぶメリットが少ない  ○ わざわざ自分の担当外の業務に関して、契約として責務を負うインセンティブがない  ■ データ基盤側で基盤が生み出している価値を認識し、ソース側に伝える必要がある  今後やっていきたいことデータ生成側とのデータ契約 ○ データ品質の向上に投資する価値は何？   ○ ビジネスにもたらされるポジティブな効果は？   ○ なぜ他のシステムではなくデータに投資する必要があるの？  © istyle Inc. No.29

Slide 30

Slide 30 text

● データの価値を明確に伝えて、データ生成側にデータ契約の必要性を認識してもらう ○ データの価値を伝えることで、ソース側の工数を確保してもらえる  ○ データ生成者という意識を持ってもらうことで、ソース側・基盤側で共にデータの価値を高めていくという文化を醸成できれば更にＧＯＯＤ  ○ 社内でのデータ基盤の広報活動の実施（エンジニア月次会での発表等）  今後やっていきたいことデータ生成側とのデータ契約データ基盤側ソースシステム側契約内容のデータを提供データの価値を伝える © istyle Inc. No.30

Slide 31

Slide 31 text

● 第一に、提供側とのデータ契約に着手して運用まで持っていく  ○ 「契約」まで行けなくても、提供内容の取決めを行い、双方同意の状態まで進めたい     ● スプレッドシート→YAMLへの自動変換  ○ 提供側はYAMLに慣れていない場合もある   ○ データ基盤⇔提供側のインターフェースとしてはスプレッドシートを使用し、YAMLに自動変換するプログラムを使用する    ● データカタログを使用して、提供側でも契約内容を容易に確認できるようにする    今後やっていきたいことデータ提供側とのデータ契約 © istyle Inc. No.31

Slide 32

Slide 32 text

おわりにアイスタイルではデータエンジニアを募集しています！！データエンジニア 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