Tableau のガバナンス

このコンテンツは、Tableau Blueprint の一部です。Tableau Blueprint は、組織がデータの活用方法を拡大および改善して、影響力を強化できるよう支援する成熟したフレームワークです。使用を開始する前に、まず評価(新しいウィンドウでリンクが開く)を受けてください。

Tableau におけるガバナンスは、データのセキュリティと整合性を維持しつつ、分析の採用と活用を推進するための重要なステップです。モダン分析ワークフローを通じてデータやコンテンツを安全に管理するには、標準、プロセス、ポリシーを定義する必要があります。また、これらを定義するのと同様に、ワークフロー内のすべてのユーザーがその定義を理解して、それに従うことが重要となります。それにより、ユーザーはデータに基づいた意思決定に使用する分析に確信を持ち、信頼することができるようになります。

組織の Tableau のガバナンスモデルを定義するには、『Tableau Blueprint プランナー』を使って、以下の図に示されているデータとコンテンツのガバナンスの各領域を確認する必要があります。

 

Tableau のデータガバナンス

モダン分析ワークフローでのデータガバナンスは、組織内の適切なユーザーが必要な時に適切なデータにアクセスできるようにすることを目的としています。これによって、アカウンタビリティが実現し、アクセスを制限するのではなく、あらゆるスキルレベルのユーザーがセキュアで信頼できるコンテンツにアクセスできるようにすることが可能です。

データソース管理

データ ソース管理には、組織内でのデータの選択と配布に関わるプロセスが含まれます。Tableau は、企業のデータプラットフォームに接続して、そのシステムにすでに適用されているガバナンスを活用します。セルフサービス環境では、コンテンツ作成者やデータスチュワードはさまざまなデータソースに接続して、データソースやワークブックなどのコンテンツを作成し、パブリッシュすることができます。このようなプロセスがなければ、重複したデータ ソースが急増し、ユーザー間で混乱を招き、エラーが起こる可能性が高まり、システム リソースを消費することになります。

Tableau のハイブリッドデータアーキテクチャでは、ライブクエリまたはインメモリの抽出を使用した 2 つのモードでのデータ操作が可能です。これらのモードは、ユースケースに適したオプションを選択するのと同じように簡単に切り替えることができます。ライブクエリおよび抽出のどちらを使用する場合でも、ユーザーは追加的な作業を必要とすることなく、既存のデータウェアハウスの表、ビュー、ストアドプロシージャに接続して、それらを活用できます。

高速なデータベースを利用している場合、最新のデータが必要な場合、または初期 SQL を使用している場合は、ライブクエリが適しています。データベースまたはネットワークが遅すぎてインタラクティブなクエリを実行できない場合、トランザクションデータベースの負荷を減らしたい場合、データへのオフラインアクセスが必要な場合は、インメモリの抽出を使用する必要があります。

Tableau 2020.2 では、複数テーブルの論理レイヤーとリレーションシップが新たにサポートされたため、ユーザーは Tableau データソースにある単一のフラットな非正規化表のデータの使用だけに制約されることはありません。ユーザーは、柔軟性があり LOD を認識する、表と表のリレーションシップを使って、複数テーブルのデータソースを作成できるようになりました。データに関してどのような質問ができるかを予測して、結合タイプを指定する必要はありません。複数テーブルのサポートによって、Tableau データ ソースは、スター スキーマやスノーフレーク スキーマなどの一般的なエンタープライズ データ モデルのほか、さらに複雑なマルチファクト モデルも直接表現できるようになりました。1 つのデータ ソースで複数の詳細レベルがサポートされているため、同じデータを表すために必要なデータ ソースが少なくなります。また、リレーションシップはデータベースの結合より柔軟性が高く、新たなユースケースが発生するたびに対応できるため、新しい質問に答えを出すために新しいデータモデルを作成する必要性が抑えられます。うまくモデリングされたスキーマでリレーションシップを使うと、データモデル作成にかかる時間も、ビジネス上の質問に答えを出すためのデータソースの数も減らすことができます。詳しくは、このセクションで後ほど取り上げる「メタデータ管理」と、「Tableau データモデル」をご覧ください。

Tableau Server や Tableau Cloud にワークブックをパブリッシュする場合、ワークブックの作成者は、そのデータソースをパブリッシュするか、ワークブック内に埋め込まれたままにするかを選択できます。この決定は、定義するデータ ソース管理プロセスによって決まります。Tableau プラットフォームの組み込みコンポーネントである Tableau Data Server を使用すると、データモデルの共有と再利用、ユーザーによるセキュアなデータアクセス、パブリッシュされたデータソースによる抽出の管理と統合が可能になります。また、パブリッシュされたデータソースによって、Tableau Creator や Explorer のライセンスを持つユーザーは、Tableau のセキュアで信頼できるデータにアクセスして、Web 作成や「データに聞く」機能で使用できるようになります。詳細については、「パブリッシュされたデータ ソースのベスト プラクティス」「Web 上でのビューの編集」「データに聞くためのデータの最適化」を参照してください。

データ ディスカバリ機能の強化により、Tableau Catalog はワークブック、データソース、フローなどのすべてのコンテンツをインデックス化して、作成者がワークブックやパブリッシュされたデータソース内のフィールド、列、データベース、テーブルを検索できるようにします。詳しくは、「Data Management」をご覧ください。

Tableau Catalog を有効にすると、コンテンツ作成者は、データ ソース、データベースとファイル、表とオブジェクトのいずれかを選択してデータを検索し、そのデータが Tableau Server や Tableau Cloud に存在するかどうかを調べて、データ ソースの重複を最小限に抑えることができます。

また、Tableau Server や Tableau Cloud にパブリッシュされたビューの [データの詳細] タブには、ビューで使用されているデータに関する情報が表示されます。詳細には、ワークブック (名前、作成者、変更日)、ビューで使用されるデータ ソース、使用中のフィールドのリストに関する情報が含まれます。

パブリッシュされたデータソースを新たに作成するデータスチュワードの場合、以下のワークフローに示されているように、データソース管理に影響を与える主な意思決定ポイントが 2 つあります。1 つは、ライブか抽出かの意思決定、もう 1 つはデータモデルを埋め込むか共有するかの意思決定です。これは、分析を始める前に、正式なモデリングプロセスが必ず必要であることを示唆しているわけではありません。


重要なデータソースを発見して優先順位付けるには、『Tableau Blueprint プランナー』の「Tableau のデータと分析の調査」および「Tableau のユースケースとデータソース」のタブを使用してください。

 

データソース管理での主な考慮事項

  • 部門やチームにとって重要なデータ ソースは何か?
  • データスチュワードまたはデータの所有者は誰か?
  • データにはライブ接続するのか、それとも抽出するのか?
  • データソースを埋め込むべきか、それともパブリッシュすべきか?
  • データセットのバリエーションが複数存在しているか? 複数ある場合、それらを信頼できる 1 つのソースに統合することは可能か?
  • 複数のデータソースを 1 つに統合した場合、過剰な数のユースケースに一度に対応しようとすると、そのデータソースのパフォーマンスまたは実用性に悪影響が生じるか?
  • データソースによって、ビジネス上のどのような質問に答える必要があるか?
  • パブリッシュされたデータソースにどのような命名規則を使用しているか?

 

データ品質

データ品質は、特定のコンテキストでの目的を果たすためのデータの適正を測る指標です。ここでのコンテキストは、ビジネス上の意思決定になります。データ品質は、正確性、完全性、信頼性、関連性、最新性といった要素によって決まります。組織では、ソースシステムからデータを取り込む際にデータ品質を確保するプロセスがすでに存在している可能性が高いですが、アップストリームのプロセスでデータが修正されていれば、それだけ分析時の修正の必要性が軽減されます。データの利用に至るまでの過程全体を通して、一貫したデータ品質を確保する必要があります。

