【istyle Data Talk #02】ガバナンスの夜明け ～@cosmeの分析基盤を陰で支えるスペシャリスト達～

株式会社アイスタイルでは、データ分析基盤の強化を進めています。
事業部にデータ活用を普及させてゆくには、データガバナンスは必要不可欠ですが、これまで弊社では様々な紆余曲折がありました。
それら歴史を振り返り、改めて「事業部×データ管轄部門でデータガバナンスを向上させる」ための考え方を紹介します。

Transcript

1. ガバナンスの夜明け ～@cosmeの分析基盤を陰で支える スペシャリスト達～
 istyle Data Talk #02
 © istyle Inc. No.0 株式会社アイスタイル　遠山　拓

2. 自己紹介
 No.1 © istyle Inc. 遠山　拓
 Taku Tohyama 
 データ戦略推進室
 
 株式会社アイスタイルに2019年、小売事業のBPR推進メンバーとして入社。
 商品DB統合やプレゼント配送センター移管のPJT推進をしながら、EC・店舗の横断的 な実績ダッシュボードを構築。
 2021年からはデータモデリングを行う部署に移動し、事業部やアナリストにとって使いや すいDB作りをしています。
 謎解きと赤べこ収集にハマっています。

3. 今日のistyle Data Talkを聞いていただくことで…
 No.2 • 我々が経験してきた失敗と学びの歴史を通して、データガバナンスに関する気づき を得ることができる。 • 基盤を構築する際、我々が大事にしていることがわかる。 • 当社が直面している「品質担保」の課題と、それらにどう立ち向かっているのかを知 ることができる。
4. アジェンダ
 No.3 • キーメッセージ • Introduction • ガバナンスの夜明け前 ～ 失敗と学びの３時代 ～ • ガバナンスの夜明け ～ 事業に寄り添ったデータガバナンス ～ • サマリ
5. キーメッセージ：事業部の要件はデータ整備に欠かせない
 No.4 データドリブンな経営を行うには、データ分析基盤は必要不可欠である。しかし、分析基盤は、データ管轄 部門のみでは構築することができない。 事業部の要件に積極的に介入し、要件を構造化し、データ設計に取り込んでゆくことが重要。 事業部 データ管轄 部門 ビジネスロ ジック 業界 慣習 事業 特殊性 DB スキル 仮説 思考 DB構成
6. No.5 Introduction

7. はじめに：アイスタイルにおけるデータの価値
 No.6 認知
 興味
 関心
 検討
 購入
 リピート
 アップセル
 クロスセル
 ロイヤル
 カスタマー
 生活者の購買行動の全プロセスに介在 日本最大級の美容に関する「ヒト・モノ・コト・バショ」のデータを持つ 
 アイスタイルだからこそ、生活者の購買行動の全てのプロセスに介在している。 

8. 今までの変遷と、これからのガバナンスについて話します
 No.7 データ専売の時代 編纂・再編の時代 データ民主化の時代 ２．ガバナンスの夜明け １．ガバナンスの夜明け前
9. No.8 １．ガバナンスの夜明け前

10. ① データ専売の時代
 No.9 どんな時代 だった？ １つのデータ管轄部門が、全事業部からのデータ抽出依頼にフルオーダーメイドで対応 （単発依頼はCSVで、継続的に使用する場合はRedashで提供） 何が大変 だった？ • ロジックの正誤が不安だから、都度テクノロジー部門に確認。 • 「2回以上使います！」⇒ Redash利用実態を見ると、９割が1度しか使われて いない… その裏に 潜む課題は？ データ
 管轄部門
 • システム画面から出せないものは、データ管轄部門に頼るしかない。 • 似てるけどちょっと違うRedashクエリに埋もれる ⇒ 「よくわからないから新規に 作ってください」のループ 事業部
 • データ管轄部門の個人が場当たり的に対応するため、システムや業務の特性を深く知るこ とができず、高品質＆汎用的なデータを納品することができなかった。
