タイミーのデータモデリング事例と今後のチャレンジ

by Toshiki Tsuchikawa

Slide 1

Slide 1 text

2025/7/4 土川稔生, 大河戸裕一タイミーのデータモデリング事例と今後のチャレンジ @tvtg_24 , @miburo_data Data Modeling Night -「今」だからできる理論の実践事例 -

Slide 2

Slide 2 text

自己紹介土川稔生（Tsuchikawa Toshiki）株式会社タイミーに2020年入社 DRE（Data Reliability Engineering）グループマネージャー 1人目データエンジニアとしてデータ基盤を構築し始める現在はプロダクトオーナーとして、データ基盤プロダクト作りに励む

Slide 3

Slide 3 text

自己紹介大河戸裕一（Okodo Yuichi）スタートアップにてソフトウェアエンジニアを経験後、 1人目データ人材として、データ組織の立ち上げとデータ基盤の作成を経験タイミー入社後はアナリストを経験後、データエンジニア兼アナリティクスエンジニア業務に従事主にLookerやデータモデリングの開発をリード

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

あなたの組織では、データが十分に活用されていますか ??

Slide 8

Slide 8 text

データは大量にあるが、使いづらい ... データ活用者大量のデータ

Slide 9

Slide 9 text

データは大量にあるが、使いづらい ... データ活用者大量のデータほしいデータが入っているテーブルがわからない SQLのロジック複雑。A さんに聞かないと中身編集できないテーブルたくさんあって SQLがすごく長い

Slide 10

Slide 10 text

データモデリングのメリット 1. 社内のビジネスドメインをSQL定義に落とし込んでSSoTとして管理できる! 2. ディメンショナルモデリングにより、SQLを書く際に直感的に理解しやすいデータ構造になる! 3. テーブル数や結合が少なくなりSQLがシンプルなり、パフォーマンスも向上する!

Slide 11

Slide 11 text

タイミーにおけるデータモデリング

Slide 12

Slide 12 text

タイミーのデータ基盤

Slide 13

Slide 13 text

タイミーのデータモデリング業務アナリストの開発領域データモデラー (DRE G)の開発領域ここを広げたい!

Slide 14

Slide 14 text

タイミーのデータモデリング業務 PII情報に対するクエリを承認制にしつつモデリングに露出させるか整備したりセマンティックレイヤーの命名をユーザーライクなものにする実装をしたりみたいな領域もデータモデリングという枠組みで行なってます

Slide 15

Slide 15 text

既存のデータモデリング開発で顕在化した進め方の課題ユーザーの起票ベースで開発を行なっていて、Lookerを使っていない部署の意見が反映できない。攻めのデータモデリングが行えていない。既に運用に乗っているアナリストが作成したクエリ (合計2800行ほど)をディメンショナルモデリングで置き換える作業で実装が泥沼化

Slide 16

Slide 16 text

既存のデータモデリング開発で顕在化した進め方の課題ユーザーの起票ベースで開発を行なっていて、 Lookerを使っていない部署の意見が反映できない。攻めのデータモデリングが行えていない。 Lookerの利用率は高いため、 Lookerをすでに使っている部署の改修・追加依頼はたくさん来るが、データ出力をデータモデリングでカバーできる領域自体を広げる動きには繋がりづらい。タイミー社内で日常的に生まれる新しい領域や新規プロジェクトに対して先回りして動けておらず、その領域において非効率なクエリが生産されている状態。後手後手の依頼対応で意思決定の高速化に貢献できていない状態・・

Slide 17

Slide 17 text

既存のデータモデリング開発で顕在化した進め方の課題既に運用に乗っているアナリストが作成したクエリ (合計2800行ほど)をディメンショナルモデリングで置き換える作業が泥沼化既存のデータモデリングと同音異義語の指標名や dimension名が多数存在してすり合わせが困難事業部サイドの要求が反映された複雑で横展開できない特殊定義が多数存在既存のクエリが正解ではなく間違いなどもあるので正解がなく、一度定まった定義を変更してすり合わせていく作業が発生一緒に作っていくプロセスを経ればこんなことは起きなかったのに・・

Slide 18

Slide 18 text

アジャイルデータモデリングの実践

Slide 19

Slide 19 text

アジャイルデータモデリングアジャイルデータモデリングのメリット (一部): ● 従来の大規模で時間をかけたモデリングではなく、ビジネスニーズに合わせて段階的かつ柔軟にデータモデリングを構築・改善する ● ユーザーとの頻繁なコミュニケーションを通じて、ビジネス側のステークホルダーと協調しながら要件にあったモデリングを構築できるタイミーにおける課題に対して期待していること： ● 攻めのモデリング : モデリングするべき重要なデータユースケースを把握しながら、将来的にスケールする分析環境の提供 ● 段階的なモデリング : 既存の2800行のクエリを一度に置き換えるのではなく、優先度の高いストーリー、指標から段階的に移行 ● ドメイン知識の共通化 : ビジネスユーザーとの頻繁なコミュニケーションを通じて、モデリングする人とのドメイン知識を共通化することによる属人化の防止、モデルのメンテ性向上

Slide 20

Slide 20 text

実際の事例 ①

Slide 21

Slide 21 text