セルフサービスモデルでは、より大規模なユーザー層にデータが提供されるため、プランニングの時点で、既存のアップストリームデータの品質を確認することが推奨されます。また、Tableau Prep Builder および Tableau Desktop は、データ品質の問題を検出するのに非常に優れたツールです。データ品質の問題を IT 部門やデータスチュワードに報告するプロセスを確立することで、データ品質がデータの信頼性を高める上で欠かせない要素となります。

Tableau Data Management および Tableau Catalog を使って、データ品質の問題をユーザーに伝えて、データの可視性と信頼性を高めることが推奨されます。問題がある場合は、データ資産に警告メッセージを設定することにより、そのデータ資産のユーザーが特定の問題を認識できるようになります。たとえば、データが 2 週間以内に更新されていないこと、またはデータ ソースが非推奨になっていることをユーザーに知らせる必要があるとします。データ ソース、データベース、フロー、テーブルなど、データ アセットごとに 1 つのデータ品質に関する警告を設定できます。詳細については、「データ品質に関する警告の設定」を参照してください。データ品質に関する警告のタイプには、警告、非推奨、古いデータ、メンテナンス中が含まれています。

REST API を使用してデータ品質に関する警告を設定できます。詳しくは、Tableau REST API ヘルプの「データ品質に関する警告の追加」をご覧ください。

データ品質での主な考慮事項

  • 正確性、完全性、信頼性、関連性を確保するためにどのようなプロセスがあるか?
  • プロセスを運用化するためのチェックリストが作成されているか?
  • データが共有され信頼されるようになる前に、誰がデータをレビューする必要があるか?
  • ビジネス ユーザーはそのプロセスに適応できるか? また、データ所有者と協力して問題を報告できるか?

 

強化と準備

強化と準備には、生データを分析用に強化、改良、準備するためのプロセスが含まれます。多くの場合、単一のデータソースでは、ユーザーが抱えるすべての質問に答えることはできません。異なるソースからのデータを追加することで、価値のあるコンテキストを追加できます。組織ではおそらく、さまざまなソースから生データを取り込む際にデータのクリーニング、結合、集計、保存を行うためのデータ準備プロセスがすでに存在しているでしょう。Tableau は、コマンドラインインターフェイスや API を使って、既存のプロセスに統合することができます。

セルフサービスでのデータの準備では、Tableau Prep BuilderTableau Prep Conductor を使用し、複数のデータ ソースを組み合わせてスケジュールに基づいた自動化を行う必要があります。Tableau Prep から Tableau Server や Tableau Cloud への出力には、CSV、Hyper、TDE (バージョン 2024.2 以前)、パブリッシュされたデータソースを含む、複数のタイプがあります。2020.3 以降、Tableau Prep の出力にはデータベース テーブルが含まれるようになり、フローの結果をリレーショナル データベースのテーブルに保存できるようになりました。これはつまり、Tableau Prep Builder で準備したデータは、一元化された場所に保存して管理し、組織全体で利用できるということです。Tableau Prep Builder は Tableau Creator ライセンスに含まれ、Tableau Prep Conductor は Tableau Data Management の一部となっています。Tableau Data Management は、データの準備からカタログ作成、検索、ガバナンスに至る分析環境内でのデータ管理の向上に役立ちます。これにより、信頼できる最新のデータを利用して常に意思決定を行えるようになります。

Tableau Prep Builder では、視覚的で直接的、かつスマートなフィードバックが各ステップで提供されるため、ユーザーは分析用にさまざまなデータソースのプロトタイプを作成し、準備することができます。ステップを定義して確認したら、そのフローを Tableau Server や Tableau Cloud にパブリッシュする必要があります。Prep Conductor はそこで、指定されたスケジュールに従って、そのフローを実行し、パブリッシュされたデータソースを出力します。自動化することで、一貫性のあるプロセスを作成して、エラーを起こしやすい手動によるステップを削減できるほか、成功/失敗を追跡することや、時間の節約も可能になります。ユーザーは、Tableau Server または Tableau Cloud でステップを確認できるため、この出力を信頼することができます。

 

Tableau Prep フロー

Tableau Server や Tableau Cloud 上の Tableau Prep フロー

データの強化での主な考慮事項

  • データの強化と準備は一元化またはセルフサービス化されるか?
  • 組織のどの役割がデータの強化と準備を実施するのか?
  • 強化や準備を自動化するために、どのようなデータ準備ツールおよびプロセスを使用する必要があるか?
  • どのデータソースを組み合わせると価値のあるコンテキストが得られるか?
  • 結合する必要があるデータソースはどのくらい複雑か?
  • ユーザーは、Tableau Prep Builder や Tableau Desktop を使用してデータセットを結合できるようになるか?
  • DBA によって、ユーザーがデータセットを強化および準備できるように、標準化された結合やブレンドのフィールドが確立されているか?
  • セルフサービスのデータ準備をどのように実現するのか?

 

データ セキュリティ

データセキュリティはすべての企業にとって最重要事項です。Tableau を使用すると、お客様はすでに実装されているデータ セキュリティを基に構築できます。IT 管理者は、データベース認証によるデータベース内のセキュリティ、パーミッションによる Tableau 内のセキュリティ、あるいはその両方を組み合わせたアプローチを柔軟に実装することができます。セキュリティは、ユーザーが Web 上のパブリッシュされたビューから、モバイル デバイスから、または Tableau Desktop や Tableau Prep Builder を通してデータにアクセスしているかに関係なく適用されます。大抵の場合、さまざまなユースケースに対応するための柔軟性を提供するハイブリッドアプローチが好まれます。まずは、データセキュリティを分類して、組織で利用しているさまざまなタイプのデータと機密性レベルを定義することから始めてください。

データベースセキュリティを利用する場合、データベースへの認証にどのような手段を使うかが鍵となります。このレベルの認証は、Tableau Server や Tableau Cloud の認証とは異なります (つまり、ユーザーが Tableau Server や Tableau Cloud にログインしても、データベースにログインしたことにはなりません)。そのため、Tableau Server や Tableau Cloud のユーザーはデータベースレベルのセキュリティを適用するために、データベースへの接続用の認証資格情報 (個人のユーザー名/パスワードまたはサービスアカウントのユーザー名/パスワード) も必要になります。Tableau では、データベースへの読み込みアクセスの認証資格情報を使うだけで、データをさらに保護することができます。これによって、パブリッシャーが誤って参照元のデータを変更してしまうことを防げます。また、場合によっては一時表を作成するためのデータベースユーザーパーミッションを提供すると便利です。一時データは Tableau ではなくデータベースに保存されるため、これにはパフォーマンスとセキュリティの両方でメリットがあります。Tableau Cloud の場合は、自動更新を使用するために、データソースに対する接続情報に認証資格情報を埋め込む必要があります。Google および Salesforce.com のデータソースについては、OAuth 2.0 アクセストークンの形で認証資格情報を埋め込むことができます。

保存中の抽出の暗号化は、.hyper 抽出を Tableau Server に保存しながら暗号化できるデータ セキュリティ機能です。Tableau Server 管理者は、サイト上のすべての抽出の暗号化を実施する、または、特定のパブリッシュ済みワークブックやデータ ソースに関連付けられたすべての抽出の暗号化をユーザーが指定するのを許可できます。詳細については、「保存中の抽出の暗号化」を参照してください。

組織で保存データ抽出の暗号化を展開している場合は、AWS を抽出暗号化用の KMS として使用するように Tableau Server を構成することもできます。AWS KMS または Azure KMS を有効にするには、Tableau Server をそれぞれ AWS または Azure にデプロイし、Tableau Server の Advanced Management のライセンスを取得する必要があります。AWS のシナリオでは、Tableau Server は AWS KMS カスタマーマスターキー (CMK) を使用して、AWS データキーを生成します。Tableau Server は、AWS データ キーを、暗号化されたすべての抽出のルート マスター キーとして使用します。Azure のシナリオでは、Tableau Server は Azure Key Vault を使用してルート マスター キー (RMK) を暗号化します。RMK は暗号化されたすべての抽出に使用します。ただし、AWS KMS または Azure KMS の統合が構成されている場合でも、Tableau Server 上のシークレットのセキュアなストレージには、ネイティブの Java キーストアおよびローカルの KMS が使用されます。AWS KMS または Azure KMS は、暗号化された抽出のルートマスターキーの暗号化にのみ使用されます。詳しくは、「キー管理システム」を参照してください。

