データ分析基盤の信頼を支える視点と設計

データ分析基盤の信頼を支える視点と設計データ品質向上における基礎＆ステップアップの道のり @ファインディ　 YUKI SAITO 2026/05/25

@yuki_saito_en 斎藤友樹(SAITO YUKI) 2 https://menta.work/plan/2650 https://www.udemy.com/user/yuki-saito-7/ @yuki_saito_en https://service.visasq.com/users/6078548267368448 趣味に生きる人(エンジニア)
https://note.com/yukinkoyuki

@yuki_saito_en 3 説明できるか良い分析基盤は妥当性を説明できる

@yuki_saito_en 4 今日のゴール：品質を「説明できること」として捉え直すテストを増やすだけでは、データは信頼されない。設計・メタデータ・運用を通じて、なぜ正しいと言えるのかを説明できる状態にする。観点ありがちな理解今日持ち帰る視点品質へのアプローチ
テストや監視を増やして不具合を見つけること信頼できる理由を説明できること品質問題の捉え方欠損・重複など、個々のデータ不具合の問題意味・変更・責任分界の問題改善の進め方クレンジング、名寄せなどを個別に積み上げること設計・記録・運用に戻して仕組みにする

@yuki_saito_en 5 なぜ、「説明できること」が大事なのか名前が変わっても失敗構造は繰り返す。だから、主観要件を含めた品質・運用の説明可能性をあげる必要がある歴史を振りかえると... 以下の問題に対処せず概念のラベルだけが付け替えられている • 技術複雑性を説明・運用できない •
BIツールやAI Agentが発達しても認知能力を配れない • 指標を統一すれば、組織間の調整や責任分界も自然に解けると思ってしまう本書の対応箇所基本編: 8章実践編: 1章

@yuki_saito_en 6 品質が低下する原因を理解する一般に、(データの)品質は時間とともに逓減する t 品質レベルシステム不具合・プラットフォームの不具合インフレなど指標の変化規模の拡大(プラットフォーム起因、ドメイン起因) 本書の対応箇所
基本編: 7章退職・担当者変更

@yuki_saito_en 7 品質のテストコードはデータを説明できるか品質テストは「決めたこと」の説明に特化している。逆にカバーしにくい範囲は変化をどのように吸収するかを考える決めたこと・壊したくないこと (品質テストでカバーしやすい範囲 ) 規模拡大性能劣化や運用負荷、人の認知負荷
指標の変化指標の意味が変わった、インフレで閾値が妥当でなくなった退職や担当変更背景知識、暗黙知、なぜこの定義なのか規模拡大件数異常、NULL率、遅延指標の変化定義済みの制約退職や担当変更既存のテストコード品質テストでカバーしにくい範囲本書の対応箇所基本編: 7章実践編: 6,7,8,9章

@yuki_saito_en 8 設計を通じて説明可能にする設計は、将来の変化を吸収するために残す最低限の情報のこと例:上流仕様が変わったらどうするか？への回答として　データ分析の文脈ではメダリオンアーキテクチャ※ が有名　 ※将来の変化に備えて、壊れやすい場所を分離し、変更しやすい形にする設計のこと
STEP 1 セマンティック(オントロジー)層 rawデータ品質保証データモデリング済みデータ Analytic Base View Aggregated View 利用者のほとんどはこのデータを利用ビジネスロジックはできる限り後ろに配置することでパイプラインの変更箇所を限定する Viewにより計算ロジックの変更を容易に。 (物理の場合指標変更のたびに再作成が必要) rawを残すことで再処理できる修正漏れを減らす新しい分析軸を追加しやすくする本書の対応箇所基本編: 2章実践編: 2,5章後続処理で品質確認を繰り返さずに済む

@yuki_saito_en 9 メタデータを通じて説明可能にするメタデータはデータの歴史(決めたこと変わったこと)のこと例:リネージュを2次元の広がりでみた場合と多次元の広がりでみた場合の比較 STEP 2 Table A Table
B Table C Table D 2次元のリネージュ 2次元の場合時間的な広がりはなく ”今”のみを表現する。多くのツールは 2次元のリネージュに対応している 3次元のリネージュ Table A Table B Table C Table D 時間軸を付け足すことで、歴史や履歴の入力はツールでは対応できずデータ基盤のユーザーにかかっている Table A 本書の対応箇所基本編: 6章実践編: 7,9章

@yuki_saito_en 10 理解すべきドメインを減らし、認知負荷を抑える認知の負荷の大きさは理解すべきドメインの多さに比例する。また自身の生活に近いドメインほど理解しやすい。例:データクレンジングによるドメインの排除により認知負荷を抑制する例 STEP 2ʼ 本書の対応箇所実践編:
7章 id 12 12 1 データは重複していて、桁数もバラバラであるビジネスメタデータ idは2桁で構成されるがテスト決済用の1桁のデータが存在するデータの不具合により重複データが存在するログインユーザーが商品を購入した時に採番される一意のID システムドメインビジネスドメイン id 12 ビジネスメタデータログインユーザーが商品を購入した時に採番される一意のID 重複等を削除クレンジングにより不要なドメインを排除すると、ビジネス上の意味に集中しやすくなる

@yuki_saito_en 11 運用を通じて説明可能にする変化を取り込みながら、データを使える状態に保つ仕組み例: データ品質の問題は下流のテストや監視だけでは解決しない STEP 3 リアクティブな対応のみの場合リアクティブ+プロアクティブな対応の場合
データソースデータ分析基盤側だけで名寄せ・補正・不整合対応を続けると、原因が上流に残り続ける。データソースデータソース側と、 SLO・体制・プロセス・自動バリデーションを合意し、期待値と実績を相互に監視できるようにする。 ※データコントラクトといいますデータ分析基盤 Raw 名寄せ(名称揺れ)・オーグメント・ etc Proces sed データ分析向けの変換データ分析基盤 Raw 名寄せ(名称揺れ)・オーグメント・ etc Proces sed データ分析向けの変換本書の対応箇所実践編: 6章

@yuki_saito_en 12 データ分析基盤の価値を説明可能にする成果の非対称性の対策として基盤全体の価値が発生する場を作る本書の対応箇所実践編: 11章組み合わせ例説明できるようになること
設計 × メタデータ指標定義、キー設計、ゾーン設計、責任者をメタデータとして残すなぜこのデータ構造・指標定義になっているのかメタデータ × 運用鮮度、件数、欠損率、リネージュ、利用状況を監視に使うどこで問題が起き、どこに影響するのか設計 × 運用 SLO、データコントラクト、変更手順、障害対応フローを設計に組み込む変化や異常をどう吸収し、誰が判断するのか 3観点すべて利用状況・品質状態・責任分界・改善履歴をつなげる基盤が売上・費用・利益にどう効くのか（成果の非対称性への対策）

@yuki_saito_en 13 まとめ：良いデータ分析基盤は、妥当性を説明できる良いデータ分析基盤は、「なぜ正しいと言えるのか」を説明できる。・品質は、テストを増やすだけでは支えられない・設計・メタデータ・運用で、意味・変更・責任を説明できる状態へ・積み重ねが、データ分析基盤の妥当性と価値を説明可能にするデータ分析基盤も、作って終わりではなく、説明しながら育てるもの

@yuki_saito_en ありがとうございました 14

データ分析基盤の信頼を支える視点と設計

データ分析基盤の信頼を支える視点と設計

Yuki

More Decks by Yuki

Other Decks in Technology

Featured

Transcript