11. ② 編纂・再編の時代
 No.10 どんな時代 だった？ データ管轄部門が、過去クエリを元に、データのかたまりをパターン化し、共通ビュー化。さらに BIツール（Tableau）を導入し、ダッシュボード型のデータ提供を開始。 何が改善 された？ 品質の安定 提供手段の充実 店舗販売 サイト来訪 EC販売 アクション 共通ビューを参照することで、データ管轄部門の ″場当たりロジック″ が減り、提供データの品質が 安定した。 ※後の標準DWHに繋がる ダッシュボード型の導入により、前時代よりも柔 軟で汎用的なデータ提供ができるようになった。
12. ② 編纂・再編の時代（つづき）
 No.11 課題は？ 前時代の、クエリと経験の「集積として」共通ビューを作ったため、あらゆる利 用者にとって使いやすいデータとは言えなかった。 数名のデータ管轄部門が、一括してダッシュボードを作っていたため、事業部 が本当に求めるスピードで対応できなかった。 データの 課題 提供方法の 課題 事業部の課題をデータ管轄部門がインプットしつつ、事業部自らデータを扱える ようにするため、事業部に積極的に介入してゆく 事業部の課題に本格的に向き合えていなかったため、業務に浸透させられる ダッシュボードを作ることができなかった。 Action

13. ③ データ民主化の時代
 No.12 どんな時代 だった？ ビジネス課題をスピーディーに解決するため、事業部へのBIツール導入を加速化。データアナリ ストを抱える専門部署が事業部に発足。 何が改善 された？ データの浸透 BIツールが、一部の事業部で少しずつ浸透してゆくことによって、事業部単独で意思決定ができる機会 が増え始めた。 課題は？ データの 課題 データガバナンスよりも「拡大」を優先したため、野良データマートが量産さ れ、″数値が微妙にズレる″ レポートが出来てきた。
14. 振り返り
 No.13 • 場当たり対応であったデータ抽出は、共通ビューによって効率化した。しかし、事業 部を巻き込むまでは至らなかった。
 
 • BIツールの浸透によって、事業部でもデータを扱う土壌が少しずつ育ってきた。しか し、データを出す現場が増える一方で、「どのデータをどう集計するのが正しいの か」といったコントロールをしきれず、数字が微妙にズレたレポートが濫立してしまっ た。

15. No.14 ２．ガバナンスの夜明け

16. 本章の内容
 No.15 Why • なぜガバナンスが重要なのか？ • どんな問題が起こっていたのか？ What • 何をするべきなのか？ • 何がガバナンスのターゲットなのか？ How • どんな考えを採用したのか？ • 具体的にどんな手入れをしたのか？
17. （前提）本章で言う「データガバナンス」とは
 No.16 今回のプレゼンでは、データガバナンスを、「ビジネスにデータを活用しやすくするため、 あらゆるデータ整備とルール作りをすること」と、比較的ライトに定義している。
 
 特に本章では、DMBOK2の定める体系*で言うところの、「データ品質」「データウェアハ ウス」の観点から、データ標準化をテーマとして扱う。
 * 引用元：[Japan Business Press Co.] 継続的なデータドリブン経営に必要なデータガバナンスとは https://jbpress.ismedia.jp/ts/nextdatainnovation/informatica5/
18. データガバナンス欠如は、意思決定の質と速度を下げる
 No.17 Why What How データが無秩序 な状態 取得方法が 難解 抽出ロジックの 思わぬ落とし穴 にハマる 事実と異なる 結果が抽出 されてしまう 重要な意思決定を 誤る可能性 習熟度によって、異 なる結果が抽出さ れる 同じ指標だが少しず つ異なる数値データ が濫立する 社内のコミュニケー ションコストが増大 社外に出せば誤解 を生み、信用を失う 取得するのに時間 がかかる 意思決定が 遅れる可能性 詳しい人に 依頼が集中する 事業部側では データが出せない まま データに明るい 人材が育たない
19. 当社で実際に起こっていた問題
 No.18 Why What How 同じものを指しているはずなのに、数値がズレる データソースが違うと、結果もちょっとずつズレる
 事業部が作った
 ダッシュボード
 基幹システムから
 DLしたExcel

20. 社内で７通りの「EC売上」が並存することに…
 No.19 Why What How 支店の売上を 含む or 含まない 非会員の受注を 含む or 含まない キャンセルを 含む or 含まない 返品を 含む or 含まない 金額に値引きを 含む or 含まない … 理論上、128通り
 調査したところ、社内では現に７通りの「売上」が、
 定義がブラックボックスなままで共存していた。
 

