Tableauのデータソースの機能を本当に使うべきかどうか考えてほしい。

タイトルのみだと意図が伝わらないので、経緯を含めて解説をした上で、お願いしたいことを書いてみます。
なお、本noteはTableauのデータソースの原理やベストプラクティスに則っているわけではなく、いわゆる「個人の感想」レベルの内容です。
とはいえ、Tableauのデータソース設計において考慮すべき情報は落とすつもりで筆を取っているので、議論のきっかけになればと思います。

Summary / 忙しい人向けの概要

- 個人で利用する(=誰にもデータソース、ワークブックを共有することがない)分にはTableauデータソースで提供されている機能は自由に使っていただいてよい。
- 複数人で利用する(=自分以外の1人以上の他人にデータソース、ワークブックを共有することがある)場合は、Tableauデータソースの機能を使うかどうかは検討してほしい。なぜならば、解読とメンテナンスの時間が無駄にかかってしまうので。
- (極論を言えば)Tableauの可視化部分と、データソースのロジックは別々にしたほうがよい。

Introduction / はじめに - Tableauデータソースの機能はすごい(語彙力

誤解のないようにお伝えしますが、Tableauのデータソース関連の機能はとても優れている点については強く主張しておきます。
具体的な機能詳細については、公式ヘルプや他のTableau強者の方々に解説は任せるとして、長らくデータにまつわるやんごとなきプロセスを支えてきたことは言うまでもありません。
とはいえ、どんなに優れている道具でも、使い方や理解が足りないと十分にパフォーマンスを発揮できなかったり、新たな課題を生み出してしまったりしますので、今回は技術的なお話よりも、道具を利用する際の心構え的なお話になります。
(ですので、批判は反論は多々あるかと思いますが、私個人、こうした意見やフィードバックが建設的な議論に発展すると考えていますので、何かのきっかけ作りになればと思います。)

Case: For individual use / Tableauデータソースを個人で利用・運用する場合の話

データソースに限らず、Tableauを個人利用している人を対象にしています。

結論から言うと、自由にしてもろてOKやで、というのが私の主張です。
理由はいくつかありますが、最大の理由として、「責任は常に自分にあるので、何が起きても困るのは自分」という点です(当たり前ですが)。
ですので、個人利用のケースでは特に言うことはありません。
Happy Tableau Life :)

Case: For multiple users / Tableauデータソースを複数人で利用・運用する場合の話

今回の主題です。
ざっくりと「複数人」と表現しましたが、自分以外のTableauに関わる他人が1人以上いる場合、と捉えていただいでOKです。

Tableauデータソースの機能は優れていると冒頭で主張しましたが、欠点がいくつかあります。
    - ロジックの理解が難しい
    - 変更履歴に弱い
    - 引き継ぎの難易度が高い

ロジックの理解が難しい
基本的にデータ前処理した内容はTableauのGUI内には残っていますが、この内容はhowの情報です。
中長期的にTableauを運用していると発生するのが、「なぜ、こうしたか？」というwhyの情報が必要になります。
例えば、誰かが作った計算フィールドのロジックはwhyの情報を頼りに理解するプロセスを踏みます。
ただ、Tableau内にはwhyの情報をストックすることはできないので、GUIを覗いてがんばって解読しようと試みるも、理解できなかったら時点で、メンテナンスは不可能ですし、不具合が発生しても検知できないリスクがあります。
私自身、Tableau使いという立場ですので、他人のリソースを代理でメンテナンスしたり、不具合調査することがあるのですが、ロジックの理解に苦戦し、結構な工数を持ってかれることがあります。
GitHubに対応してくれ(心の声)

補足: Tableau Catalogの話
ちなみに、この手の情報のストックにまつわる話をするとTableau強者たちはTableau Catalogがあるではないか！😡という声をいただきますが、その意見に上記の話を踏まえて反論してみます。
Tableau Catalogで提供できている機能は以下の通りです。
    - when: いつデータができたのか？いつデータが更新されたのか？
    - where: どこにデータがあるのか？
    - who: 誰がデータを提供しているのか？(ただし、これはTableau Catalogでなくても標準機能で提供している)
    - what: どんなデータがあるのか？
    - how: どのようにデータができているのか？
