C. 後から「やらなければよかった」と思った設計
それは、「必要最低限の権限」という言葉を真に受けすぎた、プロファイル設計だった。
プロジェクト立ち上げ当初、私はSalesforceのセキュリティモデルにまだ慣れておらず、"最小権限の原則"をかなり厳格に適用しようとした。結果として、オブジェクトアクセスとタブの可視性、そしてページレイアウトの割り当てが少しでも異なるユーザーグループに対して、カスタムプロファイルを次々に作成していった。
例えば、こんな感じだ。
- 営業担当プロファイル (リード・商談・取引先・取引先責任者オブジェクトの編集権限、営業関連タブ可視)
- 営業マネージャープロファイル (営業担当プロファイル + レポート・ダッシュボード参照権限強化、マネージャー向け項目へのFLS)
- 経理担当プロファイル (カスタムオブジェクト「請求書」の編集権限、標準オブジェクトは参照のみ、営業関連タブ非表示)
- マーケティング担当プロファイル (リード・キャンペーンオブジェクトの編集権限、一部レポート・ダッシュボード参照)
- サポート担当プロファイル (ケース・ソリューションオブジェクトの編集権限)
当時の私は「これで完璧だ、ユーザーは本当に必要なものしか見えないし、無駄な権限は一切与えていない」と自画自賛していた。組織の部署や役割の数だけプロファイルが増殖していった。
ところが、この設計が後々、管理上のとんでもない悪夢になるとは、その時は全く想像していなかった。
「プロファイル地獄」への滑り出し
初期の段階では、ユーザー数もオブジェクト数も少なかったため、それほど問題は顕在化しなかった。しかし、プロジェクトが進むにつれて、以下の問題が噴出した。
- オブジェクトと項目の追加・変更への対応: 新しいカスタムオブジェクトや項目が追加されるたびに、関連するであろう全てのプロファイルを手動で開いて、オブジェクト権限、項目レベルセキュリティ(FLS)を調整する必要があった。これは本当に手間がかかった。特にFLSはプロファイルごとに詳細に設定し直す必要があり、よく漏れが発生した。
- ページレイアウトの割り当て: 特定のプロファイルにはAレイアウト、別のプロファイルにはBレイアウト、という設定もプロファイルごとに行っていたため、新しいレイアウトができた時や、既存のレイアウトを変更した際の影響範囲特定と更新が非常に煩雑だった。
- レポート＆ダッシュボードフォルダの共有: 当初、レポートフォルダの共有もプロファイルをベースに行っていた。これもプロファイル数に比例して設定が複雑になり、誰がどのフォルダにアクセスできるのか、全体像を把握するのが困難になった。
- 変更セットでのデプロイ時の競合: プロファイルの変更を本番環境にデプロイする際、複数のプロファイルで少しでも権限が異なると、変更セットに含めるプロファイルXMLファイルが大量になった。そして、それらのプロファイルXMLが少しでも既存の環境と食い違っていると、デプロイに失敗することが頻繁にあった。特に、本番環境でユーザーをアクティブ化・非アクティブ化するだけでXMLが更新され、それが変更セットに含まれるプロファイルと競合することが多々あり、本番と開発環境の同期が非常に困難になった。
- 監査時の苦痛: 「このユーザーはなぜこのレコードが見えるのか？」「このボタンが押せないのはどのプロファイルのせいだ？」といった問い合わせがあった際、膨大なプロファイルの中から関連する設定を探し出すのが、文字通り地獄だった。プロファイル間の微妙な違いを把握しているのは私だけで、他の管理者では容易に特定できなかった。
特に、変更セットでのデプロイ時の苦痛はひどかった。プロファイルは変更セットではXMLファイルとして扱われるため、少しでも手動で変更が入るとデプロイ失敗のリスクが高まる。オブジェクト権限やFLSだけをピンポイントでデプロイする、という概念が当時の私には希薄だったため、プロファイル全体をデプロイしようとしていたのだ。これは完全にミスだった。
当時の私は、新しい機能リリースのたびに、影響するプロファイルを一つ一つ手作業で確認し、更新する作業に追われていた。数が増えるにつれて、もはや管理しきれない状態になり、「これではいけない」とようやく気付いた。
もし今なら別の選択をする
もし今、あの時の私にアドバイスできるなら、こう言うだろう。「プロファイルは極力少なく、権限セットと権限セットグループを活用しろ」と。
現在は、
- プロファイルは、「標準ユーザー」のような基本的なロール（ログイン時間、IP範囲、デフォルトのレコードタイプやアプリの割り当てなど、ユーザーの最も基礎的な区分）に限定し、数個に絞り込む。
- オブジェクト権限、項目レベルセキュリティ、カスタム権限、ユーザー権限（例：API参照のみ、レポート作成権限など）といった具体的なアクセス権限は、すべて権限セットで管理する。
- さらに、これらの権限セットを組み合わせて、権限セットグループで論理的な役割（例：「営業担当グループ」「経理担当グループ」など）を構成し、ユーザーにはそのグループを割り当てる。
- ページレイアウトの割り当ても、今は権限セットや権限セットグループでも可能になった（これは当時存在しなかった機能なので、当時の選択は仕方なかったかもしれないが）。
こうすることで、新しいオブジェクトや項目が追加された際も、影響する権限セットだけを修正すればよく、プロファイル全体をいじる必要がない。また、変更セットでのデプロイも、プロファイルではなく権限セットのXMLだけを含めればよいため、競合のリスクが大幅に減る。
あの時の私は、プロファイルが持つ「デフォルトのアクセス権限」という側面と、「ユーザーに付与する特定の権限」という側面を混同していた。そして、組織の柔軟性を確保するための権限セットの存在意義を、十分に理解していなかったのだ。
今でも、あの頃の組織でプロファイルのメンテナンスをしていた時の悪夢を思い出すと、ゾッとする。本当に「やらなければよかった」と心から思う設計判断の一つだ。これは当時の自分向けのメモだ。
コメント
コメントを投稿