データ分析基盤の信頼 を支える視点と設計 データ品質向上における基礎＆ステップアップの道のり @ファインディ　 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