SaaSのデータ基盤構築事例：手作業のスプレッドシートからセルフサービス分析へ

同社のプロジェクト管理SaaSは1,200社以上が利用し、前年比40%で成長していました。データは、HubSpot、Stripe、本番環境のPostgreSQLデータベース、Intercom、Google Analytics、QuickBooks、Gustoの7つのシステムで発生していました。基本的な経営上の質問に答えるだけで、アナリスト2名が何日もスプレッドシートで作業していました。

売上継続率（NRR）を出すには、Stripe、HubSpot、プロダクトのデータベースからデータを書き出し、一致しない顧客IDをVLOOKUPで突き合わせる必要がありました。そうして出した数字を、誰も完全には信用していませんでした。CEOが求めていたのは、月曜の朝に、ARR、NRR、解約、既存顧客からの増収、利用状況の推移をアナリストの手を借りずに確認できるダッシュボードです。財務担当VPは、月次決算に5日を費やしていました。財務レポートを作るために、4つのシステムのデータを手作業で集計する必要があったためです。

まず1週間、4,000ドルのデータ診断で、7つのデータソースをすべて調査し、レポートの必要性に優先順位を付けました。ARR/MRRのダッシュボードだけで毎週4時間、NRRに毎月8時間、月次決算の資料一式に毎月20時間の手作業がかかっていました。方針は、すべてのデータをSnowflakeに取り込み、指標をdbtでモデル化し、Metabaseでセルフサービスのダッシュボードを提供することです。

第2〜3週で基盤を立ち上げました。Fivetranで7つのデータソースをすべて接続し、同期の頻度は必要性に合わせました。プロダクトの利用データは1時間ごと、StripeとHubSpotは6時間ごと、Google AnalyticsとQuickBooksは1日1回です。Snowflakeは3層構成にしました。監査証跡として変更を加えない生データ層、システム間で顧客IDを統一したステージング層、そして財務、顧客、プロダクト、サポートの各領域でそのまま業務に使えるマート層です。

第4〜5週で、34個のdbtモデルを構築しました。日割り計算のロジックを含む顧客別のMRR、ARRのウォーターフォール、コホート別のNRR、複合的な顧客ヘルススコア、機能の利用定着モデルなどです。各モデルにはデータ品質テストを付けました。元データが壊れていた場合は、誤った指標を出すのではなく、パイプラインがはっきりとエラーで止まります。第6〜7週で、6つのMetabaseダッシュボード（経営、月次決算、顧客ヘルス、プロダクト分析、サポート、マーケティング）を公開し、2時間の研修で各チームに使い方を伝えました。

手作業のレポート作成は、月56時間以上から、確認のための4時間に減りました（-93%）。月次決算は5日から2日に短縮されました（-60%）。経営上の質問に答えるまでの時間は、手作業の分析による4〜8時間から、ダッシュボードでの30秒になりました。7つのデータソースはすべてSnowflakeに集約され、信頼できる唯一の情報源になっています。1,200社の全顧客について、ヘルススコアをリアルタイムで確認できます。

ヘルススコアのダッシュボードは、解約を先回りして防ぐ動きにつながりました。カスタマーサクセスチームは解約に向かっているアカウントを47件特定し、そのうち31件を維持しました（維持率66%）。これにより約186,000ドルのARRを守りました。プロダクト分析では、あまり使われていなかった時間記録の機能が、ほかのどの機能よりも2.4倍強く継続利用と相関していることがわかり、次のリリースサイクルの方向が変わりました。

初年度の投資額は合計78,200ドル（構築44,000ドル、プラットフォーム費用月額850ドル、サポート契約月額2,000ドル）です。これに対し、アナリストの作業時間の削減と解約防止による初年度の効果は270,000ドル以上でした。