背景・目的

最近、読んだ実践的データ基盤への処方箋が、実践的かつ自分が知らないことがあり、興味深かったので、知識を整理する目的で投稿します。
データ活用に関わる方は、読むことをお勧めします。
本ページでは、データ活用のためのデータ整備について整理します。

前提

第一章〜第三章はデータ、システム、ヒトの３つの観点で解説されています。
本書は、以下で構成されています。
- はじめに
- 第一章データ活用のためのデータ整備 ※ 本ページの対象
- 第二章データ基盤システムの作り方
- 第三章データ基盤を支える組織

#結論

データソース
- 分析はデータソースの整理から。
- GIGOに陥らない。
- データの品質は、データソースで作る
  - CRUDとE-R図でユースケースで必要なデータソースが担保されているか可視化する。
  - データ項目の意味を確かめる。
    - ホモニム、シノニムがないか確認する。
- 直す場合は、調整が必要。
  - 組織間の対立が生まれやすいところでもあるので丁寧に。
  - インセンティブを考える。データ生成部門のミッションにも理解を示すこと。
データレイク
- 1つだけつくること。
- 加工しないでそのままコピーすること。
ツール
- ユースケースから先に考える。
データ基盤は、ITシステムではなく、ITサービスである。
データスチューワードは、ITサービスの品質を支える重要な役割。

#内容

第一章データ活用のためのデータ整備

本書は、おおまかに以下のように構成されています。
- データの流れを把握する
- データの品質の担保について
- データが生じる現場を把握して業務改善につなげる
- データソースの整備について
- データソースのコピーを集約する
- 共通指標の管理
- 共通指標の選び方
- データマートの作り方
- ユースケースを軸にしたツールの整備
- メタデータの活用
- サービスレベルの設定とPDCA
- データスチュワードの役割
以降、書かれている内容をざっくりと整理します。

データの流れを把握する

データソースからユースケースまでの流れを以下に記載する。（書籍では、図解付き。）
- 例は、仮想のECサイトを題材としている。表にすると分かりづらい。書籍では図でとてもわかりやすい。

	解説	例
データソース	オリジナルデータ、または発生源を指す。顧客がECサイトで注文するとDBに購買履歴が記録される。または、材料の仕入れや商品の輸送については、紙の台帳で管理しているかもしれない。	通販サイトの購買履歴、会員情報等
データ収集	データソースからデータを集める仕組み。ECサイトのDBから記録を出したり、紙の台帳をデジタルに記録したり、データを収集する。システム開発の比重が強い。	転送システム
データレイク層	多様なデータを集約する場所。データソースをそのままコピー。またはそのデータの置き場を指す。加工・結合しないコピー。データマートと1:1の関係	通販サイトの購買履歴
データウェアハウス層	加工・結合したデータを置く場所。共通指標となるデータ。またはその置き場所。自社ECだけではなく、外部のWebサイト、オフラインイベントでも同じ商品を販売している場合、それらも組み合わせて売上という横断の指標を売上という横断の指標を集計する。	売上
データマート層	加工・結合したデータ。特定用途向けデータ。ユースケースと1:1	毎週のジャンル別の売上、毎月の売上
ユースケース	データ基盤の用途。経営者がダッシュボードツールで、毎週のジャンル別の売上を確認する。キャンペーン担当者が特定の顧客層にシステムでクーポンを配布する。など	モニタリング、クーポン配信等
メタデータ	データを説明するためのデータ。データの利用状況を確認することで、促進のヒントを得たり、トラブルを検知してその対策につながったりする。

自社のデータの流れを洗い出すには、CRUDでマッピングすると良い。
複数のステークホルダーが登場するため、用語を整理することで齟齬を失くす。

データの品質の担保について

