Salesforce ロール階層: 管理者向け完全ガイド

日付:

背景と適用シナリオ

Salesforce の専門家として、私が最も頻繁に議論するトピックの一つがデータセキュリティです。特に、組織が成長し、チームが複雑化するにつれて、「誰が何を見るべきか」という問いは、ビジネスの成功に不可欠となります。この問いに答えるための Salesforce の根幹をなす機能が、Role Hierarchy (ロール階層) です。

Salesforce 管理者である私たちの主な責務は、ユーザーが必要なデータにアクセスできることを保証し、同時に機密情報への不正アクセスを防ぐことです。Role Hierarchy は、このバランスを取るための強力なツールです。

具体的なシナリオを考えてみましょう。あるグローバル企業の営業組織を例にとります。

典型的な営業組織の構造

  • 営業担当副社長 (VP of Sales): 全世界の営業実績を把握する必要があります。
  • 地域担当ディレクター (Regional Director): 担当地域（例：APAC、EMEA）内のすべての営業活動を監督します。
  • 営業マネージャー (Sales Manager): 自身のチームメンバーの商談や活動を管理します。
  • 営業担当者 (Sales Representative): 基本的に自分自身の顧客と商談にのみアクセスできれば十分です。

このシナリオでは、データの可視性に関して明確な縦方向の要件が存在します。VP は、ディレクター、マネージャー、担当者全員のデータを見る必要があります。ディレクターは、担当地域のマネージャーと担当者のデータを見る必要がありますが、他の地域のデータを見る必要はありません。この「上位の役職者が下位の役職者のデータにアクセスできる」という構造を、Salesforce 上で直感的かつ自動的に実現するのが Role Hierarchy の役割です。

もし Role Hierarchy がなければ、各マネージャーが部下のレコードを一つ一つ手動で共有してもらうか、あるいは複雑な共有ルールを無数に作成する必要があり、管理は非常に煩雑になります。Role Hierarchy は、組織の報告体制やデータアクセス階層をモデル化することで、このプロセスを劇的に簡素化します。

原理の説明

Role Hierarchy の原理を理解するためには、まず Salesforce の共有モデル全体像を把握する必要があります。データアクセスは、複数のレイヤーで制御されています。

  1. オブジェクトレベルのセキュリティ (Object-Level Security): ユーザーが特定のオブジェクト（例：取引先、商談）自体にアクセスできるかどうかを定義します。これは主に Profile (プロファイル) と Permission Sets (権限セット) によって制御されます。
  2. 項目レベルのセキュリティ (Field-Level Security): オブジェクトにアクセスできるユーザーが、その中のどの項目（例：商談の「金額」項目）を閲覧・編集できるかを定義します。これも Profile と Permission Sets で管理します。
  3. レコードレベルのセキュリティ (Record-Level Security): オブジェクトにアクセスできるユーザーが、その中のどのレコード（個々のデータ）を閲覧・編集できるかを定義します。Role Hierarchy はこの層で機能します。

レコードレベルのセキュリティは、以下の要素で構成されています。

1. Organization-Wide Defaults (OWD) - 組織の共有設定

これは、レコードレベルのセキュリティにおける最も基本的なベースラインです。OWD は、各オブジェクトに対してデフォルトのアクセスレベル（非公開、公開/参照のみ、公開/参照・更新可能）を設定します。例えば、商談オブジェクトの OWD が「非公開」の場合、デフォルトではレコードの所有者とその上位のロールを持つユーザーしかそのレコードを閲覧できません。これがセキュリティの最も厳しい出発点となります。

2. Role Hierarchy - ロール階層

OWD の設定の上に、Role Hierarchy が機能します。これは垂直方向の共有 (vertical sharing) を実現します。階層内で上位のロールに割り当てられたユーザーは、そのロールの直下およびそれ以下のすべてのロールに割り当てられたユーザーが所有する、または共有されているレコードに対して、OWD を超えるアクセス権（参照、編集など）を持ちます。

