Tableau向けSalesforceデータ抽出で「やらなければよかった」と後悔した設計

後から「やらなければよかった」と思った設計

当時の私は、SalesforceのデータモデルをそのままTableauのデータソースとして持ち込めば、ユーザーは慣れ親しんだSalesforceのレポートに近い感覚で分析できるだろう、と安易に考えていました。特に、Salesforceの標準レポートでは結合数が最大5オブジェクトという制約があったり、行数の上限（最大2,000行、エクスポートで最大65,000行）があったりするため、これらの壁を乗り越えるにはTableauが最適解だと信じ込んでいたんです。

結果として、Salesforceのオブジェクト構造、特にルックアップや主従関係が複雑に絡み合う商談やケース、あるいは大量のカスタムオブジェクトを持つ環境で、その失敗は顕著に現れました。Tableau Desktopでデータソースを作成する際、GUI上でSalesforceオブジェクトをドラッグ＆ドロップしてJOINを重ね、必要そうな項目はとりあえず全部持ってくる、というやり方を繰り返してしまいました。

膨れ上がるExtractと、見えないパフォーマンスボトルネック

まず最初に直面したのは、Tableau Server (当時、Tableau Cloudはまだ一般的ではなかった) 上のExtractファイルの肥大化でした。商談オブジェクトだけでも多くの関連オブジェクトが存在します。たとえば、商談に紐づく商品ラインアイテム、商談履歴、活動、関連する取引先、担当者、更にはカスタム設定やサマリーオブジェクトなど、あらゆるデータをJOINでつなぎ合わせた結果、たった一つのデータソースのExtractが数百GBに達することも珍しくありませんでした。当時はまだExtractの増分更新 (Incremental Refresh) の概念もそこまで深く理解しておらず、毎日のようにフルリフレッシュを走らせていたため、リフレッシュジョブが夜通し終わらない、という事態も発生しました。

次に、ワークブックのパフォーマンスです。ユーザーがダッシュボードを開くたびに、肥大化したExtractからデータを読み込み、複雑な計算フィールドや複数のフィルタが適用されるため、表示に何十秒もかかることが当たり前になりました。当時、SQLの知識も今ほど深くなかったため、Tableau Desktopのデータソース画面でオブジェクトをJOINする際、どのようなSQLが裏側で発行されているのか、インデックスがどう使われているのか、といったデータベースの基本的な最適化を全く考慮していませんでした。ただ闇雲にSalesforceのオブジェクトをJOINしていれば、Salesforceのレポートの限界を超えられる、と信じていたわけです。

失われた「使いやすさ」とメンテナンスの悪夢

そして、最も後悔しているのは、ユーザーエクスペリエンスの低下とメンテナンスコストの増大です。Salesforceのレポートは、たとえ結合が多くても、UI上で直感的に項目を選択し、グループ化や集計ができるように設計されています。しかし、TableauでSalesforceの複雑なデータモデルをそのまま再現しようとすると、ユーザーは「これは一体何の項目なのか」「どのテーブルをJOINすれば正しいデータが得られるのか」といった混乱に陥りやすくなりました。

データエンジニアである私の視点では、一つのSalesforceオブジェクトの項目が少しでも変わると、そのオブジェクトを参照している複数のExtractの定義を見直す必要がありました。Salesforceのカスタム項目名の変更や、新しいルックアップ項目の追加一つで、Tableau側のデータソースのJOIN条件や計算フィールドに影響が出ることが多々あり、デバッグに多くの時間を費やすことになりました。結局、Salesforceのレポートが提供する「リアルタイム性」や「レコード詳細へのシームレスなドリルダウン」といった利点を、Tableauで無理やり再現しようとすることで、かえって複雑性ばかりが増し、どちらのツールの良さも半減させてしまったように感じています。

今なら別の選択をする

今なら、SalesforceのデータはTableauでの分析目的のために、徹底的に整形された「データマート」として抽出する、というアプローチを取ります。具体的には、Salesforceのデータモデルをそのまま持ち込むのではなく、Tableauで利用するメトリクスとディメンションを明確にし、必要な項目のみをSELECT文で抽出し、場合によってはSQLで事前に集計やJOINを済ませてからExtractを作成します。

中間データウェアハウスがある環境であれば、ETL/ELTプロセスでSalesforceデータを適切なスキーマ（例えばスター・スキーマ）に変換し、それをTableauのデータソースとします。もし中間データウェアハウスがない場合でも、TableauのカスタムSQL機能や、Salesforce APIを直接叩いて必要なデータを取得し、データ抽出ツール（例えばTalendやInformaticaといったSaaS連携ツール、あるいはPythonスクリプト）で整形してからTableauにロードする、という手順を踏むでしょう。

何よりも重要なのは、Salesforceのレポートで十分な要件はSalesforceで完結させ、TableauはSalesforce単体では実現できない高度な分析、あるいはSalesforce以外のデータとの統合分析に特化させる、という割り切りです。当時はその区別が曖昧で、Salesforceのレポートの限界をTableauですべてカバーできる、と過信していたのが、今振り返ると最大の判断ミスだったと感じています。これは当時の自分向けのメモだ。