データソースは、オリジナルデータを指す。
GIGOの考え方。ゴミ入れたらゴミ出てくる。適切なデータを取得しないと適切な分析ができない。
- データ分析だけではなく、そもそも業務が回っているかも怪しい。
上流の問題を下流でカバーするのに、問題は解消されない。労力はかかる。
- 自分も、似たような体験あり。とても大変。
- きちんとデータ生成者にフィードバックするべし。
データの生成過程を知ること。
- ユースケースで求めるデータを得るために、データの生成過程を押さえることが重要

データが生じる現場を把握して業務改善につなげる

データの全体像を把握するには、CRUD表が役に立つが、ここのデータソースの詳細を把握するためにE-R図（ERD)が有用である。
- ERDがなければ、作成する。
- 細部まで落とし込んで読む。
  - 分析するときに、過去データが存在しないなどに気づける。
- ユースケースの目的が達成できない場合、データソースに記録するように働きかける。（ログ要件を伝える。）
業務レイヤを書く。
- ロール、オペレーション、アプリケーション、ストレージの4つのレイヤに分解して整理する。
- 整理することで、実現したいユースケースの課題が見えてくる。
  - 対立を生まないように課題を調整する。

データソースの整備について

問題になりやすのは、マスタ、共通ID、履歴
マスタの課題。
- ジャンルやカテゴリなどの表記ゆれ
- 各部門ごとに独立して業務を行う場合に起こりやすい。
- 解決策としては、部署横断のマスタデータと入力マニュアルを準備する。
共通ID
- 同一商品だが、別名や別IDで登録されている。
- 別商品だが、同一名称で登楼されているなど
  - あるあるだな。
- ECサイトであれば、共通商品IDを発行する。
履歴データ
- 商品の説明文などを更新してしまい、履歴に残していないため、どの説明のときに売上が下がったのかなどの分析ができない場合がある。
- 分析以外の業務でも必要になる。
  - CS、リーガルなど
- 履歴に残すには、非正規化する。

商品テーブル（顧客がECサイトを介して登録）	編集履歴テーブル（CSが参照）
ID	商品ID
名前	名前
説明文	説明文
-	編集日時

データソースのコピーを集約する

データレイク層とは？
- 元のデータをコピーして、1つのシステムに集約したものを指す。
- データソースと1:1の関係。何も加工してない。
- 修正や、加工しないでそのまま集約する。
データレイクの作り方。
- オブジェクトストレージか、DWH製品で作ることが多い。
- 転送する方法はETLツールが多い。
- デジタル化されていない場合、紙→スキャナで画像ファイルなど。
  - 言っていることは理解できるが、このような現場に出くわしたことがなく想像しづらいな。。
データレイクの課題
- データレイクは、シンプルにコピーするだけだが、課題がでる。
  - 元のデータをそのままコピーしない。分析用に集計してしまう。
    - 同じデータをコピーするだけならITインフラのコストが無駄。
      - これは、昔言われたな。
    - 元データのままでは、使いづらいので加工するなど担当が良かれと思って対応するが、後ほどデータ活用が進むとやりたいことが変わり対応できず問題に発展する。
      - 月単位にサマったが、Daily単位で見たいなど
    - 加工後のデータが使い物にならない際に、調査するコストがかかる。最初からコピーだけしておく。
  - 複数箇所にデータレイクを作る。
    - 数値が一致しないケース。
      - これも、あるある。
    - 全てのコピー箇所で同じように修正が必要。オプトアウトなどで個人情報を削除する場合など対応も複数必要。
なぜ一箇所に集めるののか？
- データレイクは、部署横断で複数のデータを集約する場所。
- 部署・システムを横断してデータを活用することで、顧客体験やビジネス価値を向上できる。
  - 集客部門とカスタマーサポートがExcelでそれぞれの部門のデータを管理していた場合、集客はキャンペーンやクーポンの発行情報といったデータを持っているが、CSに顧客からキャンペーンに関する問い合わせが寄せられてもデータが集約できてないと、満足できる回答はできない。
  - データ活用が進み、データを統合できると、それまではわからなかった次のような事実が可視化できる。
    - クーポンをきっかけに流入した顧客はすぐに解約する。
    - クーポンで流入した顧客のサポートに労力を費やしていた。
    - トータルで見ると、クーポン配布キャンペーンは他施策と比べてROIが低い.
  - 集約できないと、ひとつひとつデータソースを開いて確認するので大変な労力。