Tableau Cloud の場合は、既定ですべてのデータが保存時に暗号化されます。ただし、Advanced Management for Tableau Cloud を使用すれば、顧客管理の暗号化キーを活用してキーのローテーションや監査をより詳細に制御できます。顧客管理の暗号化キーにより、顧客が管理するサイト固有のキーを使用してサイトのデータ抽出を暗号化できるため、セキュリティをさらに強化することができます。Salesforce の Key Management System (KMS) インスタンスには、サイトで暗号化を有効にするユーザー向けに、既定のサイト固有の暗号化キーが格納されます。暗号化プロセスは、キー階層に従います。まず、Tableau Cloud が抽出を暗号化します。次に、Tableau Cloud KMS が、適切なデータキーのキーキャッシュをチェックします。キーが見つからない場合は、キーに関連付けられたキー ポリシーで付与されたパーミッションを使用して、KMS GenerateDataKey API によってキーが生成されます。AWS KMS が CMK を使用してデータキーを生成し、プレーンテキストのコピーと暗号化されたコピーを Tableau Cloud に返します。Tableau Cloud がデータキーのプレーンテキストコピーを使用してデータを暗号化し、暗号化されたデータとともにキーの暗号化コピーを保存します。

Tableau Server と Tableau Cloud のどちらでも、データソースにユーザーフィルターを設定すると、どのユーザーがどのデータを表示できるかを制限することができます。これによって、Tableau Server のログインアカウントに基づいて、ユーザーがパブリッシュされたビューでどのデータを表示できるかをより詳細に管理することができるようになります。このテクニックを使えば、地域マネージャーは、他の地域マネージャーのデータを含めることなく、自身の担当地域のデータのみを表示することができます。これらのデータセキュリティアプローチを使用することで、Tableau Cloud または Tableau Server の幅広いユーザーにセキュアでパーソナライズされたデータと分析を提供できる 1 つのビューまたはダッシュボードをパブリッシュすることができます。詳しくは、「データセキュリティ」および「データ行レベルでのアクセスの制限」をご覧ください。行レベルのセキュリティが分析ユースケースにとって最優先事項の場合は、Tableau Data Management を使用し、仮想接続とデータポリシーを活用して規模に応じてユーザーフィルタリングを実装できます。詳しくは、「仮想接続とデータポリシーについて」をご覧ください。


データセキュリティでの主な考慮事項

  • どのようにして異なるタイプのデータをその機密性に基づいて分類するのか?
  • ユーザーはどのようにしてデータへのアクセスを要求するのか?
  • データに接続するためにサービスアカウントとデータベースセキュリティのどちらを使用するのか?
  • 機密性の分類に応じてデータを保護するには、どのようなアプローチが適切か?
  • データセキュリティは、法律、コンプライアンス、規制の要件を満たしているか?

 

メタデータ管理

メタデータ管理には、データソース管理の延長として、組織全体での情報へのアクセス、情報の共有、分析、維持を確実にするためのポリシーおよびプロセスが含まれます。メタデータは、従来の BI プラットフォームのセマンティック レイヤーと同様に、一般的な用語でビジネス向けにデータを表現したものです。整備されたデータソースは、組織のモダンなデータアーキテクチャの複雑さを感じさせないようにするとともに、取得元のデータストアやデータ テーブルにかかわらず、フィールドをすぐに理解できるようにします。

Tableau は、シンプルでエレガント、かつ強力なメタデータ システムを採用しており、企業でのメタデータ管理を可能にしながら、ユーザーに柔軟性を与えます。Tableau データモデルは、ワークブックに埋め込むことも、パブリッシュされたデータソースとして Data Server で一元管理することもできます。データに接続して、Tableau データモデルを作成したら、ユーザーの視点で見てみましょう。それを Tableau Server や Tableau Cloud にパブリッシュされたデータソースにした場合、ビジネス上の質問に合わせてフィルタリングやサイズ調整がされている、分析に適した形式になっていれば、どれほど簡単に分析できるかを考えてみてください。パブリッシュされたデータソースについて詳しくは、「Tableau データモデル」、「パブリッシュされたデータソースのベストプラクティス」、「Tableau Data Server でガバナンスが行き届いたデータアクセスを実現」をご覧ください。

以下の図は、Tableau データモデルに存在する要素を示しています。

2020.2 以降、データソースには、接続、接続属性、データモデル内の物理レイヤーと論理レイヤーが含まれています。接続すると、Tableau は自動的にフィールドをディメンションまたはメジャーとして認識します。さらに、データモデルには計算、別名、書式設定が保存されます。また物理レイヤーには、結合、ユニオン、カスタム SQL で定義された物理テーブルが含まれています。1 つ以上の物理テーブルからなるそれぞれのグループは論理テーブルを定義し、その論理テーブルはリレーションシップとともに論理レイヤーに保持されます。

リレーションシップは、結合よりも柔軟な新しいデータモデリング方法です。リレーションシップでは、共通のフィールドに基づいて、2 つの表が互いにどのように関係しているかが表されますが、結合した場合のように表が組み合わされることはありません。関係には、結合を使用する場合よりもいくつかの利点があります。

  • テーブル間で結合の種類を構成する必要はありません。必要なのはリレーションシップに必要なフィールドを選択することだけです。
  • 関係では結合が使用されますが、その処理は自動的に行われます。結合タイプは、分析する時点で、分析のコンテキストに応じて選択されます。
  • Tableau は、ワークシートで使用されているフィールドの現在のコンテキストに基づいて、分析時に正しい集計と適切な結合を自動的に生成します。
  • 1 つのデータソースで複数のテーブルに様々な詳細レベルで対応しているため、同じデータを表すために必要なデータ ソースが少なくなります。
  • 一致しないメジャー値は削除されません (データが誤って失われることはありません)。
  • 現在のビューに関連するデータに対するクエリだけが生成されます。

VizQL モデルでの実行時に、ビジュアライゼーションのディメンションとメジャーに基づいて複数のクエリが動的に生成され、フィルター、集計、表計算が適用されます。Tableau は、独立した論理テーブルのコンテキスト情報を使って、的確な集計を行うのにどの結合を適用するかを決定します。これによってユーザーは、他のユーザーがそのデータソースで実行するさまざまな分析をすべて把握したり、それに対して計画、考慮したりしなくても、データソースを設計できるようになります。また Tableau Catalog は、ワークブック、データソース、シート、フローなどを含めた、Tableau 上のすべてのコンテンツを把握してインデックス化します。

データソースに直接アクセスできるデータスチュワードまたは作成者はまず、Tableau ワークブックの埋め込みデータソースとして、データソースのプロトタイプを作成する必要があります。その後、パブリッシュされたデータソースを Tableau に作成して、整備された Tableau データモデルを共有しなければなりません。以下に示した、直接アクセスのワークフローをご覧ください。

データソースに直接アクセスできない作成者は、DBA またはデータスチュワードに、Tableau ワークブックに埋め込まれたデータソースのプロトタイプを提供してもらう必要があります。必要なデータがすべて含まれていることを確認したら、サイト管理者またはプロジェクトリーダーがパブリッシュされたデータソースを Tableau に作成し、Tableau データモデルを共有します。以下に示した、制限アクセスのワークフローをご覧ください。

以下のメタデータチェックリストは、パブリッシュされたデータソースを整備する際のベストプラクティスを示しています。このチェックリストを使用してデータ標準を確立することで、使いやすくて分かりやすい、管理されたセルフサービスのデータアクセスが社内で実現します。Tableau で抽出やパブリッシュされたデータソースを作成する前に、Tableau データモデルを以下のチェックリストで見直してください。

  • データモデルを検証
  • 実施する分析に応じたフィルタリングおよびサイズ調整
  • 使いやすい標準の命名規則を使用
  • フィールド名の同義語とカスタム提案を「データに聞く」機能で追加
  • 階層 (ドリルパス) を作成
  • データ型を設定
  • 書式設定を適用 (日付、数値)
  • 会計年度の開始日を設定 (該当する場合)
  • 新しい計算を追加
  • 重複した計算やテスト計算を削除
  • フィールドの説明をコメントとして入力
  • 最上位レベルに集約
  • 使用していないフィールドを非表示にする

