こんにちは！データサイエンス室（以下、DS室）の山本です（@__Y4M4MOTO__）です。
11/28(木)に開催されたFindy Lunch LT『データカタログ事例から学ぶメタデータ管理の実態』に表題のタイトルで登壇してきました！
この記事では、その時の登壇資料や発表中では割愛した内容などについて記しています。
登壇資料
補足
発表では時間の都合で割愛した内容を以下で補足します。
「①dbt導入と並行したdbt docs整備」の詳細資料
このセクションの内容は今年5月のTROCCOユーザー会（TROCCOUG）にて発表したものをかいつまんだものです。当時の登壇資料が下記記事に載っていますので、興味がある方はご覧ください。
なぜトラッキング仕様書が二重管理状態になってしまったのか？
元々はGoogle Analytics（GA360）を使ってトラッキングを行なっており、その仕様管理のためのスプレッドシート（資料中の「各種計測サービスへ送信する場合のトラッキング仕様書」）が存在していました。
4年ほど前のGoogleからのGA360→GA4への移行アナウンス時に、データ活用を強化していきたいタイミングが重なったため、トラッキング機構を内製化して分析用データ基盤を構築することになりました。この時に「分析用データ基盤へ送信するためのトラッキング仕様書」が誕生し、二重管理状態になりました。
2枚のスプレッドシートを1枚へマージする際の工夫
マージはどちらかのスプレッドシートに寄せるのではなく、新規のスプレッドシートへ移行することで行ないました。理由は次の2点です。
- PdMやDS室メンバーの通常業務に影響を及ぼさずにマージ作業を進められるため
- 記載フォーマットの再構築も行なう必要があったため
フォーマットの再構築についてですが、今回、2つのスプレッドシートを1つへマージするほかに次の要件もありました。
- 顧客展開用のトラッキング仕様書も社内向けのトラッキング仕様書から自動で更新がかかるようにする
- トラッキング仕様の変更履歴もセットで記録できるようにする
これらを実現するためにフォーマットの再構築が必要でした。具体的に行なったことは次のとおりです。
- 定義や仕様に関するメモが同じセルに書かれていたので、1つのセルには1つの情報のみを記載するよう項目を分割
- 備考がどの項目についてのものなのかわかりにくいので、項目ごとに備考の欄を追加
- 変更履歴を記録するための項目を追加
マージ後のスプレッドシート切り替えタイミングはPdM側と調整して業務に支障が出ないタイミングに設定しました。また、切り替え時は以前のスプレッドシートに編集ロックをかけて更新されないようにするとともに、マージ後のスプレッドシートへのリンクを記載してスムーズに移行できるようにしました。
なぜ新規開発/既存改修時のトラッキング仕様策定にDS室が関われていなかったのか？
理由は主に下記の2点です。
- 最初のDS室メンバーが入社する前からトラッキング自体は行なわれていたため、「DS室メンバーを入れて仕様策定する」という概念がなかった
- 最初のDS室メンバー入社後も3年ほどは1人だけだったので、仕様策定に関わる余裕がなかった
フロー整備をどうやって進めたか
DS室はプロダクト開発に直接関わっているわけではないため、そもそもどんなフローで新規開発や既存改修が行なわれていて、どのタイミングで誰がトラッキング仕様書を更新しているのかがわかっていない状況でした。そのため、まずはフローをPdM側へヒアリングするところから始めました。
ただ、今回のトラッキング仕様書の更新フロー整備を取り組む前に別件でPdMの方から「一緒に仕様検討してほしい」と言われた新規開発プロジェクトがありました。こちらで仕様検討〜リリースまでの流れを一通り体験できた上、DS室がプロジェクトに関わることでトラッキング周りの仕様策定や実装がスムーズに行なえることが確認できていたおかげで、一定の解像度を持って今回のフロー整備に取り組むことができました。
PdM側とのヒアリング結果をもとに、現状のトラッキング仕様書の更新フローを整理しました。整理は「ケース」と「タイミング」の2軸で次のように行ないました。これにより、トラッキング仕様書の更新ミスなどが起きやすいケースやタイミングを特定できました。
ケース
- 新規開発 →ケース1
- 既存改修
- プロジェクトを組む（大規模改修）→ケース2
- プロジェクトを組まない（小規模な改善・不具合修正）
- PdMが入る →ケース3
- エンジニアのみ →ケース4
タイミング
- 仕様検討時
- 実装中
- リリース時
フロー整備の際に意識したことは「PdM側の業務フローに負荷をかけないようにすること」です。なるべく既存の業務フローのまま、変更が生じる場合もPdM側と納得感のある形にしたいと考えていました。フロー検討のMTGを行なった際にPdM側から「今やってるこのフェーズにDS室も呼べば良いのでは？」などの提案をいただき、最終的に「現状すでに行なっていることを改めて明文化した」程度の変更で済みました。そのおかげでフロー変更によって生じたトラブル等もありませんでした。
その他、今回の取り組みで得られた知見など
今回の取り組みでスプレッドシートの「フィルタビュー」という機能をはじめて知りました。
フィルタビューは共有中のスプレッドシートで自分専用のフィルターをかけられる機能です。この機能のおかげで、「この機能のトラッキング仕様どうなってたっけ？」といった際のフィルタリングを他の閲覧ユーザーに影響を与えずに行なうことができ、とても便利でした。
注意点は、範囲選択した領域の先頭行をヘッダーとしてフィルタが作成される仕様になっていることです。そのため、ヘッダー行が複数行ある場合は範囲選択を工夫しないと変なフィルタが作成されてしまいます。これに対処するため、トラッキング仕様書ではヘッダー行を1行にまとめました。
例:
| 大項目1 | ... | |||
|---|---|---|---|---|
| 中項目1-1 | 中項目1-2 | ... | ||
| 小項目1-1-1 | 小項目1-1-2 | 小項目1-2-1 | ... | |
| 1 | xxx | xxx | xxx | ... |
| ... | ... | ... | ... | ... |
↓
|
大項目1 中項目1-1 小項目1-1-1 |
小項目1-1-2 |
中項目1-2 小項目1-2-1 |
... | |
|---|---|---|---|---|
| 1 | xxx | xxx | xxx | ... |
| ... | ... | ... | ... | ... |
こちらの記事が参考になったので、興味を持たれた方はご覧ください。
結び
以上、Findy Lunch LTに『ヤプリのデータカタログ整備1年間の歩み』という題で登壇してきた話でした。
この記事を読んで弊社に興味を持たれた方はぜひカジュアル面談にお越しください！
ここまでお読みいただきありがとうございました🙇
