Sansan株式会社 部署 名前 データ基盤開発における 技術負債と返却戦略 Sansan技術本部 Sansan技術本部 研究開発部 Architectグループ 中村 崚

中村 崚 Sansan株式会社 研究開発部 Architectグループ Data Direction Team - 経歴 - 新卒:バックエンドエンジニア > DBや検索システム周りを中⼼ - 2社⽬:データエンジニア > ⼩売のデータプラットフォーム開発 - 2023/4にSansanにJOIN > 全社横断データ基盤開発とデータ利活⽤推進

会社概要 2 表参道本社 神山ラボ Sansan Innovation Lab 社 名 Sansan株式会社 所在地 表参道本社 東京都渋⾕区神宮前5-52-2 ⻘⼭オーバルビル13F グループ 会社 Sansan Global Pte. Ltd.（シンガポール） Sansan Global Development Center, Inc.（フィリピン） ログミー株式会社 株式会社ダイヤモンド企業情報編集社 クリエイティブサーベイ株式会社 株式会社⾔語理解研究所 従業員数 1,421 名（2023年8⽉31⽇時点） 2007年6⽉11⽇ 設 ⽴ ⽀店：⼤阪、名古屋、福岡 サテライトオフィス：徳島、京都、新潟 拠 点 寺⽥ 親弘 代表者

今⽇お話すること

データ基盤/利活⽤のこれまでとこれから Before AsIs ToBe Ph.1 ToBe Ph.2 - Sansanは名刺管理から営業DXへ - Bill Oneをはじめとしたマルチプロダクトの展開 - 事業成⻑に伴い、データサイロ問題が顕在化 - 全社横断データ基盤を⽴ち上げ主要データを集約 - 分析/レポート/Labsアプリ などビジネス価値を提供 - 初期のデータマネジメントにおける負債が顕在化し始めてめている - プロダクト開発・データ利⽤者と積極的に協働しドメイン知識の吸収 - データマート/データレイヤを再整理し、⾼品質で無駄のないDWHへ - データガバナンス強化と不要データの積極的廃棄 ただ今このあたり - 利⽤者、データオーナーへの責務の委譲による利活⽤の⾼速化 - 全社的なデータリネージの最適化、マスタデータマネジメント

Sansanの全社横断データ基盤の成り⽴ち (ちょっとだけ詳しく)

Sansanの提供プロダクトとデータの歴史(~2020年) 営業DXサービス 名刺アプリ Sansan データ分析基盤 Eight データ分析基盤 各種営業⽤ データ 名刺データ化 分析基盤 2007~ 2024 2020

Sansanの提供プロダクトとデータの歴史(2020年) 営業DXサービス 名刺アプリ Sansan データ分析基盤 Eight データ分析基盤 各種営業⽤ データ 名刺データ化 分析基盤 2007~ 2024 2020 インボイス管理サービス ⼈事異動情報 企業情報 Bill One データ分析基盤

データのサイロ化による課題が顕在化(よくある話) - データ管理コストの増⼤ - 複数の部署で同じデータを管理している場合があり、データの重複が発⽣している - 顧客の契約/利⽤情報がSalesforce、独⾃のKPIモニタリングツール、 スプレッドシートなどに散在 - データ取得するまでの⼿間がかかる - 各部署で定められた接続⽅法にしたがってデータ基盤にアクセスしてデータ取得する必要がある - Salesforceなどデータ取得するために営業からエクスポートしてもらう必要があった - データ基盤で対応するためにアプリケーションエンジニアやインフラエンジニアが個別対応 ※ Salesforce は salesforce.com, inc. の商標であり、許可のもとで使⽤しています。

Sansanの提供プロダクトとデータの歴史(2021年) 営業DXサービス 名刺アプリ Sansan データ分析基盤 Eight データ分析基盤 各種営業⽤ データ 名刺データ化 分析基盤 2007~ 2024 2020 全社横断 データ基盤 インボイス管理サービス ⼈事異動情報 企業情報 Bill One データ分析基盤 爆誕！！！ 契約データベース