2019.3 以降、Data Management では、Tableau Catalog によってワークブック、データソース、シート、フローなどを含めた、Tableau 上のすべてのコンテンツを把握しインデックス化できるようになりました。インデックスは、コンテンツのメタデータ、スキーマ、系列に関する情報を収集するために使用されます。その後、Tableau Catalog はそのメタデータを基に、Tableau Server または Tableau Cloud サイトのコンテンツに使用されているすべてのデータベース、ファイル、表を特定します。データの取得元を把握することは、データを信頼する上で重要となります。また、そのデータを使用する他のユーザーについて知ることは、環境内でのデータの変更による影響を分析できることを意味します。Tableau Catalog の系列機能によって、社内外のコンテンツがインデックス化されます。詳細については、「インパクト分析での系列の使用」を参照してください。

系列を使用することによって、系列図の終端でコンテンツ所有者を突き止めることができます。所有者のリストには、ワークブック、データ ソース、またはフローの所有者として割り当てられたユーザー、および系列にあるデータベースまたはテーブルの連絡先として割り当てられたユーザーが含まれます。変更を加える場合には、所有者にメールでその変更による影響について知らせることができます。詳しくは、「メールを使用して所有者に連絡する」をご覧ください。

メタデータ管理での主な考慮事項

  • どのようなプロセスでデータソースをキュレーションするか?
  • 実施する分析に合わせてデータソースのサイズが調整されているか?
  • 組織での標準の命名規則およびフィールドの形式は何か?
  • Tableau データモデルは、使いやすい命名規則などを含めた、整備のための基準をすべて満たしているか?
  • メタデータのチェックリストが定義およびパブリッシュされていて、検証、利用拡大、認証のプロセスに組み込まれているか?

 

監視と管理

監視はセルフサービスモデルの重要な要素です。IT 部門や管理者は監視を行うことで、データがどのように使用されているかを理解するとともに、使用状況、パフォーマンス、データ接続、更新の障害を常に把握し対応できるようになります。企業のデータベース標準に応じて、IT 部門は、ツールやジョブスケジューラーを組み合わせて使用し、生データとサーバーの状態の取り込みと監視を行います。

ビジネスユーザーがよりスマートな意思決定を行うためにデータを活用するのと同様に、管理者も Tableau の導入についてのデータに基づいた意思決定を行うことができます。Tableau Server では既定の管理ビューとカスタム管理ビューを利用できます。Tableau Server 管理者やサイト管理者は、既定の管理ビューを使って、抽出更新のステータス、データソースの使用状況、サブスクリプションやアラートの配信を監視することができます。カスタム管理ビューは Tableau Server のリポジトリデータから作成されます。また、Tableau Cloud の場合、サイト管理者は既定の管理ビューでサイトアクティビティの監視を行い、管理者インサイトを使用してカスタムビューを作成することもできます。詳細については、Tableau の監視 および Tableau のユーザーエンゲージメントとユーザー利用の評価を参照してください。

監視と管理での主な考慮事項

  • 抽出更新に必要な時間をスケジュールできるか?
  • ソースシステムからの生データの取り込みをどのように監視しているか? ジョブは正常に実行されたか?
  • データソースの重複がないか?
  • 抽出更新はいつ実行されるようにスケジュールされているか? サーバーで抽出がどれくらいの時間実行されたか? 更新が成功したか失敗したか?
  • 抽出更新の実行後にサブスクリプションスケジュールを利用できるか?
  • データソースが使用されたか? 誰によって使用されたか? 予想されたオーディエンス規模と比較するとどのようになっているか?
  • 古いパブリッシュされたデータソースを削除するためのプロセスはどのようなものか?

 

データガバナンスのサマリー

コントロールとアジャイル性のバランスをとることが極めて重要です。厳格なガバナンスポリシーがあるにもかかわらず、ユーザーは、すばやく分析を行うために、ローカルに保存されている機密性の高いデータや分析を頻繁に使用します。セルフサービス環境でのデータガバナンスの役割は、セキュリティを確保しながらも、データへのアクセスを許可して、ユーザーが必要な答えを得られるようにすることです。組織によって要件はさまざまですが、以下の表はセルフサービスのデータアクセスを管理するための理想の状態を説明しています。

 

領域

IT 管理者/
BI プロフェッショナル

コンテンツ作成者

データソース管理

データソースへのアクセスを提供し、組織のデータ戦略、ポリシー、手順に従う。

分析で使用されているデータモデルを定義、管理、変更する。

データ品質

データを検証して、意思決定に向けたデータの正確性に対する信頼を築くためのプロセスを定義する。

パブリッシュされたデータモデルに適用されている、データクリーニングのルールを取得し、提示する。

強化と準備

分析用のデータを準備するために、複数のデータソースからのデータ準備プロセスを作成する。

パブリッシュされたデータモデルに適用されている、強化と準備のルールを取得し、提示する。

データ セキュリティ

パブリッシュされたデータモデルに対し、セキュリティのパラメーターとアクセス制御を設定する。

企業のデータセキュリティポリシーと外部規制を順守する。

メタデータ管理

組織でのメタデータ管理のポリシーおよびプロセスを定義する。

ユーザー用にフィールドレベルのメタデータを定義、変更、提示する。

監視と管理

コンプライアンスとデータ資産の適切な利用を確実にするために、使用状況を監視して監査する。

一元的に管理されたデータモデルの使用状況に関する指標を監視し追跡する。

 

Tableau のコンテンツガバナンス

分析の活用が進むにつれて、ビジネス上のより多くのミッション クリティカルな意思決定がデータに基づいたものになります。それによる影響として、コンテンツ量が増えるだけでなく、より幅広いスキルレベルのユーザーが連携して、価値のあるインサイトを発見するようになります。ますます多くのユーザーが日々データを利用するようになることから、Tableau のコンテンツを保護、管理し、信頼性を確保するだけでなく、ユーザーが自信を持ってコンテンツを発見、利用、作成できるように、コンテンツを整理できることが不可欠となります。コンテンツ ガバナンスがなければ、ユーザーは無関係な、古い、または重複したワークブックやデータ ソースの中から必要なものを見つけることがますます困難になるでしょう。

コンテンツガバナンスには、予想されたトラフィックが得られていないことからコンテンツを非推奨にするタイミングを判断する場合や、重要なダッシュボードが意思決定にまったく使われていない理由を突き止める場合など、コンテンツを関連性の高い最新の状態に保つためのプロセスが含まれます。組織のコンテンツガバナンスポリシーの順守を確実にすることは、コンテンツ作成者の中核的な責任です。

このセクションでは、IT 管理者やビジネスユーザーに、Tableau のコンテンツガバナンス機能を支える中核的な概念について説明し、急成長しているモダン分析プラットフォームで作成されるコンテンツを管理するために、その概念をどのように適用すべきかについてのガイドを提供します。

コンテンツ管理

一貫したコンテンツ整理の構造を定義することで、管理者は、コンテンツを管理して、ユーザーにとって見つけられやすくすることができます。Tableau Server と Tableau Cloud は、特定のガバナンス要件に基づいて、環境を構築しコンテンツを管理するために必要な柔軟性を備えています。サイトを慎重に構築することで、真のセルフサービス分析を規模に応じて提供できるようになり、責任あるデータ使用を確実に行えるようになります。これにより、ユーザーはインサイトの発見と共有を行えるようになります。

プロジェクト

