唯一の“源泉”を創るデータ統合プロジェクトのリアル

2025 7/17 16:00~ Yuki Saito
17-B-8 セッション　Data Architect@SOMPO HD.inc

Transcript

1. 2025 7/17 16:00~ Yuki Saito 17-B-8 セッション　Data Architect@SOMPO HD.inc 唯一の“源泉”を創る データ統合プロジェクトのリアル 1
2. About SOMPO Group 2 安心・安全・健康をお客さまや社会に届けるため、SOMPOグループはコア領域である国内損保、国内生保、 海外保険、介護・シニア領域およびデジタル等の新たな領域における事業を通じて様々なサービスを提供します
3. 3 Who we are SOMPO Digital Labは、SOMPOグループのDX推進のため、 進化するデジタルテクノロジーを追求していくイノベーション部門です R&Dチーム、内製開発チームやデータサイエンティストなどにより構成されており、 デジタル・データを活用した「安心・安全・健康」の体験価値の提供を目指しています 詳しくはこちら（SOMPO Digital Lab サイト）
4. 自己紹介(YUKI SAITO) About Me 4 SOMPO HDでデータエンジニア(アーキテクト)をやっています ごちゃごちゃしたことをじっくり整理して言語化することが好きです 娘達の成長速度に負けないように1日一個新しいことを学んでいます https://menta.work/plan/2650 https://www.udemy.com/user/yuki-saito-7/ @yuki_saito_en @yk-st https://note.com/yukinkoyuki
5. We are Hiring!! Hiring!!!! 5 データ分析基盤の構築からデータガバナンスの確立までを担う データプロフェッショナルを募集しています！ カジュアル面談も随時受付中です！ Devサミ見た！ とお伝えいただけると 嬉しいです データエンジニア データアプリエンジニア データサイエンティスト https://sompo.io/ja/recruit/data-engineer https://sompo.io/ja/recruit/data-app-engineer https://sompo.io/ja/recruit/data-scientist
6. Actions “源泉統一”への道 6
7. データソースとペインポイント 7 Chaos of Daily Pain 代理店さん 部門 システムA 部門 システムZ ・分析場所の分散による指標 のブレ ・部門システム固有のフラグの 追加による複雑性増加 ・クローズドな環境化による暗 黙知化の増長 収入系 (保険料) 契約計上 清算・収納 システム 成績 システム ※理解のために 簡略化しています 経理会計 システム ・分析場所の分散による指標 のブレ ・部門システム固有のフラグの 追加による複雑性増加 ・クローズドな環境化による暗 黙知化の増長 分析 出金系 (保険金) お客様 事故受付
8. こうする 8 Solution of Daily Pain 代理店さん 部門 システムA 部門 システムZ 収入系 (保険料) 契約計上 清算・収納 システム 成績 システム ※理解のために 簡略化しています 経理会計 システム 出金系 (保険金) お客様 事故受付 数値指標はこれを使おう
9. ご参考:実際のデータソースのシステム構成図 (ぼかし) 9 Detail of DataSouces 利用
10. 何をしたのか 10 What have we done データ/品質の調査 名寄せ パイプライン作成 カタログ作成 データマート公開 運用ルール Next Horizon モデリング セマンティックレイ ヤー コンシステンシー 調査 制約の調査 Early Wins ガバナンス テクニカルライティ ング データの拡張 制約排除 数値 指標 これ 数値確認 決定論 マッチング ドメイン知識 リネージュ
11. データとデータ品質の調査※ 11 1. エクスターナルコンシステンシー (外部整合性)の調査 a. 火災のデータ（A部署、B部署でそれぞれ持っている）７００万件のうち Aにしかないオーファンレコードが２万件 あることが判明（これらを利用して全体的な合意形成 (精度の見通しなど)を図る） b. 一部の契約で証券番号が見入力、桁数が揃ってない。等は割とざらに存在する 2. 「妖怪1合わない」と戦う a. 求めている数値と合わないー＞システム障害により一つのレコードに複数の計上の数値が混ざる b. 別事業部算出の結果とも合わないー＞ そのデータへの理解と説明が発生 3. 決定論的マッチング(メタデータの名寄せで利用 )を利用して一致を調査 a. 理由がつけばマッチとして、名称やデータを名寄せする（あくまで見えている範囲） b. 調査にはデータ分析基盤に付随のデータプロファイリング機能を大いに活用 Investigate Data Quality データ/品質の調査 パイプライン作成 カタログ作成 データマート公開 数 値 指 標 これ ※データが多いため、2023年度のデータに絞って確認
12. ご参考:(3Stepで見る)決定論マッチング 12 Deterministic Matching 種目 A1 B0 C0 D9 Step① 基本ルールとして Aテーブル「種目」「区分」＝ Bテーブル「種目」を作成Join等 で検証 Aテーブル Bテーブル Step② 一致しないものも説明可能であれば 一致(や無視)とみなす(ようにデータは変更する) Step③ 公式名称(マッピングマスタ/用語集等より)を採用 種目 区分 A 1 B 0 0C 0 D 種目 A1 B0 C0 D9 正規化後 Aテーブル
13. データパイプラインの作成※ 13 1. カタログ駆動で制約の解除を意識しながらパイプラインを作成する a. 社内の標準名に名寄せし統合 i. B列とC列を連結してA列を生成し、そのメタデータを社内の標準的な用語である A列とする。など b. 品質で調査したルールに従って機械的に名寄せ処理を追加 2. スタースキーマを持ちいて正規化 (Silver層)から最終的にワイドテーブル (Aggregated View)で提供 a. 将来のセマンティックレイヤー連携の可能性のため (全社的にセマンティックレイヤーを利用する文化がある ) 3. ビジネス計算ロジックはできる限り後ろに寄せる a. 今回は事前集計しているものの、将来的にはセマンティックレイヤーに Aggregated部分を移譲 4. データのオーグメンテーション a. 契約が終了したというレコードが上流で存在しないことが多数。終了した月のデータが存在せず Lagの計算ができないた めデータを拡張するようにパイプラインを形成 i. データ調査における妖怪 1合わないで判明 ※今回はSaaS型データプラットフォームである Foundryで主にSparkを利用したパイプラインを利用 Build Data PipeLine データ/品質の調査 パイプライン作成 カタログ作成 データマート公開 数 値 指 標 これ
14. カタログの作成 14 1. カタログ内容がシンプルになるようにパイプライン開発とカタログ整理をイテレーション a. カタログ経由で人にデータを説明する材料として解釈の明確さと容易さが必要だった b. カタログを書いてみて制約が多くなってしまったらパイプラインの修正を繰り返す 2. 認知負荷を考慮しテーブル名およびカラム名は日本語へ統一 a. 日本語と英語では認知負荷の差が段違い（みんな同じ英語レベルではない。無理に英語にすると揺れる） 3. リネージュを整理するより、実際に現場で利用している紙 (やWeb)の申し込み画面を取り寄せて確認 a. データソースの最上位まで整理するのはかなり複雑で年単位を要する b. テクニカルな方法論ばかりに拘らず、現場を理解するのが一番手っ取り早い 4. ドメイン知識の整理(スプレッドシートに整理)にはテクニカルライティングを意識 a. 流れ(ストーリー)を意識した記入とし、データの一点だけを捉える書き方にしない i. bad: 契約の識別のために付与する番号で 12桁の数値で構成する。 ii. better: 代理店保険の受付システムに登録後に被保険者向けの保険証券へ付与するユニークな番号。 12桁の数値 で構成する。 b. 制約の記載 i. ソース側の障害などパイプラインでは対処不可な制約のみ記載し情報量を削減 Organize Data Catalogs データ/品質の調査 パイプライン作成 カタログ作成 データマート公開 数 値 指 標 これ
15. データマートの公開 15 1. プラクティカルなガバナンスとガイドライン a. 個人情報やセンシティブ情報の明確化(法務部等との連携) i. 保険会社には「センシティブ情報」という要配慮個人情報に類似したカテゴリが存在する 1. 各PJで組み合わせ等の主観要件を満たすためにも「センシティブ情報」含めた個別の項目指定が必要 b. 効力範囲の明確化(WIP) i. 守るべきドキュメントなのかわからなければ誰も守らないため、決済や決議を通す c. 尺度の明確化(WIP) i. 品質低下によるアクション等を定め揺らぎの少ないプラクティカルなガイドラインへ 2. 運用スキームの構築と準備（オペレーショナルメタデータ） a. リリースサイクルの明確化(分析に参加するというオーナーシップを作るきっかけに) i. 定期的なリリースサイクル、変更がある場合の移行期間、移行の方法を明示 b. アクセスログによる利用者の監視導入 i. 利用促進やリソース最適化、不正利用の抑止につなげるため、アクセスログを取得・活用する仕組みを機械的に準備 Publish DataMarts データ/品質の調査 パイプライン作成 カタログ作成 データマート公開 数 値 指 標 これ
16. Next Horizon 地道な活動は続く.... 16
17. Early WinsとNext Horizon 17 Early Wins • 課題の解像度が劇的に向上 • 「ダメそう」から「理由がついた」ダメという説明ができるようになった。 • 潜在的なデータ解釈リスクの発見 • 例えば、値は一緒でも、出来上がるイベントやタイミングが微妙に異なり単純な Joinは正解ではない • スキームを実施するための体制も整備の下地を作れた Next Horizon • 技術の選択肢を増やし「唯一の “源泉”」におけるエンティティ解像度上げる • マッピングマスタの作成 • カタログ製品の導入/確率的マッチングの導入(決定論的マッチングだけだと限界がある) • ドメイン知識のグラフ化 • 潜在的なデータ解釈リスクを排除しながらより汎用的なデータマートへ • 異動データの逐次捕捉など Next Horizon
18. 18 ご清聴ありがとうございました At the end データエンジニア データアプリエンジニア データサイエンティスト https://sompo.io/ja/recruit/data-engineer https://sompo.io/ja/recruit/data-app-engineer https://sompo.io/ja/recruit/data-scientist