共通指標の管理

共通指標となるデータ、その置き場所。
共通指標を集計する理由
- 部署横断のデータ活用は進まない。
- 横断的な指標は、一箇所に定めておくことが重要
  - SSOT（Single Source of Trust：信頼できる唯一の情報）
- 部署ごとに、用途によって売上の定義が異なる。
  - 消費税含むのか
  - 割引率は？
  - 年契は？
  - 途中解約は？
  - 返金は？
- ある部署の視点だけで考えると、他部門と乖離する。
分析用DBで共通指標を集計、管理する理由
- 他のツールから参照される前提で作られている。様々なユースケースで用いられるツールと適切に連携できるのが特徴。
- 表計算ソフト、Tableau、RedashなどのBIツールは基本的に他のツールから参照されることを前提にしてない。多様なユースケースに対応できない。
  - BIツールで、売上を集計していたがレコメンド機能で利用しようとした場合に、売上の集計ロジックやデータはBIツールオリジナルのため対応できない等。
    - 以前、このアンチパターンで作っていた。

共通指標の選び方

DWHの作りかた。
データクレンジングのあとに、加工や集計を行い、スタースキーマと共通指標を作成して管理する。
- データクレンジング
  - 欠損埋め、重複削除、名寄せなど
- スタースキーマの作成
  - 例えば、購買履歴（ファクト）＋購買日時（ディメンション）のスキーマなど
- 共通指標の集計
  - 例えば月次売上など
上記をワークフローエンジン等のツールを用いて定期的に一連の集計プログラムを実行する。
集計が完了したら、集計結果を保存する。
データ量が多い場合は、注意が必要。
- パフォーマンスやコストの問題が顕在化する。
以下の手順で作る。
1. クレンジング
  - DWH層では最初にクレンジングを行う。直さないと誤った分析結果を招く。
2. スタースキーマ
  - DWHでは、分析用の顧客テーブルのように横断でデータを管理することになる。代表的な手法がスタースキーマ。
    - スタースキーマの他にスノーフレークスキーマがある。これらをディメンショナルモデルという。
  - ファクトテーブル
    - 関心対象となるイベントの発生毎に1レコードで表現したデータ
    - ECサイトに1人の顧客が1つの商品を購入したら、購入履歴に1レコードが追加される。ファクトテーブルの1レコードは分析対象となる粒度を設定する。
    - 一度の決済で複数商品を購入した場合は、商品ごとにレコードを分割する。
  - ディメンションテーブルは、分析の切り口となる属性値
    - 購入履歴なら、購入日時、購入金額、購入者などが紐づく。
    - ECサイトだけではなく、オフラインでも販売していれば購入場所を属性場所として付与する。
    - 7W3Hで属性を洗い出すことができる。
      - いつ
      - どこで
      - だれが
      - 何を
      - なぜ
      - だれに
      - だれと
      - どのように
      - どのくらい
      - いくらで
  - ECサイトや店頭POSなど各システムが持つDBには、それぞれのシステムが機能要件を満たすためのデータが格納されている。
  - それらのデータを統合してディメンショナルモデリングを行うことで、ここの役割に閉じずにビジネス全体に撮って意味のあるデータを表現できる。
3. 共通指標の集計
  - スタースキーマを用いて、共通指標を集計する。
  - 例えば、ECサイトの人気商品を月次でモニタリングするには、購入履歴について、年月、商品、場所などのディメンション（切り口）で売上、購入数を集計する。これらの共通指標で月次モニタリングが可能になる。
