概要
Salesforceのテクニカルアーキテクト試験（事前試験）と同等量の問題に対して解説を行います。
デプロイメントについては事前試験の対象外であるため、言及していないです。
シナリオ
実際のシナリオ・問題は以下からダウンロードできます。
今回はEvaluationPracticeScenarioを利用しています。（あれ、日本語どこいった・・・）
本シナリオは、他のシナリオと異なり、「配布厳禁」など記述がなかったため例示として活用しています。
Patient Travel Support Foundation（英語）
それ以外のシナリオ（日本語）
問題を解く際の姿勢
CTA受験時には、受験者は「システムを提案する」という前提で進める必要があります。ですので、あいまいな問題であっても必ず1個自分の答えを持ち、前提や根拠を示す必要があります。前提理解が誤っていたり、説明が上手く伝わっていない場合、ジャッジのかたが質問（フォロー）してくれますので、まずは自分が考える前提を伝え、答えを1つに絞りましょう。
また、QAではジャッジのかたから質問を受けると思うのですが、意図としては、試験から落としたくて難しい質問をするのではなく、フォローするため・正しく採点するために質問をしてくださってますので、落ち着いて答えるとよいと思います。
回答・解説コメント
以降、問題に対して回答と補足コメントを記述しています。
回答
実際の試験などのでの回答はこちらに記述します。
補足コメント
実際はプレゼンで話すような補足や、問題に対する解説はこちらに記載します。
★免責事項★
・前提の置き方、最新の技術動向によって回答は変わりますので、あくまで自学習時の参考として捉えていただきたいと思います。
・ですます／てにおは等、色々適当ですが、その点はご了承ください。
Patient Travel Support Foundation解説
（１）パワーポイントでの作成物
（２）シナリオへのインライン回答
プロジェクトの概要
Patient Travel Support Foundation (PTS財団) は、遠隔地に住む人々（患者）が、地元では受けられない医療を受けられるように支援する非営利団体である。PTS財団は、患者の旅費（バス、電車、飛行機の運賃）を補助することで、患者の治療を支援しています。
⇒(コメント)今回の提案先はPTS財団。患者さんが医療を受ける際の、旅費を補助するらしいと理解。
PTS財団は、シンガポールに本部を置き、APAC、EMEA、AMERの各地域で活動している。PTS財団は、各地域に10のサテライトオフィスを持ち、特定の地域をカバーしている。これらのサテライトオフィスでは、旅行の申し込みを受け、承認し、予約を行う。
⇒(コメント)国を横断した地域がまたがっている前提のため利用者の言語や通貨が異なると考えられる。1組織にする場合、トランスレーションワークベンチの機能を使って、利用者ごとに言語を切り替えや、マルチ通貨を使って現地通貨で補助金額など表示など行い、多言語・他地域対応を行う。
また、各地域で補助金の申込みや承認を行うようだが、サテライトオフィスごとにバラバラな仕組みで作ると保守性が悪くなるので、標準化していく。
回答
Orgは1つの場合、複数地域への対応は、トランスレーションワークベンチやマルチ通貨を活用。
PTS財団は、設立から5年で350万人の患者を抱えるまでに成長した。現在のプロセスは、各サテライトオフィスでローカルに運用されている特注システムで管理されていますが、PTS財団は、現在のシステムとプロセスではこれ以上拡張できないことを理解し、適切なデータとプロセスをSalesforceプラットフォームに移行したいと考えています。
⇒(コメント)設立して5年で350万の患者。1テーブルに100万件以上のデータが格納されるため、LDV（大量データ）になるかと思われる。（ERに要反映。）
また、特注システムが地域ごとに何個もあって、それぞれ作りこみを行っており、拡張が難しい。明確にSalesforceに移行したいと書いているので、特注システムは廃止し、Salesforceへ移行する前提とする。移行の際には、プロセスの標準化、レコードタイプやレイアウトを使って地域差異を吸収する。
回答
⇒特注システムからSalesforceにデータ含めて移行が必要。プロセスの標準化を検討する。
（患者数は後段に500万人とあるためそちらの数字を使う。）
システムのユーザ
PTS財団には、以下のようなお客様やパートナーがいます。
回答
ライセンスで整理
- 患者：旅費交通費の補助金を申請する
⇒(コメント)患者さんは社外のユーザ。すくなくともこのシナリオは、商品の設置や保守業務を行うようなFieldServiceや、外部ユーザが顧客に対して営業するようなPartnerCommunity(PC)ではなさそうなので、ライセンスはCustomerCommunity(CC)か、CustomerCommunityPlus(CCP)になると思われる。
２． 4000 人の医師（Medical Practitioners）：候補者が医療を受ける資格があるかを評価する
⇒(コメント)医師も患者同様に、ライセンスはCCかCCPかと思われる。（医師が何か商品を設置したり、患者に販売したりしないので。）
3． PTS財団には、新システムを使用する必要がある、約500人の社内ユーザがいます。
⇒(コメント)社内ユーザは500人。
CTAの試験はファイルストレージ試算が必須だが、前提としてエンタープライズ向けの大型システムの提案なので、まず組織のEditionは、UnlimitedやPerformanceで前提を置くため、10GBとなる。加えて社員は1名あたり2GBの容量が付くので、ストレージ容量は全体で1,010GBになる。
４. 査定員（Assessor）：医療従事者（Medical Practitioners）からの補助金申請書や査定書を審査する
⇒(コメント)説明を読むに、何か商談や見積もりを行うような営業支援の業務ではなさそうなので、LightningPlatformや、ServiceCloudがライセンスとしてマッチしそうに見えるが、現段階、断定できない。
５. マネージャ（Manager）：査定員の世話をし、より高額な補助金の申請を承認することができる。また、ビジネスを運営するマネジメント層のサポートを行う
回答
高額申請は、承認プロセスの開始条件で分岐する。
⇒(コメント)マネージャーは査定員のお世話をするので、査定員以上のライセンスになる。
LightningPlatformや、ServiceCloudがライセンスとなる見込み。
また、経営層のサポートともあるので、アドホックな分析や、外部のデータをもとにした分析が必要なら、CRMAnalyticsも検討したい。（ただこの問題はレポート要件が書かれてないので決め手にならないが。）
高額申請については、承認プロセスを作る際に、（要件次第だが）ステップ、もしくは承認プロセス自体の開始条件で分岐する。（金額＞XX円ならば、このステップに入る。）
現在のシステム
俯瞰図に整理
- Travel Application Management System（TAMS）は、現在すべての補助金申請書を保存する特注のシステムです。このシステムは、各サテライトオフィスにローカルに配備されています。各サテライトオフィスは、独自のニーズに合わせてカスタマイズしています。
⇒(コメント)前述の通り、廃止してSalesforceに移行する。
- Web サイトでは、患者や医師がプロセスを理解するのに役立つ静的コンテンツ、ダウンロード可能なPDF医療評価フォーム、およびFAQを提供しています。
後段で、FAQや評価の入力はSalesforceに保持する方針とするため、廃止を行う。
⇒(コメント) Webサイトは、後段で、Communityからの直接申込みやFAQ確認を想定するため、機能移管となり廃止する。Webサイトを俯瞰図に明記し、廃止のためグレーアウト。データ移行が発生するため、WebサイトからETLを介してSalesforceにデータ移行する表記を行う。
- 各地域で個別の Active Directory インスタンスを管理しています。新しいシステムでは、適切なActive Directoryインスタンスを使用して内部ユーザーを認証する必要があります。
⇒(コメント)SAMLSSOを行う。IDストアとしてActiveDirectoryを俯瞰図に明記。IdpとしてAzureADも記述。オンプレとクラウド間の接続はAzureADConnectを利用。
（細かい要件がなかったので、いったんSP開始のSSOとしている。メールのリンクをクリックしてSSOなどの要件の場合、SP開始SSO。）認証フロー資料も更新。
- 健康保険チェッカー（Health Insurance Checker）は、グローバルなAPIサービスで、患者の健康保険の資格を確認します。便利なサービスですが、ピーク時には結果を返すのに15秒ほどかかることもあります。
⇒(コメント)保険チェッカーは、ピーク時に結果が15秒かかるということなので、同期処理(保険チェッカーへの確認依頼・結果取得までの一連の流れを待つ)の場合、利用者が最大15秒、通信を待機することになり、ユーザビリティが悪いと思われる。（ガバナ自体は累計2分なので落ちはしないが。）なので、非同期処理を行う前提とする。（非同期なので、即時に画面に結果は返ってこないが、保険チェッカーへのリクエスト依頼は実行できる。(依頼の完了はまたない。)）
※Amazonの注文やLINEのメッセージ送信でも、あとで「失敗しました」とメールや通知が来るケースがありますが、あれは非同期だからです。非同期とはリクエストを投げっぱなしで結果を待ちません。（といっても軽量なものなら基本ほぼリアルタイムで処理が行われる。）
一方同期は、銀行ATMの引き出しやクレカ決済のように、すぐに画面に結果が返ってきます。(画面上でぐるぐるマークが出て、「通信中です。ブラウザを閉じないでください。」と表示されている処理はだいたい同期化と思います。)
・俯瞰図に関して、大量データの移行やバッチ処理は、大量データ処理に強みのあるETLを活用する。
・システム連携は、ログの取得やエラーハンドリング、プロトコル変換、フォーマット変換、リトライ、ルーティングなどの機能を有するESBを活用し、原則システム連携にESBを挟むことにより疎結合のアーキにする。（小規模のシステムならポイントtoポイントの連携アーキで問題ないが、エンタープライズ向けで大量にIFがある際にシステム同士固有でIFをしてしまうと、処理が二重・冗長な処理が作られてしまったり、ログや認証も一元管理できない。）
ビジネスプロセス要件
患者の初期登録（Onboarding）
- 患者は、メールアドレスとパスワード、および Facebook を使ってアカウントを作成できる必要があります。
ソーシャルサインオン
OpenIDConnect。ソーシャルサインオンを選択。（認証資料に反映）
- 初回のログイン時には、オンボーディングウィザードを使用して、氏名、メールアドレス、生年月日、住所、使用言語、保険などの個人情報を入力していただく必要があります。
画面フロー
⇒(コメント)後段に同期連携処理があるため、ソリューションはLWC＋Apexか、画面フロー＋外部サービスになる。基本的に標準とカスタムなら標準ソリューションを奨励するため、画面フローを選択。
a. PTS財団は、健康保険チェッカーから返された属性を個人のプロフィールデータにあらかじめ登録したいと考えています。
IF、FF(ファイア＆フォーゲット、非同期)、返却結果はAccountに保持
保険チェッカーとのIF、最大15秒の待ち時間があるため、ユーザビリティを考えてファイア＆フォーゲット（非同期通信）を想定。
b. PTS財団は、患者が入力した物理的な住所を検証したい。
IF、リクエスト＆リプライ・同期処理、画面フロー＋外部サービス、3rdPartyの住所検証サービスを活用
c. オンボーディングプロセスが完了するまで、患者は補助金を申請することができません。
取引先への個人情報の登録が完了すると、レコードトリガフローが検知し、取引先のステータスを「申請完了」とする。
「申請完了」でない場合、取引先に紐づく申請レコードを登録しようとすると、入力規則でエラーを表示する。
d. 患者は、オンボーディングが完了した後、補助金申請プロセスを説明するウェルカムメールを希望する言語で受け取る必要がある。
Cで「申請完了」で変更後の処理で、メールアラートを送信。
言語ごとにVFテンプレートを定義し、Userの言語設定(=希望する言語)に応じて分岐する。
⇒(コメント)
＜前提＞取引先に保険チェッカーで返ってきた結果や、オンボーディングが完了しているかのステータスを保存する。
＜流れ＞
・利用者が画面フローで氏名や住所など入力
・「登録」ボタンをクリックすると、外部サービス(OpenAPI)を使い、3rdpartyの住所検証サービスへ郵便番号を引き渡す。患者の入力値と、住所サービスの住所がマッチした場合、画面上は「受付が完了しました」という画面を表示。（マッチしない場合は「都道府県が違います」とエラーで先に進めない。）
・マッチ／成功後、後続でレコード登録処理が動き、取引先(Account) に入力値を保存。また、保険チェックサービスと非同期通信するためのプラットフォームイベント生成。
・ESBはイベントをリスンすると、保険チェックサービスのAPIをCall。結果が返ってきたら、Salesforceの取引先のAPIをCallし、保険チェック情報を更新。
※詳細要件が書かれていないが、Userにもデータを保存する場合、設定系・非設定系で1トランにできない点注意。
以下、住所がマッチした後の超ざっくりの流れ。
ちなみに非同期の連携ソリューションとして、プラットフォームイベントではなく非同期のApexCallOutという手段もあるが、以下の点において、プラットフォームイベントのほうが優位である。
・イベントバス（72時間イベントデータを保持する）があるため、対向が障害で落ちていても72時間データを保持している。（ApexCalloutだとバスがなく、例えばSF-ESB間で障害が発生した場合、リトライが難しい。）
・一般論として、標準機能のほうがカスタマイズ難易度が低く、保守性も高い。(ApexCalloutはカスタム開発)
トラベルアシスタンスの依頼（Requesting Travel Assistance）
- PTS財団では、500種類以上の診療科目の渡航支援に対応しています。補助申請には、治療種別の選択、申請理由、既往歴などの情報が必要となります。
申請に、種別や理由項目を保持する。既往歴は複数あり、今後変更しうるものなので、別テーブルで保持する。
種別は複数の選択リストを定義し、連動させる。（500個からすべて選ばせるのは現実的ではない。マスタ持ちするとデータスキューの懸念あり。）
⇒(コメント)データスキューとは、所有者や親レコードに紐づく子レコードが1万件を超えると、データ登録や更新時に権限処理が走るため、パフォーマンス懸念を生じるというもの。対処としては所有者となるユーザにロールを付与しない（ロールの計算処理が走らないから）、最上位ロールを充てる（走る処理が少ない）、1万件以上紐づかないようにそもそもテーブル定義せず選択リスト化できるなら選択リスト化するなど。
２. 補助金申請の際には、患者様から提供された既往の既往歴情報を確認する必要があります。
既往歴テーブルを定義
⇒(コメント)既往歴は更新されていくものなので、申請テーブルとは別テーブルで定義する。（申請断面の既往歴情報がバックアップとして欲しいなどの際には、申請テーブルに対して既往歴をコピーする、もしくは審査中は情報が変わるとこまるのでロックする機能などあるとよいかと思われるが、今回はそこまで書かれていないので考慮しない。）
３. PTS財団は、患者が加入している健康保険に、旅費が保険金として支払われるかどうかを確認する。健康保険者が旅費をカバーしている場合、補助金申請は自動的に却下される。
⇒(コメント)前提として、前段のオンボーディングで取引先（Account）に保険金情報を保持している前提となる。
承認プロセスの申請時に、保険をカバーしている場合、自動却下とする。
４. 補助金申請書が作成されると、その治療タイプに登録されている医療従事者が自動的に割り当てられるようにする。割り当ては、医療従事者の診療所と患者の住所の間の最も近い距離に基づいて行われるべきです。
Apex。申請レコードが登録されると、治療タイプと、医療従事者（取引先に病院のAddressを保持前提）の住所情報をもとに最短距離の医療従事者を担当者として紐づけ
⇒(コメント)申請レコードの所有者に医者を割り当てることも案として挙げられると思いますが、後段で、申請に対して医者は複数名付けられるデータモデルとあるため、申請と取引先責任者の中間テーブル「医師の割り当て」を定義することが正解かと思われる。
※メインの医者を所有者、追加の医者（専門の人）を中間テーブルで紐づけるやりかたもあると思います。ただレポートとか色々複雑になるので、一旦はすべて「医師の割り当て」レコードを生成する方針で後段の記述を進める。
⇒割り当て処理ですが、レコードトリガフローも対処として考えられると思いますが、緯度経度の計算・リスト比較など複雑な処理があるためカスタムロジックが適切と考える。標準のリードやケースの割り当てルールも、カスタムオブジェクトのため不適切となる。
Apexでは緯度経度で比較するためのdistanceメソッドが用意されている。
https://developer.salesforce.com/docs/atlas.ja-jp.apexcode.meta/apexcode/apex_class_system_Address.htm
※現状はApexが優位だが、レコードトリガフローはバージョンアップがよく行われるため、最新はHelpなど確認
５.医療従事者は、患者の評価が必要であることを通知され、3営業日以内に申請を受け入れなければなりません。応答がない場合、または医療従事者が評価を拒否した場合、システムは同じ割り当てロジックを使用して別の医療従事者に再割り当てしなければなりません。
評価は、申請に対して複数回行われる可能性があるため、申請とは別テーブルで定義する。
申請と医者の中間テーブルにレコードが生成されると、レコードトリガフロー(Apexに混ぜたほうが綺麗かも？)が検知し、医者に対してカスタム通知を送る。（医者はMPを利用する前提とし、モバイルで通知を受け取ることができる。）
拒否された場合、レコードトリガフローで検知し、再度Apexクラスを呼び出す。（すでに指定された医者は除外し、再度緯度経度／割り当ての計算。）
3営業日以内の応答判定は、レコードトリガフローのスケジュール済みパスで行い、3営業日経ってもステータスの変更がなければ、上記同様Apex処理を呼び出す。
営業日判定は、標準の休日テーブルを利用する。
⇒(コメント)
・Apexクラスはフローから呼び出しが可能。（バッチは確かInvocable不要。トリガも。）
https://developer.salesforce.com/docs/atlas.ja-jp.apexcode.meta/apexcode/apex_classes_annotation_InvocableMethod.htm
・営業日は、「休日」テーブルの利用を想定しているが、国ごとの祝日など管理しづらい場合、カスタムオブジェクトも検討する。
・モバイルでは何を使うかを必ず問われるため、選択したモバイルツールとその根拠を説明する必要がある。
（１） Salesforce標準アプリ⇒無料のアプリで社員向けなので、顧客は使えない。
（２） ブラウザからのアクセス(HTML5)⇒社外ユーザのみ利用可能。WebブラウザからLightningのSalesforce画面にアクセスできる。ただしブラウザなのでプッシュ通知など受けられないため、通知やオフライン要件があるならお勧めしない。
（３） モバイルパブリッシャー(MP)⇒一定ブランディングもでき、プッシュ通知など受け取れる。カスタマイズはLightningビルダーで行うことができ、LWCなど埋め込むことができる。オフライン要件は×のはず。
（４） ハイブリッドアプリ⇒ブルートゥース、NFC、AR、大きなキャッシュなど特殊要件がある際に適している。コルドバなど使い、画面はHTMLで構築。ネイティブより工数が低い。
※クックパッドがハイブリットアプリなので、ぜひインストールして、モバイルアプリとWebで比較してみてください。
（５） ネイティブアプリ⇒ハイブリットより自由度高く細やかなUIUXの定義が可能。速度もWeb通信でないため、ハイブリットより早い。コストも当然高い。
（６） FieldServiceアプリ ⇒フィールドサービスでないので、選択肢にならない。（オフライン作業、位置情報や顧客宅までの経路、1日の作業が表示されるデイビュー、作業後のサービスレポート表示や指でのサイン、バーコード読み取りなどの要件がある場合。主に設置業者が使う。社員も使える。）
- 患者や医療従事者が質問や問題を抱えている場合、PTS財団の評価者とプロセス中にチャットできる機能を希望する。 また、一般的な質問に対するサポートリクエストを回避する方法があれば教えて欲しい。
ケース、チャット(デジタルエンゲージメント)、顧客数も多く、効率化を目指し、スキルベースのオムニチャネルルーティングを行う。一般質問についてはFAQ、EinsteinBotを活用する。
⇒(コメント)
・試験前にはServiceCloud周りなど新しいライセンスや機能が出やすのでキャッチアップすることをお勧めします。
チャットやSMS通知は直近デジタルエンゲージメントに含まれているらしいです。（？）
・チャットという言葉からChatterを連想された方もいるかもしれませんが、たぶんリアルタイムのやり取りをしたいという要件かと面ますので、デジタルエンゲージメントのチャットや、内部向けの要件ならSlackなどが正しい回答になるかと思います。
・EinsteinBotやコミュニティへのFAQ設置により、顧客がセルフで不明点を検索できるようにしましょう。（業務効率化）
・今回顧客数が3800万人もいますので、顧客から大量にチャットの問い合わせが来ることが予想されます。自動でスキルや地域(言語、専門性)、応答状況に応じてルーティングしたほうが効率的です。なのでスキルベースのオムニチャネルルーティングを行います。
患者評価と補助金申請承認
（Patient Assessment and Subsidy Application Approval ）
１. 現在、医療従事者は、ウェブサイトから適切な医療アセスメントフォームをダウンロードし、患者を評価した後、記入したPDFを電子メールでPTS財団査定員に返送している。ほとんどのフォームは電子的に記入されるが、一部のフォームは印刷して手書きで記入した後、スキャンしてシステムに手入力する。PTS財団では、このようなエラーが起こりやすいプロセスを改善したいと考えている。
⇒効率化のため、直接SalesforceのCommunity画面から申請情報を入力してもらう。
※どうしても紙運用がなくしきれないなら、OCRの導入など検討
⇒(コメント)基本的に紙で申込書を記入したり、紙で申請を回している場合には、電子化(効率化)を提案します。
２. 評価が医師に割り当てられてから15日経っても「保留」のままの場合、システムは医師をフォローアップするチームマネージャーにエスカレーションすべきである。
⇒レコードトリガフロー、スケジュール済みパス、15日経過でマネージャーにメールアラート
⇒(コメント)私は申請オブジェクトをカスタムオブジェクトとして定義しましたが（問い合わせとは性質が違う気がしたので）、ケースオブジェクトと仮定した方は、ケースのエスカレーションルールがソリューションになるかと思います。
３. 開業医は、患者の特定の側面を評価するために追加の専門家を必要とする場合があり、補助金申請の ために追加の評価を要求できるようにすべきである。
⇒中間テーブルを用意、複数人の医師を、申請に紐づけられるようにする。
⇒(コメント)上記問題から中間テーブルが必要と判断。
４. 補助金申請が承認された場合、査定者は交付された補助金の額を入力する。システムは、移動距離と予想される交通手段（航空機、列車、タクシーなど）を考慮して、査定者が適切な補助金額を決定するのに役立つはずです。
⇒参考補助金額、という金額項目を定義する。
補助金承認のタイミングで、FF、レコードトリガフロー、プラットフォームイベント生成。
ESBはリスンすると補助金を算出する3rdPartyシステムのAPIをCall。
ESBはSalesforceの申請APIをCallし、参考補助金額を更新
補助金が承認されたら、申請レコードのステータスを「承認」に変更。（承認プロセス）
レコードトリガフローで、ステータス変更を検知し、プラットフォームイベントを生成。（非同期）
ESBがイベントをリスンすると、補助金額を算出する3rdPartyのAPIをCallし、結果を取得します。
非同期なので、トランザクションはイベント生成処理で切れており、再度ESBからSalesforceの申請レコードのAPIをCallし、補助金の参考額をUpdateします。
※尚、今回補助金申請や住所検索に3rdPartyのシステムを活用していますが、自社のオンプレで構えるよりも、メンテナンスが不要になったり、新機能が追加される可能性があったり、短時間に導入できるため、3rdPartyとしました。オンプレのほうが自由度があってセキュリティも高いですが、今回の要件だと3rdPartyで充分かと思います。
データ要件
１. PTS財団は、500万人の患者を地域ごとに均等に抱えており、今後5年間で毎年50％の成長を見込んでいる。毎年、平均して総患者数の20％が補助金を希望している。
⇒患者は5年で3,800万程度、毎年の補助金申請は20％のため年760万件程度を想定。LDV。
２. 既存の患者、補助金申請、評価をすべて新システムに移行すること。
⇒初期データ移行を行う。
⇒(コメント)初期データ移行では、患者数などデータが大量データになりますので、大量データの移行における対処を語る必要があります。
・＜外部でのデータクレンジング＞患者データなどは支社ごとに特注システムがある場合、重複していたりフォーマットが違ったり、誤ったデータで入っているケースがあるでしょう。重複排除ツールやjavaでロジックを組み、氏名や電話番号などで重複排除を行い、フォーマット変換、抜けている値を保管、外部のマスタと比較して正しい値をセットなどします。
（Salesforce内での大量データの処理は奨励されませんので、Salesforceの外部でやったほうがいいでしょう。）
・＜外部IDの指定＞また、例えば顧客データを登録した後に紐づくデータをアップロードする際に、外部IDが指定されていないと、一度登録した顧客データをExportして、SalesforceIDを取得する必要があり、移行作業が煩雑になりますので、外部IDは必ず指定して移行しましょう。（実際にはリレーションが多いと外部IDが使えなかったりいろいろあるのですが・・・）
・＜BulkAPIを使ってのデータ投入＞大量データは、投入パフォーマンスの良いBulkAPIで投入しましょう。
・＜ロジックOff/共有適応の遅延＞Salesforceへ大量データを取り込む際に、複雑な処理が組まれていると、投入に長期で時間がかかることが予想されます。ですので、あらかじめSalesforce外部に処理を寄せて投入時にはSalesforceのロジック（トリガやフロー）をOffにしたり、権限ロジックである共有処理の適応を遅延させて、データ投入完了後に共有処理を再実行するなど工夫が必要となります。
３. 既存の補助金申請は現行システムで完了させるべきであり、申請プロセスは平均1ヶ月で完了する。
⇒段階移行を行う。初期では完了のみ移行、1か月後に残りの申請を差分移行。（すべて完了になるため）
可視性とアクセス要件
１. 医療従事者は、自分が担当している補助金申請に関連する患者のすべての評価を見ることができます。
申請と評価は主従関係（申請を見ることができれば、必ず評価が見える。）
⇒(コメント)申請と評価のレコード権限は連動していると読み解いた。（今回この文章しかないので、前提を置く。）
２. 医療従事者は、補助金申請書に記載されている患者の氏名、電話番号、電子メール、および必要なサービスに関する患者の説明のみを見ることができます。
項目レベルセキュリティで、参照可能な項目を限定する。
⇒(コメント)レコードの権限とは別に、レコード上の項目について1個1個、見えるか見えないか編集できるかプロファイルや権限セット上で指定できます。ここは特定項目のみ見れるということなので、項目レベルセキュリティ（FLS＝FieldLevelSecurity）が妥当と考えました。
３. 医療従事者は、評価が割り当てられた補助金申請が行われている期間中、患者の既往歴を見ることができます。PTS財団内部のユーザーは、一切の既往歴を見ることができません。
Apex共有。申請に複数医師が紐づくため、共有セットやロールは使えない。
⇒(コメント)外部ユーザが使える権限機能は、基本的に、プロファイル、ロール、共有セットになります。（細かくいうと共有ルールやテリトリ、取引先データ共有とかスーパーユーザとかいろいろありますが・・・）。プロファイルはテーブル・オブジェクトに対して見えるか否かなので、粗すぎます。ロールは、下位のユーザが所有するデータが、上位ユーザが見えるということで、ユーザベースのコントロールになるのでマッチしません。共有セットは、医師が申請に対して1名であればマッチしたのですが、今回複数名紐づくので、中間テーブルで申請と医師をマッチさせるとなると、共有セットでは要望に対応できません。ですので標準機能だと対処が厳しく、ここではApex共有となります。（医師と申請の紐づきが登録されたら、Apexトリガで申請に対してShareを付与し、医師の割り当てが削除されたら、Shareを削除。）