Salesforce 認定 Sales Cloud コンサルタント 1-10

本問はプライベート共有モデルにおけるアクセス権の付与方法が問われています。
プライベート設定ではレコードは所有者と共有されたユーザーのみ閲覧可能です。
そのため、製品管理担当者にアクセスさせるには共有設定の追加が必要です。
選択肢Cの条件付き共有ルールを使用すると、特定条件（製品など）に基づいて自動的にレコード共有が行われます。
コード開発不要でスケーラブルにアクセス権を付与できる点が重要です。
一方、トリガー（A・B・D）は開発が必要であり、標準機能で実現できる要件には不適切です。
Salesforceではまず宣言的機能（共有ルール）を優先する設計原則がある点も重要です。

共有ルールタイプ

「ファネルの管理」は、商談が各ステージをどのように進み、どこで停滞しているかを把握し、将来の売上を予測することが目的です。
そのため、ステージごとの滞留時間や進行状況、予測情報が重要になります。
選択肢Aの「ステージ期間の経過」は各ステージでの滞在時間を分析でき、「営業担当者による予測」は将来の売上見込みを把握できます。
ファネルの健全性（滞留・進捗）と予測の両方をカバーできる点が重要です。
一方、Bはリード分析、Cは活動量や単純な件数把握であり、ファネル全体の流れや予測管理には直結しません。
ファネル管理では“ステージの流れ”と“予測”の可視化が最重要である点を押さえる必要があります。

商談フェーズの期間に関するレポートを作成

本問は「特定の条件（ステージがクローズ/受注以降）」で編集を制御する方法が問われています。
フィールドレベルセキュリティは常に編集可否を制御するものであり、条件付き制御はできません。
検証ルールを使用すると、「ステージが特定条件のときに編集を禁止する」といった制御が可能です。
条件に応じて保存自体をブロックできる点が重要です。
また、ワークフロールールは更新処理用であり、入力制御には適していません。
Salesforceでは条件付き入力制御は検証ルールで実現するのが基本設計である点が重要です。

検証ルール

Salesforce for Outlookでは、ユーザーは手動および自動の両方でデータ同期を実行できます。
Aの「今すぐ同期」はユーザーが任意のタイミングで同期を実行する手動操作です。
ユーザー主導で即時同期できる点が重要です。
Dのバックグラウンド同期は、設定により定期的に自動同期が実行されます。
ユーザー操作なしで継続的にデータ同期が維持される点が重要です。
BやCのように個別にスケジュールを細かく設定する仕組みはなく、Salesforce for Outlookでは主に手動同期と自動（バックグラウンド）同期の2種類で管理されます。
なお、Salesforce for Outlookは現在は非推奨となり、後継として「Outlook Integration」や「Einstein Activity Capture」へ移行されています。

Salesforce for Outlook(引退)とMicrosoft® Outlook®間の同期

本問は分割払い（サブスクリプション的な収益）をどのように管理・予測するかがポイントです。
Sales Cloudでは「収益スケジュール」を使用することで、売上を期間ごとに分割して管理できます。
収益スケジュールを使うと、各支払いのタイミングや金額を設定でき、長期契約における収益認識が可能になります。
月次などの期間単位で収益を分割し、将来の売上予測に活用できる点が重要です。
他の選択肢は単なるデータ保持や処理自動化に過ぎず、財務予測には不十分です。
収益のタイミング管理と予測精度向上には標準機能である収益スケジュールの利用が最適である点が重要です。

商品スケジュール

Salesforceの資産（Asset）は、必ずしも自社が販売した製品だけに限定されません。
資産は顧客が所有している製品や設備を記録するためのオブジェクトであり、他社製品や外部で取得した製品も登録可能です。
そのため、「自社が販売したもののみ追跡可能」という記述は誤りです。
資産は顧客が所有するあらゆる製品を管理できる点が重要です。
また、資産はサポートや保守、アップセルなどに活用されるため、販売元に依存せず管理できる設計となっています。
顧客中心のデータモデルであることが重要なポイントです。

Field Service での納入商品の管理と最適化
商品/納入商品レポート

本問は「モバイル活用が実際に行われているか」をどのように証明するかがポイントです。
単なる設定確認ではなく、実利用の証拠が求められています。
Aのようにモバイルから作成された商談をレポートすれば、実際に営業担当者がモバイルを活用して業務を行っていることを示せます。
実際の業務データに基づく利用状況の可視化ができる点が重要です。
Bはログイン情報であり利用状況の一部しか分からず、Cは設定確認に過ぎません。
導入効果の証明には「利用実績データ」を示すことが最も重要である点がポイントです。

Salesforce for Android and iOS アプリケーションからモバイルログインを追跡する

本問は異なるリード種別ごとに異なる業務プロセスを適用する設計が問われています。
Salesforceでは「レコードタイプ」と「リードプロセス」を組み合わせて実現します。
まずCのレコードタイプで「ディストリビューター」と「小売業者」を分けます。
次にAのリードプロセスで、それぞれに異なるステータスフローを定義します。
さらにEで各プロセスに対応したステータス値を設定します。レコードタイプ＋プロセス＋選択リストの組み合わせで業務分岐を実現する点が重要です。
Bは不要な制約を生み、Dはプロセス制御とは無関係です。Salesforceの標準設計では「レコードタイプで分岐しプロセスで制御する」ことが基本である点が重要です。

複数のビジネスプロセスの管理

本問は「通知の柔軟性」と「ユーザーごとの通知制御」がポイントです。
ワークフロールールによるメール通知は一律配信となり、ユーザーごとの頻度調整ができません。
Chatterを利用すると、レコードフォローにより更新通知を受け取ることができ、ユーザー自身が通知頻度（即時・日次など）を設定可能です。
ユーザーごとに通知頻度を柔軟に制御できる点が重要です。
また、重要な商談をフォローすることで必要な更新のみを受信でき、情報過多も防げます。
フォロー機能により関心のあるレコード単位で通知を最適化できる点が重要です。

フォロー・レコード

本問は開発手法（プロジェクト手法）の選定に関する問題です。要件として「迅速な反復」「頻繁なフィードバック」「継続的な改善」が求められています。
アジャイルは短い開発サイクル（スプリント）で反復的に開発し、都度フィードバックを取り入れて改善していく手法です。
頻繁なアップデートと柔軟な要件変更に対応できる点が重要です。
一方、ウォーターフォール（滝）は要件固定型で変更に弱く、Kanbanは可視化には強いものの本問のような反復開発プロセスの主軸にはなりません。
Salesforce導入では反復・適応型のアジャイルが標準的に採用される点が重要です。

Salesforce がアジャイルを採用した理由の理解