21. 取り組むべきは、「データの標準化」
 No.20 Why What How ① 直感的に扱いやすい形に成形する
 • ECと実店舗は、同じ小売事業のため、
 集約して横串で見られるようにする
 • 「返品」のレコード生成挙動を統一する
 ② 集計値の社内標準を決定する
 • 「売上」に何を含める／含めないを決める
 • 「新規顧客」の定義を決める

22. 事業×データの目線で情報を構造化する
 No.21 Why What How ※ ここは会社によって、構造化の軸は変わってくる想定。
 共通 Master ToC - Transa ction @cosme リテール 広告 BO 販促 会員 共通会員(社員フラ グ含む) プレミアム会員 プロデュース会員 etc... SHOPPING会員/STORE会 員/STOREカード会員/ 会員ランク 商品/ブランド/ 仕入先/カテゴリ その他 アクセスログ ライトアクション系 購買 プレゼント・ サンプル(仮)※ アプリDL クチコミ その他 仕入・在庫 広告・販促売上 ToB - Transa ction プロダクト・バリエーション /@ブラン ド/メーカー /@カテゴリ SKU/ブランド/仕入先(会 社)/メーカー/カテゴリ その他 地理情報/ カレンダー/許諾管理 GAログ/FAログ プレゼント・サンプ ル(仮)統合版 ポイント付与 (何かあれば記入) ランキング /ベスコス /記事掲載 /ブ ログ/商品キーワード /タグ？ @cosme アクセスログ 商品Like/Have/ブランドフォロー / 商品クチコミ Like/コンテンツ Like/brazeデータ？ プレパブ/プレミアム限定/ポイ ント利用プレゼント アプリDL クチコミ投稿 / 画像投稿 ゲームプレイ/スペシャリス トのフォロー （プレゼント・サンプル 在庫） (何かあれば記入) ランキング販路/クーポン/支払 方法/注文種別etc... SHOPPINGアクセス ログ/ストア入店 商品お気に入り/ブランドお気 に入り/カートイン 購買/決済 購入時付属サンプル / 店頭配布 etc... クーポン利用/ポイ ント利用 発注・仕入/在庫 プロモーション関連 費用 事業領域
 データ
 分類
 sample
23. データ標準化の５累計
 No.22 XXX
 集約
 挙動の統一
 基準の統一
 評価・意味付け
 名称の統一
 横断的に分析されるべき
 エンティティを単一テーブルに
 集約する
 • ECと店舗の販売実績を一元化
 • @cosmeの各種プレゼント応募履歴を一元化
 類似した行いなのに、テーブル上の
 処理のされ方が異なるもの同士を
 統一する
 • ECと店舗の「返品」挙動を統一（後述）
 • “deleted_flag”等の「論理削除フラグ」が
 テーブルによって使途が異なるのを統一
 元テーブルに類似した意味合いのカラ ムはあるが、定義が揃っていないもの 同士を統一する
 • ECと店舗の「購入日時」の基準点
 • プレゼント企画の応募日・当選日の統一 etc…
 元テーブルには直接存在しないが、分 析観点で必要なカラムを付与する
 • 「新規／既存」の判定
 • クチコミの品質定義付与 etc…
 ABC
 あいう
 同一概念なのに異なる名称（または異 なる概念なのに同一名称）を、適切な 名称に再編成する
 • 「品番」や「SKU_ID」
 • 「product_id」の氾濫 etc…
 Why What How
24. 集計値の社内標準を決定する
 No.23 かならずしも「ひとつの定義に揃える」のではなく、「標準 + オプション」
 という考え方を採用する。
 標準定義 オプション ふつう「売上」と言った場合は、
 • 支店を含める
 • 非会員の受注を含める
 • キャンセルは除く
 • 返品は含める
 etc…
 必要に応じて条件を変えることで、簡 単に含める／含めないを切替可能。 
 （例）
 • 売上の「会員」比率推移
 • 経理基準に合わせて「返品」分を 減算する
 Why What How
