Salesforceの説明
Salesforceは単なるCRMではありません。本質は「業務アプリケーションを高速に構築・運用できるクラウドプラットフォーム」です。この認識がないと、設計も開発も必ずズレます。
まず従来のシステム開発と比較してみましょう。
■ 従来（オンプレミス）
・サーバー構築が必要
・DB設計、アプリ開発、インフラ運用が分離
・リリースに時間がかかる
■ Salesforce
・インフラ不要（完全クラウド）
・DB＋アプリ＋権限管理が一体化
・設定変更が即時反映
この違いにより、「開発の重心」が大きく変わります。
Salesforceではコードを書く前に設計で勝負が決まると言っても過言ではありません。
データモデルの本質：すべてはオブジェクト
Salesforceのコアは「オブジェクト」です。これはRDBでいうテーブルに相当します。
代表的な標準オブジェクト：
・Account（取引先）
・Contact（取引先責任者）
・Opportunity（商談）
・Lead（リード）
ここで重要なのは、「業務＝オブジェクト構造で表現する」という考え方です。
例えば営業プロセス：
リード → 商談 → 受注 → 契約 → 請求
これをそのままオブジェクトとして分解・設計します。
リレーション設計が8割
Salesforce設計で一番ミスりやすいのがここ。
Lookup（参照関係）
・ゆるい結合
・親が削除されても子は残る
・独立性が高い
Master-Detail（主従関係）
・強い結合
・親削除で子も削除
・ロールアップ集計が可能
判断基準はこれ👇
| 観点 | Master-Detail | Lookup |
|---|---|---|
| データ独立性 | 低い | 高い |
| 削除連動 | する | しない |
| 集計 | できる | 基本できない |
よくある失敗：
「とりあえずLookupにして後で考える」
→ 後からMaster-Detailに変更できないケース多発
→ 設計やり直し地獄
メタデータ駆動開発という思想
Salesforce最大の特徴はここ。
通常の開発：
コード = ロジック
Salesforce：
設定（メタデータ） = ロジック
例えば：
・バリデーションルール
・ワークフロー
・Flow
・レイアウト
これらはすべて「設定」で実現されます。
つまり：
👉 「できるだけコードを書かない」が正解
理由：
・保守が楽
・変更が早い
・非エンジニアでも触れる
ただし逆に：
👉 「設定で無理やりやる」のも地雷
→ 可読性崩壊
→ デバッグ不能
実務での最適バランス
現場でよく使う判断基準：
| 要件 | 手段 |
|---|---|
| 単純な分岐・更新 | Flow |
| 複雑なロジック | Apex |
| UI制御 | LWC |
| バリデーション | 設定 |
ガバナ制限という“見えない敵”
Salesforceはマルチテナント環境のため、リソース制限があります。
主な制限：
・SOQL：100回/トランザクション
・DML：150回
・CPU時間：約10秒
これが意味するのは：
👉 「雑なコードは本番で必ず死ぬ」
特に危険なのがこれ：
for (Account acc : accounts) {
Contact[] cons = [SELECT Id FROM Contact WHERE AccountId = :acc.Id];
}
これはSOQL ループ内実行で即アウト。
正解：
Map<Id, List<Contact>> contactMap = new Map<Id, List<Contact>>();
→ まとめて取得して処理
まとめ（ここ外すと全部崩れる）
・Salesforceは「開発基盤」である
・設計（特にリレーション）が最重要
・設定とコードの使い分けがカギ
・ガバナ制限を常に意識する