DWHを作るタイミングについて
- 早すぎる最適化を行いがちだが、失敗することがある。自社にとっての共通指標とは何かをわからないまま想像に基づき設計し、実態にそぐわない共通データが出来上がり利用されない。
  - これは、学び。確かにありそうだ。
- データマートが使われる様になった後に、DWH層の設計に着手するのがよい。
  - 以下のように先に両端を充実させる。（書籍では、図で解説している。）
    - データソース→データレイク
    - ユースケース→データマート
- 最初にデータマート層を作成する場合、データレイク層を直接参照する。
- データ活用施策を成功させる。つぎに共通指標が明らかになってから、DWH層を作成する。
- 段階的にシステムを進化させる。
  - 学び。このアプローチは納得。

データマートの作り方

データマート層とは
- 特定の利用者、特定の用途向けに加工・整理したデータ、データの置き場を指す。
- すぐに使える完成品を取り揃えているマート
- ユースケースと1:1
  - DWHの購買履歴を元に、毎週のジャンル別の売上を集計している場合、その集計データがマートに相当する。
- マートが充実するにつれて、重複した集計が出来上がる。この時点で、マートかDWHか判断できない場合は、時期尚早なのでデータマートにおいておく
ユースケース毎にデータを管理する理由
- 影響範囲を制限できる。
  - ユースケースと1:1の関係にあるため、他部門、多用途への影響を気にせずに、集計ロジックをアップデートできる。
  - 影響範囲を制限できるので、試行錯誤できる。
- 集計ロジックを再利用できる。
  - ユースケース毎にデータを管理すると、既存の集計ロジックを参考にできる。
- システムのレスポンスタイム（レイテンシ）が速くなる。
  - ダッシュボード画面を表示する度に複雑な集計処理が必要になると、何分もまつことになる。
  - 事前に複雑な集計処理を済ませる。
どのようにデータマートを作るか
- データレイクと、DWH層のデータを抽出し集計を行う。
現場で生じるデータマート層の課題と解決方法
- メンテナンス難が生じる。
  - 部署ごと、用途別に特化しているため、個々のデータマートにガバナンスが効きにくい。
    - データマートが多すぎる
      - 役目を終えたマートが放置され、似たようなロジックが散財する。
      - 誤った分析結果を招く。
      - クリーニングの仕組みを組織横断で担保する。
    - ツールが分断される
      - BIやExcelなどで集計したため、集計ロジックがツールに分断され横断で依存関係を管理できなくなる。
- データマート作成時に2つのステップを経るように案内する。
  - 最初の試行錯誤はBIツール、表計算で行う。各部署にとって使いやすいツールで試行錯誤してもらう。
  - データ活用が運用に乗ったら、集計ロジックをSQLに書き換えて定常的に実行できるようにワークフローに組み込む。

ユースケースを軸にしたツールの整備

データ基盤の用途を指す。
ビジネスとデータは不可分。あらゆる部署、あらゆる業務でデータ活用のチャンスがある。
現状と理想のギャップを把握して改善アクションを促したり、人間が判断しなくても自動で処理できるようになったりと、ビジネス価値を創出できる。
なぜユースケースに着目すべきか
- データ基盤を作るのはユースケースを実現するため。
- 技術的に難易度の高い挑戦をしても、活用施策が満足行かなければビジネス価値はない。
- 赤字を垂れ流すだけのシステムは持続できない。
- 開発・運用コスト＜ユースケースの便益という状態を目指す。
  - ユースケースの便益以上に開発や運用に手間を掛けるのはNG。
    - 週次のレポートにリアルタイム集計は不要。
    - 月曜日の深夜に障害を出しても私生活を犠牲にしてまで障害対応を行う必要はない。
      - ** あるある。**
- 最初にユースケースから検討すること。データの活用方法を描いて、ゴールから逆算する形で、データ収集・整備の投資判断を行う。
  - ** これは本当に大事。**
