[第3回] 新しい運用ルールの決め方 ～パーミッション続編
miyabiiです。
Tableauサイト管理者 兼 DATA Saber挑戦中のApprenticeとして、考えたことや学んだことをシェアしていきます。
第3回は、Tableauのパーミッションについて続編。パーミッションで地獄を見た私が、新しいサイトでどのように運用ルールを決めたのかをお話しします。
永遠にパーミッション地獄が再発しないための運用ルール作り
結論から言うと、新しいサイトではめっちゃ厳しい運用ルール（現行比）にしました。
新運用ルールの方針
ガバナンスを最優先とする。ユーザの自由度は、ガバナンスと相反する場合は下げることもやむなし。ただし、ユーザの業務が止まるような支障がでるようなルールにはしない。
ガバナンスと自由度は、一般的にトレードオフの関係ですが、そのバランスが肝要です。ユーザの利用実態をふまえて、ルール変更の業務影響を考慮しながら、落としどころを探りました。
いったん以下のルールを定めて新サイトのスタートを迎えることにしたのですが、今後、Tableau Cloud移行を進めていく中で、もしくは、新サイトでの運用をやってみて、よりベターなルールに変えることも十分ありえます。また、新サイトの状況が変わればルールは自ずと変わるべきです。
しかしながら、運用開始後の度重なるルール変更は、サイト管理者側もユーザ側も負担が大きいため、現時点での最善を求めるべく、師匠（DATA Saberの師匠であり仕事上のエバンジェリスト）との対話を尽くしました。
新ルールの骨子
パーミッションに関する新ルールは、以下としました。
パーミッション管理をサイト管理者が行う（ユーザに委ねない）
パーミッションは、プロジェクトに対してグループを設定（例外なし）
2種類のパーミッションパターンに限定し、グループと紐付け
パブリッシュ可能グループ
ビューのみグループ
現サイトでパーミッション地獄が生まれた歴史的背景
私がこの現サイトを引き継ぐ前、Tableauを導入した先任者（会ったこともないけど）は、フィジビリ的にこじんまりと運用を始めたようです。フィジビリ的な運用は、ユーザの自由度が大きいものでした。Tableauの機能や機微なデータの取り扱いを把握しているユーザだけが使うという、暗黙の前提があったのではないかと思われます。
データ利活用の拡大に向けてガバナンス強化が求められる理由
時は流れ、フィジビリ利用から本格的に業務利用を拡大しようとするフェーズに移り変わりつつある今、新サイトはより多くの様々なユーザが安心して使えるプラットフォームであることが求められていることを感じます。
それは、セキュリティ・インシデントを抑止できること、ユーザのリテラシーに関わらず安定して継続可能であること です。
運用ルールを決めた手順
師匠と対話しながら新しい運用ルールを決めていったのですが、振り返ってみると、Tableauおすすめの『マネージド セルフサービス』のサイトを作る手法と重なる部分が多いことに気付きました。
正直言って『マネージド セルフサービス』（管理されたセルフサービス）という言葉には馴染みがなくピンと来ない点（※）もあるのですが、運用ルールを実際に決めていった手順を、その手法になぞらえて簡単にシェアしていこうと思います。
（※）ユーザがコンテンツを検索するという点。後述。
手法についての詳細は、Tableauヘルプの以下トピックを参照してください。
マネージド セルフサービスに向けたプロジェクト、グループ、パーミッションの設定 - Tableau
１．プロジェクト、グループ、パーミッション ルールの包括的な計画を立てる
２．クローズド パーミッション モデルを使用する
１・２は冒頭で述べた方針のとおり。クローズドモデルでは、ユーザーは必要最低限なパーミッションのみを取得するとされており、新ルールの方針に合致します。加えて、前回（第2回）でお話ししたベストプラクティスを死守することとします。
３．必要なプロジェクトとグループのタイプを特定する
超絶シンプルなプロジェクト構造として、対象業務ごとに最上位プロジェクトを作成し、最上位プロジェクトでパーミッションを管理するという設計にしました。ネストされたプロジェクトは最上位プロジェクトのパーミッションのルールに従います。
グループは、最上位プロジェクトごとにデフォルトで以下の２つを作成し、４で後述するパーミッションパターンを強制することにしました。
・pグループ：パブリッシュできる
→既存のパブリッシュ テンプレートに一部カスタムあり
・vグループ：パブリッシュできない
→既存のビューテンプレートを適用
その他、運用作業を行うオペレーター用のグループを１つ作成し、全ての最上位プロジェクトに同一のパーミッションパターンを必ず設定します。
これらの設計により運用手順が型化できるので、最後の手順で述べる「最上位プロジェクトの作成と同時にXXXXする」という運用が成立します。
４．パーミッション パターンを設計する
パーミッションパターンの設計のため、ユーザーがコンテンツをどのように操作するか、一覧表を作成して一つずつ決めていきました。
Tableauヘルプに書いてあるとおり、この設計が最も難しい部分でした。サイトの特性やユーザの利用方法によって、最適解が異なるためです。
師匠が管理する別サイトでは、ワークブック・データソースのパブリッシュを制限しており、サイト管理者だけがパブリッシュする設計で、究極にクローズドなパーミッションモデルになっているそうです。
一方、このサイトは、ユーザが必要なタイミングでパブリッシュできないルールでは受け入れられないと考えられます。アクセスログから把握している利用状況からも特定ユーザのパブリッシュの頻度が高いため、その都度パブリッシュ申請をすることへの負担感が高いはず。更に、これまでなんでも自分でやれる状況からのギャップを考えると、強い抵抗が容易に予想されました（実際に抵抗されたし）。そこで、パブリッシュは許可し、それ以外のあまり使われない機能は不許可に変更する という落としどころに着地しました。
５．[default] のパーミッション パターンを設定する
[default] プロジェクトには、サイト内でプロジェクトを新規作成すると、テンプレートとして[default] プロジェクトの設定が新しいプロジェクトに反映（[default] がコピーされる）という機能があります。
これを利用して簡便に同一内容の設定を反映できるので、共通の設計は最初に[default] プロジェクトに設定しておくと大変便利です。
新サイトの場合、運用グループのパーミッションパターンを[default] プロジェクトに設定しました。
また、[default] プロジェクトで、[すべてのユーザー] グループのパーミッションを削除します。
サイトに追加されたすべてのユーザーは自動的に [すべてのユーザー] グループのメンバーになります。複数のグループに設定されたパーミッション ルールとの混同を避けるために、[すべてのユーザー] グループからパーミッションを削除するようTableauヘルプでも推奨しています。
６．パーミッション ルールを作成する
７．プロジェクトを作成し、パーミッションを調整する
８．コンテンツ パーミッションをロックする
上記の設計に基づき、最上位プロジェクトの作成ごとに、６～８を実行します。
最上位プロジェクトの作成と同時に、デフォルトで２つのユーザーグループを作成する。
そのグループと運用グループに、最上位プロジェクトでのパーミッションを付与する。
最上位プロジェクトでのパーミッション付与は、項番４で設計した内容で統一する。
最上位プロジェクトを作成する際は、必ずアセットのパーミッションをロックする。
新ルールにより地獄は再発しないか？
現ルールと比べると、かなりクローズドモデル寄りの新ルールとなっており、サイト管理者がルール通り運用することで、ユーザががんばらなくてもガバナンスのきいたプラットフォームを継続的に維持できるようになると考えています。
もうユーザはパーミッション管理をがんばらなくても良い
ユーザ側でパーミッションについて考えるのは、新たなメンバがパブリッシュするか否かにより２つのどちらのグループに入れるか決めるだけです。ユーザは自由度が下がる反面、パーミッション設計について自ら深く理解し考えなくてもよくなるので、コンテンツの中身をどうするかに集中できます。
今まではユーザの自己責任であった点をサイト管理者が巻き取るということで、私は責任重大ですね・・・！
最適なパーミッションモデルによってルールは変わる
運用ルールは一度決めたら終わりではなく、方針や利用状況によって見直しが必要です。データ利活用の進化やユーザの成熟度よって将来的にオープンモデル寄りに変わる日が来るかもしれません。
To-Be像としてのマネージド セルフサービスとのギャップ
Tableauが提示する『マネージド セルフサービス』とは、ユーザーが自分でデータを分析し、ダッシュボードやレポートを作成できる状態・機能を指します。この機能により、ユーザーはデータにアクセスし、必要な分析を行い、可視化することができますが、同時に組織のデータ管理とセキュリティの面で管理された環境を提供します。組織はデータへのアクセス権を管理し、データの品質やセキュリティを維持しながら、ユーザーがデータを自由に活用できるようにすることができます。
Tableauヘルプを読んで「ユーザがコンテンツを検索する」という記載に違和感を覚えた理由は、おそらく、自分の管理するサイト固有の背景があるためだと思われます。非常に厳格かつ複雑なデータセキュリティポリシーがあり、完全なデータの民主化はできない（少なくとも当面は・・・）ため、検索して既存のコンテンツを見つけるというユースケースが想像できないのです。
ステップを踏んで進化しよう
データ利活用の拡大フェーズ初期に入ろうとする今、まだユーザーがデータを自由に活用する状態になるまでに乗り越えるべき課題が複数あります。まずはユーザの裾野を広げることを前提として、Tableauマスターに限らず誰でも安全にTableauを使えるよう、ユーザの自由度を一部制限してガバナンスを確立することが現状の目指す状態と考えました。
また、組織のデータ管理とセキュリティはプラットフォーム全体で実現するため、BIツールであるTableau単体ではなく、データベースとの機能分担の上でTableauのパーミッションを設計する必要があります。
次回以降は、パーミッションと絡めながら、Tableauとデータベースの関係について触れていこうと思います。
【backnumber】
[第1回]TableauのExplorerライセンスは、どういう時に使うのか？
[第2回] Tableauのパーミッションはベストプラクティスを死守すべし！
[第3回] 新しい運用ルールの決め方 ～パーミッション続編
[第4回] 権限制御はどこに実装する？ ～Tableauとデータベースの機能分担について
[第5回] Tableauでの行レベル/列レベルセキュリティの実現方法あれこれ
[第6回] Tableauからデータベースへのアクセス時の認証について
[第7回] 失敗例から学んでほしいダメなTableauの使い方
[第8回] クリーニングから始まるTableau Cloud移行
[第9回] Vizが遅い？！ ～TableauCloud移行で性能に悩んだ話