このとおり、残念ながら「why: なぜそのデータが存在しているのか？なぜそのロジックなのか？なぜそのプロセスなのか？etc...」という問いにはTableau Catalogは応えることはできません。
(descriptionを頑張れば、といった話はあるかもしれませんが、体系的に整理できるレベルではありません)
(さらに補足ですが、Tableau Catalogに限らず、現状、こうしたData Catalogのツールやサービスはいくつかありますが、whyの実現に至ったものは執筆時点ではありません)

変更履歴に弱い
Tableauワークブックに関しては、バージョン管理があるのですが、Tableauデータソースにはバージョン管理の類はありません。基本的に設定やロジックの変更は上書き保存です。
この環境下で想定しうる問題としては、「誰がどのような変更をしたか？」が隠蔽されるので、不具合発生時の火種となっています。
この話もロジックの件と同様、whyの話と通ずるものではあります。
GitHubにry

引き継ぎの難易度が高い
(以上の2点の内容と重複している気がしますが)引き継ぎの難易度は他のBIツールよりは高めになっています。
特に、メンバー交代や退職時の引き継ぎコストが大きく、別途引き継ぎ資料を用意するなどの方法を取らねばならない時があります。
ちなみに、企業内であれば統制できる内容ではありますが、無償のコミュニティで複数人で運用しているTableauデータソースがあると、よりカオスになります。経験則ですが。
GitHubにry

Suggestion / じゃあどうすればいいんだってばよ

前段が長くなりましたが、以下2点が私の主張です。

1. Tableauデータソースの機能を安直に使っていないかチェックする
Tableauデータソースのロジックを複雑にしている要因となる機能を使うべきか、立ち止まって考えてみるのをオススメします。

> Tableauデータソースのロジックを複雑にしている要因となる機能
以下、一例です。
データの結合 / データブレンド / データのユニオン / 計算フィールド
☑︎これらの機能を使わずにするにはどうすればよいか？
    - 元データがデータベースであれば、Data Mart化、カスタムSQLを検討する。
    - 元データがExcel, Google Sheetsであれば、集計をExcel, Google Sheets側で担ったり、データベース化できないか検討する。
    - Tableau PrepをはじめとするETLツールで前処理できないか？
☑︎これらの機能を使う意思決定をした場合、引き継ぎリスクを回避することは可能か？
    - description, コメントアウトを活用して情報を充実させる。
    - 外部ドキュメントサービス(notion, Confluence, esa, etc...)に情報をストックする。

2. Tableauの可視化と、データソースのロジックを別にできないか検討する
これを読んでいる方々の立場の考慮は一切していないので、ある意味極論とも言える提案です。
この手のTableauデータソースにまつわる課題をシンプルにするために、可視化とデータのそれぞれの責任分界点を分ける提案を数年前から行っています。
1の提案の例でも挙げましたが、Tableauソリューション内であれば、Tableau Prepを利用検討するのは手です。
ただし、それでも完璧ではないので、Tableau Prepではない別のETLを検討したり、データエンジニアの力を借りて内製でETLをコード管理する、といった道もあります。特に後者に関しては、コード管理 = GitHubで運用がデファクトとなっているため、ロジックの理解と変更履歴の課題が解消できます。
(とはいえ、このあたりの話はエンジニアリング領域となり、本noteの想定読者層とはアンマッチだと思いますので、詳しい話は割愛します)

Conclusion / 結論

Summaryの再掲です。

- 個人で利用する(=誰にもデータソース、ワークブックを共有することがない)分にはTableauデータソースで提供されている機能は自由に使っていただいてよい。
- 複数人で利用する(=自分以外の1人以上の他人にデータソース、ワークブックを共有することがある)場合は、Tableauデータソースの機能を使うかどうかは検討してほしい。なぜならば、解読とメンテナンスの時間が無駄にかかってしまうので。
- (極論を言えば)Tableauの可視化部分と、データソースのロジックは別々にしたほうがよい。

Tableauの機能が優秀であるがゆえに、Tableauデータソース設計について疎かになりがちなので、これを機に考えるきっかきになればと思います。
なお、本noteの内容がベストプラクティスではない点、あくまで「個人の感想」レベルの提案という点をご留意くださいませ。