1.Tableauとは
1-1. Tableauは基本的にDesktop製品
Tableauは作成したダッシュボードをTableau serverで共有する場合であっても、
開発用として必ずDesktop（Creatorライセンス）が最低１本必要となる。
Server上でもブラウザベースでダッシュボードを開発できるが、
Desktopのような細かい設定はできない。
一方、Tableauを買収したSalesforceの"Salesforce Einstein Analytics"がいつの間にか"Tableau CRM"になり（これをTableauと呼ぶにふさわしいかは別として）、Prepもブラウザ版になる。
しかし、クラウドサービスであるSalesforceの一部としてのTableauが存在することになるかというとそれは別の話だ。
TableauはDesktop製品だからなしえるUIを強みに持つ製品だ。
現状の操作性をそのままにクラウドサービスとしてTableauが動作するとは思えない。
しかしながら、他のBI製品が注力しているDevOps対応やAI/ML連携などを考えると、Webアプリケーション化しなければ、なんでもかんでも自前で開発していくことになる。
これまでTableauは他のBIベンダーに追いつくべく独自ソフトウェア製品として並外れた企業努力をしてきたが、これから先（特にSalesforceに買収されて以降）を考えると、現在のアーキテクチャーから転換する時期が必ず来る（そうしなければ新しい技術についていけなくなるかも）と思う。
それをSalesforceの思惑で湾曲されなきゃいいけどというのが懸念点だ。
1-2. Tableauは最もノーコーディング指向の製品
もちろん、LOD表現やカスタムSQLを使用してさらに高度なこともできるが、データサイエンティストではない一般ユーザの大半はTableauの基本機能を使って（Microsoft Officeを使うかのごとく）、ノーコーディングで簡単にデータ集計を行っているものと思う。
「分析に必要な機能を全てノーコーディングで設定できるようにする！」
というのがTableauのポリシーと言ってもいいくらいだ。
実際、ノーコーディングで移動平均の計算までできちゃうなんて至れり尽せり。
一方では、逆に製品内の限られた機能を使って実現するしかないのも困ることもある。
例を上げると、ドーナツチャートは標準でサポートされていないので、円グラフを２つ作って二重化して重ね合わせる。
Sanky Diagramなど作ろうとすると後で忘れちゃうくらいに大変な手間がかかる。
では他のBI製品ではどうだろうか。
WebテクノロジーをベースとしたBI製品では、D3、Chart.js、HighChartsなど外部のチャートライブラリを簡単に組み込めるものが多い。
このような機能上の限界はTableauが自力で解決するしかない完全な独自技術で成り立っている製品だということに起因する。
実際、公開されている拡張機能（エクステンション）の少なさがそれを物語っている。
実はTableauユーザの多くはTableauに自己満足していて、世にある素晴らしい（ほとんど無償の）ライブラリを知らない。
1-3. Tableauはビッグデータに弱い？
Tableauの最初のデモはExcelからデータを抽出あるいはライブ接続で利用する形態だ。
実利用ではインメモリ製品であることを考えると、抽出主体の使い方が一般的だと思う。
抽出での利用場面では、Desktopではディスクでキャッシュするし、Serverではメモリでキャッシュする。既にキャッシュされたクエリを投げたら速い。Serverでのメモリキャッシュの弱点もウォーム処理で補える（便利！）。
一方、ライブ接続では、特定の関数を使用したときのパフォーマンスに問題があると報告されている。
ライブコネクターの良し悪しはSQL翻訳機能にあると思っているので、Tableau独自の関数のSQL変換が必ずしも適切ではないのだと思う。
というより、そもそもその最適化なんて自ずと限界があるような気さえする。
そういう意味ではSisenseのようなSQLに親和性の高いアーキテクチャーの製品のほうが翻訳性能が高く、ライブ接続のパフォーマンスが高くなって当たり前だ。
さらに、ライブ接続時にサーバ側のキャッシュに多くのリソースを消費するようで、この点でも改善の余地がありそうだ。
一般にTableauは他のBI製品と比較して「ビッグデータに弱い」「ガバナンスが弱い」と言われる。
しかし、Tableauという製品は、予め準備されたデータソースを使ってコーディングなどせずに簡単にデータ集計、可視化するためのエンドユーザ向けツール（これがホントのセルフサービスBI）だと思うので、それを求めてはいけないものだと思う。
２. TableauとSisenseとの比較
2-1. 位置づけの違い
上で述べたようにTableauは優れたセルフサービスBI製品なので、エンタープライズ・ダッシュボードやレポートの用途で使用するのは他社製品と比較して向いてはいないと僕は思っている。
コーディングできない（コーディングしたくない）エンドユーザ自身が、自分自身で分析するためにTableauを使用していけば、間違いなくITリテラシーは向上するだろう。
一方、Sisenseは"Single Stack"というキーワードで表されるように、データの上流からエンドユーザが利用する現場までをフルカバーするデータ基盤を提供する製品と位置づけられている。
数億件までならElastiCube、それを超えるデータではライブと、いかなるデータボリュームでも優れたパフォーマンスを発揮でき、使用されている技術も独自文化ではなく一般的な技術であるため、企業内の情報共有・データ分析基盤として利用するのに最適な製品と言える。
2-2. 複雑なデータモデリングは得意ではない
TableauはTableau内で複雑なデータモデルをつくることができない（仮に作ってもパフォーマンスが出る保証はない）。
バージョン2020.2で初めて「リレーションシップ」ができるようになったくらいで、実際、Tableauユーザは最初からTableau内で複雑なデータモデルを作ろうとは思っていない。
つまり、Tableauのエンドユーザの多くは、
Tableau用にデータマートを予め準備してもらうものだと思っている。
従ってIT部門やパワーユーザがその要求に応えていく覚悟がなければいけない。
SisenseはセルフサービスBIとしての機能は十分にあるとは思うが、
真価を発揮するのはやはり「データガバナンスに優れたデータ分析基盤を提供できる」という点だ。
ElastiCubeは複雑なデータモデルでもパフォーマンスを維持できるし、
汎用的なElastiCubeを作成してしまえば、ElastiCubeとダッシュボードは１対多で作成することができるから、IT部門やパワーユーザの負荷は大幅に削減できる。
実際、Tableauの大規模ユーザがデータマートを作成し続けることに疲弊して、
Sisenseに切り替えた事例もあるくらいだ。
2-3. メンテナンスはできるのか
Tableauではドラッグ＆ドロップで簡単にビュー（チャート）を作成できる。
しかし一旦できあがったビューはどうやって作成されたものか、その過程がわからない。
しかも、独自路線の製品であるがゆえに、高度なテクニックで作成されたものほど「合せ技」の産物なので、それを作成した人が異動してしまったり、退職してしまうと後任の担当者を待っているのは困惑だ。
作成手順はマニュアルにできないからやっかいである。
その点、Sisenseは標準機能でできないことはSQL、JavaScriptやCSSなど一般的な技術で実現するので、ちょっと勉強すれば理解できる。
Tableauと違って「手順」ではなく「仕様」となるからだ。
僕はこれまで、社内のAccess、Excelマクロ、FileMakerなどで凝りに凝った「負の資産」にお客様がギブアップして「なんとかしてくれ」と相談を受けたことが幾度となくある（大抵のケースはその使用をやめるという結果になる）。
先にデータのガバナンスの話を書いたが、
実はこのダッシュボードのガバナンスのほうが大きい問題だと思っている。
個の資産を共通資産にするのは難しい。
これをコントロールできないと「野良アプリ」が乱立し、混乱状態に陥る。
アプリ側でのガバナンスも大切だ。
「負の遺産」にならないようセルフサービスBIとして使用すれば、
これ以上の製品はないと僕は思う。
３. まとめ
僕はセルフサービスBI製品としてのTableauを高く評価しているし、
ノーコーディング指向のエンドユーザにとっては、最もとっつきやすい製品だと思っている。
一方、あくなきセルフサービス指向が、
データ基盤全体のTCOや資産の継承という点で裏目に出る企業もあるだろうなと思う。
その点、Sisenseは標準的な技術で作成されている安心感があり、
データの上流から下流までをサポートする「シングルスタック」な製品という点でも企業全体のデータ分析基盤としてもっと評価されて然るべきだと考える。
Sisenseのココがすごい！Tabelau,Power BI, Qlik Looker... BI製品徹底比較」まとめページ