Yappli Tech Blog

株式会社ヤプリの開発メンバーによるブログです。最新の技術情報からチーム・働き方に関するテーマまで、日々の熱い想いを持って発信していきます。

ヤプリ製アプリの「熱量」を可視化せよ！インターン生がdbtとデータモデリングで挑んだ社内ダッシュボード構築記

インターン データエンジニアリング dbt データサイエンス Looker Studio BigQuery

はじめに

はじめまして！会津大学コンピュータ理工学部4年の寺田優彦と申します。
2026年1月16日から2月27日までの期間、株式会社ヤプリのデータサイエンス室にインターンとして参加させていただきました！ 私は会津若松市在住のため、今回のインターンは基本的にフルリモートで勤務しました。

今回のインターンでは、単にコードを書くだけではなく、データの先にいるユーザーやビジネスを意識した実務ならではのデータモデリングの考え方を学ぶことができました。
データエンジニアリング自体が初めての経験で、フルリモートという環境もあり最初は正直不安でしたが、約1ヶ月半を終えた今では、想像以上に濃い時間を過ごせたと感じています。

本記事では、私がこの期間に経験したことや、そこから得られた学びについて紹介します。

ヤプリインターンに参加した経緯

大学で統計学やデータサイエンスを学ぶ中で、理論の勉強だけでは「実務でどう使われているか」がどうしても見えてこないと感じていました。 統計検定準1級を取得して一定の基礎は固まったものの、次のステップとして実務経験が必要だと思い、Wantedlyでインターン先を探していたときにヤプリに出会いました。 数ある企業の中でヤプリに惹かれた理由は、大きく2つあります。

1. BtoBtoCというデータの面白さ

ヤプリは多くの企業にアプリプラットフォームを提供しているため、多様な業種・規模のユーザー行動データが蓄積されています。その多様さと規模感は、データを扱う場としてとても魅力的に映りました。

2. Web開発経験との親和性

元々Webサービスの実務開発に2年半ほど携わっていたため、ユーザーが触れる「アプリ」というプロダクトそのものへの愛着がありました。その開発経験と、ヤプリの「アプリ開発プラットフォーム」という領域の親和性に惹かれました。

ミッション

今回の私のミッションは、「オフィスのモニターに、Yappli製アプリが日々世の中で動いている『熱量』を常時表示するダッシュボード」を構築することでした。

プロジェクトの背景

このプロジェクトのきっかけは、代表の庵原さんからいただいた「オフィスにある空きモニターを活用して、社内の活動やプロダクトの動きを映し出したい」というリクエストです。

これを受けて、データサイエンス室でプロトタイプが開発されました。 しかし、スピード優先で構築されたこともあり、運用面や見せ方の部分に下記のような課題がある状態でした。

  • インサイトの不足：表示項目が単調で、データから新たな発見を得ることが難しい
  • 訴求力の欠如：ビジュアルに動きが少なく、プロダクトの「熱量」が伝わりにくい
  • 運用の高負荷：複雑なクエリが直接書き込まれており、メンテナンスや改修がしづらい

これらの課題を解消し、実用性とデザイン性を兼ね備えたダッシュボードへ進化させるべく、私がリニューアルを担当することになりました。

取り組んだこと

データパイプライン構築

プロトタイプの時点ですでに BigQuery と Looker Studio が導入されていましたが、BigQueryのビューで作られていたためメンテナンスがしにくい状態でした。 そこでdbtを導入し、この問題を解消しました。
データパイプラインはdbtをTROCCOで動かすことで構築しました。

加えて、「ディメンショナルモデリング」の手法を用いてデータモデリングをやり直しました。 「誰が（Who）」「何を（What）」「いつ（When）」といった7W分類に基づきデータを整理して、柔軟に分析を行えるデータ基盤としての土台を整えました。

ダッシュボード表示項目の検討

今のプロトタイプに対するフィードバックのメモをベースにしつつ、社内イベント「バトンランチ1」で社員の方々から頂いた「こんな指標があったら嬉しい」という生の声を肉付けし、ダッシュボードに載せるべき指標を定義していきました。

定義した内容を反映し、最終的に作成したダッシュボードがこちらです。 ※アプリ名、数値などはダミーです。

得られた学び

計算量を意識したSQL実装の重要性

当初は「まず必要なテーブルを全件読み込み、後続のロジックで直近30分に絞り込む」という素直な記述をしていました。しかし、ヤプリが扱う大規模なログデータに対してこれを行うと、たとえ最終的な表示結果が数件であっても、BigQueryが一度に膨大なデータをスキャンしようとしてしまい、"Run time error (Timeout)" が頻発しました。

そこで、スキャン対象を最小化するため、データの読み込みを行う最初の段階（CTE内）で直接時間を指定し、必要な期間のデータだけをピンポイントで取得するように修正しました。

修正前：全件を読み込んでから、後の処理で絞り込んでいた（非効率）

WITH 
_events AS (
SELECT
　user_id,
　event_at
FROM 
　{{ ref('fct_app') }}
),
-- ここでスキャン量が膨大になりタイムアウトが発生

final AS (
SELECT
　COUNT(DISTINCT user_id) AS au
FROM
　_events
WHERE
　-- ここで期間を絞る
　event_at >= TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 510 MINUTE) 
)

修正後：読み込みの起点で、時間を指定

WITH 
_events AS (
SELECT
　user_id,
　event_at
FROM 
　{{ ref('fct_app') }}
WHERE
　-- ここで期間を絞る
　event_at >= TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 510 MINUTE)
),