主要なプロダクト&営業系データを集約！ ⼈脈情報 コンタクト 情報 企業情報 その他情報 契約情報 請求情報 全社横断データ基盤 企業DB データ構造化 データ連携 データ連携 名寄せ BIツール In-house solution データプロダクト マネジメント Salesforce ※ Salesforce は salesforce.com, inc. の商標であり、許可のもとで使⽤しています。

GCPフル活⽤で開発・運⽤コストを抑えつつ Cloud Storage Amazon S3 Amazon Aurora Storage Transfer Service Cloud SQL Logging Cloud Composer Project データ基盤 Data lake BigQuery Project データ分析A BigQuery DWH BigQuery Data mart BigQuery Project データ分析B BigQuery Group A Group B データ基盤エンジニア その他 AWSリソース Azure Blob Storage Salesforce

データセット単位でのアクセス制御で安⼼安全！ データ利⽤者 メタデータ データセットA データセットB データ利⽤者1 ◯ ◯ ◯ データ利⽤者2 ◯ × ◯ データ利⽤者3 ◯ × × Project データ分析A データ利⽤者1 Project データ分析B データ利⽤者2 データ利⽤者3 Project データ基盤 BigQueryデータセットA Join Join Join Googleグループα Googleグループβ Read&Query Read&Query BigQueryデータセットB

100点満点？ そうではない！

Case1: リネージ&ロジックの複雑なマート問題 とりあえずBIで⾒たいので、 このSQLでマートテーブルつくって〜 はいよ〜 (クエリペロっと貼って 定期更新組んで と) いい感じの 定期レポートにできた！ あざっす！ ※もちろん全部が全部こうじゃないです

やがて時が経ち闇のマートに・・・ この数値も追加してちょ〜 クエリ複雑すぎて、 どう変えればいいか分からんぞ・・・ そういえば、先⽉に元データの仕様変わったけど 集計値に影響出ているのでは・・・？ え、このマート別のマートでも参照されてる？！ 開発/問い合わせ⼯数の爆発へ🤯

どうすればよかったのか - データレイヤの設計に制限をかけてなかった - 結果リネージが複雑フリーダムに・・・ - マート提供時のクエリの理解/分解不⾜ - 「⽴ち上げ期だし、試しでサクッとやってみよう！」 - この時点でカラム命名規則や型などの最低限の標準ルールの制定しておけば良かった

プロダクト/利⽤者チームに潜り込み、 ドメイン知識の習得 - データはあるが仕様の理解が浅い状態である - メンバーそれぞれが利⽤者(アナリスト/データサイエン ティスト)と伴⾛して分析ナレッジのキャッチアップ - 実際に可視化や分析⽤クエリ作成、 ビジネス課題の発掘まで全部やる - 重要なデータの特定 - クエリのテンプレパーツをGithubで共有 - ビジネスメタデータの共有ポータル運営 dbtの導⼊とレイヤの再設計 - レイヤリングの再設計とルールの厳密化 - (Airflowの⽣クエリ実⾏であるため) まずはリネージを常に把握できるようお引越し - →セマンティックなモデルに分割し、 整備されたDWHの拡充 Sandbox環境の提供 - 利⽤者が⾃部⾨⽤のGCPプロジェクトの BigQuery上でお試し的にテーブルを作成可能に - ⼀定効果検証をしたうえで クエリ&仕様を整理し、 データ基盤本体に乗せる ToBeに向けていろいろやってます

Case2: やたらマートあるぞ？ 問題 プロダクトDB source_2 source_1 source_2 source_1 mart_2 mart_1 mart_2 mart_1 Transform Transform Load Load とある旧データ分析基盤 全社横断データ基盤 よっしゃ！ 新基盤へのデータ移⾏出来たで！

Case2: やたらマートあるぞ？ 問題 source_2 source_1 mart_2 mart_1 Transform 全社横断データ基盤 やたらマートが多いけど、 どれ使えば良いんだろう？ source_3 source_1000 ︙ mart_200 mart_3 ︙ そもそもユーザはこのマート 使っているんだっけ？ 情報資産棚卸し 数が多くて時間かかる...