重要なのは、この機能はオブジェクトごとに有効/無効を切り替えられるという点です。共有設定にある「階層を使用したアクセス許可」 (Grant Access Using Hierarchies) のチェックボックスがオンになっているオブジェクトでのみ、Role Hierarchy によるアクセス権の継承が有効になります。標準オブジェクトのほとんどはデフォルトで有効になっていますが、カスタムオブジェクトでは管理者が意図的に有効にする必要があります。

3. Sharing Rules - 共有ルール

共有ルールは、Role Hierarchy ではカバーできない水平方向の共有 (horizontal sharing) や、例外的な共有を実現します。例えば、「東日本営業チームと西日本営業チームが、お互いの特定の商談を共有する」といったシナリオです。これはロールの階層構造とは関係なく、特定の条件に基づいてレコードを共有する仕組みです。

4. Manual Sharing - 手動共有

レコードの所有者が、個々のレコードを特定のユーザーやグループに手動で共有する機能です。

これらの要素は連携して動作します。Role Hierarchy は、OWD で設定された厳格なベースラインを緩和し、組織構造に基づいた自然なデータアクセスを可能にする、非常に効率的な仕組みなのです。

サンプルコード (SOQL)

管理者としての Role Hierarchy の設定は、主に Salesforce の設定画面（UI）で行うため、通常はコードを記述しません。しかし、組織のロール構造を文書化したり、監査したり、あるいはデータ移行の際に分析したりする場合、SOQL (Salesforce Object Query Language) を使用してロール階層の情報をプログラム的に取得すると非常に便利です。

ここでは、組織内に存在するすべてのロールとその親子関係を取得するための基本的な SOQL クエリを紹介します。このクエリは、Developer Console の Query Editor や、Salesforce CLI、Data Loader などで実行できます。

ロール階層の構造を照会する SOQL

/*
 * Salesforce 組織内のすべてのロールを取得し、その名前と親ロールの ID を表示します。
 * このクエリにより、ロール階層の全体像を把握することができます。
 */
SELECT
    Id,                  // 各ロールの一意の 18 桁の ID
    Name,                // ロールの表示名（例：「営業マネージャー」）
    ParentRoleId,        // このロールの親となるロールの ID。最上位のロールの場合、この値は null になります。
    DeveloperName,       // API や Apex で使用される一意のロール名
    RollupDescription    // ロールアップサマリーレポートでの表示名
FROM
    UserRole             // ロール情報を格納している標準オブジェクト
ORDER BY
    Name                 // 結果をロール名のアルファベット順にソートして見やすくします

コードの解説

  • SELECT Id, Name, ParentRoleId, ...: UserRole オブジェクトから取得したい項目を指定しています。Id は各ロールのユニークなID、Name は私たちが設定画面で見るロール名です。そして最も重要なのが ParentRoleId で、これがロール間の親子関係を定義しています。あるロールの ParentRoleId が別のロールの Id と一致する場合、階層関係が成立します。
  • FROM UserRole: これらの情報が格納されている標準オブジェクトが UserRole です。
  • ORDER BY Name: 取得した結果をロール名で並べ替えることで、リストが見やすくなります。

このクエリ結果をスプレッドシートなどにエクスポートすれば、ParentRoleId を使って階層構造を視覚化したり、特定のロールに親が設定されているか（つまり、階層のどこに位置しているか）を簡単に確認できます。

注意事項

Role Hierarchy は強力な機能ですが、その設定と運用にはいくつかの注意点があります。

1. 階層を使用したアクセス許可 (Grant Access Using Hierarchies)

前述の通り、この設定はオブジェクトごとに存在します。カスタムオブジェクトを作成した際に、階層に基づいた共有が意図通りに機能しない場合、まずこのチェックボックスがオンになっているかを確認してください。機密情報を扱うカスタムオブジェクトなど、意図的に垂直方向の共有を無効にしたい場合は、このチェックを外すことが正しい選択となります。

