ヤプリのデータカタログ整備 1年間の歩み 2024.11.28 @ Findy Lunch LT『データカタログ 事例から学ぶメタデータ管理の実態』

Speaker 開発統括本部 プロダクト開発本部 データサイエンス室（以下、DS室） ⼭本 雄太 ● 2023に新卒⼊社 ● dbt導⼊に際して、開発体制やリリース フロー構築などを担当 ● 最近はデータカタログ拡充‧ドキュメン ト整備に取り組み中

ヤプリの製品｜ノーコードのアプリ開発プラットフォーム「Yappli」 ● 700社以上が導⼊、800アプリ以上を提供 ● 40種類以上の機能が利⽤可能。多様なシーンに合致したアプリが作成可能

ヤプリの製品｜Yappli 導⼊顧客向けにアナリティクスサービスを提供 CMS ダッシュボード Yappli 管理画⾯のトップに 表⽰されるダッシュボード Yappli Data Hub アプリ内の⾏動データや属性データを ユーザ単位で分析を可能にする データ連携サービス Yappli Analytics アプリログを網羅した分析や、 機能別に特化した分析が可能な ダッシュボード

2023年から分析⽤データ基盤の   移⾏を開始

2023年から分析⽤データ基盤の   移⾏を開始 https://tech.yappli.io/entry/update-dbt-infra-dev-flow https://speakerdeck.com/yamamotoyuta/ci-no10nian -wozhan-erufen-xi-yong-detaji-pan-gou-zhu-nodi-bu- dbtniyoruji-pan-shua-xin-tokuerifei-yong-90-percent- xue-jian-henoqu-rizu-mi https://tech.yappli.io/entry/replace-ya-mart-to-dbt https://tech.yappli.io/entry/improve-dbt-docs-descri ption-with-dbt-osmosis dbt Advent Calendar 0 4で 出ます！ https://findy-tools.io/products/dbt/37/113

ヤプリのデータカタログ整備、1年間の歩み

ヤプリのデータカタログ整備、1年間の歩み この2パートに分けて 紹介します！

ヤプリのデータカタログ整備、1年間の歩み ① dbt導⼊と並⾏した dbt docs整備

誰のため、何のためのdbt docs？ 誰のため？ ● DS室メンバーのため 何のため？ ● データの仕様をまとめていく場所を作るため ○ 元々、DS室メンバーは1⼈しかおらず、データの仕様をまとめる余裕がなかった ○ ここ1〜2年でメンバーが4⼈に増え、データの仕様がまとまっていないことが深刻化 ■ 散り散りのドキュメント、時間を要するクエリ解読、頻発する作成者召喚、etc. ①dbt導⼊と並⾏したdbt docs整備

やったこと 1. 早いうちからGitHub Pagesへ⾃動デプロイする仕組みを導⼊ 2. 社内ドキュメントにあったDB仕様書をdbt docsへ転記 3. dbt-osmosis導⼊によるカラム説明の継承 ①dbt導⼊と並⾏したdbt docs整備

1. 早いうちからGitHub Pagesへ⾃動デプロイする仕組みを導⼊ ①dbt導⼊と並⾏したdbt docs整備 ＞ やったこと 💡ポイント CMSダッシュボードの 参照元切り替えから 複数⼈でのdbt開発がスタート このタイミングで ⾃動デプロイの仕組みを導⼊ ↓ 以降のタスクを通して dbt docsが⾃然と浸透👍

Q. dbt導⼊時にdbt docsを使い始めてもテーブルやカラムの説明は空欄ばかりで は？それで役に⽴つのか？ A. ⼗分役に⽴ちました ● リネージグラフが⾒れるだけでも役⽴った ● 「拡充すればもっと役⽴つはず」というのを実感できた →拡充のモチベがUPし、ネクストアクションへ繋がった ①dbt導⼊と並⾏したdbt docs整備 ＞ やったこと 1. 早いうちからGitHub Pagesへ⾃動デプロイする仕組みを導⼊

