①スクラッチOrg VS Developer
開発時にはDeveloperを奨励。
スクラッチはコマンドベースで環境構築もできるが、30日で消える環境で、構築当初まっさらな環境。
主に新しい技術などのテストや検証目的が適しており、長期の開発にはDeveloperのほうが向いていると考える。
②オムニチャネルとは？ServiceCloudVoiceとは？
ServiceCloudVoiceは、設定ベースで開発ができ、機能としてはオムニチャネルやCTI（=AmazonConnect、IVRなども対応）、音声テキスト化による作業時間短縮、Einsteinの奨励回答による応答時間短縮、オムニチャネルスーパーバイザーなど機能を内包している。
ServiceCloudVoiceを適応する場合、設定ベースでCTI（=AmazonConnect）と連携可能。以前はAppExchangeなどからOpenCTIを落としてSalesforceのコールセンターに読み込むなどの対応が必要だった。（ちなみにServiceCloudVoiceは、AmazonConnect以外のCTIを使うことも勿論可能。）
▽ServiceCloudVoiceの設定
https://base.terrasky.co.jp/articles/KRS2u
▽ServiceCloudVoiceの主要概要
オムニチャネル自体は、複数のチャネル（メールやチャットなど）からの問い合わせを一元管理し、各担当者のプレゼンスやスキル、業務量に応じたルーティングを行う機能。
▽ServiceCloudVoice
https://www.salesforce.com/jp/products/service-cloud/solutions/call-center-management/
▽オムニチャネルの設定
→スキルベースがコーディングになっているので少し古い。今は設定ベースでオブジェクトと項目値に応じたスキルの優先度策定が可能。
※リードやケースの割り当てルールは使ってないようです。（念ため問い合わせ中）
③マルチオルグの際に、資源が二重になるが、同資源管理やリリースを実施するか？
要件次第だが、Org間で多少は資源が異なるので、基本的にGitのプロジェクトは分ける。SandboxもOrgが違うから当然分かれる。（GitやJenkins自体は1つかもしれないが、実施のタイミングなどは分ける）
共通機能への影響・修正などがあった際にも、基本的には片方でまずは開発テストなど行い、もう片方に資源を渡し、同様にテスト・影響有無・動作検証など実施。
④代理管理の機能、具体的に？→ユーザの作成・有効化、編集、無効化、PWリセットなど
⑤プラットフォームイベントの技術
→昨今はPubSubAPIでSubscribe/Publish可能（以前はCometDを使ってストリーミングAPIでSubscribe、PublishはRESTAPIなどで実施）
▽20:35あたり
⑥要件トレーサビリティのメリット
→要件トレーサビリティとは、要件と設計書や資源、テストなどをマッピングしたもので、品質向上（抜け漏れ確認）や変更があった際の影響確認などに寄与する
⑦CoEとは？
→技術に限らずベストプラクティスや標準化を行い、組織のパフォーマンスや効率向上を目的としたチーム。