「必要とされるデータ基盤」で あり続けるためにやってきたこと 2025.9.4 in レバテックMeetup 株式会社ヤプリ ⼭本 雄太 

SPEAKER 開発統括本部 プロダクト開発本部 データサイエンス室（以下、DS室） ⼭本 雄太 ● 2023年に新卒⼊社 ● dbt導⼊に際して、開発体制やリリースフローなどの 構築を担当 ● pUG（旧TROCCOUG）の運営にも携わらせていただ いています 

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

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

データ基盤は 必要とされ続けることが重要 

ヤプリのデータ基盤は必要とされ続けている ● プロダクト⽤データ基盤：Yappliのサービスデータを扱う ○ 各アナリティクスサービスの提供 ○ Yappliの機能開発の優先度づけの根拠 ○ 顧客へのCS活動の補助 ■ アプリの運⽤状況の把握、施策の効果検証、etc. ○ 営業戦略の補助 ■ アプローチをかけるべき業界の検討、etc. ● ビジネス⽤データ基盤：Salesforce等のビジネスデータを扱う ○ 経営指標のモニタリング ■ 売上⾼、受注件数、チャーンレート、営業進捗、etc. 

必要とされ続けるために 何をやってきたのか？ 

INDEX ⽬次 1. 要望に応え続けした 2. エンジニアから集計の責務を剥がした — 3. 必要とされ続けることで起きること 

INDEX ⽬次 1. 要望に応え続けした 2. エンジニアから集計の責務を剥がした → 要点だけ。⼤幅カット🙇   （詳細は後述の過去登壇資料をご覧ください） — 3. 必要とされ続けることで起きること 

要望に応え続けた 

「要望に”応え続ける”」には ● 様々なデータ利⽤者からの「〜したい」を実現し続ける ● データ利⽤者から要望が勝⼿に集まってくるようにすることが重要 ○ ヒアリングしないと要望が出てこない場合、データ基盤がうまく活⽤されてない可能性あり ■ ちゃんと活⽤されていれば要望（や不満）が⾊々出てくるはず 1. 要望に応え続けした 

要望が勝⼿に集まってくるようにするには？ ● 「要望を⾔えば応えてもらえる」という信頼を得ること ● カジュアルに要望が⾔える関係値を築くこと 1. 要望に応え続けした 

要望が勝⼿に集まってくるようにするには？ ● 「要望を⾔えば応えてもらえる」という信頼を得ること ● カジュアルに要望が⾔える関係値を築くこと 1. 要望に応え続けした 

要望が勝⼿に集まってくるようにするには？ ● 「要望を⾔えば応えてもらえる」という信頼を得ること ○ 要望にスピーディーに応える ○ 直接叶えられなくても、代替案で可能な限り応える ● カジュアルに要望が⾔える関係値を築くこと 1. 要望に応え続けした 

「要望を⾔えば応えてもらえる」という信頼を得るには 要望にスピーディーに応える ● 早く対応してもらえると、シンプルにありがたい ○ 弊社の場合、社内からの要望‧問い合わせはなるべく1営業⽇以内に対応 ● すぐ対応できない場合は⼀次回答 ○ リアクションを押したり、「ちょっと待ってね」を返信したり ○ ⼀次回答がないと… ■ 要望を送った側は「対応に時間がかかってる」or「⾒逃してる」がわからない → 地味にストレス ○ ⼀次回答が早いだけでも信頼は少しながら得られる 1. 要望に応え続けした 

「要望を⾔えば応えてもらえる」という信頼を得るには 要望にスピーディーに応える ● 要望‧問い合わせ対応を頑張ってたら、他の仕事できなくない？ ○ 根本的な改善タスクに取り組めず、その場しのぎの対応しかできない… ● 採⽤した新メンバーに根本的な改善タスクを任せる ○ 元から在籍していたメンバー（1⼈） ■ 引き続き、要望‧問い合わせ対応 ○ 新たに⼊社したメンバー（3⼈） ■ 根本的な改善タスクを担当 ● dbt導⼊、RevOps基盤構築 1. 要望に応え続けした 要望に応え続けつつ、⼤元のデータ基盤をしっかり成⻑させる 

「要望を⾔えば応えてもらえる」という信頼を得るには 直接叶えられなくても、代替案で可能な限り応える ● 応えられる要望の数は多い⽅が早く信頼が得られる ● 要望をしっかり聞いてみると、そこまで正確性が求められてないこともある ○ 代替案での近似で⼗分応えられるケースも全然ある ○ 実際にあった事例） ■ 要望: Yappliの機能の改修優先度をつけたいので、各機能の設定状況の変遷が知りたい ● 各アプリでどの機能がどのくらい設定されてきたのか ■ しかし、データが存在するのは「現在」の設定状況のみ… ■ そこで、現存する機能の初回設定⽇で代⽤ ● 改修優先度をつける⽤途であれば、⼗分代⽤可能 1. 要望に応え続けした 

要望が勝⼿に集まってくるようにするには？ ● 「要望を⾔えば応えてもらえる」という信頼を得ること ○ 要望にスピーディーに応える ○ 直接叶えられなくても、代替案で可能な限り応える ● カジュアルに要望が⾔える関係値を築くこと 1. 要望に応え続けした 

カジュアルに要望が⾔える 関係値を築くには？ 1. 要望に応え続けした 

仲良くなる🤝 1. 要望に応え続けした 

カジュアルに要望が⾔える関係値を築くには ● 単純接触効果 ○ オフィスで雑談する ○ ⼀緒にご飯にいく ○ 隣の席で仕事してみる（フリーアドレスの場合） ○ Slackで#times-*チャンネルがあったら⼊って、リアクションしたり会話したりする ● 仲良くなっていくと、相談ベースで要望がポロっと出てくることがある ○ 例）「こういうデータって出せたりするの？」「こういうことってできたりするの？」 ● ポロっと出た要望に応えると、次から相談‧要望を⾔ってもらいやすくなる ● 「あの⼈に相談するといいよ」という認識が広がっていけば成功 1. 要望に応え続けした 