ユースケースを定めかた
- 最初に、自社あるいは担当事業について、目標、現状、課題、施策を洗い出す。
  - 中計などを元にする。例えば以下のようなもの。
    - 3年後の目標
      - 売上50億円＝顧客50万人＊単価1万円
    - 現状
      - 売上30億円＝顧客30万人*単価1万円
    - 課題
      - 顧客数＝新規登録10万人＋継続利用20万人（去年からの解約10万人）
    - 施策
      - ①.デジタル広告配信による登録促進
      - ②。解約候補者へのクーポンメール配信
  - 実務においては、これらを詳細まで検討。（調査・分析を行う）
    - 登録過程のどこを改善すると効果的か
    - 何を改善すると解約すると減らせるか
    - 優良顧客の解約で平均単価が下がるリスクが有るか
- 導入後のモニタリング項目
  - 導入したツールは活用されているか
  - 期待する効果が得られるか
  - 想定外のトラブルや労力が発生していないか
- 導入前の想定と現実の活用状況にギャップが有る場合、改善策を講じる。
現場で生じるユースケースの課題
- ユースケースを考慮せず、システム開発者目線で作ると使われない。
  - データを見るときにこのツールを使ってください。という場面。
- データ基盤担当者は、「部門、役割によって最適なツールが異なる。」ことを念頭に置くべき。
  - 自分にとって使いやすいツールが、他の役割を担う人々にとってベストではない。
  - よくある話。

メタデータの活用

メタデータとは、このデータは、何のデータかを説明する情報。
メタデータ候補の例
- データの作成者
- データの作成日時
- データに個人情報が含まれるか
- データは文字列か数値か？（データタイプ）
- 単位（円？cm?）
- データが誰にどのくらい参照されているか
  - 個人的に重要だと思う。
- データを保管する義務のある期間
  - 法令要件などある
ETLツールなどでコピーされた日時を入れ、いつもデータが作成される時間帯が分かる。
メタデータを管理する理由
- 活用の現場では、データの正当性の調査に多くの時間を割いている。
  - これは、本当にそうだな。明記しないことでグレーゾーンができあがり、余計なコストが発生する。大企業であればあるほど。
- 作った人は、理解しているから必要性がわからないが、利用する人はわからない。また、時間の経過とともにわからなくなる。
- メタデータの使い所
  - データ収集の参考情報（テーブル名、カラム名など）
- DWHを作るときにDL層をもとに集計ロジックを作る
- マート層を作るときに、DL層やDWH層のデータを把握して集計ロジックを作る。
- データ基盤トラブル時に、誰にどのデータがどのくらい参照されているかを調べてアナウンスする。
  - この使い方は、有用そう。
メタデータの管理方法
- 分析用DB、メタデータ管理ツールを利用する
  - 分析用DBであれば、監査機能がある
  - データソースとDL層であれば、各データの説明文を記載する。
  - DSがMySQL、PostgreSQLなどであれば説明文が書ける。
  - DWH層、DM層であれば、ワークフローエンジン、ETLツールを用いて該当のメタデータを扱う。
現場の課題と対処方法
- まずはデータベース説明文を書く。
  - 専用ツールや専門部隊を導入すると挫折することがある。
    - データソースが多様化すると専用ツールの開発や、情報更新が追いつかなくなる。
    - 予算がつかなくなるなど、データ整備のツール・体制への継続投資が難しくなる。
    - リソースが足りなくなるとメンテナンス不足によりメタデータが十分に更新されない。現場とニーズとのギャップが広がり続け徐々に使われなくなる。
- メタデータがないと困る利用者（アナリストなどのデータ活用者）だが、一方でメタデータを更新できるのはデータ生成者。
  - メタデータを作成してもらう重要性や意義などを理解してもらわないと、反発がある。
  - データソースに一番詳しく、内容に責任を持っているのはそのデータを生成する人たち。
  - ビジネスや製品の変化によるデータソースの変化を誰よりも早く正確に検知できるのは、データ生成者。
  - データ生成者を巻き込むことが必須。
    - 確かに、これは重要。

