はじめに
こんにちは！データマネジメント部の本田です。 普段はTableauを使ったデータ活用文化の推進を担当しており、データ調達、民主化支援、ダッシュボード開発、アカウント管理などデータ活用文化の浸透に必要な業務を幅広く行っています。
2024年10月頃に社内のBI基盤をTableau ServerからTableau Cloudに移行するプロジェクトを行ったのですが、約1年ほどたって安定的な運用を行えるフェーズに入ったので移行時の課題を振り返りながらプロジェクトの概要をご紹介します。
背景
Tableauとは、データの可視化や分析を通して意思決定の支援を行うツールであり、現在多くの企業で導入されているBIツールです。
Tableauを社内に導入するときはダッシュボードを共有・管理するBI基盤としてTableau ServerかTableau Cloudかどちらかを選択するかと思います。 KADOKAWAグループでは長年Tableau Serverを利用しており、2022年にはグループのTableau Serverを統合するプロジェクトも行いました。
サーバー統合後は、ありがたいことにユーザーやユースケースがさらに増加しました。しかしその一方で、ライセンス管理業務は煩雑化し、サーバー負荷の増大に伴って障害頻度も増加しました。さらに、障害発生時の業務影響も大きくなったことで、Tableau Serverの管理に必要なスキルやリソースは増大の一途をたどっていました。
そのような状況の中、2024年6月のサイバー攻撃による全社的な障害でTableau Serverも影響を受けたことをきっかけに、Tableau Cloudへの移行を決断しました。
移行プロジェクトの目的
Tableau Cloudに移行することで以下のようなメリットを獲得したいと考えました。
- 基幹システムと疎結合化
- オンプレのTableau Serverは認証システムやデータ連携において周辺システムとの依存関係が強く、1箇所で障害が起きたときに連鎖的にTableauが使えなくなってしまうリスクがあった
- サーバー維持コストの削減
- Tableau Serverのために必要なスペックが年々増しており、リソース増強を繰り返していた状況からの脱出
- Tableau Serverの運用を最適化するためのスキルを持った人材＝サーバー管理とBI分析のプロフェッショナルという人材の育成に必要なコストの削減
- ダッシュボード資産の棚卸しと整理
- BI基盤の切り替えをきっかけとして利用頻度の少ないダッシュボードやユーザーを大規模に棚卸する
- プロジェクト構成や権限管理ルールを再構成しガバナンスを強化する
移行プロジェクトの進め方と課題
移行プロジェクトはシステム周りのテスト→運用ルールの整備→コンテンツ移行という順序で進めました。
システム周りの話は認証方法の選定・Tableau Bridgeの導入・REST APIを利用した周辺システムの開発など様々な調整を行ったため、それだけで記事ができてしまいそうなので今回は割愛し、運用ルールの整備とコンテンツ移行について紹介いたします。
権限管理ルールの再整備
運用ルールの再整備の中でも特に大変だった部分が権限管理ルールの再整備です。
今までは会社毎や案件毎にサイトを分割していたのですが移行の直前では31サイトも作られてしまっていました。
サイトを分けることによる権限管理はそれはそれで便利だったのですが、3つの課題がありました。
- ユーザーがサイトを横断利用する際にサイトごとに異なるライセンスロールが割り当てられることがあり、自身の権限を把握しづらい状況が生まれていた
- Tableau利用時に権限グループ、パーミッション、最大ライセンス、サイトロール等様々な要素を理解しないといけない状況になっており、混乱が生まれやすかった
- 部署やグループ会社を横断したデータ活用を行いたい時、サイトが分かれているとコラボレーションすることが難しくなり、類似案件があると同じデータソースやワークブックを複数のサイトにパブリッシュしなくてはならないケースが出てきた
- 今回契約したプランではTableau Cloudで利用できるサイトは最大3サイトであったため、サイトの統合が必須であった（Enterpriseプランや、Tableau+プランではサイト数を増やすことも可能）
これらの課題により、今回のTableau Cloud移行ではグループ会社共通の1サイトに統合することとしました。
そしてこの影響により権限管理ルールの厳密さがより重要となったため、プロジェクト構成や権限構成を大幅に見直すこととなりました。
統合後のサイトでは下図のように大きく分けて3つの親プロジェクトを作りました。
基本的には「個別案件管理用プロジェクト」をメインに使う構成にしてます。
プロジェクト単位で権限を管理し「ネストされたプロジェクトまでロックする」の機能を活用することで、ワークブック単位、データソース単位での権限管理をほぼ廃止し、さらには権限グループを使った権限管理を行うことで権限パターンの複雑さを抑制しています。
また「グループ全体共有用」を意図的に作ることで横断的なデータ活用を促進し、「個人用プロジェクト」を用意することでパワーユーザーが自由に活動できる領域も作りました。
これらの複合的な要素によって、必要な統制を取りつつも自由度を残し、Tableau Cloud運営チームの管理業務も簡略化することができています。
※参考：権限ロック機能の詳細についてはTableauのヘルプページもご参照下さい。
プロジェクトを使用したパーミッションの管理 - Tableau
Tableau Serverからのコンテンツ移行
Tableau ServerからTableau Cloudへの移行プロジェクトで大きな課題となる要素の一つに、既存コンテンツの移行という作業が存在するとTableauのユーザー会などでよく耳にします。 私たちのプロジェクトでもワークブック資産の移行をどのように行うかは大きな検討事項となりました。
今回はサイバー攻撃の影響で単純な移行が困難という特殊な事情もあり、思い切って「移行作業は各ユーザーに任せる」という判断をしました。
ユーザー側の負荷は未知数であり不安もあったため、いざという時には運営チーム側で個別支援をできるようにバックアップ体制は取っていましたが、結果としてユーザーによる移行はスムーズに行われ大きな混乱も無く移行が完了できたと考えています。
スムーズに行えた背景には大規模な棚卸を同時に行ったことと、Creatorユーザーと個別にコミュニケーションを取りながら進めたことの2点がありました。
実は、Tableau Serverの利用も長くなっていたため非アクティブなコンテンツや非アクティブなユーザーが大部分を占める状態もありました。 そこで、全コンテンツ・全ユーザーの移行は不要であるという意思決定を早々に行ったことで作業量を大幅に減らすことができ、また必要なワークブックはCreatorユーザーの一人一人がメンテナンスをしながら手元で管理していたため、サイバー攻撃による多数のシステム障害が起こっている中でもそれぞれに影響の確認や復旧作業に手を付けて下さっている状況もありました。
運営チームだけでは全容把握が困難な状況でしたが、各Creatorが本当に必要としている部分だけをピンポイントで支援する形式を取れたため、大きなリソースをかけずに移行を完了できました。
現在のTableau Cloudの状況について
Tableau Cloudを導入したことで、サービス運営の効率を大幅に改善することができました。
運営チーム視点では、サーバーのリソース増強やアップデート対応から解放された点が大きいです。これにより、サーバー管理の専門家だけでなく、BIツールを使いこなすアナリストも運営に深く関われるようになり、よりユーザー目線での改善が進めやすくなったと感じています。
また、ユーザー意識としてTableau Serverのスペックや構成が悪いからパフォーマンスが悪いのではないかという懸念が無くなったことで、ワークブックチューニングに対する学習意欲が向上し、しっかりパフォーマンスチューニングされて安定的な挙動を示すワークブックが増えたという感覚もあります。
ユーザー数は棚卸基準を厳格化したことで一次的には大幅な減少があり、運営チームとしては焦りを感じた部分もありましたが、社内のパワーユーザーと協力し全社ダッシュボードの拡充やDataSaber拡大の取り組み等を行ったことで現在は移行前以上の盛り上がりを見せ、DAU 200程度、四半期に1度以上利用するアクティブユーザーの割合も70%程度という利用状況にまで広がってきました。
おわりに（まとめ）
KADOKAWAグループではTableau活用レベルの成熟とともに、Tableau Desktopのみの利用（twbxファイルでローカル共有）、コアライセンスでTableau Server利用、ロールベースライセンスでTableau Server利用、Tableau Cloud利用と様々な形でBI基盤を変容させてきました。
どの形でもダッシュボードの開発と共有はできますが、ユーザーの利用方法や利用規模に応じて必要となるBI基盤が変わってくるというのを実感しています。 BI基盤の移行は影響が大きく、腰が重くなりがちなプロジェクトだと思いますが、私たちの経験から「やってよかった」と自信をもってお伝えできます。
本記事が、TableauおよびTableau Cloudの導入を検討している方の一助となれば幸いです。
