こんにちは、Hello again！delyのデータエンジニア、Nikoです。
この記事を書いている今は夏なのですが、なぜかセミの鳴き声がまったく聞こえません。うちのアパートの裏側は完全なPrivate Gardenなのに。不思議です！
最近は私たちデータチームが新しいデータアーキテクチャの構築に忙しくしていました。これは、私たちのPDCA（Plan-Do-Check-Act）サイクルをF1スピードに引き上げることを目指しています。そして今まさに、RedashからLightdashへの移行を全社的に進めている最中です！
このRedashからLightdashへの移行や、なぜLightdashを選んだのかについては、以前の記事でも詳しく紹介しているので、ぜひご覧ください：
ここまでの移行は順調そのもので、社内でもどんどんLightdashに分析を移してくれる人が増えてきています。いい感じです！…が、もちろん課題もゼロではありません！この記事では、私たちが直面した（そして今は解決した！）「ユーザー管理」に関する課題について共有したいと思います。
課題について
現在私たちは、LightdashのCloud Starterプランを使っています。なぜかというと…
全部なんてメンテしてるヒマねーっての！😂
データチームがたった2人なので、セルフホスティングするのは重すぎます。Lightdash Cloudを使うことで、価値ある作業に集中でき、メンテナンスにかかるコストもぐっと抑えられます。
そして、チームの方針として「まずはSmall Startして、そこのMVPから徐々に改善していく」ことを大事にしているため、Starterプランで始めています。Starterプランでも多くの課題は解決できたのですが、「ユーザー管理」に関しては制限が多いのが正直なところです。
Starterプランにおけるユーザー & アクセス管理
Starterプランでは、ユーザー管理に関する機能はほとんど提供されません：
- SSOログイン非対応（Google認証のみ）
- グループ管理なし
- データソースレベルのアクセス制御なし（グループが必要）
これらの機能はProプランで提供されています。現在、Proプランへのアップグレードを検討中ですが、この記事ではStarterプランのままでもどのようにユーザー管理を実現したかを紹介します。もし皆さんも同じような状況なら、ぜひ参考にしてみてください！
私たちとしては、Lightdash内でユーザーにどこまでの権限を与えるかをちゃんと管理したい。特に、各チームが異なる機密性の高いサービス・プロダクトを扱っているような会社では必須の要件です。
アクセス制御要件
私たちは、会社の組織構造に合わせた簡易RBAC（ロールベースアクセス制御）モデルの構築を目指しました。
組織的な背景：
- 現在、当社は5つの主要ドメイン（アプリ/サービス）と複数のスクラムチームで構成されています。
- チームを跨いだ分析も大切ですが、関係のないチーム間での機密情報の露出は防がなければなりません。
求めるアクセスレベル：
- Viewer：既存のチャートやダッシュボードの閲覧のみ可能
- Editor：チャートやダッシュボードの作成は可能だがロジックは編集不可
- Developer：dbt関連のメトリクスやディメンションの定義も可能
承認の分散管理：
すべてのアクセス申請を中央で手動承認したくありません。各チームにドメインごとのデータオーナーを設け、チームメンバーの申請をその人がレビュー・承認する形を取ります。
データオーナー
前のセクションで少しだけデータオーナーについて書きましたが、そもそもデータオーナーとは何なのでしょうか？簡単に言えば、チーム内でドメイン知識を持っており、日々の意思決定にデータを活用している人のことです。スクラムチームから出てくるデータやレポートに対して責任を持つ立場の人でもあります。通常はPdMか、そのチームで最もデータに関する知識を持っている人がデータオーナーになります。
では、なぜ私たちのチームでデータオーナーを定義する必要があるのでしょうか？もう一度思い出してほしいのですが、
🌟 たったの2人しかいねーんだわ 🌟
そのため、会社のすべてのアプリやサービスに対して分析を担当するのは、現実的に不可能です。私たちには各プロダクトのドメイン知識がなく、分析がボトルネックになるだけです。実際に一度それを試してみたことがありますが、かえって全体のスピードを遅くしてしまいました。私たちのPDCAサイクルをF1のように高速に回すためには、各チームにデータオーナーを任命してもらう必要があると判断しました。
このデータオーナーの仕組みを導入してからは、私たちがボトルネックになることもなくなり、各チームが自律的にPDCAサイクルを回せるようになっています。
ここまでが私たちの課題についての説明でした。では、本題に移りましょう。今の体制の中で、どのようにしてユーザーマネジメントを解決したのかをご紹介します。
解決方法：Slackを使ったアクセス申請ワークフロー
Lightdash Starterにはグループ管理やSSOがないため、SlackのワークフローとLightdashのAPIを組み合わせて、効率的なアクセス管理フローを構築しました。
🔁 アクセスフロー（Slack + Lightdash API）
この仕組みにより、Slackでアクセス申請ができるようになり、データオーナーが確認・承認すれば自動でユーザーの権限や属性を更新できます。
承認されると、対象ユーザーのアクセス権と属性情報が自動で更新されます：
ユーザー属性（User Attributes）とは？
User Attributes（ユーザー属性）とは、チームごとにLightdashの表示やデータを制御できる仕組みです。たとえば、セールスチームには技術的なカラムを非表示にしたり、特定のテーブル自体を隠したりできます。
これが私たちのアクセス制御のキーポイントになっています。他のチームのデータにアクセスさせないようにしつつ、複数チームを跨いで関わる人には必要な範囲だけ提供できます。
例えば、BさんがゲームチームとリワードチームのPdMであれば、その2つのドメインにはアクセス可能ですが、オファーウォールのデータにはアクセスできないようにできます。
各ドメインごとに必要な属性を定義し、対象のモデルにYAMLファイルで記述しています。例：
models:
- name: stg__test__events
description: >
テストイベントテーブル
meta:
required_attributes:
is_rewards: "true"
※required_attributesには文字列しか指定できないので注意！
これをユーザーごとに設定することで、YAML側の条件と一致し、アクセス制御が実現できます。
他の属性も活用すれば、より柔軟なロールベースアクセス制御のようなことも可能です。ぜひ試してみてください！
利用したLightdash APIエンドポイント
このSlack連携による自動化フローを実現するために、以下のLightdash Cloud APIを使用しています：
🔹 ユーザー招待API
POST https://app.lightdash.cloud/api/v1/invite-links
公式ドキュメントにはまだ載っていませんが、このエンドポイントを使えばLightdashに未参加のユーザーに招待リンクを送れます。
最初はこのAPIが存在しないと思っていたのですが、Lightdashのサポート＆開発者に直接問い合わせて存在を確認しました。
サンプル：
リクエストのbodyはこんな感じ：
email : 対象ユーザーのメールアドレス
role : 組織ロール（Viewer/Editor/Developerなど）
expiresAt : 招待リンクの有効期限
🔹 プロジェクトロール割り当てAPI
POST /api/v1/projects/{projectUuid}/access/uuid
ユーザーを対象プロジェクトに追加し、適切なロールを割り当てます。
詳細：
🔹 ユーザー属性更新API
PATCH https://docs.lightdash.com/api-reference/user-attributes/put-apiv1orgattributes
チーム名やドメインなど、ユーザーごとの属性情報を更新します。
ポイント：
このAPIでは、全ユーザーの属性を一括で更新する必要があります。
1人分だけ更新はできないため、まず全属性を取得 → 変更を加える → まとめてPATCH、という流れで行う必要があります。
詳細：
これらのAPIは、Slack上でデータオーナーによる承認後に自動で呼び出され、Cloud Starterプランでも自動ユーザー登録が実現できました。
今後の展望
このフローは、グループやSSOの機能がないStarterプランでも、安全かつ効率的にユーザー管理を行える一時的なソリューションです。ただし、将来的にはスケールしない可能性もあるため、現在：
- Lightdash Proプランの導入を検討中
- エンタープライズ機能の費用対効果を精査中
- データガバナンスのさらなる自動化を模索中
最後に
そして、どんなに便利なツールにも、使い方次第でその価値は大きく変わってきます。
Lightdash Starterプランには確かに制限があります。
SSOが使えない、グループ管理ができない、細かなアクセス制御が難しい──
それでも、工夫と仕組み化によって、十分に実用的なユーザー管理の仕組みを構築することができました。
本記事で紹介したように、SlackやAPIといった「既にあるツール」を活かせば、
限られたリソースでも、スケーラブルで柔軟なアクセス制御は実現できます。
このアプローチは、あくまで“一時的なBest Practice”かもしれません。
それでも私は、この取り組みが同じようにLightdash Starterの制約の中で悩んでいる方々にとって、一つのヒントやきっかけになれば嬉しいと思っています。
制限があるからこそ、独創性のスポットがあります。
少しでもこの記事が、皆さんの「次の一歩」の助けになれば幸いです。
次回の記事もどうぞお楽しみに！
Happy Data Engineering! 🚀
Discussion