どうすればよかったのか - 旧基盤上のデータをまるごと再現するのではなく、 あらかじめ旧基盤上での利⽤状況を確認し必要なものに絞って移⾏ - とはいえ、新基盤への移⾏を促進するためにはやむなしな⾯もある - (Viewでもマート作ってしまっていたが)なるべくテーブルで作るべきだった - Viewの場合、 「INFORMATION_SCHEMA.JOBS_BY_*」単体での利⽤状況把握が困難

ToBeに向けていろいろやってます 状況モニタリングの強化 - 利⽤状況の可視化 - 利⽤ユーザ/参照テーブル/クエリスキャン量推移 など - マートは原則的にテーブルにする - テーブル捨てます活動

ここまでのまとめ

データ基盤/利活⽤のこれまでとこれから(再掲) Before AsIs ToBe Ph.1 ToBe Ph.2 - Sansanは名刺管理から営業DXへ - Bill Oneをはじめとしたマルチプロダクトの展開 - 事業成⻑に伴い、データサイロ問題が顕在化 - 全社横断データ基盤を⽴ち上げ主要データを集約 - 分析/レポート/Labsアプリ などビジネス価値を提供 - 初期のデータマネジメントにおける負債が顕在化し始めてめている - プロダクト開発・データ利⽤者と積極的に協働しドメイン知識の吸収 - データマート/データレイヤを再整理し、⾼品質で無駄のないDWHへ - データガバナンス強化と不要データの積極的廃棄 ただ今このあたり - 利⽤者、データオーナーへの責務の委譲による利活⽤の⾼速化 - 全社的なデータリネージの最適化、マスタデータマネジメント

データ基盤開発において負債は常に発⽣する - 負債負債 と書いてしまったけど、必ずしも悪い選択だったわけでもない - ⽴ち上げ期において、短期的なビジネス価値提供&サッと作って試しただけの結果 - 3つの⽴場で考える技術的負債への組織的アプローチ - 負債の許容と返済計画が必要 - 例1: 現在dbtに引っ越しを進めているがベスプラ100%遵守は⽬指さない (が、引っ越し後にカラム名や型の標準化から進める) - 例2: 更新頻度が少ないので⼿動でバッチ処理を回している物がある (が、半年後に更新頻度が変わるのでイベント駆動でバッチを回せるようにする)

負債の放置は基盤が腐る - 結果としてQCDが下がり、エンジニアの⼠気も下がり⼈がいなくなる - データエンジニアもそれほど市場に潤沢に居るわけではないですし・・・ - 返済する仕組みを作っていこう - ① ADRを記録し、⼀定の負債を借り⼊れる選択と返済期⽇を残す - ② 潜在的な負債(課題)に気づいたらKAIZENバックログにいれる > 週次の運⽤当番がこまめに解消する - ③ 単発の依頼のタイミングで負債返却に動く > たとえば、「モデルの改修タイミングでValidationを加える」など > 「最短での提供ではないが今後の継続的な価値提供を⾒据えた場合、良い⽅法である」 ということをユーザ(依頼者)に率直に伝える

そして究極のToBeへ！

今後(2-3年後) - ⼀部開発領域の⺠主化 - このままだとデータエンジニアチームがボトルネックになる恐れがある - (必要なガードレールがあるうえで)「利⽤者主体でのマート作成」や 「プロダクト開発者側がメタデータの拡充をしてくれるような組織/仕組みづくり」を構築 - 「スーパーマーケット型」ではなく「百貨店型」 - 既存基盤の整理 - まだ廃⽌出来ているものは多くないので、どんどん横断データ基盤での成果を増やし、 ユーザを集める&旧基盤のユーザを減らして廃棄

データエンジニアリングから データマネジメントまで⼀気通貫で 経験できます

Sansan 技術本部 研究開発部 採⽤情報 https://media.sansan-engineering.com/randd

No content