📊

2年間運用した個人開発アプリを、dbtとLightdashで分析基盤化した話

に公開
個人開発
BigQuery
dataengineering
dbt
Lightdash
tech

2年間運用した個人開発アプリを、dbtとLightdashで分析基盤化した話

Lightdashで作成したダッシュボード

個人開発では、

  • ログイン機能を作る
  • フォームを作る
  • DBに保存する
  • 管理画面を作る

といったところまで作って「完成」となることが多いと思います。

もちろん、そこまで作るだけでも十分大変です。

ただ、実際にプロダクトを運用していると、次のようなことを考えるようになります。

  • どれくらい利用されているのか
  • どのユーザーが継続利用しているのか
  • どんな入力傾向があるのか
  • 改善すべき箇所はどこか
  • 業務は本当に効率化されたのか

つまり、

「データをどう活用するか」

という問題です。

今回は、約2年間運用している個人開発の問診票・記録管理アプリに対して、

  • BigQuery
  • dbt
  • Lightdash

を導入し、分析基盤まで構築した話を書きます。

運用実績

まず、今回のプロダクトの実績です。

  • 約2年間運用
  • 登録ユーザー数：298名
  • 問診票数：475件
  • 問診業務を約92%削減
  • 約435時間（約54営業日）の工数削減
  • 約65万円相当の業務コスト削減（試算）

単なる「作って終わり」の個人開発ではなく、実際に継続運用されているプロダクトです。

なぜ作ったのか

元々は、PDFやWord形式の問診票をメールで送付していました。

つまり、

施術者
↓
メール送信
↓
利用者が入力
↓
メール返信
↓
施術者が確認

というかなりアナログな運用です。

このフローには多くの問題がありました。

  • メールテンプレート作成
  • PDF添付
  • 記入方法説明
  • 添付ファイル返送サポート
  • 返信待ち
  • 手動確認
  • データ転記
  • 属人化

特に大きかったのが、

「返信が返ってくるまで数時間〜1日待つ」

という同期的な業務フローでした。

解決したかったこと

今回やりたかったのは、

「問診票入力を完全非同期化する」

ことです。

つまり、

利用者が好きなタイミングで入力
↓
DBへ自動保存
↓
LINE通知
↓
管理画面で即確認

という流れに変えました。

これによって、

  • 待機時間
  • メール往復
  • 添付管理
  • 転記

などのコストを大きく削減できました。

作ったもの

作ったものは大きく2つあります。

1. 問診票・記録管理アプリ

施術者向けのWebアプリケーションです。

主な機能は以下です。

  • ユーザー登録・認証
  • 問診票入力
  • 症状チェックリスト
  • 重症度評価
  • 日常生活動作評価
  • 既往歴・現病歴管理
  • 施術メモ
  • AIによる要約・分類
  • Slack / LINE通知

アプリ本体は、

  • Next.js
  • Supabase
  • Vercel

を中心に構築しています。

2. 分析基盤

もう一つが、今回の記事の中心である分析基盤です。

こちらは、

  • BigQuery
  • dbt
  • Lightdash

を使っています。

技術スタック

領域 技術
Frontend Next.js 14 / React 18
Backend Supabase
Database PostgreSQL
Auth Supabase Auth
Hosting Vercel
Infrastructure Docker
Notifications LINE Messaging API / Slack Webhook
AI OpenAI
DWH BigQuery
Data Modeling dbt
BI Lightdash

アプリ本体の全体設計

アプリ全体の構成は以下です。

アプリ本体の全体設計

全体としては、

User / Admin
  ↓
Next.js Frontend
  ↓
Next.js API Routes
  ↓
Supabase Auth / PostgreSQL
  ↓
External Services
  ├── OpenAI
  ├── Slack
  └── LINE

という構成になっています。

また、

  • LINE通知
  • Slack通知
  • 非同期フォーム入力
  • OpenAIによる要約

なども組み込んでいます。

なぜ分析基盤を作ったのか

アプリを作って運用していると、当然データが蓄積されます。

すると次第に、

  • どれくらい使われているのか
  • どのユーザーが継続利用しているのか
  • どんな傾向があるのか

を見たくなります。

しかし、アプリケーションDBは、

  • 登録
  • 更新
  • 表示

には向いていても、

分析に向いているとは限りません。

そこで、BigQuery + dbt + Lightdash を使って分析基盤を作ることにしました。

全体構成

分析基盤側の全体構成は以下です。