カジュアルに要望が⾔える関係値を築くには 「あの⼈に相談するといいよ」という認識が広がって⼤成功した事例 ● 24卒メンバーが⼊社後、ビジネス部⾨の⼈と積極的に交流 ○ オフィスで雑談したり、ご飯に⾏ったり、隣の席で仕事したり（フリーアドレス） ● その結果、オフィスで仕事をしていると席まで相談に来てくれるように ○ 「今、ちょっと良いですか？」 ● その後、RevOpsの波が到来＆社内でもビジネス部⾨の全体最適化が課題に ○ → RevOps基盤の構築プロジェクトへ参画 1. 要望に応え続ける 

この章のまとめ 必要とされ続けるために何をやってきたこと① ● 要望に応え続けた ○ データ利⽤者から要望が勝⼿に集まってくるようにする ■ 「要望を⾔えば応えてもらえる」という信頼を得ること ● 要望にスピーディーに応える ● 直接叶えられなくても、代替案で可能な限り応える ■ カジュアルに要望が⾔える関係値を築くこと ● 仲良くなる ○ 雑談、ご飯、隣で仕事、Slackでリアクション、etc. 1. 要望に応え続けした 

エンジニアから 集計の責務を剥がした 

プロダクト⽤データ基盤の誕⽣経緯 ● CMSにレポート画⾯をつけるために構築された専⽤データ基盤 ● エンジニアの持ち物として管理 ○ 集計クエリのメンテナンスもエンジニアで担当 ● まだデータ組織は存在してなかった ○ ようやく1⼈⽬のデータ⼈材が⼊社したくらい 2. エンジニアから集計の責務を剥がした 

3年ほど運⽤して、課題が噴出 ● CMSレポート以外のアナリティクスサービスが登場 ○ Yappli Analytics、Yappli Data Hub ● 既存のデータ基盤を増築して対応 →ガタが⾊々来てた ○ クエリ費⽤、バッチの実⾏時間、リソースのメモリ上限、etc. ● 2⼈⽬〜のデータ⼈材が⼊社し、「データ組織」が誕⽣ 2. エンジニアから集計の責務を剥がした 

エンジニアから集計の責務を剥がした ● dbtを導⼊し、エンジニアがメンテナンスしていた集計処理を移譲 ○ 従来、集計処理を⾏っていた箇所は集計済みテーブルをSELECT * FROM tableするだけに ● 集計の責務が無くなったことで、エンジニアの負担が⼤幅軽減 ○ 増改築された数百⾏のSQLを⾒なくて良い ○ データ量が増えてメモリエラーを起こすバッチと向き合わなくて良い ○ 「集計がおかしい」というインシデントに対応しなくて良い ○ etc. ● データ基盤の良さ（＝必要性）を感じてもらえた ○ 以後のコミュニケーションが円滑に 2. エンジニアから集計の責務を剥がした 

詳細はこちらの資料をご覧ください🙇 2. エンジニアから集計の責務を剥がした https://speakerdeck.com/yamamotoyuta/ci-no10nian-wozhan-er ufen-xi-yong-detaji-pan-gou-zhu-nodi-bu-dbtniyoruji-pan-shua-xi n-tokuerifei-yong-90-percent-xue-jian-henoqu-rizu-mi https://speakerdeck.com/yamamotoyuta/growth-strategy-of-data -analytics-platforms-from-a-product-perspective https://speakerdeck.com/yamamotoyuta/cross-team-impact-95-p ercent-off-raw-data-query-costs 

必要とされ続けることで 起きること 

何が起きるのか？ 3. 必要とされ続けることで起きること 

外部要因によって 急に追い⾵が吹いてくる📈 3. 必要とされ続けることで起きること 

それによって、⼀気に事が進む💪 3. 必要とされ続けることで起きること 

追い⾵が吹いて⼀気進んだこと ● プロダクト⽤データ基盤だと… ○ プロダクト⽤データ基盤で⼀定の必要性を⽰せた事で、採⽤枠がもらえた ○ 同タイミングでdbtが台頭してきた（＝外部要因） → 新メンバーをdbt導⼊に専念させる事ができ、データマネジメント強化が⼀気に進んだ ● ビジネス⽤データ基盤だと… ○ 24卒メンバーが⼊社後、ビジネス部⾨の⼈と積極的に交流 →しっかり関係構築 ○ 外部要因: RevOpsの波が到来＆ビジネス部⾨の全体最適化の機運の⾼まり → RevOps基盤の構築が⼀気に進んだ 3. 必要とされ続けることで起きること 

「必要とされるデータ基盤」であり続けるよう頑張って、 吹いてきた追い⾵に乗って ⼀気に事を進めよう！ 3. 必要とされ続けることで起きること 

まとめ 

ヤプリのデータ基盤が必要とされ続けている秘訣 ● ① 要望に応え続けた ○ データ利⽤者から要望が勝⼿に集まってくるようにする ■ 「要望を⾔えば応えてもらえる」という信頼を得ること ● 要望にスピーディーに応える、直接叶えられなくても代替案で可能な限り応える ■ カジュアルに要望が⾔える関係値を築くこと ● 仲良くなる（雑談、ご飯、隣で仕事、Slackでリアクション） ● ② エンジニアから集計の責務を剥がした ○ 開発者体験の向上や考慮事項の減少により、データ基盤の必要性を感じてもらえた まとめ 必要とされ続けることで、外部要因によって急に追い⾵が吹いてくる → ⼀気に事を進めよう！