2. 社内ドキュメントにあったDB仕様書をdbt docsへ転記 ● 同じく2023年にサーバチームでサービスDBの仕様書を社内ドキュメントにまと めるプロジェクトがスタート ● ヤプリの分析⽤データ基盤は⼤半がサービスDBのデータ → DB仕様書の内容をdbt docsへ転記すれば、dbtのSource層の⼤半が説明埋まる！ ①dbt導⼊と並⾏したdbt docs整備 ＞ やったこと DB仕様書 dbt docs 転記

2. 社内ドキュメントにあったDB仕様書をdbt docsへ転記 そもそもDB仕様書(=他チームのドキュメント)の存在にどうやって気づいたか？ ● ⽇頃から関連他チームの社内ドキュメントも覗くようにしていた ➡ 他所の情報も越境して取りに⾏ってみると良いことがあるかも 転記作業はどのタイミングで⾏なったのか？ ● ヤプリでは毎⽉「YappdateDay」という改善に注⼒する⽇が存在 ○ この⽇に取り組り組むことで通常業務との兼ね合いを考えずに作業可能に ➡ 素早く＆無理なく転記作業を⾏えた ①dbt導⼊と並⾏したdbt docs整備 ＞ やったこと

3. dbt-osmosis導⼊によるカラム説明の継承 ● DB仕様書の転記でdbtのSource層は⼤体拡充できた ● dbt-osmosisを使えば、上流dbtモデルのカラムの説明を下流dbtモデルへ継 承させられる → dbt-osmosisを導⼊してdbt docsの拡充率を⼤幅UPさせよう！ ● 導⼊時の詳細はテックブログをご覧ください→ ● dbt docsの拡充率は30%→80%まで向上 ①dbt導⼊と並⾏したdbt docs整備 ＞ やったこと https://tech.yappli.io/entry/improve-dbt-docs-description-with-dbt-osmosis

ヤプリのデータカタログ整備、1年間の歩み ① dbt導⼊と並⾏した dbt docs拡充

ヤプリのデータカタログ整備、1年間の歩み ② トラッキング仕様書の 移⾏＆更新体制構築

● Yappli製アプリでは、閲覧/操作ログを 取得して分析⽤データ基盤や各種計測 サービス（GA4等）に送信している ● 各閲覧/操作イベントでどのようなログ を送信するか？をまとめたもの ○ スプレッドシート管理 ○ 累計ユニーク閲覧者: 55⼈（社員の1/5） ○ 先⽉の⽇平均PV: 1.4 ○ 最古の更新履歴: 7年前 ● PdMが新機能開発/既存機能改修時に更 新していた トラッキング仕様書とは？ ②トラッキング仕様書の移⾏＆更新体制構築 閲覧ログ 操作ログ 分析⽤データ基盤 計測サービス

トラッキング仕様書の⾟い状況 ②トラッキング仕様書の移⾏＆更新体制構築 閲覧ログ 操作ログ 分析⽤データ基盤 各種計測サービス 分析⽤データ基盤へ送信する場合の トラッキング仕様書 ② DS室がトラッキング仕様の策定に関われていなかった PdMが⼿探りで仕様を策定＆DS室が仕様を知るのはリリース後 → ⼿探りでPdMが疲弊＆分析での使い勝⼿でDS室も疲弊… 各種計測サービスへ送信する場合の トラッキング仕様書 ① 「分析⽤データ基盤送信」と「計測サービス送信」で仕様管理のスプレッドシートが別 → ⼆重管理による記載ミスが度々発⽣

1. 2枚のスプレッドシートを1枚へマージ 2. トラッキング仕様書の更新フローを整備 3. 記載されている仕様があっているか調査 やったこと ②トラッキング仕様書の移⾏＆更新体制構築