共有とコラボレーションを行うために、ユーザーはコンテンツを作成し、Tableau Server または Tableau Cloud のプロジェクトにパブリッシュします。プロジェクトは、コンテンツを整理および保護するために使用される既定のコンテナであり、その中にワークブック、データ ソース、フロー、およびその他のネストされたプロジェクトを保持します。これにより、Tableau にパブリッシュされたコンテンツへのアクセスを管理するスケーラブルな構造が作成されます。

組織はフラットではなく、コンテンツを管理する方法でもありません。プロジェクトおよびネストされたプロジェクトは、ファイルシステムフォルダーのように機能し、ビジネスに即したユーザー、グループ、また対応するパーミッションに関連するデータとコンテンツを集約する階層的構造を提供します。管理者のみがトップレベルのプロジェクトを作成できますが、ネストされたプロジェクトはそれぞれのニーズに応じてプロジェクト所有者またはプロジェクトリーダーに簡単に委任できます。一般的なコンテンツ管理アプローチには、組織的 (部門/チーム別)、機能的 (トピック別)、またはハイブリッド (組織的および機能的の組み合わせ) アプローチなどがあります。コンテンツ構造を計画する際には、部門の枠を超えた Tableau チームが、プロジェクトおよびそれらへのアクセス権を持つグループに関する一貫した命名規則を確立する必要があります。

たとえば、最初の Tableau Server 導入では、営業、マーケティング、および IT 部門が参加します。組織的構造に従って、各部門のトップレベルのプロジェクトを作成します。この 3 部門のユーザーは、部門の枠を超えたデジタルトランスフォーメーションチームの一員ともなります。デジタルトランスフォーメーションコンテンツは複数の部門のユーザーにまたがるため、デジタルトランスフォーメーションという別の名前のプロジェクトも必要になります。各部門のユーザーは、それらにアクセスできるグループの一員となります。ユーザーおよびグループには、アクセス権を持っているプロジェクトのみが見えるので、管理者として閲覧するプロジェクト数を気にする必要はありません。

サンドボックスプロジェクトと認証済みプロジェクト

セルフサービスをサポートするには、サンドボックスプロジェクトと本番プロジェクトを使用する必要があります。サンドボックスプロジェクトにはアドホックまたは認証されていないコンテンツが含まれ、本番プロジェクトには検証および認証済みのコンテンツが含まれます。ユーザーはこれら 2 つのプロジェクトタイプの目的の違いを理解しておく必要があります。サンドボックスプロジェクトにアクセスできるすべてのコンテンツ作成者は、自由にデータを探索し、コンテンツを作成し、アドホック分析を実行できます。本番プロジェクトの検証および認証済みコンテンツは、データに基づいた意思決定に使用できる高レベルの信頼性があるものになります。

本番プロジェクトへのパブリッシュは少人数のユーザーのみに限られており、その場所向けのにコンテンツの検証、利用拡大、認証を行います。これらのコンテンツ管理タスクは、プロジェクト所有者およびプロジェクトリーダーであるユーザーに委任する必要があります。詳しくは、プロジェクトレベルの管理 (Tableau Server | Tableau Cloud) をご覧ください。コンテンツの検証、利用拡大、認証の役割とプロセスについては、このトピックの後半で説明します。

以下の図は営業部門のプロジェクト階層を示し、部門全体のデータ ソースを保持する「営業部門データ ソース」プロジェクトがあります。営業部門のプロジェクト内にあるネストされたプロジェクトは、営業地域にマッピングされています。各地域内のユーザーに対応するグループは、該当する地域のネストされたプロジェクトへのアクセス権があります。地域で作成されたコンテンツは、ネストされたプロジェクトに従って保持されており、それらのネストされたプロジェクトは整理および保護するために必要に応じて使用されます。Tableau コンテンツの構造のマッピングを開始するには、組織的な構造から始めるのが最適です。各部門ではすでに、それぞれの職務に応じたセキュリティ、データ、およびアプリケーションアクセスを持っていることが多いからです。

部門チームの例として、マーケティングは、分岐して部門全体の本番コンテンツやデータソースなどの共有リソースに対応しますが、同時に独自の本番プロジェクトとサンドボックスプロジェクトを設置している「デジタル」などのグループ向けに特定のリソースをロックダウンします。マーケティングプロジェクトの階層は下図のとおりです。

パーミッションは、ロックされたプロジェクトおよびグループを使用してプロジェクトレベルで管理し、コンテンツにはガバナンス管理されたアクセスを適用して、管理をシンプル化します。ロックされていないプロジェクトでアイテムレベルでパーミッションを管理することも可能ですが、すぐに管理が手に負えない状態になります。ロックされたプロジェクトではデータを保護しながら、必要に応じてプロジェクト全体でのコラボレーションも可能です。詳しくは、「プロジェクトを使用したコンテンツへのアクセスの管理」 (Windows | Linux) をご覧ください。

2020.1 では、ネストされたプロジェクトのロックが導入されました。これにより、プロジェクト階層のどのレベルでもプロジェクトをロックできます。その親が異なるパーミッションでロックされていても関係ありません。Tableau Server 管理者とサイト管理者、Tableau Cloud サイト管理者は、コンテンツ管理責任を、その業務により近いプロジェクト所有者またはプロジェクトリーダーに委任することで、より効果的にコンテンツとパーミッションを管理できます。それらの人々は、階層内の任意のレベルで特定のグループのニーズを満たすパーミッションモデルに従って、ロック済みのネストされたプロジェクトを使用します。

[Apply to nested projects (ネストされたプロジェクトに適用)] にチェックマークを入れて、ネストされたプロジェクトを個別にロックします。

コレクション

2021.2 で登場したコレクション機能は、コンテンツの仮想コンテナーの役割を果たします。コレクションでは、Spotify のプレイリストのように、他のユーザーと共有するコンテンツの組み合わせを整備することができます。この機能は、他のユーザーと共有することができないお気に入り登録とは異なります。

コレクションは簡単に使い始めることができ、Tableau ユーザーのどのサイトロールでも利用可能です。

ほとんどのコンテンツ タイプ (ワークブック、ビュー、データ ソースなど) は、プロジェクトの場所に関係なく、単一サイトのどこからでもコレクションに追加できます。新しいチームメンバーのオンボーディング、ワークフローのサポート、関連コンテンツの共有を、既存のアイテムを移動したり複製したりせずに、柔軟に行うための手段として使えます。アイテムのパーミッションは引き続き維持されるため、コレクション内のコンテンツにアクセスできるのは適切なユーザーのみです。

組織のコンテンツ管理フレームワークの一環として、コレクションにはさまざまな使い方があります。上記の例を使い、組織に複数のプロジェクト (営業とマーケティング) があるとしましょう。それらのプロジェクト全体でユーザーが関連コンテンツを簡単に見つけられるようにするには、コレクションを作成します。するとチームは 1 か所で、あるトピックの全体像を簡単に組み立てることができます。

個人用サンドボックス

すべてのユーザーが安全に作業を保存できる場所を Tableau Server または Tableau Cloud 上に設けるには、1 つの個人用サンドボックスと、コンテンツ所有者に各自のアイテムの表示のみを許可するパーミッションを作成する必要があります。個人用サンドボックスは、アドボックまたは進行中の分析に使用することができ、広範にリリースする準備が整っていないコンテンツを表示されないようにしておくことができます。準備ができたら、ユーザーは、コンテンツを部門用サンドボックスに移動させることができ、そこで検証、利用拡大、認証のプロセスが実行されます。各ユーザーに 1 つの個人用サンドボックスがあれば、保護および管理するプロジェクト数が減り、管理作業が削減されます。「個人用サンドボックス」という名前のトップレベルのプロジェクトを作成した後、プロジェクトのパーミッションを「すべてのユーザーがパブリッシュ」で「ワークブックはなし」、「データ ソースはなし」、「フローはなし」、「メトリクスはなし」(従来のメトリクス機能は、2024 年 2 月の Tableau Cloud、Tableau Server バージョン 2024.2 で廃止されました。詳細については、「メトリクスの作成とトラブルシューティング (廃止)」を参照してください。) に設定します。