25. トップダウン型のアプローチで社内標準を握る
 No.24 現場層向けポリシーを「標準」として定義。
 事業部 現場層 経営層 経理 経理（財務） ブランド等 ポリシー ある程度の正確性は求められる一 方で、事業を推進するためのス ピーディーさがより求められる。た だし現場間の認識齟齬を防ぐた め、ロジックは明文化されオープン な状態になっていることが望まし い。 経営のコンディションを正しく把握 するため、正確な数値が求められ る。厳格なルールは無いため、運 用しやすいロジック・フォーマットで よいが、きちんと合意形成のされた 定義であることが望ましい。 会計基準等に基づいて計上される ことが求められる。厳格なルール 有。 当社が販売主体である以上、必ず しも厳格に子細を報告する責任は ないが(※)、現場層と同等の状態 になっていることが望ましい。 ※対外的にサービスレベルを定義している ／契約書等で取り決めをしている／売上に 基づく仕入先の費用負担がある場合等を 除く やや厳しい （5%程度？） 厳しい （3%程度？） 最も厳しい （ただし事業部側でこれから定義す るものではない） やや厳しい （5%程度？） 許容誤差 社外 受注ベース （出荷ベースでも見られるように なっているべき） 受注ベース 出荷ベース 出荷ベース 受注ベース 売上基準点 無 ものによっては有 有（月次） 無 締めの概念 Why What How
26. 【事例】売上の「返品」データに苦労した話（１／５）
 No.25 Why What How • 小売の販売データには、過去のトランザクションを消し込む概念として、
 「キャンセル」と「返品」が存在する。
 
 • 「返品」と聞いて、データ管轄部門が最初に想定していた動きは、以下。
 元レコード 受注ID： 001 status：通常 返品日：null 返品済
 6月9日

27. 【事例】売上の「返品」データに苦労した話（２／５）
 No.26 Why What How • ところが、ECの受注データは以下のように、「元レコード」＋「返品レコード（＝反 対伝票）」が生成されることがわかった。
 元レコード 受注ID： 001 status： 通常 返品日：null 返品レコード 受注ID： 002 status： 返品 返品日： 6月9日 元受注 ID：null 元受注ID： 001 受注IDをキーに
 消し込まれる

28. 【事例】売上の「返品」データに苦労した話（３／５）
 No.27 Why What How • さらに、店舗における「返品」は、元レコードが ”受注ヘッダごと” 論理削除され、 「返品されなかった分だけのレコード」が新規作成されることがわかった。かつ、 元レコードとの紐づけキーが存在しない。
 元レコード 受注ID： 001 status： 通常 返品日：null 返品しなかった 商品のレコード 受注ID： 002 status： 通常 返品日： null 元受注ID 元受注ID 返品済
 6月9日
 紐づけキーが
 存在しない

29. 【事例】売上の「返品」データに苦労した話（４／５）
 No.28 Why What How • さらにさらに、店舗では例外的に、レシートが持参されなかった場合も「返品」を 受け付けている。この場合、そもそも元レコード自体が特定できないため、やむを 得ず「返品レコード」が生成されることがわかった。
 元レコード 受注ID： 001 status： 通常 返品日：null 返品レコード 受注ID： 002 status： 返品 返品日： 6月9日 元受注ID 元受注ID そもそもレコード単位で
 消し込まれない

30. 【事例】売上の「返品」データに苦労した話（５／５）
 No.29 Why What How • 現状の受注データでは、ECと店舗の返品時の挙動を、トランザクション単位で揃 えることは困難。
 • ただし、返品データは全体の1%未満であることから、大まかな傾向値を掴む際に は問題にならないと判断し、前述の差異は許容する方針。
 • なお、集計値に関しては問題なく返品を減算する／しないを選択することができ るため、売上標準定義には影響なし。

31. No.30 サマリ

32. サマリ
 No.31 事業部 データ管轄 部門 ビジネスロ ジック 業界 慣習 事業 特殊性 DB スキル 仮説 思考 DB構成 安心安全なデータを用意するためには、事業部が持っている情報は必要不可欠。 一方で、それを解釈し、トップダウン型で構造整理し、わかりやすい形で双方と握ることも 非常に重要。
33. No.32 おわり