1. 2枚のスプレッドシートを1枚へマージ ポイント💡 記載内容がconflictしたり誤ってたりしてもコメントだけ残して仕様調査は後回し ● 仕様調査までやってるとマージ作業が⻑期化 ○ マージ作業中も既存のトラッキング仕様書は更新され続けている → 早く終わらせないとどんどん⾟くなる ● コメント時は分析時の困る度合いをCRITICAL/MEDIUMで記載 → 仕様調査時の優先度づけに利⽤ ②トラッキング仕様書の移⾏＆更新体制構築 ＞ 改善⽅針

2. トラッキング仕様書の更新フローを整備 ②トラッキング仕様書の移⾏＆更新体制構築 ＞ 改善⽅針 仕様策定 ● 新規開発/既存改修時の仕様策定⽤ テンプレが存在 ● テンプレに基づいてPdMが開発/改 修内容の仕様書を作成 実装中 リリース時 ● 作成した仕様書をもとにエンジニア が実装 ● エンジニアとPdMが会話し、仕様 の詳細が固まっていく ● トラッキング仕様のみスプレッド シートで仕様管理 開発内容の仕様書 トラッキング仕様書 ✏ ● PdMがリリース内容をSlackで全社 周知 ● 併せて、テクニカルライターが社内 向け機能仕様書を更新 ○ 詳細はこちらを参照: Yappliの仕様書整備を例とし た情報整理の考えかた【Yappli Tech Conference 2023】  新規開発/既存改修時のフロー（当時😖） PdM 開発内容の仕様書 ✏ PdM エンジニア PdM 全社Slack 社内向け 機能仕様書 テクニカル ライター DS室がどこにも関われていない…＆トラッキング仕様書の管理がエアボール… DS室メンバー DS室メンバー DS室メンバー

2. トラッキング仕様書の更新フローを整備 ②トラッキング仕様書の移⾏＆更新体制構築 ＞ 改善⽅針 ● トラッキング関連の仕様策定につい てはDS室メンバーを呼んで⼀緒に 策定 ● エンジニアの実装結果について、 DS室にもチェック依頼 ● トラッキング仕様も開発内容の仕様 書に⼀緒に記載 開発内容の仕様書 ● 全社周知前に⾏っているリリース内 容チェックにDS室も関与 ● 社内向け機能仕様書更新時にトラッ キングに関するものはDS室へエス カレーション ● このタイミングでDS室がトラッキ ング仕様書を更新  新規開発/既存改修時のフロー（整備後🥳） PdM 開発内容の仕様書 ✏ PdM エンジニア DS室メンバー DS室メンバー DS室メンバー トラッキング仕様書 ✏ 仕様策定 実装中 リリース時 PdM 全社Slack 社内向け 機能仕様書 テクニカル ライター 各フェーズでDS室が関与！＆トラッキング仕様書はDS室オーナーで管理する体制に！

3. 記載されている仕様があっているか調査 ● マージ作業時につけたコメントをもとに記載内容が実態と合っているかチェック ○ 数が多いので、分析時の困る度合い“CRITICAL”とコメントされているものから優先して調査 ②トラッキング仕様書の移⾏＆更新体制構築 ＞ 改善⽅針

ヤプリのデータカタログ整備、1年間の歩み ② トラッキング仕様書の 移⾏＆更新体制構築

ヤプリのデータカタログ整備、1年間の歩み ①は… Source層を先に埋めてから下流を埋めていった ②は… 仕様検討に関われるようにした ● 整備したデータカタログは現在進⾏形で役に⽴っている ● 下流のテーブルは様々な要因で追加‧改廃が激しい（例: 業務フローの変更、ビジネスロジックの変更） ● 上流のテーブルは変化が少なめ（例: サービスDBのスキーマ） → データカタログは上流から埋めていくと無駄になりにくそう

ヤプリのデータカタログ整備、これからの歩み これまでの歩みで、DS室向け（＝データ組織向け）のデータカタログ（＝仕様書📚）はある程度整備できた → 次はデータ利⽤者向けのデータカタログ（＝取説🔰）を整備していきます！