Salesforceの設計力
Salesforceで一番差が出るのは「設計力」です。
正直ここミスると、どんな優秀なエンジニアでも詰みます。
ステップ1：業務を分解する
いきなりオブジェクト作るのはNG。
まずやるべきはこれ：
・業務フローを書き出す
・登場する“モノ”を洗い出す
・それをオブジェクト化する
例：受注管理
・顧客
・商品
・注文
・注文明細
👉 これがそのままオブジェクトになる
ステップ2：正規化を意識する
ありがちなミス：
「全部1オブジェクトに詰める」
→ データぐちゃぐちゃになる
悪い例：
注文オブジェクトに商品1〜10まで項目作る
良い例：
・注文（親）
・注文明細（子）
ステップ3：項目設計の原則
型は絶対に正しく選ぶ
| データ | 正しい型 |
|---|---|
| 日付 | Date |
| 金額 | Currency |
| フラグ | Checkbox |
NG例：
日付をTextで保存
→ 並び替え不可
→ 集計不可
→ 地獄
必須項目は最小限
初心者あるある：
「全部必須にする」
→ 入力できない
→ ユーザーが嫌う
基本ルール：
👉 必須は“本当に業務に必要なものだけ”
命名規則は命
おすすめ：
・API名は英語＋スネークケース
・ラベルは日本語OK
・略語は禁止
例：
customer_contract_start_date__c
ステップ4：将来変更を前提にする
設計は必ず変わる。これ前提。
だから：
・拡張しやすい構造にする
・ハードコードしない
・選択リストを活用
ステップ5：レコードタイプ設計
用途：
・同じオブジェクトで複数業務を管理
例：
・法人顧客
・個人顧客
レコードタイプで分けることで：
・画面
・必須項目
・選択肢
を変えられる
よくある失敗パターン
① Lookupだらけ
→ データ構造が崩壊
② 項目乱立
→ 何が何かわからない
③ 命名カオス
→ 誰も触れない
④ 拡張不可設計
→ 改修コスト爆発
実務チェックリスト
設計レビューで見るポイント：
・オブジェクト分割は適切か？
・リレーションは正しいか？
・項目型は適切か？
・命名規則は統一されているか？
・将来変更に耐えられるか？
まとめ
・設計＝プロジェクトの成否
・正規化は必須
・型と命名が品質を決める
・将来変更を前提に設計する