final AS (
SELECT
　COUNT(DISTINCT user_id) AS au
FROM
　_events
)

この修正により、スキャン量を劇的に削減でき、ダッシュボードがサクサク動くようになりました。「ただ結果が出るSQL」を書く段階から、「基盤の特性を意識し、計算リソースを適切に扱うSQL」を書くという、実務ならではの洗礼を受けた経験でした。

dbtの3層構造による、変更に強いモデリングの習得

dbtを用いたデータモデリングにおいて、ロジックを Staging / Intermediate / Marts の3層にどう切り分けるかに非常に苦労しました。 最初は各層の責務の理解が曖昧だったこともあり、本来はクレンジングのみを行うべき Staging層で複雑な計算をしてしまったり、逆に後半は Marts層にロジックを詰め込みすぎて、処理が著しく重くなってしまうといった失敗を繰り返しました。 特に痛感したのは、「どこで、どういうデータが欲しいか」というゴールからの逆算の重要性です。 「Intermediate層には不要だろう」と判断して削った項目が、後になってダッシュボード構築時に必要だと分かり、また一段階前の層に戻って修正するという手戻りが何度も発生しました。 業務を進めていく中で次第に「この分析項目が必要なら、Intermediateであらかじめこの形にしておき、Martでこう出す」という、最終形を見据えたデータの流れを意識して設計できるようになりました。

最終的に各層の責務は次のように理解しました。

  • Staging: 元データのクレンジングと最小限の型変換
  • Intermediate: 7W分類に基づいた複雑な結合や、再利用可能な集計ロジックを配置
  • Marts: Looker Studioから直接参照する、ビジネス指標に直結した最終テーブル

下記の記事を参考にしました。

ダッシュボードの本質は意思決定を促すインサイトにある

完成後のフィードバック会で、庵原さんに見てもらったところ「これ(画像の赤枠)ってなんのインサイトがあるの？」という問いをいただきました。 それまでの自分はダッシュボードの見栄えの良さや数字が正しく出ることに満足してしまっていました。しかし、フィードバック会でのやり取りを通じて、データ活用の本質は「見た目の綺麗さ以上に、それを見た人に何らかの発見や意思決定を促すことにある」のだと強く再認識させられました。

一方で、今回の工夫として取り入れたランキングは思いのほか好評で、デザイン面でも評価をいただくことができました。この経験から、プロのアウトプットには「直感的な分かりやすさ（デザイン）」と「深い洞察（インサイト）」の両立が不可欠なのだと身をもって学びました。

フィードバックを受けて、CX系アプリ（アパレル、飲食などのアプリ）とEX系アプリ（社内向けアプリ）を分けて、それぞれのアクティブユーザー率ランキングを追加しました。 事前にdbtで層分けやモデリングを整えていたおかげで、後からのロジック追加もスムーズに対応でき、基盤を整えておく重要性も改めて実感する機会となりました。

フィードバック会前のダッシュボード
※アプリ名、数値などはダミーです。

今後の展望

今後はこの基盤をさらに発展させることで、以下のような価値を提供できる可能性を感じました。

AIと連携による「数値の背景」の可視化

単に数値を並べるだけでなく、外部ニュースとAIを連携させた機能を実装したいです。各アプリに関連する最新ニュースを自動取得してAIで要約し、「なぜ今、この数値が動いているのか」という背景までをダッシュボード上で一言で伝えられるはずです。

#to-data への頻出依頼を「先回り」で可視化

データサイエンス室のSlack（#to-data）を見ていると、日々さまざまなデータ抽出や調査の依頼が寄せられています。 こうした依頼の中から、共通して求められる情報の傾向を特定し、あらかじめダッシュボードに反映しておくことができれば、依頼者が自ら解決できる「セルフサービス化」が進み、チーム全体の工数削減につながる可能性を感じました。

おわりに

このインターン期間は、dbtやSQLといった技術スキルの向上はもちろん、「そのデータは何のためにあるのか」というビジネス視点でのモデリングを学べた、非常に濃密な時間でした。 しかし、最終盤のフィードバック会で庵原さんからいただいた言葉を受け、正直に言えば「もっと良いものができたはずだ」という強い悔しさも残っています。実装を急ぐあまり、データが持つ本来のインサイトを突き詰めきれなかったことが、今の自分の課題だと痛感しました。

もし、インターンの初日に戻れるとしたら、私は以下のプロセスを徹底したと思います。

  • 目的の言語化： 実装に入る前に「どのテーブルのどの項目を、何の目的で可視化するか」を関係者全員と擦り合わせ、ドキュメントに残す。
  • 多角的なフィードバックの回収： メンターに相談するだけでなく、改修案を出してくれたメンバーにも制作途中のものを積極的に見せ、早い段階で多方面から意見をもらう。

「とりあえず動くものを作る」段階から、「何が求められているかをちゃんと汲み取ってから作る」というプロの仕事の難しさと大切さを知ることができました。この悔しさは、学生生活だけでは決して味わえなかった、実務の厳しさと面白さそのものでした。

最後になりますが、フルリモートの私を温かく迎え入れ、粘り強く付き合ってくださった山本さん、そして刺激的な環境を提供してくださったヤプリの皆さんに心から感謝しています。今回の学びと悔しさを糧に、これからも「思いやりのあるコード」と「価値のあるデータ」を追求するデータサイエンティストを目指して精進します！

  1. 新入社員の社内交流を深めるための「紹介制ランチ」制度
    リモートワーク下でも、部署の垣根を越えて雑談や繋がりを作るヤプリ独自の企画↩