Tableauを活かすためにTableauに制約を設けた話

2026-04-24に開催された人材サービス業界 Tableau Meetupの登壇資料

Transcript

1. 2026/04/24 ⼈材サービス業界Meetup Tableauを活かすために Tableauに制約を設けた話
2. 2 © 2026 Leverages Co., Ltd. 01 - ⾃⼰紹介 CONTENTS 03 - 当時のデータ分析基盤と課題 04 - データ分析基盤の再構築 05 - Tableauの役割を再定義 06 - 結果‧今後の展望 02 - 会社紹介 07 - さいごに
3. 3 © 2026 Leverages Co., Ltd. ⾃⼰紹介 01
4. 4 © 2026 Leverages Co., Ltd. 01 ⾃⼰紹介 経歴： ‧新卒でコンサル会社にデータサイエンティストとして⼊社  ‧4年間、機械学習モデルの構築やモデル構築後のシステムの開発   保守、運⽤、システム拡⼤に従事 ‧2023年8⽉にレバレジーズにデータアナリストとして中途⼊社  ‧分析業務していく中で指標やセグメントの定義統⼀の重要性を   知り、データ分析基盤再構築プロジェクトの発起⼈として   データマネジメント領域に突っ込む  ‧現在は全社のデータ分析基盤再構築のPM / データガバナンス策定など   データマネジメントに関わるプロジェクトを推進したり、   リーダー業務としてチームマネジメント‧採⽤に従事 レバレジーズ株式会社 マーケティング部 データ戦略室 データアーキテクトグループ リーダー ⽥代 渉（たしろ わたる）
5. 5 © 2026 Leverages Co., Ltd. 会社紹介 02
6. 6 © 2026 Leverages Co., Ltd. 02 会社紹介 社名 レバレジーズ株式会社 Leverages Co.,Ltd. 従業員数 3,338名（2025年4⽉現在） 代表者 岩槻 知秀 資本⾦ 5,000万円 所在地‧拠点 本社：東京都渋⾕区渋⾕2丁⽬24番12号 渋⾕スクランブルスクエア24F‧25F 国内拠点：27拠点 海外拠点：3拠点 会社概要 事業の種類
7. 7 © 2026 Leverages Co., Ltd. レバレジーズのデータ / AI職種は7職種に分かれており、2026年3⽉時点で正社員32名が在籍。 02 会社紹介 職種名 職種概要 在籍⼈数※ 2名 （兼任1名） 6名 4名 5名 （兼任2名） 6名 （+契約社員 / 業務委託） 6名 3名 ※ 2026年3⽉時点。上記職種とは別にマネージャーが2名在籍
8. 8 © 2026 Leverages Co., Ltd. 当時のデータ分析基盤と課題 03
9. 9 © 2026 Leverages Co., Ltd. データ⺠主化を素早く提供する環境を構築していたため、属⼈的な中央集権で⾃由に分析できる環境を提供していた。 03 当時のデータ分析基盤と課題 当時のデータ分析基盤‧体制 事業成⻑するために、各々担当者の属⼈的な⽅針に則っている 例：TableauにはGoogle Spread Sheetを繋ぐ / 繋がない ⽅針 DWHやTableau：データ戦略室が管理（中央集権） データ出し‧集計：データ戦略室管轄と現場管轄に分かれる 体制 DWHツール：BigQuery 変換ツール：Dataform / Cloud Composer BIツール：Tableau / Google Spread Sheet 技術スタック データ周りの引き継ぎコスト、ロジックの信頼性が失われている ‧DWH / BIのデータ分析基盤のフローや役割が複雑 ‧DWH内部のテーブル依存関係が複雑 ‧使⽤するシステムデータが増えすぎて⼈が管理するには限界 課題
10. 10 © 2026 Leverages Co., Ltd. 基本的にDWHとBIはデータ戦略室が管理‧作成を⾏い、分析等は分析者がDWHからデータを出⼒していた。 また各種データソースは基本DWHに格納していたが、⼀部のお⼿製データはTableauに直つなぎが⾏われていた。 03 当時のデータ分析基盤と課題 お⼿製データ 外部ツール SFA 内製システム データソース データ分析基盤 DWH BI 複数システムをあわせて 分析する⼈が簡単に分析 可能にする基盤を データ戦略室が構築 BigQuery 事業全体で⾒る 数値はこちらで 管理。データ戦略 室が管理 Tableau 分析やチーム単位 の数値は⾃由に 分析‧出⼒。 管理者なし Spread Sheet 管理できていないところで正しくないデータ を使った分析が⾏われることでガバナンスの 崩壊が起きかけており、 保守運⽤コストがかなり⾼くなった お⼿製データ
11. 11 © 2026 Leverages Co., Ltd. 短期の事業成⻑を優先した結果、早くデータを出すために依存関係を無視したデータマートが複数発⽣しており、 いつ時点のデータが更新されているかがわからないテーブルが存在していた。 03 当時のデータ分析基盤と課題 テーブルA テーブルB テーブルA テーブルC 参照 参照 当時のDWHのアーキテクチャ 事業成⻑を優先したため、datamartのロジックを今あるテーブルの内容を参照するように作成した結果 循環参照になってしまったため、いつ時点の更新のデータが⼊るかがわからない → データ戦略室内で引き継ぐときになぜこれが起きているのか誰も把握できていない状態
12. 12 © 2026 Leverages Co., Ltd. DWHとTableauで重複した機能があったが、どちらのツールで処理を⾏うか決めていなかったため属⼈的に⾏っていた。 結果として、保守運⽤および引き継ぎコストがかなり⾼くなった。 03 当時のデータ分析基盤と課題 当時のDWHとTableauで使⽤している機能 DWH（SQL） Tableau テーブル作成機能： ユースケースごとのテーブルを作成 ロジック作成機能： 集計やモニタリングに必要なロジックの実装 Tableauのビジュアライズ機能： ドリルダウンやグラフ‧表の⽣成機能 ブレンド機能： 複数テーブルの結合 計算フィールド： 集計やモニタリングに必要なロジックの実装 DWHとTableauで使⽤している機能が重複することで、どちらのツールで処理を⾏っているかが 属⼈化したことでデータ分析基盤全体の保守運⽤コストが⾼くなってしまった 結合機能： 単⼀システム内のデータの結合 複数システムのデータの結合
13. 13 © 2026 Leverages Co., Ltd. 会社が急成⻑を遂げるにあたり、データ分析基盤を再構築しないと崩壊することが⽬に⾒えていたため、 「安⼼/安全」に「素早く」「正しい」データが出せるようにするために⼤規模なプロジェクトを開始。 03 当時のデータ分析基盤と課題 ⼤⽅針 ⽬標 利⽤⼈数やデータ量が10倍になっても耐えられる形にする！ 「安⼼/安全」に「素早く」「正しい」データが出せるようにする ビジネスモデルに依存しないデータアーキテクチャの設計 〜データ組織内の誰でも対応できるアーキテクチャへ〜 1 2 すでに浸透されたデータ⺠主化を加味したテーブル設計 〜SQLを当たり前に使⽤する弊社社員に優しさを〜 3 各種ツールやデータアーキテクチャの層の役割を明確にする 〜なんでもできるツールだからこそ強みを最⼤限に活かす〜 今回のプロジェクトの⽬標と⼤⽅針
14. 14 © 2026 Leverages Co., Ltd. DWHではビジネスロジックをGitHubでコード管理をできるようにし、Tableauはビジュアライズに特化させるように 役割を分けてツールを使⽤。 03 当時のデータ分析基盤と課題 DWH（SQL） Tableau ‧テーブル結合 ‧データ型の変換 ‧ビジネスロジックに当てはめた  指標 / ディメンションの定義 ‧GitHubによるコード管理 ‧指標を集計するためのダッシュボードのルールとして策定 ‧探索⽤（データの⼀覧を出⼒する等）のルールは未策定 ‧Tableauのビジュアライズ機能 ‧ビジュアライズするための割合の計算  （分⼦ / 分⺟の計算） ‧ビジュアライズするためのカラムリネーム ‧ブレンド機能によるテーブル結合 ‧データ型の変換 ‧ビジネスロジックに当てはめた  指標 / ディメンションの定義 ‧GitHubによるコード管理 ‧割合の計算 ‧ビジュアライズに関すること やること やらない こと 前提 指標やディメンションの定義を統⼀する ビジュアライズに特化させる 役割
15. 15 © 2026 Leverages Co., Ltd. データ分析基盤の再構築 04
16. 16 © 2026 Leverages Co., Ltd. DWHでの役割の詳細をまずはご説明。 04 データ分析基盤の再構築 DWH（SQL） Tableau ‧テーブル結合 ‧データ型の変換 ‧ビジネスロジックに当てはめた  指標 / ディメンションの定義 ‧GitHubによるコード管理 ‧指標を集計するためのダッシュボードのルールとして策定 ‧探索⽤（データの⼀覧を出⼒する等）のルールは未策定 ‧Tableauのビジュアライズ機能 ‧ビジュアライズするための割合の計算  （分⼦ / 分⺟の計算） ‧ビジュアライズするためのカラムリネーム ‧ブレンド機能によるテーブル結合 ‧データ型の変換 ‧ビジネスロジックに当てはめた  指標 / ディメンションの定義 ‧GitHubによるコード管理 ‧割合の計算 ‧ビジュアライズに関すること やること やらない こと 前提 指標やディメンションの定義を統⼀する ビジュアライズに特化させる 役割
17. 17 © 2026 Leverages Co., Ltd. 依存関係や役割を分割するために、データ分析基盤全体として8層構成のアーキテクチャを設計。 04 データ分析基盤の再構築 今回実施したアーキテクチャの概要図 ‧BigQuery内部のテーブル7層 + Tableau1層の合計8層で管理 ‧テーブルの依存関係を明確にするために、基本⼿前の層のテーブルしか参照しないルール ‧データ分析をする⽅たちへはデータマート層を連携 概要
18. 18 © 2026 Leverages Co., Ltd. データレイク層では、ETLツール等を使⽤して連携したデータをそのまま格納する。 04 データ分析基盤の再構築 ‧ETLツールを利⽤して、ローデータを取得してBigQueryを更新するのみ⾏う ‧データに対する処理を⼀切⾏わない ‧使⽤するETLツールは問わない（何を使⽤するかは本取り組みのスコープ外） 概要 各システム等のデータソースからBigQueryへ連携する 役割 データレイク層 名称
19. 19 © 2026 Leverages Co., Ltd. ステージング層では、ETLツール特有の不要なカラムや物理削除されているレコードを除外。 04 データ分析基盤の再構築 ‧ETLツールの変更等によりデータレイク層が変わったときの付け替え ‧不要なカラムおよび物理削除されたレコードの除外、データ型の変換を⾏う ‧テーブルの結合やビジネスロジックは実装しない 概要 データレイク層のローデータに対して最低限の加⼯を⾏う 役割 ステージング層 名称
20. 20 © 2026 Leverages Co., Ltd. シングルシステムデータウェアハウス層では、1つのシステム内で必要なテーブルの結合および論理削除への対応を⾏う。 04 データ分析基盤の再構築 ‧同システム内におけるテーブル結合およびカラム名の統⼀（date型なら~_date）を⾏う ‧論理削除に対する処理を⾏う ‧他システムからのデータを使⽤したテーブルは作成しない 概要 単⼀システム内のテーブル同⼠を結合し、単⼀システム内でのシステム改修を吸収する 役割 シングルシステムデータウェアハウス層 名称
21. 21 © 2026 Leverages Co., Ltd. データウェアハウス層では、複数システム同⼠のシングルシステムデータウェアハウス層のテーブルを結合。 04 データ分析基盤の再構築 ‧複数システム間のテーブル結合とカラム名の変更のみを⾏う ‧単⼀システムのテーブル結合やビジネスロジックは⾏わない 概要 複数システム内のテーブル同⼠を結合し、データ活⽤の基礎となるテーブルを作成 役割 データウェアハウス層 名称
22. 22 © 2026 Leverages Co., Ltd. データマート層では、⽤途に合わせたテーブルを作成し、必要なビジネスロジックを実装する。 また、利⽤者のイメージが持てるようにカラム名は⽇本語。 04 データ分析基盤の再構築 ‧事業の指標やディメンションに必要なデータに絞り込み、ビジネスロジックを追加 ‧事業で使⽤する⽤語を正確に表現するため、基本的にカラム名を⽇本語へ変更 ‧⽬的に合わせてテーブルを作成するため、全情報を載せたテーブルは作らない 概要 特定の⽬的に合わせたデータを活⽤しやすい形で保持する 役割 データマート層 名称
23. 23 © 2026 Leverages Co., Ltd. セマンティックレイヤーでは、指標およびディメンションの定義を⼀元管理。 04 データ分析基盤の再構築 ‧指標、ディメンションの定義を⾏い、SQLで表現する（データを縦持ち） ‧複雑なロジックは導⼊しない（データマート層で対応する） ‧指標の多重管理を阻⽌するため、可能な限りサービスごとに1ファイルで管理する 概要 指標、ディメンションの定義を共通化する 役割 セマンティックレイヤー 名称
24. 24 © 2026 Leverages Co., Ltd. リバースETL層では、DWHの外へ連携するテーブルを作成する 04 データ分析基盤の再構築 ‧複雑なロジックは導⼊しない（select / from / where / union等に留める） ‧接続するシステムごとにデータセット（スキーマー）を作成する  （セマンティックレイヤーのデータ量が膨⼤のため） 概要 BigQueryではないシステムへ連携する 役割 リバースETL層 名称
25. 25 © 2026 Leverages Co., Ltd. Tableauの役割を再定義 05
26. 26 © 2026 Leverages Co., Ltd. Tableauでの役割を具体的にご説明。 05 Tableauの役割を再定義 DWH（SQL） Tableau ‧テーブル結合 ‧データ型の変換 ‧ビジネスロジックに当てはめた  指標 / ディメンションの定義 ‧GitHubによるコード管理 ‧指標を集計するためのダッシュボードのルールとして策定 ‧探索⽤（データの⼀覧を出⼒する等）のルールは未策定 ‧Tableauのビジュアライズ機能 ‧ビジュアライズするための割合の計算  （分⼦ / 分⺟の計算） ‧ビジュアライズするためのカラムリネーム ‧ブレンド機能によるテーブル結合 ‧データ型の変換 ‧ビジネスロジックに当てはめた  指標 / ディメンションの定義 ‧GitHubによるコード管理 ‧割合の計算 ‧ビジュアライズに関すること やること やらない こと 前提 指標やディメンションの定義を統⼀する ビジュアライズに特化させる 役割
27. 27 © 2026 Leverages Co., Ltd. Tableauへの連携はDWHからのみとすることで、 「データの信頼性を向上」および「データ組織内で知らないデータの存在をなくす」ことを実現。 05 Tableauの役割を再定義 お⼿製データ 外部ツール SFA 内製システム データソース データ分析基盤 DWH BI 複数システムをあわせて 分析する⼈が簡単に分析 可能にする基盤を データ戦略室が構築 BigQuery 事業全体で⾒る 数値はこちらで 管理。データ戦略 室が管理 Tableau 必ずBigQueryの外部テーブルにしたうえで データ連携 → 必ずデータ戦略室が噛むことで   データの信憑性を担保できる体制に お⼿製データ
28. 28 © 2026 Leverages Co., Ltd. ビジュアライズ機能が充実しているため、「⾒せるための機能」は制約を設けないことを採⽤。 05 Tableauの役割を再定義 当時 今回 制約なしで使⽤ ‧サービスによって表やグラフの  配置がバラバラ テンプレートを使⽤すれば制約なしで使⽤ ‧⾒せる相⼿⽬線で理解しやすい形であれば  なんでもOK Tableauのいくつかの機能に対する弊社のルール例 ビジュアル 機能 ⽇付や数値 の表⽰形式 パラメータ の使⽤ 制約なしで使⽤ ‧yyyy/mm/dd、yyyy年mm⽉dd⽇と  表記がバラバラ 制約なしで使⽤ ‧⾒せる相⼿⽬線で理解しやすい形であれば  なんでもOK 制約なしで使⽤ ‧⾃由に使っていた ⾒せるための利⽤であれば制約なしで使⽤ ‧⾒せる相⼿⽬線で理解しやすい形であれば  なんでもOK
29. 29 © 2026 Leverages Co., Ltd. Tableauを作成するときはサービスごとにテンプレートを⽤意することで、保守運⽤性を⾼める 05 Tableauの役割を再定義 Tableauのテンプレート例 ポイント1： サービスカラーを採⽤することで ダッシュボードをよく⾒せる ポイント2： 配置を明確にすることで保守運⽤性の 向上をねらう ポイント3： BigQueryの最終更新時間とTableauの 最終連携時間を明記することでエラー時の 対応をスムーズに⾏えるようにする
30. 30 © 2026 Leverages Co., Ltd. ビジュアライズ機能以外の機能はDWHやリバースETLツールと被ったりするため、 Tableauではあえて「⾒せるため」の機能のみになるように制限。 05 Tableauの役割を再定義 当時 今回 制約なしで使⽤ ‧複数テーブルを結合するときに使⽤ 使⽤禁⽌ ‧数値ブレの要因調査に時間がかかる ‧ビジュアライズ機能を超えた機能  となるためDWH側で吸収 Tableauのいくつかの機能に対する弊社のルール例 ブレンド 機能 計算 フィールド Tableau Prep 制約なしで使⽤ ‧複雑な処理もTableauで処理 ‧DWHとの棲み分けはなし ⾒せるための処理のみOK ‧カラムリネームや割合を出す等はOK ‧指標/ディメンションの新規作成は禁⽌ 制約なしで使⽤ ‧特に使⽤していなかったので、⾔及なし 使⽤禁⽌ ‧ビジュアライズ機能を超えた機能となり  DWHとの⼆重管理になるため禁⽌
31. 31 © 2026 Leverages Co., Ltd. 結果‧今後の展望 06
32. 32 © 2026 Leverages Co., Ltd. データ組織としては保守運⽤がしやすいデータ分析基盤になり、データ組織以外は指標やセグメントを 正しく定義することの重要性を認識していただくことができた。 06 結果‧今後の展望 ‧SQL側のデータソースを変えるだけでダッシュボードへの反映が  最低限の修正程度になったことで対応が早くなった ‧ツールに求める機能を明確化等の共通認識が取った上で業務ができているため  組織の⼈数が増えているが、属⼈性が少し解消された データ組織 データ組織以外 ‧ダッシュボードや⾏動⾃体は変わらないが、意思決定のためのデータの精度が向上 ‧本取り組みを通じて、指標やセグメントを認識を統⼀する重要さが浸透した  → 事業⽅針の認識も統⼀しようとする意識が醸成された ‧データ組織が作ったダッシュボードが正と認められ、不要なダッシュボードが  作成されなくなった
33. 33 © 2026 Leverages Co., Ltd. 今後データ利活⽤を推進するために「AI / BIの責務の分割」「正しいデータ利活⽤の促進」「データガバナンスの強化」を 重点的に取り組んでいく。 06 結果‧今後の展望 AI / BIの 責務の分割 ⽣成AI / Tableauにどんな役割をもたせるかを改めて決めていくことで、 Tableauの利活⽤シーンを再定義していく。 場合によっては、よりリッチなダッシュボードの開発を⾏う。 正しいデータ 利活⽤の促進 データマートからGoogle Spread Sheetに出⼒されたダッシュボードを 可能な限りTableauのダッシュボードに統合。 正しい数値を⾒たうえで事業判断をできるようにし、 チーム内のKPIができてもすぐに導⼊できる体制を引き続き構築。 ガバナンス強化 個⼈情報以外のデータの取り扱いをどこまで誰が扱ってよいのか？を定義する。 また、場合によってはダッシュボード⾃体の管理を分けるために、 Tableauのサイト⾃体を分けて管轄を決めて管理していく。
34. 34 © 2026 Leverages Co., Ltd. さいごに 07
35. 35 © 2026 Leverages Co., Ltd. ツールの機能に依存せず、その強みを戦略的に使いこなすこと。 その地道な活動の延⻑線上に、今回の成果があるのだと確信しています。 07 さいごに まずは⾝近な ところから 現在今回のプロジェクトは全社へ展開‧浸透していますが、 最初は⾝近な事業‧サービスから試⾏錯誤しながら導⼊しました。 展開していきながら上⼿くいかないケースは都度考え、設計を更新しています。 「餅は餅屋」 万能なツールは存在しない。各専⾨家に頼ることと同じように、 それぞれのツールの強みを活かしながら組み合わせて使っていく必要がある。 TableauもDWHも万能なツールではないからこそ各ツールで補いながら、 各会社に合わせたデータ利活⽤が最も上⼿くいくような制約が必要。 最後は⼈ プロジェクトの発⾜から2年経ってようやく評価され始めました。 個⼈の強い思いや浸透するためにメンバーに思想を伝えたり、サービスを運営している⽅への 地道な布教活動が今回のようなデータ利活⽤の推進には不可⽋。
36. 36 © 2026 Leverages Co., Ltd. 社外の⽅に向けてブログやYouTubeなどの発信も⾏っていますので、チャンネル登録‧フォローをお願いします！ 07 さいごに melev YouTube データ/AIブログ テックブログ データ戦略室紹介記事① データ戦略室紹介記事② データ戦略室紹介動画 AI戦略紹介動画 Leverages Tech Blog レバレジーズデータAIブログ
37. 37 © 2026 Leverages Co., Ltd. EOF