最終更新:
2023/01/29
注釈1:
本記事では主にTableau Serverについて言及しますが、内容はTableau Cloud利用についても当てはまります。
便宜上Tableau Serverという名称を主に使用しますが、基本的には両方を指しているとご理解ください。
注釈2:
本記事は概念的にプロジェクトパーミッションを理解することを目的としますので、Tableauの正式用語を厳密に使用せず記載、解説をしている箇所が存在します。ご了承ください。
注釈3:
本来であればTableau Server上の様々な概念（ライセンス、Site Role、グループとユーザー、etc...）を最初に説明したうえで本トピックに入ることが丁寧であると理解しつつ、今回は書きたいことを書くことを優先しました。
したがって内容がTableau Serverの権限管理に慣れている方向けとなりました。
補完が必要な個所については、別記事を書き、本記事から都度繋げる形で将来的に補完しようと思います。Tableau Serverにおけるコンテンツガバナンスについて、例えば複数部署が利用するようなTableau Server環境を用意した場合、大きく分けて以下3種類の運用があるように思います。
各部署にTableau Serverを立て、物理的に環境を分ける
一つのTableau Serverに複数サイトを作成する
一つのサイトに複数（第一階層）プロジェクトを作成する
上記いずれかを選択するかはセキュリティ要件等に依存すると思いますが、データを物理的に分ける必要がない限りは、基本的には2か3のアプローチで、一つのTableau Server環境内で利用することが良いのかなと思います。 （主に管理コストおよびライセンスコストの観点から）
本記事では3番目のシナリオを深掘り、主にプロジェクトの権限設定に関して整理をし、2番目と3番目を選ぶとしたらどちらが良さそうかについて考えます。
ちなみに1番目について、インフラ面でのコストや、ライセンスが複数Tableau Serverで使いまわせない点から、基本的にはオススメにならないのではと思いつつ…
ただし歴史的事情やデータの置き方の要請から、そのような運用があることを承知しております。
プロジェクトについて（おさらい）
Tableau Serverにおけるプロジェクトについて復習します。
プロジェクトとは、端的に言えば「コンテンツの置き場」です。
ここで言うコンテンツとは以下などを指します。
Workbook
Flow
Published Data Source
仮想接続
例えば以下の「Sample Project」には、2つのWorkbook、1つのPublished Data Source、1つのFlowが格納されています。
そしてプロジェクトの権限設定に関して言及します。
Tableauにおける権限設定は中々に複雑なトピックでもありますので詳細は割愛しますが、プロジェクトの権限設定について重要なのは以下の「プロジェクトのロック」だと思います。
「プロジェクトのロック」機能について
この機能は、そのプロジェクト直下のコンテンツに対して以下の2つを強制します。
プロジェクトの権限設定画面で設定した権限設定をコンテンツに強制的に適用する
コンテンツごとの権限設定を不可とする
ちなみに「Apply to nested projects」オプションは、直下だけでなく配下全てのプロジェクトおよびコンテンツに上記を強制します。
（基本的にはオンにしておくことが推奨されている理解です）
「プロジェクトのロック」機能および恩恵について説明するために、以下のような「複数部署が1つのサイトを共同利用している」ケースを考えます。
（注：後日模式図を足します）
各プロジェクトには、適切なユーザーのみが閲覧などの権限を所持する状態を担保したいとします。
例えば「Human Resource」のプロジェクトには、HR部署の方のみがプロジェクトおよび中のコンテンツを閲覧でき、コンテンツを作成（パブリッシュ）できる状態が望ましいとします。
以下の例では、ユーザーグループにより
閲覧権限をのみを持つユーザー
上記に加え、パブリッシュ権限を持つユーザー
プロジェクトの管理者ユーザー（プロジェクトリーダー：後述します）
上記3つのユーザー群を定義し、それぞれ権限付与しているとします。
上図ではユーザーグループでの権限管理により、簡潔ながら十分な権限管理が行われています。
現在の設定では、サイト管理者以上の権限をもつユーザーを除けば「Human Resource」内の全てのコンテンツについて、上図に示されている3つのユーザーグループに所属するユーザーのみが、それぞれ定義された権限を持つことが出来ます。
また「プロジェクトのロック」機能により、上図の権限設定が配下の全コンテンツに適用され、コンテンツの権限設定も上図と同様になります。
万が一「プロジェクトのロック」が外れていた場合、例えばコンテンツ所有者が上手で定義されたユーザー以外に対して、閲覧権限などを付与することが可能となります。
したがって今回のような「複数部署が1つのサイトを共同利用している」については「プロジェクトのロック」設定は、ガバナンスの観点から多くのケースで必要になるのではと思います。
プロジェクト所有者の権限について
プロジェクトの権限設定に関して、プロジェクト所有者は若干トリッキーです。
Tableauにおける「所有者」は、今までの権限設定画面に明示的に示されることなく、そのコンテンツまたはプロジェクトに対して「管理者」の権限を保持することが出来ます。
ひとつ例をお見せします。
下図では「Explorer (Can Publish)」のSite Roleを持つユーザー(Yoshitaka Arakawa (2nd))として、あるプロジェクトを開いています。
ただしこのユーザーは、実はこのプロジェクトに権限付与されているユーザーグループいずれにも追加されておらず、権限設定画面上は権限が付与されていないユーザーのように見えます。
（ユーザー選択時に下図全てのユーザーグループがグレーアウトしている）
つまりプロジェクト所有者は上図のような権限設定画面には表れないが、プロジェクトに対して全ての操作が可能なユーザーとなります。
単に閲覧やパブリッシュ以上に、もちろんプロジェクトの権限設定を変更することが可能です。
そしてプロジェクト所有者の変更は、プロジェクト所有者またはサイト管理者以上が可能です。
プロジェクト所有者となる方は必ずしもデータガバナンスに精通しているわけでは無いと思いますので、もしかしたら不適切な方をプロジェクト所有者に任命し、権限管理上好ましくない事態が生じるリスクがあります。
ちなみに：
プロジェクトリーダーはプロジェクト所有者の変更は不可ですが、権限設定の変更が可能です。
したがって適切な権限設定を厳密に担保するという意味では、プロジェクトリーダーも若干の懸念を持つ可能性が・・・？ここで「ガバナンス上のリスク回避のため、プロジェクト所有者もサイト管理者またはサーバー管理者など、ある程度ガバナンスに関する知見あるユーザーが担当した方が良いのか」という問いが出てきます。
（さらに言えば、プロジェクトリーダーも廃止した方がいいのか、と）
確かにガバナンス的観点で見ると、権限設定に関するリスクを機能上の制限により抑制することは良いかもしれません。
ただしTableauはいわゆるSelf-service BI、あらゆる人がデータを使って面白いことが出来るよう手助けする製品ですので、プロジェクト所有者とリーダーの廃止がデータ活動にどのような影響を与えそうかについて評価しなければなりません。
以下では、プロジェクト所有者をサイト管理者などに固定し、またプロジェクトリーダーを廃止した場合の想定される弊害について言及します。
プロジェクト所有者を管理者などに固定する弊害
プロジェクト所有者（またはプロジェクトリーダー）のみが可能な操作の一つに、そのプロジェクト内でのプロジェクト作成（ネストされたプロジェクトの作成）があります。
Tableau利用が進むにつれて、コンテンツ置き場を増やしたりコンテンツ管理の方法を変更したりと、流動的にプロジェクトを作成、削除、移動する必要が生じるように思います。
そのような際に、上記のようにプロジェクト所有者を管理者に固定した場合は、プロジェクトに関する作業を行えるのは、以下のユーザーとなります。
そのプロジェクト管理者ユーザー（サイト管理者以上ユーザーを想定）
サイト管理者以上の権限を持つユーザー
（第3階層以降のプロジェクトについて）2階層以降のプロジェクト所有者
3番目について補足しますと、今回の想定は「権限ロックを含めた権限設定を変更できないようにする」場合です。
したがって最上位のプロジェクト所有者のみが問題となりますので、第2階層以降のプロジェクトについては、管理者ユーザーがプロジェクト所有者となることにガバナンス上の懸念は無い認識です。
（最上位プロジェクトで定義された権限設定を触れないので）
（注：後日模式図を足します）
端的に言えば、以下2つの弊害があることが分かります。
プロジェクト関連作業がサイト管理者以上の権限を持つユーザーに集中する （管理者の作業工数が増加）
第3階層以降の作業についても、プロジェクト所有者は特定個人なので、その方に作業が集中する （プロジェクトリーダーを使用し作業分担できない弊害）
この辺りは各組織の事情次第だと思いますが、いずれにしてもユーザー側で主体的かつ迅速にコンテンツ管理が出来なくなるなと…
頻繁に発生する作業でもないので、割り切って管理者側で巻き取ることも不可ではありませんが…
思うに「プロジェクトの権限管理はできないが、コンテンツの場所管理は出来る権限」がTableau Serverに実装されれば良いと思うのですよね。
Tableau Serverではコンテンツに関して細かい権限設定が出来ますが、Projectに関する権限設定は閲覧とパブリッシュのみのため…
アイデア提出するか、改善要望として提案してみるか…というが現状でしょうか。
良いアイデアをご存じであればぜひ教えてください。
サイトで分けたらダメなのか
そもそも権限付与について厳格に対処したかった理由は「複数部署が1つのサイトを共同利用している」ためでした。
更に具体的な想定理由を（端的に）挙げると「ある部署のデータを許可なく他部署に見せてはいけない」などが挙げられます。
その場合「部署ごとにサイトを分けたらどうか」というアイデアが出てきます。
確かにユーザーはサイト単位で追加/削除など管理されるものですので、サイト内のコンテンツの権限設定に問題があったとしても、基本的にはその部署内での話と出来そうです。
（もちろん部署内でさらに権限管理を行いたい場合には、今までの議論と同様な話をする必要は出てきそうですが…）
一方で、サイトを細かく分けて運用することにも一定の懸念があります。
個人的には運用上の点が思いつくなと…
サイトごとの設定を適宜実施しなければいけないため、サーバー管理者の負担増につながる懸念がある
サイト管理者はデータガバナンスおよびコンテンツガバナンスについて一定の知見があることが望ましいが、各サイトにそのような人材を用意できるかの懸念がある
例えば部署間でコンテンツやデータ（Published Data Source）を共有したいとき、それぞれ別のサイトにある場合には共有やデータの同時利用が難しくなる懸念がある
1番について、例えばTableau Server Repository（Tabelau Serverの利用データなどが格納されているDB）の中にあるサイトに関するテーブルを見てみます。
あるいはこちらのサイト設定リファレンスも良いですね。
全部を個別設定する必要は無いと思いますが、サイトで設定できる項目って結構多いんですよね。
また新機能追加時にも増えている覚えなので、部署ごとにサイトを分けた結果、管理および設定する箇所が増えてしまうのは大変なのかなと…
2番について、サイト管理者もなかなか強力な権限を持ちますので、細かく分けたサイトの数だけ教育や監視（言い方がよくないですが）をする必要が生じる可能性があります。
少なくともサイト管理者はユーザー追加も可能ですので、各サイトに追加されるユーザーが適切かどうかの監査などについての工数は発生しそうですね。
3番について、例えば1つのWorkbookで2部署のデータを組み合わせたい、同時に表示したいというニーズがあるとします。
その際、各データが別々のサイトにある場合、上記の実現はかなり難しいと思います。各サイトに必要なデータをコピーして持ってくるなどは必要そうですね…
もし部署間のデータ共有やコラボが許可されている、頻繁に発生する場合には、少し運用を考えないといけないかもしれません。
一方で同一サイト上にある場合には、基本的には権限付与だけで完了します。
まとめ：結局どちらが良いのか
冒頭に述べたように、本記事では以下どちらが良さそうか考えました。
一つのTableau Serverに複数サイトを作成する
一つのサイトに複数（第一階層）プロジェクトを作成する
それぞれのPros(良い点) / Cons(悪い点)を(今回と取り上げなかった点も含め)端的にまとめます。
一つのTableau Serverに複数サイトを作成する
【Pros】
サイトごとにユーザー追加されるので、権限管理上の問題が生じても影響は限定的
サイトごとに管理者が立てられるので、よりユーザー側に自治権がある
サイトごとに容量上限が設定できるので、容量面での利用制限が簡単
【Cons】
サイト設定に関するサーバー管理者の工数増の懸念
サイト管理者ユーザーが増える分だけ強い権限を持つユーザーが増えるので、利用監視などの工数増の懸念
サイト管理者に相応しいガバナンス知見を持ったユーザーを揃えられるかの懸念
部署またぎでのコラボレーションの際に、データ連携などで困る懸念
一つのサイトに複数（第一階層）プロジェクトを作成する
【Pros】
管理するサイト数が少なく、またサイト管理者などの強い権限を持つユーザーが少ないので、サーバー管理者などの管理者ユーザーの工数が相対的に少ない（はず）
コンテンツ共有が簡単（良くも悪くも…）
新機能開放などが比較的楽（のはず）
【Cons】
機能上の制限を利用したガバナンス管理とSelf-serviceのバランスが難しい （プロジェクト管理が可能な権限設定がリリースされてほしい）
プロジェクトごとの容量制限が不可の認識なので、場合によっては問題となるかもしれない
どちらが良いのかは組織の様々な状況によると思いますので、一概にどちらが良いとは言いにくいのかなと思いました。
個人的には1サイトで管理した方が楽なのではと思いつつ、最上位プロジェクトでプロジェクトロック実施した際に、プロジェクトリーダー権限が使いにくい点が痛いなと思っています。
ここはTableauの改善に期待ですね。
また自分もTableau Serverおよびサイトの管理業務に就いてから浅いので、ぜひ先人の知恵をお借りしたいところです。
このトピックに関するコミュニティ資料が若干見つけられないところもあり…海外のTableau Server Admin User Groupとかで話していたりするのでしょうか…
良い資料ありましたら是非教えて頂ければ幸いです。
質問などありましたらTwitterかLinkedinでお願いします。それでは。