プロジェクトレベルのみでのパブリッシャー限定パーミッション

個人用サンドボックスのコンテンツが 1 つの場所に保存されていることで、管理者はコンテンツが表示される頻度を監視して、コンテンツ所有者に古いコンテンツの削除を提案することも、個人用サンドボックスを最も活用しているユーザーを特定することもできます。コンテンツ所有者は、ワークブックやデータソースを表示する権限が拒否されているプロジェクトにパブリッシュされている場合でも、所有するコンテンツを常に見ることができます。認可については、次のセクションで詳しく説明します。

サイト

Tableau Server と Tableau Cloud は、どちらもサイトを使用したマルチテナントをサポートしています。Tableau Server では、マルチサイトを作成して、同じ Tableau Server 導入環境の特定のユーザー、グループ、データ、コンテンツを分離する安全な境界を確立できます。あるサイトのユーザーは別のサイトへアクセスすることはできず、別のサイトが存在することさえ知りません。サイトは、厳格な境界があることで、意図的にユーザーをコラボレーションできないようにする必要があったり、開発のすべてのフェーズを通してコンテンツが分離したままになる場合に役立ちます。

たとえば、下図は 2 つの Tableau Server サイトを示しています。この例では、サイト 1 のユニークユーザーはサイト 2 へのアクセス権 (データとコンテンツを含む) がありません。サイト 1 と サイト 2 の両方にアクセス権があるユーザーは、一度に 1 つのサイトにしかサインインできません。両方のサイトのユーザーが特定のコンテンツを必要とする場合、そのコンテンツをそれぞれのサイトに複製するか、またはそれらのユーザーの共有コンテンツ用の新しいサイトを作成する必要があり、監視、評価、維持などの管理作業が増えてしまいます。Tableau Cloud では、Tableau のインスタンスは単一のサイトです。

サイトは厳格な境界を作り出す (上図を参照)

Tableau Server のサイトは、データソース、ワークブック、ユーザーをセグメント化する便利な構造のように最初は思えますが、そのセキュリティ境界は、規模に応じて真のセルフサービスを提供するためにほとんどの組織が必要とするコラボレーションやコンテンツの利用拡大を妨げます。そのため、コンテンツ管理責任の委任が可能な単一サイト内のプロジェクトではなく、サイトを使用する際の影響については慎重に考慮する必要があります。サイト間に厳格な境界を示すには、新しいサイトを立ち上げる場合に、関連するデータソースを新しいインスタンス内に再作成する必要があります。

新しいサイトは、独自のユーザーセットとそのコンテンツを他のすべての Tableau ユーザーおよびコンテンツから分けて管理する必要がある場合にのみ作成するべきです。意図的に、境界を超えてコンテンツを共有できないようになっているからです。詳細について、およびサイトの使用が妥当な場合の例については、「サイトの概要」 (Windows | Linux) をご覧ください。

コンテンツ管理での主な考慮事項

  • ワークブックおよびデータソースは企業全体で共有されるか?
  • 機密性の高いコンテンツを分離するのに、サイトと部門のどちらを使用するのか?
  • プロジェクトには、組織的 (部門/チーム) アプローチ、機能的 (トピック) アプローチ、またはハイブリッドアプローチのどれが使用されるか?
  • アドホックのコンテンツと検証されたコンテンツに対応するために、サンドボックスプロジェクトと本番プロジェクトがセットアップされているか?
  • コンテンツの命名規則が使用されているか?
  • 作成者によって、異なるフィルターが選択されている同じワークブックのコピーが複数パブリッシュされているか?
  • コンテンツには説明とタグがあり、ビジュアルスタイルに従っているか?
  • 読み込み時間の期待値が設定されていて、例外処理が存在しているか?
  • 従業員が退職した後に、コンテンツの所有権を再割り当てするためのプロセスはどのようなものか?

 

認可

ユーザーが Tableau にログインしようとすると、認証によってユーザーのアイデンティティが確認されます。Tableau Server にアクセスする必要がある人はすべて、Tableau Server のアイデンティティストア (Windows | Linux) でユーザーとして示される必要があります。また、Tableau Cloud の認証では、ユーザーのアイデンティティの検証手段として、Tableau、Google、SAML がサポートされています。認可とは、ユーザーが認証された後に、Tableau Server 上や Tableau Cloud 上で何にどのようにアクセスできるかを示すものです。認可に含まれるもの:

  • Tableau Server や Tableau Cloud でホスティングされているコンテンツ (サイト、プロジェクト、ワークブック、ビュー、データソース、フローなど) に対し、ユーザーが許可されている操作
  • Tableau Server や Tableau Cloud の管理で、ユーザーによる実行が許可されているタスク (サーバーやサイトの設定の構成、コマンドラインツールの実行、サイトの作成など)

これらのアクションの認可は Tableau Server や Tableau Cloud が管理し、ユーザーのライセンスタイプ、サイトロール、具体的なエンティティ (ワークブックやデータソースなど) に関連付けられたパーミッションの組み合わせによって決まります。Tableau のロールベースのライセンスにはその機能が含まれているため、暗黙的なガバナンスが組み込まれています。各ライセンスの具体的な機能について詳しくは、チームおよび組織向けの Tableau をご覧ください。

Tableau Server や Tableau Cloud でサイトにユーザーを追加する際は、ライセンスタイプにかかわらず、そのユーザーにサイトロールを適用する必要があります。サイト ロールはサイトに対してユーザーが持つことができる最大アクセス レベルを示します。

Tableau Creator ライセンスのユーザーは、Tableau Server と Tableau Cloud のいずれか、Tableau Desktop、Tableau Prep Builder、Tableau Mobile にアクセスできます。以下のサイトロールは、Tableau Creator ライセンスを使用します。

サイトロール

説明

サーバー管理者

Tableau Server でのみ利用可能。Tableau Cloud には適用されません。

Tableau Server、Server 上のすべてのサイト、ユーザーおよびグループに加え、プロジェクト、データソース (接続情報を含む)、ワークブック、フローなどすべてのコンテンツ資産でも、設定を構成します。

ブラウザ、Tableau Desktop、Tableau Prep Builder から、Tableau のパブリッシュされたデータソースまたは外部データに接続できるほか、新しいデータソースやフローの作成とパブリッシュ、ワークブックの作成とパブリッシュを行うこともできます。

サイト管理者 Creator

上記のとおりコンテンツに対する無制限のアクセス権がありますが、サイト レベルでのアクセス権は除きます。ブラウザ、Tableau Desktop、Tableau Prep Builder での Tableau または外部データへの接続のほか、新しいデータソースの作成、コンテンツの作成とパブリッシュを行うことができます。

Tableau Server では、Server 管理者が、サイト管理者にユーザーの管理およびサイトロールとサイトメンバーシップの割り当てを許可するかどうかを決定できます。Tableau Server では既定で、また Tableau Cloud では常に、サイト管理者にはこれらの機能が許可されます。

Tableau Cloud で最高のアクセス レベルです。サイト管理者はサイトの構成設定へのアクセス権があります。

Creator

データに接続して、新しいデータソースやダッシュボードを作成します。作成したものは、Tableau Server や Tableau Cloud でパブリッシュ、共有されます。データソースは、データスチュワード (DBA やデータアナリストなど) がパブリッシュします。Creator は、組織の義務や規制義務を順守しながら、プロセスの定義、ポリシー、ガイドラインや、エンタープライズメタデータ管理に関するビジネス知識を取り入れます。

 

 

Tableau Explorer ライセンスのユーザーは、Tableau Server と Tableau Cloud のいずれかに加え、Tableau Mobile にもアクセスできます。以下のサイトロールは、Tableau Explorer ライセンスを使用します。

サイトロール

説明

サイト管理者 Explorer

サイトおよびユーザーの構成に対するアクセス権はサイト管理者 Creator と同じですが、Web 編集環境からは外部データに接続できません。

Tableau のパブリッシュされたデータソースに接続して新しいワークブックを作成することも、既存のワークブックの編集や保存を行うこともできます。