サービスレベルの設定とPDCA

サービスレベルは品質水準を表現したもの
サービス品質は、以下に分けられる。利用者は、システムにアクセスしたら整備済みのデータを利用できる。という体験を期待している。（簡単にアクセスできる便利さ＋整備済みのデータを使える安心感）
- 便利
- 安心
サービスレベルの改善は、以下のサイクルを通して改善することが望ましい。
- 目標設定
- 関係者との合意
- 現状の計測
- 課題の特定
- 必要な施策の実施
- 結果の振り返り
サービスレベルを計測する理由
- サービスの品質改善では、システムではなく、サービスに注目する。
  - データを整備したが使われない場合、ITシステムを整備して満足している。
  - ITシステムではなく、ITサービスに着目する。
  - ITサービスは、ITシステムを包含してる。ITサービスは、ITシステムの使用方法をレクチャー、ITシステムのトラブル時のサポートを受けるなどITシステムに付随する体験も含めた概念。
- 計測しない場合、何をどれくらい改善すればよいのか判断できない。
  - 関係者の合意形成も難しい。
  - 目標達成しているが、無駄な投資を続けているなど
サービスレベルの設定、計測方法
- サービスレベルの目標設定
  - ユースケースをヒアリング
  - ユースケースにおいて暗黙的に期待されているサービスレベルを可視化する。
    - ユースケース毎に品質は異なるので、ユースケース毎に設定すること。
    - 以下に例を記す。

UC	約束相手	連絡先・周知先	利用データ	約束事項	違反時の影響
日次レポート	ディレクター	Slack	BQの売上テーブル	毎週営業日の午前X時までに欠損なく、前日の売上がレポートされること	売上状況に応じた施策が打てなくなる。（機会損失）
・・・	・・・	・・・	・・・	・・・	・・・

現場で生じる課題と対処方法
- 過剰な品質目標を設定していないか注意する。
  - 複数のユースケースのどれを優先するのか
  - セキュリティ、利便性をどれだけ担保するのか
  - 全てに対して実施すると、身動きが取れなくなる。
- 「人が不足している」という話は、足りてないのは人材ではなく品質のコントロールであることがある。
- PIIは扱うと厳密に管理する必要がある。反対に財務データは自由にアクセスできるように設定するなど。

データスチュワードの役割

スチュワードは、執事、世話役の意味。
データ整備の推進者
LINEさんや、メルカリさんでは、データマネージャーと言うロールらしい。
データスチュワードの必要性
- データ基盤のサービス品質を担保するために不可欠。
- 利用者から問い合わせを受け、課題を検知し、データ基盤全体のサポートや利用促進と言った総合的なサービスを提供し対処する。
- メタデータ、DWH層を充実させることで、根本的な課題を解決する。
- データソースに課題があれば、データ利用者が困っている点をデータ生成者に対して、フィードバックする。
- 現状のデータソースの形式になった背景・事情をデータ利用者にフィードバックもする。
- 間を繋ぐ役割。
2つの役割が求められる
- 問い合わせ対応
- データ整備の推進
問い合わせ対応によって、データ利用者の要望やユースケースを把握する
- ユースケースを実現できるだけの品質をサービスレベルとして定義する
- 品質水準や利用状況をメタデータで計測する
- 目標と現状の差文から課題を検知して解決策を検討する
- データソースを整える。
- データレイク、DWH、データマートを整備する。
現場の課題と対処
- データスチュワードは、問い合わせ対応などの受動的な活動と、品質改善の能動的な活動の正反対を両立する。
- 問い合わせに工数を割くと、品質改善に工数を割けない課題が出る。そうする問い合わせが減らず、更に工数を割くことになる。
- まずは、現状を可視化し、バックログで管理する。

#考察

このデータ整備では、きれいなデータを揃えること、データ基盤を運用し続けるための考え方が書かれていた。
かなり重要な事が書かれているので、何度か読み返して自分のものにする。

#参考