※作成中
・資料作成にあたり、最低限必要な知識_シナリオへの回答
まずは、SFAやコールセンター、フィールドサービスの業務フローを抑えると、問題を読み進めやすく／当てはめやすくなりますので、よく出る以下3パータンは頭に入れておく必要があります。（模擬シナリオにはもちろん以下以外の業務も当然出てきます。）
(業務の流れ)SFA／CRM
営業員が、顧客やその商談情報を管理して成約に進めていく業務になります。
例えば、マーケティング担当者が、キャンペーン(試食会・金融セミナーなど)を開催し、来店してくれた見込み顧客(リード)を管理します。
※後ほどそのキャンペーンが本当に取引につながったか、開催にかかった金額に対して利益／ROIが妥当か集計もできます。
※Web画面やコミュニティ画面から見込み顧客が資料請求などを行い、リードが自動生成されるケースもあります。
そのうえで、案件化しそうなら、営業員がリストビューなどから見込み顧客(リード)を確認／セールス電話など行い、商談化しそうなら取引開始(取引先や商談にコンバート)を行います。
※リードの割り当てルールで地域に応じて自動で営業員にリードが割り当てられるケースもあります。
商談に入ると、営業員は情報を集め、見積を複数回実施／見積書を作成・送付を行い、折り合いがついたら商談に同期します。
成約したら商談ステータスはクローズにし、契約レコードや注文レコードを作成します。必要に応じて注文情報はSAP(ERP)と連携し、後続の会計や発注処理など行います。最終的に顧客に対して納入商品のレコードを作成し、今後ケースなど紐づけて保守サポートを管理していきます。
(業務の流れ)コールセンター／サポートセンター
お客さんから、多様なチャネルで問い合わせが来ますが、コールセンターの担当者が効率的に割り当てられて、SLAに準拠したサポートを提供するという流れになります。
具体的には、お客さんから、電話・チャット・EinsteinBot、Web経由(Webtoケース)、メール(メールToケース)など多様なチャネルから問い合わせがきます。CTA試験は利用者の多い大規模案件が想定されるため、効率化のためにスキル(言語=複数の国と地域にまたがるシステムなので、専門知識)や業務量、対応状況に応じて担当者に割り当てが行われます。担当者は割り当てのポップアップが表示されるため、受け入れるか否か手動でボタンをクリックし、お客さんからの問い合わせ対応を進めます。
コールセンターの上司は、オムニスーパーバイザーという機能で、配下の社員がどのくらい業務量をもっているかなど一元的に見ることが可能です。また若手／入社したての部下のチャットに対して、お客さんには見えない状態でテキストでのアドバイスをすることも可能です。通話に関しては音声の自動テキスト化が行われて、それに対しておすすめAction（NextBestAction＝クーポンの配布奨励など）を表示したり、Einsteinによって通話結果のサマリを自動生成できます。（メールの返信内容を自動生成／評価する機能もあります。）
VisualRemoteAssistantを使うと、ビデオ通話や録画、AR表示なども可能です。
専門知識の必要なケース対応では、スキルやSlackと組み合わせてスウォーミング（専門家をSlackの特定チャネルに呼び出し）もできます。
お客さんがプレミアムサポートに加入してるなどの資格情報は、お客さんに紐づくエンタイトルメント情報で管理できます。加入しているエンタイトルメントに応じて、ケース画面上に8時間以内に対応が必要など視覚的に確認することができます。
仮に特定の時間内に対応やステータス変更がなされない場合にはケースのエスカレーションルール（上司にエスカレする機能）も活用できます。
(業務の流れ)フィールドサービス
顧客から依頼されたエアコンやソーラーパネルなどの設置・修理を行うために、作業指示書や適切な業者の割り当て業務を行います。
例えば、お客さんから電話・チャットなどでエアコン設置の問い合わせがくると、受けたコールセンターはケースを起票し、適宜作業指示を作成します。作業種別というフォーマットを定義した機能を使うことにより、自動サービス予定（訪問予定）や必要なスキル、商品など自動生成することができます。ディスパッチを行うディスパッチャーに引き継ぐと、スキルやスケジュール、営業時間に応じて設置業者を自動ディスパッチできます。ディスパッチされた設置業者はモバイルで通知を受け取り、お客さん先に訪問します。モバイルのデイビューで1日の作業の流れを確認し、訪問・設置・修理など行います。設置が完了したらモバイル上で指でサインができますので、サービスレポートをお客さんに提示し、サインしてもらいます。
困ったらモバイルのChatterでコミュニケーションをとったり、ナレッジで回答を確認します。
お客さんはAppointmentAssistantを使うことにより、予約の変更や、設置業者が今どこにいるかなど位置情報の確認が可能です。
SalesCloud／ServiceCloudにおける必修のSalesforce標準機能
以下機能については、最低限、実機操作の上、機能概要の把握や制限が必要かと思います。
▽最低限、機能概要の把握や制限が必要な機能
注意
思い付きで上げており、あまり網羅的でない気もするので、参考まで。
その他機能
サンプル問題です。
１） 顧客がWebサイトから顧客情報を入力し、資料ダウンロードの申し込みを行います。（1日100件未満。）その見込み顧客情報をもとにマーケティング担当はSalesforce上で評価をし、営業に引き渡します。営業は見込み情報を見て顧客に電話し、顧客化しそうであれば商談を作成します。
２） 顧客数が3万人います。電話やメールなど多様なチャネルでコールセンターに問い合わせが行われます。コールセンターは業務の効率化を目指しています。
３） ケースが作成されて、社内の担当者が割り当てられたのですが、プラチナ会員のお客さんの問い合わせにも関わらず、対応が進んでいないようです。
４） 履歴データをシステム上に保管する義務があります。原則画面から見える必要はないのですが、監査要件のため、必ず5年保持する必要があり、基本的に項目などの定義変更はありません。データ件数は数億件となる見込みです。
回答です。
１）WebサイトからSalesforceのリード情報の登録はWeb-to-リード（上限1日500件のため）。マーケティング担当はリード画面上で必要情報を入力したり、ステータス変更。営業はリストビューなどから評価済み（＝ステータス変更されたデータ）のリードを確認し、顧客に電話をする。話が進みそうな場合、リードの取引先開始（コンバート）で、取引先・取引先責任者・商談を生成し、商談を開始する。
２）電話やメールが来た際に、効率化のためにスキル(専門知識や言語)や業務量に応じたルーティングを行うため、ServiceCloudVoiceを導入し、オムニチャネルルーティングや、電話内容の音声テキスト化、ナレッジの活用、Einsteinによる文章のサマリを行う。（お客さんが3万人もいた場合、手動でスキルや習熟度など考慮して担当の割り当てなど不可能なので、必ず自動でルーティングする機能が必要です。それがスキルベースのオムニチャネルルーティングです。）
３）ケースのエスカレーションルールで24時間まったくステータスが対応中に変わらない場合、マネージャーに通知を行う。エンタイトルメントで顧客の資格（プラチナサポートか、ベーシックサポートかなど）は管理。
４）BigObjectを検討。BigObjectは性質として画面がなく（カスタムすればSalesforce上から参照画面定義可能）、インデックスの変更など生じる場合は作り直し／データ移行が必要になります。今回履歴データでカラムも変わらない、画面も不要、データとして数億ということなので、BigObjectが最適と思われます。
※仮に項目が変わるようなデータであれば、BigObjectではなく外部ストレージの検討が必要です。ETLで定期的に外部ストレージにSalesforceのデータを移動させるイメージとなります。
アクセス権限機能
Salesforceにはいくつか権限設定機能が存在します。
主要なものについて解説します。（厳密な説明はしておらず、ざっくり概要がわかる説明をしていますのでご留意ください。）
【FieldService】サービステリトリによるバッチ権限付与
※名称があってるか不明 日次で、サービス予定に割り当てられているサービステリトリに対して、サービス予定とその親レコード（確か作業指示以外のケースもあったような・・・）の権限を付与する。
※上記以外に付与する場合は、Apex共有など別の対処が必要。
※SalesCloudのテリトリ(=割り当てられた営業地域)と、FieldServiceのサービステリトリ(=設置作業可能な地域)は別物です。名前似てるけど。
これ以外にも取引先チームや取引先データ共有などいろいろあり、全部の権限機能を網羅するのが無難です。
ちなみに共有ボタン（手動共有）は、エンタープライズ向けだとミスも多いので、あまり奨励となるケースはないかと思います。
★Qiirtaリンクを張る。取引先データ共有、所有者の件など
https://qiita.com/nori83/items/bba42687b327b5035341
FieldService機能
FieldServiceで抑えておくべきポイントは以下です。一度、無料の開発環境を取得し、全部の画面を触ってみる／認定資格があるので取得してみるといいと思います。
・ライセンスと機能の関係
・業務フロー（誰がどのタイミングで何をするのか） ※ここを理解すると、回答に当てはめやすいです。
例）コールセンターが顧客から電話を受けてケースを作成。そのあと業者へ依頼のため、作業指示レコードを作成。（この時に作業種別の設定で、自動でサービス予定を生成できる。ディスパッチャーはサービス予定（＝訪問予定）に、設置する作業者をディスパッチする。（ディスパッチコンソールから一括で可能）。ディスパッチされると設置業者のモバイルに通知が行く。またディスパッチのタイミングでサービス予定のステータスが変わり、設置業者へ権限が付与される。・・・
・各テーブルの代表項目、レコードの粒度、提供機能
・作業種別の機能（ここでサービスレポートやスキル、必要商品などのフォーマットが定義できる。効率化）
例）エアコン設置の場合は、XXの器具が必要で、スキルはYYが必要 など定義できる。
・ディスパッチ機能（ディスパッチコンソールで提供している機能。何をもとにディスパッチしてくれるか？（スキルや営業時間などサービスリソースの状況を見てディスパッチが可能。））
・メンテナンス計画、メンテナンス作業ルールなど（メンテナンス計画で作業指示レコード作成のバッチ処理を組むことが可能。例えば納入商品の利用料がXX％になったら、作業指示を作るなど複雑なロジックは、メンテナンス作業ルールで定義が可能。
・納入商品（シリアル番号、納入日、ステータスなど。目的はあくまで納入された商品をレコードとして定義。営業支援の商品はあくまでメニュー表なので、納入された1個1個の商品とは同じにならないケースが多い。）
・スキルとサービスリソース、サービステリトリの関係
・FieldServiceのアクセス権限仕様
以下の通り、複雑な権限付与はできないため、細やかな権限制御はApex共有や共有ルールを活用することになると思います。
★Qiirtaリンクを張る。FiledService権限
・FieldServiceのモバイルアプリの仕様
https://qiita.com/nori83/items/7c581157e9696ca21e98
https://qiita.com/nori83/items/e54c9451c12ab87e4817
https://qiita.com/nori83/items/36b68ac61d06251d8a03
サンプル問題です。
１）社内の専門査定員は、コールセンターで作成された問い合わせをもとに指示書と設置業者の訪問予定を作ります。設置業者は5,000人おり、営業時間やスキル、ロケーション、その日のほかの訪問場所など考慮して効率的に訪問予定を割り当てたいです。
回答です。
１） 専門査定員はFieldServiceのディスパッチャーライセンスとなる。（ディスパッチするので。）
指示書は作業指示で、訪問予定はサービス予定。効率化のために作業種別を定義し、作業指示に紐づけると自動でスキルやサービス予定が自動生成される仕組みを活用する。また、FieldServiceのディスパッチ機能を使うことにより、スキルや営業時間など加味して設置業者の訪問予定への割り当てを行う。（5,000人も設置作業者がいるので、手動割り当ては運用が回らない／非効率になるので、自動処理を活用する。）
モバイル比較
Salesforceのモバイルについては以下が選択肢／比較となる。
あくまで2023年時点の私の中の調査結果／評価であるため、（これに限らずだが）自身でも調査／確認いただきたい。
また、Salesforceアプリは実際にストアからインストールもできるので、ぜひ触ってみるとイメージが付くと思います。
※ちなみに実際の案件では、PC、タブレット、モバイルごとに、アプリと各ブラウザ、バージョンなどしっかり非機能を調査して使えるか確認してください。
モバイルでは何を使うかを必ず問われるため、選択したモバイルツールとその根拠を説明する必要があり、以下のように自身の中でどういうケースのときどのソリューションか？また根拠はどう考えるか？をシミュレーションしておく必要がある。
サンプル問題です。
１）顧客はモバイルからSalesforceにアクセスします。また顧客はモバイルからBluetoothと自身の購入した機器を連携したいと考えます。
２）営業員はモバイルアプリから顧客の商談情報を入力したいユースケースがあります。Chatter通知もアプリから受け取りたいです。
回答です。
１）ネイティブアプリを提案。ブルートゥースはハイブリットとネイティブしか対応していない。開発工数は高くなるが、顧客向けのアプリであるためユーザビリティは重視したく、UIUXの自由度や操作速度を鑑みるとネイティブ。
２）Salesforceアプリを提案。社員のブラウザからのSalesforceアクセスは機能提供しておらず、社内向けであるため開発工数の低いSalesforceアプリを提案
システム連携 インテグレーション方式
まず、俯瞰図の章でも記述しましたが、疎結合化するため、システム連携はESBを挟み、バッチ処理やデータ移行、アーカイブはETLを使う前提としましょう。（実案件ではお客さんの予算や規模によって使わないケースも多々ありますが、大規模のエンターブライズ向けの案件ですので、ESB、ETLは必須としましょう。）
（補足コラム）同期と非同期
私が若手のころ、理解しづらかったことの１つが同期処理と非同期処理の違いです。
同期・非同期とは、通信を投げて即座に画面に結果が返ってくるのが同期、返ってこないのが非同期です。
同期は、処理してすぐ結果を出すので、利用者を待たせます。
例えばECサイトのクレカ決済は、決済処理（通信）を待たされて、「決済が完了しました！」って出てくるケースが多いですよね？
こんなイメージです↓
一方、LINEやAmazonなどは、メッセージ送信や注文はスムーズに行えて、あとで失敗したときに連絡が来るかと思います。それが非同期です。一見メッセージ送信や注文が成功したように見えますが、以下のように時間が経つと、「送信失敗」のメッセージや、「注文が失敗しました」などのメールが送信されます。なので、一回処理を投げて終わりにしてしまうのが非同期で、結果どうなったかは待ちません。
インテグレーション
Salesforceと他システムのインターフェースを検討するにあたり、以下が候補してあがるケースが多いです。
いずれも回答について、なぜこのソリューションを選んだのか、他と比較して何が優位か？を問われます。
また、バージョンアップによってベストソリューションはよく変わるので、2024年頃のソリューションと考えてください。
加えて、ESBやETLを使うことのメリット、冪等性の担保の方法（ボタンを1度押したら非活性にするとか、ESBで履歴を持ち、ユニークキーをもとに重複処理か判断など）、エラーハンドリング方法（非同期なら対向でエラーが起きたらESBでリトライ、同期なら画面に即座に帰るのでユーザが画面上からリトライ、など）、ジョブの組み方（バッチウィンドウを計測し、1時間ごとに実行していくことや、JP1を使って前段が終わったら後段を実行など）、連携におけるユニークキーの持ち方（SFにERPごとの外部IDをそれぞれ別項目に持ち、SFから注文データが登録されたら、ESBで地域情報をもとに対象ERPにルーティング、もしくはERPが100個くらいあるならMDM（マスタデータ管理）を検討する）など問われるケースがあります。
以下、インテグレーションパターンなど読み、私の中でのインテグレーション回答の基準となります。
まず向きがどちらか、データ量や標準か否かなどが、ソリューションを確定する判断条件です。
▽（参考）プラットフォームイベントや変更データキャプチャｎ
https://qiita.com/nori83/items/01ba54570d68c2cc1c8c
Canvas
サンプル問題です。
１） 顧客の新規ログイン後のオンボーディング画面では、氏名など個人情報に加え、有効な免許情報を必須で登録してもらいます。免許が有効であるかは、3rdPartyを活用して行い、有効でないなら即座に画面にエラーを表示します。
２）顧客が申請情報をSalesforce画面から登録すると、リアルタイムに社内の申請システムに対しても申請情報が登録され、基幹システムとの後続処理がなされます。
回答です。
１） 画面フロー＋外部サービス
即座に画面エラーを返したいと明確に記載がありますので、同期処理となります。（この時点で#1/2に絞れます。）
その中でも画面要件について複雑な要件の記述もないため、標準の画面フローを使います。
流れとしては、ログイン後に画面フローが立ち上がり（ボタンを押して立ち上げてもらうか、ログインフローの処理として画面フローを立ち上げるようにするか）、顧客が個人情報・免許情報を入力し、「次へ」ボタンを押すと、外部サービス(OpenAPI、対向のAPIを呼び出す処理)が起動し、ESBのAPI(免許チェックシステムのAPIをラップしたもの)を呼び出し、ESBは免許システムのAPIを呼び出します。免許システムは有効か否か判定し、ESBに結果を返し、ESBはSalesforceに結果をもとします。画面フローに結果が表示されます。
※標準のページレイアウトだと同期コールアウトの外部サービスが組み合わせられませんので、今回ソリューションを標準にするためにも画面フロー＋外部サービスとしています。標準のページレイアウトで同期コールアウトする場合は、画面上にLWC＋Apexのコンポーネントを埋め込みます。（＝カスタムになってしまいます。）
※余談ですが、クレカ情報に関しては特殊で、セキュリティ要件が高すぎますので(PCI)、原則Salesforce内に持たない（PCIやトークン化は3rdPartyに任せる、トークン化した結果をSalesforceに持つケースはある。Shieldや暗号化と組み合わせてセキュリティ強化すること。）、3rdPartyにクレカ情報を渡す際にはサーバサイドのロジックは通さずクライアント処理を行う（3rdPartyが提供してくれる）など気を付ける必要があります。
２） レコードトリガフロー＋プラットフォームイベント（画面は標準画面）
即座に画面に結果を戻す必要がないのと、リアルタイム（＝実態としてはニアリアルになると思います。）に返す必要があるということで、Salesforceに申請情報が登録されたら、そのあとすぐに申請システムに申請情報を連携する必要があります。（なので、1日1回のバッチ処理などはダメかと思います。）
ソリューションとしては、Salesforceに申請情報が登録されると、レコードトリガフローが申請レコードの新規作成を検知し、申請情報を含んだプラットフォームイベントを生成します。（非同期なので、ここでトランザクションは終わり。）
ESBがリスンすると、申請システムのAPIをCallし、申請情報を登録／更新します。申請システムは必要に応じて後続処理を行います。
※基本的に「画面に即時に返す」などの記述がない場合、非同期のほうが良いと思われます。同期の場合、対向が障害でダウンしていた場合などSalesforceから申請情報が登録できなくなりますので業務が止まってしまいます。
※また、レコードトリガフロー＋プラットフォームイベントではなく、申請の登録をApexTriggerが検知し、非同期Callout（もしくはLWC＋ApexクラスのCallout）というのもできなくもないのですが、プラットフォームイベントみたいにバス(72時間データを溜められる)があるわけじゃないので、連携が失敗した際にリトライやエラハンがしづらくなることが予想されます。
※そもそも、標準とカスタムというソリューションを比較すると、カスタムの場合Salesforceのバージョンアップのために、保証されないので検証を細やかに行う必要もあるので、メンテナンス性などの観点からもApexよりは標準のプラットフォームイベントがいいでしょう。（コンフィグで設定できますので）
ガバナンス
以下、最低限頭に入れるべき知識です。
・開発手法について
ウォーターフォールなのか、アジャイルなのか、ハイブリットなのか問われます。
ポイントは、開発期日があるか（特定期間内に計画的に開発を終える必要があるか）、対向システムに影響するか、かと思います。
やはりXX月に開発を終わらせたい場合や、IFなど対向システムを巻き込むような開発の際には、柔軟性は低くなりますが、計画的に開発を進めていくウォーターフォールが適切と考えます。
一方、Salesforceの性質として他チームに関係なくアジャイル的に進められる個所ですと、画面開発かと思います。
お客さんに、Salesforce実機の画面イメージを見せて、フィードバックをいただき、ブラシュアップしていく進め方です。
ただ、データモデル事態まで変えてしまうと、対向のIFに影響が出たりしますので、大規模の場合はデータモデルを原則固定して、その上でUIUXに限定してブラシュアップするケースが多いかと思います。（実案件でも標準のUIは、実際に画面を実機で作り、フィードバックを受けて直してユーザビリティを上げていくアジャイル的な進め方をするケースが多いかと思います。）
ですので回答としては、
・期日が決まっており、対向チームに影響あるならウォーターフォールが奨励（工程が明確ですので品質もアジャイルより管理しやすいと思います。）
・ただし、画面はUIUXのユーザビリティ向上のためアジャイル的な進め方を奨励しており、ウォーターフォールとアジャイルのハイブリットを奨励
・仮に明確なリリース期日がなく、柔軟に進めたい、早期リリースを行いたい、よりユーザと議論しながら進めたい場合、アジャイルを奨励となります。（ただ、全体をアジャイルでやるプロジェクトは、やはりIFがあったり利用者が多いと厳しいものがありますので、おのずと小規模の案件に向いているかと思います。）
・以下用語は確実に抑えておく必要があります。（どんな人が何を目的に行うものか？）
エグゼクティブスポンサー、ステコミ、CoE、CCB（変更管理委員会）、PMO、データスチュアード
要件トレーサビリティ、課題管理、リスク管理、CI/CD（Apex自動テスト、PMD、自動デプロイ）
https://qiita.com/nori83/items/be3e22119339f16f6431
・品質を上げるための各工程ごとのテスト内容
以下が回答例となります。（自分の経験をもとに定義しておきましょう。）
UT・・・各機能のテストする。
ITA/B・・・機能間、システム間の連携をテストする。
ST/QA・・・シナリオテスト、運用テストなど一連の流れの行う。
UAT・・・要求通りに作られているかユーザ受入テストを実施する。
上記以外に、品質向上の施策として顧客との取り決め次第で、脆弱性テスト、性能テスト、CRが多い場合はリグレッションテストを実施。
※もちろんこれ以外に移行テストなど細かく話すといろいろあるのですが、ざっくり概要は話せるようにしたほうがいいかと思います。
サンプル問題です。
１）現在３か国で開発をしていますが、各国固有のルールで開発をしており、障害対応時に双方協力ができない状態となっています。
２）複数の国で開発を行っていますが、どうしても日本の収益が高く、日本チームの強気の要望ばかり取り入れられている傾向があります。
回答です。
１）CoEにて開発標準・コーディング規約を策定し、定着化を行うことにより、国に関わらず開発できるようにする。また併せて設計書のフォーマットを統一して展開も行う。
２）CR(変更管理・チェンジリクエスト)の場合、変更管理委員会(CCB)でのスケジュール妥当性やコストなど事前評価の上、取り込み可否を横断的に判断する。また必要に応じてエグゼクティブスポンサーにエスカレを行い、方針決定を仰ぐ。
※問題を読むと、なかなか抽象的で回答しづらいのですが、状況の前提を置き、回答をするといいと思います。認識に誤りがある場合はジャッジがフォローしてくださいます。