Explorer (パブリッシュ可能)

ブラウザから新しいコンテンツをパブリッシュすることや、パブリッシュされたビューを表示および操作することができ、すべての操作機能を使用できます。Web 編集環境で既存のワークブックの編集や保存を行い、ワークブックに埋め込まれているデータ接続から新しいスタンドアロン データ ソースを保存できますが、外部データへの接続や新しいデータ ソースの作成は行なえません。

Explorer

パブリッシュされたビューの表示や操作ができます。コンテンツへの登録やデータドリブンアラートの作成を行うことも、Tableau のパブリッシュされたデータソースに接続し、アドホッククエリを実行するために Web 作成環境でワークブックを開くこともできますが、作業を保存することはできません。

 

 

Tableau Viewer ライセンスのユーザーは、Tableau Server と Tableau Cloud のいずれかに加え、Tableau Mobile にもアクセスできます。

サイトロール

説明

Viewer

フィルターとコンテンツの表示、操作を行えます。また、ビジネスイベントによってトリガーされたアラートを受信できます。

 

Tableau Server または Tableau Cloud に追加された、ライセンスを持っていないユーザーは、「ライセンスなし」となります。

サイトロール

説明

ライセンスなし

ライセンスのないユーザーは、Tableau Server または Tableau Cloud にサインインできません。

 

 

誰がコンテンツのパブリッシュ、操作、またはパブリッシュされたコンテンツの表示のみを行うことができるのか、また誰がサイトのユーザー管理やサイト自体の管理を行うことができるのかは、サイトロールとコンテンツパーミッションによって決まります。プロジェクトチームは協力して、コンテンツパーミッションモデルを定義する必要があります。Tableau Server 管理者やサイト管理者は、グループにパーミッションルールを割り当てて、それをプロジェクトにロックします。ロックされたプロジェクトでは、コンテナー内 (ネストされたプロジェクトを含む) のすべてのコンテンツにパーミッションルールが適用されます。詳しくは、「プロジェクト既定のパーミッションを設定し、プロジェクトをロックする」をご覧ください。

Tableau には、プロジェクト、ワークブック、データソースに対する既定のパーミッションルールがありますが、これらのコンテンツタイプのパーミッションルールをカスタマイズすることもできます。

パーミッションルールのテンプレート

説明

プロジェクトリーダー

適切なサイト ロールと組み合わせると、プロジェクト、その子プロジェクト、そのプロジェクト階層にパブリッシュされたコンテンツへのフル アクセスをユーザーまたはグループに許可します。

 

エディター

プロジェクト内のデータ ソースまたはワークソースへの接続、編集、ダウンロード、削除、およびパーミッションの設定をユーザーやグループに許可します。

 

データソースをパブリッシュすることもでき、パブリッシュされたデータソースの所有者である場合は、接続情報や抽出更新スケジュールを変更することもできます。このパーミッションは、データ ソースに接続するビューにアクセスする際のビューに関連しています。

 

パブリッシャー

プロジェクトへのワークブックとデータ ソースのパブリッシュを、ユーザーまたはグループに許可します。

 

コネクター

プロジェクト内のデータ ソースへの接続をユーザーまたはグループに許可します。

 

Viewer

プロジェクト内のワークブックとビューの表示をユーザーやグループに許可します。

 

なし

パーミッションルールのすべての機能を未指定に設定します。

 

拒否

パーミッションルールのすべての機能を拒否に設定します。

 

パーミッションのカスタマイズでは、データソースへのアクセスやダウンロードから、パブリッシュされたコンテンツに対するユーザーの操作方法まで、より細かいパーミッション設定が可能です。Tableau の直感的なインターフェイスにより、ユーザーを機能グループに関連付け、グループに権限を割り当て、誰がどのコンテンツにアクセスできるかを簡単に確認できます。詳しくは、個々のコンテンツリソースでパーミッションを設定する方法をご覧ください。なお、Data Management を使用している場合は、外部アセットに対するパーミッションについて、他にも考慮するべき事項があります。詳細については、「外部資産でのパーミッションの管理」を参照してください。


サーバー上でローカルにグループを作成するか、Active Directory/LDAP からインポートして、設定されたスケジュールに基づいて同期 (Windows | Linux) する必要があります。同期スケジュールは、Tableau Server 管理者か Tableau Cloud サイト管理者が設定します。メンテナンスを簡素化するには、以下に示されているように、パーミッションをプロジェクトレベルでグループに割り当てる必要があります。Tableau Cloud の場合、SCIM を介して外部 ID プロバイダー経由で Tableau Cloud でのユーザー プロビジョニングとグループの同期を自動化し、プログラムで REST API を使用してユーザーを追加または削除したり、グループからメンバーを追加または削除したりできます。

詳細については、「パーミッション設定のクイック スタート」「マネージド セルフサービスのプロジェクト、グループ、パーミッションの設定」「パーミッションのリファレンス」を参照してください。

 

認可での主な考慮事項

  • Active Directory/LDAP や SCIM のグループ同期で、最低限必要なサイトロールは何か?
  • [既定] プロジェクトで [すべてのユーザー] グループのすべてのパーミッションを [なし] に設定しているか?
  • [すべてのユーザー] グループに明示的な制限 ([拒否] パーミッション) を設定して、すべてのユーザーアカウントに反映されるようにする必要があるか?
  • 各プロジェクトの作成や表示の機能セットに対応するグループを作成しているか?
  • 特定のユーザーで有効なパーミッションを確認して、パーミッションモデルをテストしているか?
  • 親プロジェクトでパーミッションをロックすることで、プロジェクト階層全体を通してセキュリティを維持しているか?
  • パブリッシュされたデータソース用にサービスアカウントのユーザー名/パスワードが設定されているか?

 

コンテンツの検証

コンテンツの検証は、コンテンツ認証に至るまでに実施される一連のイベントの中での最初のステップです。データガバナンスでのデータ品質と同じように、コンテンツの検証には、コンテンツの正確性、完全性、信頼性、関連性、最新性を検証するためのプロセスが含まれています。

コンテンツは、まずその作成者によって検証される必要があります。コンテンツ作成者は、対象オーディエンスからフィードバックを得る必要もあります。これは、カジュアルなフィードバックグループでワークブックへのリンクを共有することによって行うこともできます。またデータスチュワードも、正確性を確認し、パブリッシュや認証の候補として埋め込みデータソースを検証するという役割を担う必要があります。データソースがワークブックに埋め込まれている場合、データスチュワードはそれがパブリッシュおよび認証の候補となるかを検討する必要があります。コンテンツの検証ではデータと計算の正確性以外にも、ブランディングやレイアウト、書式設定、パフォーマンス、フィルター、ダッシュボードアクション、そしてエッジケース (条件の境界ぎりぎりにあるケース) の挙動を、サイトロールのサイト管理者かプロジェクトリーダーが確認しなければなりません。

コンテンツの検証での主な考慮事項

  • 検証プロセスには誰が関与しているか?
  • ワークブックの正確性、完全性、信頼性、関連性、最新性は確保されているか?
  • 新しいコンテンツによって、既存のコンテンツが置き換えられるか?
  • 参照元のデータや計算は正確か?
  • ワークブックは企業のブランディングを反映しているか?
  • ワークブックには論理的なレイアウトが施されているか?
  • すべての軸や数字が正確に書式設定されているか?
  • ダッシュボードは、許容されるパフォーマンス時間内に読み込まれるか?
  • フィルターアクションやダッシュボードアクションは、対象のビューで正常に動作するか?
  • ダッシュボードは、エッジケースの動作でも有効に機能するか (すべて、なし、1 つの値へのフィルタリングなど)?

 

コンテンツの昇格

コンテンツの検証が完了したら、コンテンツの利用拡大のプロセスを使用して、信頼できるプロジェクトの場所へのワークブックのパブリッシュやパブリッシュされたデータソースへの認証バッジの追加を行うことができます。以下は、ワークブックのワークフローの例を示しています。

ワークブックのワークフロー