2. パフォーマンスへの影響

Role Hierarchy の構造は、共有計算のパフォーマンスに影響を与えます。特に注意すべきは以下の2点です。

  • フラットでワイドな階層: 一つのロール（例：営業マネージャー）の下に、数千ものロール（例：営業担当者）がぶら下がっているような構造は避けるべきです。上位ロールのユーザーがレコードにアクセスするたびに、Salesforce は膨大な数の下位ロールとの共有関係を再計算する必要があり、パフォーマンスの低下を引き起こす可能性があります。階層は、できるだけバランスの取れたツリー構造にすることが推奨されます。
  • 所有者のスキュー (Ownership Skew): 特定の一人のユーザーが大量のレコード（数万件以上）を所有している場合、そのユーザーが階層の上位にいると、共有計算に大きな負荷がかかります。このような場合は、レコードの所有権を分散させるか、共有の設計を見直す必要があります。

3. HR 組織図との違い

これは非常によくある誤解ですが、Salesforce の Role Hierarchy は、必ずしも人事上の組織図（レポートライン）と一致させる必要はありません。 Role Hierarchy の目的は、あくまで「レコードアクセスの階層」を定義することです。例えば、あるプロジェクトチームで、マネージャーではないがリーダーシップをとる人物がチーム全体のレコードにアクセスする必要がある場合、その人物をチームメンバーより上位のロールに配置することが適切です。常に「誰がどのデータを見る必要があるか？」を基準に設計してください。

4. ロールの数

Salesforce 組織で作成できるロールの数には上限があります（通常は最大500ですが、エディションによって異なります）。不必要に詳細なロールを作成すると、この上限に達してしまう可能性があります。同じアクセス権限でよいユーザーは、同じロールにまとめるように心がけましょう。

5. アクセス権の付与のみ

Role Hierarchy は、OWD で設定されたベースラインよりも多くのアクセス権をユーザーに付与することしかできません。アクセス権を制限する方向には機能しません。例えば、OWD が「公開/参照のみ」の場合、Role Hierarchy を使って特定のユーザーのアクセスを「非公開」にすることはできません。

まとめとベストプラクティス

Salesforce Role Hierarchy は、組織のデータアクセス構造を反映し、レコードの可視性を効率的に管理するための、基本的かつ不可欠なツールです。正しく設計・実装すれば、セキュリティを確保しつつ、ユーザーが必要な情報にシームレスにアクセスできる環境を構築できます。

最後に、Salesforce 管理者として心に留めておくべきベストプラクティスをまとめます。

  • シンプルさを保つ: 階層は、ビジネス要件を満たす範囲で、できるだけシンプルかつフラットに保ちましょう。不要な階層は管理を複雑にし、パフォーマンスに悪影響を与える可能性があります。
  • データアクセスに基づいて設計する: 役職名ではなく、実際のデータアクセス要件に基づいてロールを定義します。「このグループのユーザーは、どのレコードを見る必要があるか？」を自問してください。
  • ロールの数を最小限に: 同じデータアクセス権を持つユーザーは、一つのロールにまとめます。役職ごとにロールを作成する必要はありません。
  • 定期的な監査: 組織の変更（人事異動、再編など）に伴い、Role Hierarchy が現状と乖離していないか、定期的に見直しを行いましょう。不要になったロールは無効化し、ユーザーのロール割り当てが適切であることを確認します。
  • 適切なツールを使い分ける: 垂直方向の共有には Role Hierarchy を、水平・斜め方向の共有には共有ルールや公開グループ (Public Groups) を使用するなど、要件に応じて Salesforce の共有機能を適切に使い分けることが重要です。

Role Hierarchy は一度設定して終わりではありません。組織の成長とともに進化する、生きた設計図です。これらの原則と注意点を念頭に置き、堅牢でスケーラブルなセキュリティモデルを構築・維持していくことが、私たち Salesforce 管理者の重要な役割です。

コメント

コメントを投稿