Application
  ↓
Supabase / PostgreSQL
  ↓
BigQuery
  ↓
dbt
  ↓
Lightdash
  ↓
Dashboard

つまり、

アプリを作る
↓
データが貯まる
↓
分析用に変換する
↓
可視化する
↓
改善に使う

という流れです。

dbtのレイヤー設計

dbtでは以下のようにレイヤーを分けました。

models/
├── staging/
├── intermediate/
└── marts/

staging

staging層では、生データを扱いやすく整えます。

stg_users
stg_medical_diagnosis_form

ここでは主に、

  • 型変換
  • カラム整理
  • 命名統一
  • 不要カラム除外

を行います。

intermediate

intermediate層では、分析用の意味づけを行います。

int_medical_diagnoses_enriched
int_medical_diagnoses_summary
int_patient_visit_cycles

例えば、

  • 初回問診日
  • 最終問診日
  • 問診回数
  • 継続状況

などをここで計算します。

marts

marts層では、Lightdashでそのまま使いやすい形に整えます。

dim_users
fct_diagnosis_events
dim_user_progression

今回かなり勉強になったのが、

fact / dimension

の考え方でした。

今回は、

問診票1回答 = fact
ユーザー1人 = dimension

という形で整理しています。

アプリケーションDBと分析DBは違う

今回一番学びになったのは、

「アプリケーションDBと分析DBは設計思想が違う」

ということでした。

アプリケーションDBでは、

  • 更新しやすい
  • 登録しやすい

が重要です。

一方、分析基盤では、

  • 何を1行とするか
  • どの単位で集計するか
  • 何をdimensionにするか

が重要になります。

これは実際に作ってみてかなり理解が深まりました。

Lightdashで見たい指標

Lightdashでは、以下のような指標を可視化する予定です。

利用状況

  • 日別問診数
  • ユーザー数
  • 初回問診数
  • 再問診数
  • リピート率

ユーザーサマリー

  • ユーザー別問診回数
  • 初回問診日
  • 最終問診日
  • 継続利用状況

症状分析

  • 症状別件数
  • 平均スコア
  • 初回 / 再訪比較

Lightdashへのdeploy

Lightdash CLIを使って deploy します。

lightdash deploy

結果は以下のようになりました。

- SUCCESS> stg_users
- SUCCESS> stg_medical_diagnosis_form
- SUCCESS> int_medical_diagnoses_summary
- SUCCESS> dim_users
- SUCCESS> fct_diagnosis_events

Compiled 9 explores, SUCCESS=9 ERRORS=0

最初は、

No dimensions available

というエラーも出ました。

原因は、Lightdash用metadata YAMLの dimension 定義不足でした。

dbtでSQLを書くだけではなく、

  • dimensions
  • metrics
  • metadata

まで含めて設計する必要があるのが、かなり実務的でした。

運用してみて分かったこと

今回かなり感じたのが、

「作る」と「運用する」は全然違う

ということでした。

実際に運用すると、

  • エラー監視
  • データ不整合
  • UI改善
  • 問い合わせ対応
  • LINE通知調整
  • データ整合性確認

など、運用しないと見えない課題が大量に出てきます。

これはかなり勉強になりました。

個人開発で分析基盤までやる意味

個人開発は、

「アプリを作って終わり」

になりやすいです。

しかし実際には、

作る
↓
運用する
↓
データが貯まる
↓
分析する
↓
改善する

までがプロダクトだと思っています。

今回、

  • Webアプリ
  • 認証
  • DB設計
  • 通知連携
  • BigQuery
  • dbt
  • Lightdash
  • KPI可視化

まで一気通貫で経験できたのはかなり大きかったです。

今後やりたいこと

今後は、

  • dbt tests追加
  • CI/CD整備
  • mart追加
  • KPI拡張
  • retention分析
  • cohort分析
  • データ品質監視

なども進めていきたいです。

まとめ

個人開発は、アプリを作るだけでも十分学びがあります。

ただ、そのデータを分析基盤までつなげると、学びの深さが一気に変わります。

今回の取り組みを通じて、

  • アプリケーション開発
  • データモデリング
  • 分析基盤
  • BI
  • KPI設計

を一つの流れとして扱うことができました。

個人開発でも、

「データが価値になるところまで作る」

ことはできると思っています。

アプリを作って終わりにしない。
データが生まれたなら、そのデータを改善につなげるところまで作る。

これが、今回一番伝えたかったことです。

Discussion