Upgrade to Pro — share decks privately, control downloads, hide ads and more …

データ基盤開発における技術負債と返却戦略 / Technical Debt and Retur...

Sansan R&D
January 10, 2024

データ基盤開発における技術負債と返却戦略 / Technical Debt and Return Strategies for Data Infrastructure Development

■イベント:データマネジメント新年会 〜去年のしくじりを共有し、正月ボケを解消する〜
https://sansan.connpass.com/event/303723/

■登壇概要
タイトル:データ基盤開発における技術負債と返却戦略
発表者:技術本部 研究開発部 Architectグループ 中村 崚

■研究開発職 採用情報
https://media.sansan-engineering.com/randd

■Sansan Tech Blog
https://buildersbox.corp-sansan.com/

Sansan R&D

January 10, 2024
Tweet

More Decks by Sansan R&D

Other Decks in Technology

Transcript

  1. 中村 崚 Sansan株式会社 研究開発部 Architectグループ Data Direction Team - 経歴

    - 新卒:バックエンドエンジニア > DBや検索システム周りを中⼼ - 2社⽬:データエンジニア > ⼩売のデータプラットフォーム開発 - 2023/4にSansanにJOIN > 全社横断データ基盤開発とデータ利活⽤推進
  2. 会社概要 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⽇ 設 ⽴ ⽀店:⼤阪、名古屋、福岡 サテライトオフィス:徳島、京都、新潟 拠 点 寺⽥ 親弘 代表者
  3. データ基盤/利活⽤のこれまでとこれから Before AsIs ToBe Ph.1 ToBe Ph.2 - Sansanは名刺管理から営業DXへ -

    Bill Oneをはじめとしたマルチプロダクトの展開 - 事業成⻑に伴い、データサイロ問題が顕在化 - 全社横断データ基盤を⽴ち上げ主要データを集約 - 分析/レポート/Labsアプリ などビジネス価値を提供 - 初期のデータマネジメントにおける負債が顕在化し始めてめている - プロダクト開発・データ利⽤者と積極的に協働しドメイン知識の吸収 - データマート/データレイヤを再整理し、⾼品質で無駄のないDWHへ - データガバナンス強化と不要データの積極的廃棄 ただ今このあたり - 利⽤者、データオーナーへの責務の委譲による利活⽤の⾼速化 - 全社的なデータリネージの最適化、マスタデータマネジメント
  4. データのサイロ化による課題が顕在化(よくある話) - データ管理コストの増⼤ - 複数の部署で同じデータを管理している場合があり、データの重複が発⽣している - 顧客の契約/利⽤情報がSalesforce、独⾃のKPIモニタリングツール、 スプレッドシートなどに散在 - データ取得するまでの⼿間がかかる

    - 各部署で定められた接続⽅法にしたがってデータ基盤にアクセスしてデータ取得する必要がある - Salesforceなどデータ取得するために営業からエクスポートしてもらう必要があった - データ基盤で対応するためにアプリケーションエンジニアやインフラエンジニアが個別対応 ※ Salesforce は salesforce.com, inc. の商標であり、許可のもとで使⽤しています。
  5. Sansanの提供プロダクトとデータの歴史(2021年) 営業DXサービス 名刺アプリ Sansan データ分析基盤 Eight データ分析基盤 各種営業⽤ データ 名刺データ化

    分析基盤 2007~ 2024 2020 全社横断 データ基盤 インボイス管理サービス ⼈事異動情報 企業情報 Bill One データ分析基盤 爆誕!!! 契約データベース
  6. 主要なプロダクト&営業系データを集約! ⼈脈情報 コンタクト 情報 企業情報 その他情報 契約情報 請求情報 全社横断データ基盤 企業DB

    データ構造化 データ連携 データ連携 名寄せ BIツール In-house solution データプロダクト マネジメント Salesforce ※ Salesforce は salesforce.com, inc. の商標であり、許可のもとで使⽤しています。
  7. 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
  8. データセット単位でのアクセス制御で安⼼安全! データ利⽤者 メタデータ データセット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
  9. プロダクト/利⽤者チームに潜り込み、 ドメイン知識の習得 - データはあるが仕様の理解が浅い状態である - メンバーそれぞれが利⽤者(アナリスト/データサイエン ティスト)と伴⾛して分析ナレッジのキャッチアップ - 実際に可視化や分析⽤クエリ作成、 ビジネス課題の発掘まで全部やる

    - 重要なデータの特定 - クエリのテンプレパーツをGithubで共有 - ビジネスメタデータの共有ポータル運営 dbtの導⼊とレイヤの再設計 - レイヤリングの再設計とルールの厳密化 - (Airflowの⽣クエリ実⾏であるため) まずはリネージを常に把握できるようお引越し - →セマンティックなモデルに分割し、 整備されたDWHの拡充 Sandbox環境の提供 - 利⽤者が⾃部⾨⽤のGCPプロジェクトの BigQuery上でお試し的にテーブルを作成可能に - ⼀定効果検証をしたうえで クエリ&仕様を整理し、 データ基盤本体に乗せる ToBeに向けていろいろやってます
  10. Case2: やたらマートあるぞ? 問題 プロダクトDB source_2 source_1 source_2 source_1 mart_2 mart_1

    mart_2 mart_1 Transform Transform Load Load とある旧データ分析基盤 全社横断データ基盤 よっしゃ! 新基盤へのデータ移⾏出来たで!
  11. Case2: やたらマートあるぞ? 問題 source_2 source_1 mart_2 mart_1 Transform 全社横断データ基盤 やたらマートが多いけど、

    どれ使えば良いんだろう? source_3 source_1000 ︙ mart_200 mart_3 ︙ そもそもユーザはこのマート 使っているんだっけ? 情報資産棚卸し 数が多くて時間かかる...
  12. データ基盤/利活⽤のこれまでとこれから(再掲) Before AsIs ToBe Ph.1 ToBe Ph.2 - Sansanは名刺管理から営業DXへ -

    Bill Oneをはじめとしたマルチプロダクトの展開 - 事業成⻑に伴い、データサイロ問題が顕在化 - 全社横断データ基盤を⽴ち上げ主要データを集約 - 分析/レポート/Labsアプリ などビジネス価値を提供 - 初期のデータマネジメントにおける負債が顕在化し始めてめている - プロダクト開発・データ利⽤者と積極的に協働しドメイン知識の吸収 - データマート/データレイヤを再整理し、⾼品質で無駄のないDWHへ - データガバナンス強化と不要データの積極的廃棄 ただ今このあたり - 利⽤者、データオーナーへの責務の委譲による利活⽤の⾼速化 - 全社的なデータリネージの最適化、マスタデータマネジメント
  13. データ基盤開発において負債は常に発⽣する - 負債負債 と書いてしまったけど、必ずしも悪い選択だったわけでもない - ⽴ち上げ期において、短期的なビジネス価値提供&サッと作って試しただけの結果 - 3つの⽴場で考える技術的負債への組織的アプローチ - 負債の許容と返済計画が必要

    - 例1: 現在dbtに引っ越しを進めているがベスプラ100%遵守は⽬指さない (が、引っ越し後にカラム名や型の標準化から進める) - 例2: 更新頻度が少ないので⼿動でバッチ処理を回している物がある (が、半年後に更新頻度が変わるのでイベント駆動でバッチを回せるようにする)
  14. 負債の放置は基盤が腐る - 結果としてQCDが下がり、エンジニアの⼠気も下がり⼈がいなくなる - データエンジニアもそれほど市場に潤沢に居るわけではないですし・・・ - 返済する仕組みを作っていこう - ① ADRを記録し、⼀定の負債を借り⼊れる選択と返済期⽇を残す

    - ② 潜在的な負債(課題)に気づいたらKAIZENバックログにいれる > 週次の運⽤当番がこまめに解消する - ③ 単発の依頼のタイミングで負債返却に動く > たとえば、「モデルの改修タイミングでValidationを加える」など > 「最短での提供ではないが今後の継続的な価値提供を⾒据えた場合、良い⽅法である」 ということをユーザ(依頼者)に率直に伝える