アジャイルデータモデリング事例 1：進め方指標Aを全く新しい軸でみたい。今 Lookerでは見れない (=スタースキーマで表現されていない ) 新しいLooker探索環境 (=スタースキーマ )が必要ではないかと考えている依頼どういうものをイメージしているのかふわっとしかわからないつまりどういうことだってばよ・・？

Slide 22

Slide 22 text

アジャイルデータモデリング事例 1 既存ワイドテーブルをベースにBEAM＊テーブルを作る形で差異を確認。新しく実現したい絞り込みや情報の粒度を確認

Slide 23

Slide 23 text

アジャイルデータモデリング事例 1 整理を通して既存のDimensionを拡張するだけで実現可能な項目であることが判明！ふわっとした要件を解像度高く追加実装要件に落とせた

Slide 24

Slide 24 text

アジャイルデータモデリング事例 1：感想 - 「既存の」ディメンショナルデータモデリングされたテーブルも BEAM*テーブルとして表現可能で、BEAM*テーブルをコミュニケーションツールとして活用できたこと。 - 「どこが既存との差異なのか」を目線を合わせながらコミュニケーションできた。 - 具体のレコードイメージをBEAM*テーブルを通じて作ることができるので、ふわっとした要求を実装要件に落とし込めるありがたみがわかった。

Slide 25

Slide 25 text

アジャイルデータモデリング事例 2 取引先になった後の各種実績 Salesforceデータをベースにモデリング済み広告媒体の実績各種広告ツールで確認できているリード = 見込み顧客ドメイン的に微妙に浮いていてモデリングでも未着手状態ここ攻められてないからやってみようマーケの関心領域セールスの関心領域

Slide 26

Slide 26 text

アジャイルデータモデリング事例 2：進め方 ①マーケメンバーへの課題領域ヒアリング ②マーケドメインを担当するアナリストにヒアリング ③ビジネスメンバーとマーケドメインアナリストへのヒアリング

Slide 27

Slide 27 text

アジャイルデータモデリング事例 2：ヒアリング内容 ①マーケメンバーへの課題領域ヒアリング ②マーケドメインを担当するアナリストにヒアリング「What」の目安をつける「リードの数と獲得費用対効果が知りたい」「What」以外の実装案を埋めてワイドテーブルの仮組をする仮組みされたワイドテーブルをベースに実分析ケースを壁打ち ③ビジネスメンバーとマーケドメインアナリストへのヒアリング

Slide 28

Slide 28 text

アジャイルデータモデリング事例 2：BEAM*の更新 ① ② ③

Slide 29

Slide 29 text

アジャイルデータモデリング事例 2：BEAM*の更新 ① ② ③ 初回は関心領域の特定だけで終わってしまったスタースキーマがわかるアナリストメンバーと仮組み営業メンバーにぶつけてみて更新マーケ目線じゃ出てこない情報の更新

Slide 30

Slide 30 text

アジャイルデータモデリング事例 2　感想・コツ - この本で推奨されている「誰が何をしますか？」という質問から聞いても答えは得られなかった。「何をみたいですか」という問い（スタースキーマのファクトを定める質問）をしたら初めてうまくいったという切り出し方をしてもビジネスユーザーはピンとこなかったソースシステムの処理や挙動を深く理解している人相手なら刺さりそう

Slide 31

Slide 31 text

アジャイルデータモデリング事例 2　感想・コツ - BEAM*テーブルという中間成果物が何かしら更新されるので、30分や15分のヒアリング枠を複数設けて少しずつ更新するような進め方が可能 - なので複数の観点からのレビューがもらいやすいうちのチームではこの絞り込みが追加で必要うちのチームではこの絞り込みが追加で必要

Slide 32

Slide 32 text

アジャイルデータモデリング事例 2　感想・コツ ● 「本の型通りの質問をしてBEAM*テーブルを作る」ではなく、「JOIN後のワイドテーブルのレコードを作る」ってメンタルモデルにしたらヒアリングうまくいった。要するにスタースキーマを JOINしたワイドテーブルのレコードイメージを決めればいいのか。それならわかるぞ BEAM*テーブルを作るって何・・？とりあえず書いてある通りの質問をしてみよう

Slide 33

Slide 33 text

２つの事例を通して - 目線を合わせるためのBEAM*テーブルの有用性 - 顧客の要求を実装要件に具体化できる。 - 少しずつアップデートできて、複数の目線を反映させやすい - 当社での苦戦ポイント - 本に記載されているような問いかけはビジネスユーザー相手だと通じないことが多かった。（なぜなら具体の処理やデータ間のリレーションや指標の発生タイミングなどをソースシステムの理解を元に話せる人がほとんどいなかったから） - 当社はLookerの業務活用がかなり浸透しているので、Lookerで言うとどういう状態ですか？っていうディメンショナルモデリングの世界感における聞き方もできたのが大きかった。

Slide 34

Slide 34 text

２つの事例を通してこれまでもヒアリングを通して攻めのデータモデリングはしていたが、うまくできるかどうかは属人性が高かった。「BEAM*テーブル経由のコミュニケーション」という”型”ができたことで、チームとして設計スキルを手に入れられたのがとても大きい成果！

Slide 35

Slide 35 text

積極的に採用中です！まだまだ道半ばなのでお力を貸してください！XでのDMもお待ちしてます！ https://product-recruit.timee.co.jp/data