コンテンツ作成者は、データに接続して、新しいダッシュボードを作成し、サンドボックスプロジェクトにパブリッシュします。サイト管理者またはプロジェクトリーダーがそのコンテンツを検証し承認します。承認されたコンテンツは、本番プロジェクトにパブリッシュされます。Tableau Advanced Management の一部としてライセンス付与されている Content Migration Tool を使えば、Tableau Server プロジェクト間でのコンテンツの利用拡大や移行を簡単に行えるようになります。これは、異なる Tableau Server 導入環境のプロジェクト間 (どちらにも適切なライセンスがある、Tableau Server の開発インスタンスと本番環境の間など)、または 1 つの Tableau Server 導入環境内のプロジェクト間で実行できます。Content Migration Tool のユーザー インターフェイスでは、「移行計画」の作成に必要な手順を順を追って説明しています。その計画は、1 回だけ使用することも、複数回の移行のテンプレートとして使用することもできます。使用事例について詳しくは、「Tableau Content Migration Tool の使用事例」をご覧ください。

IT 要件で、3 つの個別のライセンス環境 (開発、品質保証、本番) が必要な場合、モダン分析プラットフォームでトラディショナルなウォーターフォール開発サイクルを複製しないようにしてください。ユーザーは厳格なポリシーの回避や本番環境へのコンテンツの速やかなリリースのために、品質保証環境を好んで使用する可能性があります。そのため、Tableau REST API を使ったカスタムワークフロースクリプトを使用して本番サーバーへのコンテンツの移行を自動化することで、うまくバランスをとる必要があります。

コンテンツの利用拡大での主な考慮事項

  • 利用拡大のプロセスには誰が関与しているか?
  • コンテンツの利用拡大を担当している役割は、評価基準のチェックリストを持っているか?
  • プロジェクトによって認証済みコンテンツとアドホックコンテンツを明確に区別しているか?
  • 反復とイノベーションをサポートできるアジャイルなプロセスになっているか?
  • 直接アクセスおよび制限アクセスのどちらのデータソースやワークブックにも対応できるワークフローがあるか?

 

コンテンツの認証

コンテンツの検証および利用拡大のプロセスが完了して、本番プロジェクトに対するパーミッションを持つサイト管理者、プロジェクトリーダー、パブリッシャー (コンテンツ作成者またはデータスチュワード) のいずれかが、ワークブックやデータソースを指定の場所に利用拡大すると、そのコンテンツは信頼できる認証済みのコンテンツとなります。認証によって、重複したワークブックやデータソースの増加が抑制されるため、コンテンツ利用者にとってコンテンツが見つけやすくなり、データスチュワードも企業全体のデータを Tableau でより効果的に管理できるようになります。

「コンテンツの検証での主な考慮事項」で確立されている基本要件を、認証を得るための基準として使用してください。コンテンツ作成者は、認定プロセスが最初から最後までどのように機能するかを明確に理解する必要があり、コンテンツ消費者は、コンテンツ管理標準で定義されているように、認定コンテンツが実稼働プロジェクトのどこにパブリッシュされるかを知っている必要があります。

データソース認証によって、データスチュワードは特定のデータソースをすぐに使用可能な信頼できるデータソースとして、Tableau 導入環境に利用拡大することができます。認証済みのデータソースは、Tableau Server や Tableau Cloud の検索結果と、データソースのスマート推奨アルゴリズムで優先的に扱われるため、見つけやすく、また再利用もしやすくなります。

https://cdnl.tblsft.com/sites/default/files/blog/data_source_certification_3new.png
認証済みデータソース

コンテンツの認証での主な考慮事項

  • 認証済みコンテンツを指定するのは誰か?
  • 認証ステータスを得るための基準をすべて満たしているか?
  • すべてのフィールド (概要、証明書に関するメモ、タグ) が入力されているか?

 

コンテンツの使用状況

コンテンツの使用状況によって、ビジネス上の意思決定でのデータ使用の有効性を評価することができますが、ビューへのアクセス量だけで全体像を把握することはできません。コンテンツの使用状況を評価して、誰がコンテンツの作成や利用を行っているのかといったユーザーの行動、そしてダッシュボードやデータソースの品質や関連性を理解することで、導入環境を規模に応じて稼働させることができます。コンテンツが利用されていない場合には、それを突き止め、適切な次のステップをとることができます。

Tableau Server 管理者および Tableau Cloud サイト管理者は、既定の管理ビューを使って、利用パターンを広範に監視する必要があります。より具体的な要件がある場合は、カスタム管理ビューを作成することもできます。Tableau Server の場合は Tableau Server のリポジトリデータで作成できます。また、Tableau Cloud の場合、サイト管理者は既定の管理ビューでサイトアクティビティの監視を行い、管理者インサイトを使用してカスタムビューを作成することもできます。サイト管理者は、サイト内のパブリッシュされたコンテンツ (認証済みおよびアドホック) の使用状況を評価および監査する必要があります。たとえば、アドホックコンテンツの使用が、認証済みコンテンツの使用を大幅に上回っている場合、利用拡大のプロセスでの制限が厳しすぎるか、時間がかかりすぎていて、ビジネスニーズに対応できていない可能性があります。

サイト管理者は、『Tableau Blueprint プランナー』の「Tableau のユースケースとデータソース」タブで記入された、予想されるオーディエンス規模を考慮して、コンテンツの使用状況を確認する必要があります。個々のコンテンツ作成者も、ワークブックのサムネイルにカーソルを合わせてスパークラインのツールヒントを表示するか、メニューから [このビューを表示したユーザー] を選択することで、各自のコンテンツの使用状況を確認する必要があります。詳しくは、「Tableau のユーザーエンゲージメントとユーザー利用の評価」をご覧ください。

コンテンツの使用状況での主な考慮事項

  • 各ビューへのトラフィック量はどのくらいか?
  • 古いコンテンツはどのように定義されているか? 古いコンテンツはどのくらいの頻度で削除されるか?
  • 間接的な使用 (アラートやサブスクリプション) はどのくらい発生するか?
  • 定期購読は予定通りに配信されていますか?
  • 実際のオーディエンスの規模が予測と一致しているか?
  • コンテンツが毎週、毎月、毎四半期の傾向に従っているか?
  • ユーザー集団によるログイン頻度や最終ログインからの日数はどうなっているか?
  • ワークブックとデータ ソースのサイズの分布は?

 

コンテンツガバナンスのサマリー

以下の表は、急成長しているモダン分析の導入環境でコンテンツの利用拡大およびガバナンスを行う上で理想とされる状態を定義しています。

 

領域

IT 管理者/BI プロフェッショナル

コンテンツ作成者

コンテンツ管理

パブリッシュされたコンテンツを保存し整理する環境を構築および保守する。

 

サイトやプロジェクトでのコンテンツの関連性を確保する。

セキュリティとパーミッション

分析コンテンツのセキュリティを確保し、コンテンツタイプ、機密性、ビジネスニーズなどに基づいて、ユーザーに適切なレベルのアクセスを許可する。

 

組織のセキュリティおよびパーミッションのポリシーを順守する。

コンテンツの検証

コンテンツの正確性を検証するプロセスを定義する。

ユーザーが作成した分析コンテンツの検証と正確性の確認を支援するプラットフォーム機能を利用する。

 

コンテンツの昇格

コンテンツの利用拡大のプロセスを定義する。

ガバナンスのプロセスで決められたとおりに、検証済みの分析コンテンツを一元管理された信頼できる環境に利用拡大する。

 

コンテンツの認証

コンテンツの認証のプロセスを定義する。

コンテンツを信頼されるものとして認証し、同一の環境内の信頼されていないコンテンツと区別する。

 

コンテンツの使用状況

組織の事業部門全体で幅広い利用パターンを評価する。

パブリッシュされたコンテンツの使用状況を評価して監査し、信頼されていないコンテンツの使用状況を追跡する。

 

 

フィードバックをお送りいただき、ありがとうございます。フィードバックは正常に送信されました。ありがとうございます!