目次
Platform Sharing and Visibility アーキテクトとは
はじめに、認定 Platform Sharing and Visibility アーキテクト(※以下Sharing and Visibility アーキテクト)がどのような資格なのか、ご紹介します。
Sharing and Visibility アーキテクトとは、Salesforce上での「データの機密性保持」と「適切なアクセス制御」の設計能力を証明する共有モデルに関する資格です。
単に設定方法を知るだけでなく、複雑な組織構造や大量データ環境において、パフォーマンスを維持しつつ安全にデータを共有するための最適なアーキテクチャを提案する力が問われます。
また、本資格は「認定アプリケーションアーキテクト」を取得するための前提資格4つの内の1つのため、アプリケーションアーキテクトを目指す上で避けては通れない、設計の根幹を担う重要な資格です。
詳細は受験ガイドに記載されていますが、120分の試験時間で60問出題され、合格点が67%の試験です。
試験時間は十分余裕があるので、1問1問丁寧に解いても見直す時間があります!焦らずに確実に解答していくことが重要だと思います。
対策方法
試験では、権限設定や共有を行う際のユースケースに基づく問題が多く出題されます。 今回私は基礎情報を確認した後は問題演習を行い、質問の傾向やどのような回答が求められるのかを確認する方針にしました。 以下では、私が実施した試験対策をご紹介します。- 出題範囲の確認
- Youtube動画視聴
- Trailheadでの学習
1. 出題範囲の確認
合格のためにまず重要なのは、試験概要を把握し出題範囲を正しく認識することです。 Salesforceが公開している試験ガイドには単元ごとに出題率が記載されており、当たり前ではありますが、比重が高い単元を重点的に学習することで合格に近づきます。 受験ガイドと合格通知メールに記載されていた単元に差異がありましたので、両方記載します。 ▼公式の受験ガイドの単元- 宣言的共有:76%
- プログラミング的共有:7%
- パフォーマンス:17%
- 標準/カスタムオブジェクト/項目の権限(Permissions to Standard Objects, Custom Objects, and Fields)
- レコードアクセス(Access to Records)
- その他のデータアクセス(Access to other Data)
- セキュリティモデルの影響(Implications of Security Model Choice)
2. YouTube動画視聴
本試験の内容をまとめているYouTube動画があります。 1時間程の動画なので、まずは下記動画を視聴し、自身の理解が浅い分野を確認しました。 【機能紹介】Salesforceの共有設定をマスターしよう! 〜 Sharing & Visibility ※受験後に改めて視聴すると、とても分かりやすく試験範囲がまとめられていると感じましたので、視聴して損はないかと思います3. Trailheadでの学習
2の内容で理解が浅い分野や自分が利用したことが無い機能については、 公式のTrailmix「Architect Journey: Sharing and Visibility」を用いて学習しました。 内容としてはドキュメントが中心ですので、全てを細部まで確認する場合はかなりの時間を要しますので、学習期間は長めに見積もった方が良いかもしれません。 また、文字だけの理解ではなく、実際に画面を見ながら確認をすることも非常に大切だと考えているため、ドキュメントを読んだ後は、実際に環境に触れて経験として身に付けるという流れで学習を行いました。 試験時に操作を思い出すことで、回答を導き出せることもあったのでおすすめです!受験してみて
Sharing and Visibility アーキテクトの学習を通じて、権限設定やレコード共有について理解を深めることができました。 私が受験してみて感じたことを最後にご紹介します。 資格の難易度については、対策2~3の内容を理解していれば十分受かるレベルであると感じました。 勿論Salesforceを触り始めて数カ月であれば難易度は非常に高いかと思いますが、管理者やSEとしてSalesforceに触れている方であれば、十分に可能性はあると思います。 また、既に知っている知識でも、試験の独特な選択肢を前にすると急に不安になるものです。 是非既知の内容でも復習することをおすすめします。 私が重要だと感じたトピックを簡単にですがまとめましたので、ご参考になれば幸いです。- 取引先チーム
- 特定の取引先に対して、複数のユーザーが協力して作業するための機能
- チームメンバーごとに「非公開」「参照のみ」「参照/更新」といったアクセス権を、取引先・商談・ケースの各オブジェクト単位で個別に割り当て可能
- 付与できるアクセス権は、組織の共有設定より厳しくすることはできないため、 **** あくまで「拡張」するための機能である点に注意が必要
- レコードの共有方法
- 組織の共有設定を起点として「ロール階層」「共有ルール」「手動共有」「Apex共有」といった順序でアクセス権を拡張する階層構造
- 共有設定は常に「アクセス権を開放(拡張)」する方向に働くため、一度組織の共有設定で「公開」に設定したものを、他の機能で「非公開」に制限することはできない ※「制限ルール」という機能がありますが、本資格には関係しないため割愛します
- 大量のロールを更新する際の注意事項/利用機能
- ロール階層の大幅な変更やユーザーの異動を行うと、システムは裏側で再適用を行う
- 大規模組織では再適用に多大なリソースを消費し、パフォーマンス低下やレコードロックが発生するため、「共有適用の延期」機能を使い、メンテナンス時間外に一括処理を行うのがアーキテクトとしての定石
- Experience Cloudのライセンス・権限制御
- Experience Cloudの共有については、以下の表を参照
| 機能/ライセンス | Customer Community | Customer Community Plus | Partner Community |
|---|---|---|---|
| ロール階層 | × | ○ (最大3階層) | ○ (最大3階層) |
| 共有ルールと直接設定 | × | ○ | ○ |
| 共有セット | ○ | ○ | ○ |
| 共有グループ | ○ | ○ | ○ |
| スーパーユーザー | × | ○ (※) | ○ (※) |
※Customer Community Plus と Partner Community のスーパーユーザは機能が異なります
- 主従関係と暗黙的な共有
- 主従関係: 子レコードのアクセス権は親レコードに完全連動(組織の共有設定は「親レコードに連動」に固定)
- 暗黙の共有: 取引先の子レコード(取引先責任者・商談・ケース・注文)にアクセス権を持つユーザは、その親の取引先への参照権を持つ
- プログラミングによるレコード共有・アクセス権設定
- 標準機能で対応できない複雑なロジックが必要な場合、Apexを用いて「Share オブジェクト」のレコードを作成し共有する
- 「with sharing」 キーワードを使用して現在のユーザー権限を考慮するか、「without sharing」 でシステム権限として実行するか、実行コンテキストの使い分けがセキュリティ担保の肝 ※できるだけ「without sharing」は利用しない方針で考えるのがおすすめです



