Salesforceカスタムオブジェクト完全ガイド：管理者向け徹底解説

日付:

背景と応用シナリオ

Salesforceは、Account (取引先)、Contact (取引先責任者)、Opportunity (商談) といった強力な Standard Objects (標準オブジェクト) を標準で提供しています。これらは多くの企業の営業、サービス、マーケティングの各プロセスをカバーするように設計されています。しかし、ビジネスは多種多様であり、その業界や企業独自のデータを管理する必要性が必ず生じます。

例えば、以下のようなシナリオを考えてみましょう。

不動産業

管理すべき「物件」情報を標準オブジェクトで管理するのは困難です。物件の住所、価格、面積、間取り、築年数といった独自の情報を格納するためには、`Property` という Custom Object (カスタムオブジェクト) が必要になります。

大学・教育機関

「学生」や「講座」の情報を管理する必要があります。学生の学籍番号、学部、入学年度や、講座の単位数、担当教員、開講キャンパスといったデータは、`Student` や `Course` といったカスタムオブジェクトで管理するのが最適です。

製造業

特定の「プロジェクト」や「製造設備」の管理が不可欠です。プロジェクトの予算、期間、担当チームや、設備の型番、購入日、最終メンテナンス日といった情報を追跡するために、`Project` や `Equipment` のカスタムオブジェクトを作成することが考えられます。

このように、Custom ObjectはSalesforceを単なるCRMツールから、ビジネス全体のニーズに合わせて拡張できる柔軟なプラットフォームへと昇華させるための根幹をなす機能です。Salesforce管理者として、この機能を深く理解し、適切に設計・実装する能力は非常に重要です。

原理説明

Custom Objectとは、端的に言えば「Salesforceプラットフォーム上にユーザーが独自に作成できるデータベースのテーブル」です。標準オブジェクトと同様に、レコードを格納し、他のオブジェクトとのリレーションを定義し、レポートやダッシュボードで分析することができます。カスタムオブジェクトを構成する主要な要素について解説します。

1. Fields (項目)

オブジェクトが作成されると、いくつかの標準項目が自動的に作成されます。

・Id: レコードの一意の識別子（15桁または18桁）。
・Name: レコードの名称。テキストまたは自動採番形式を選択できます。
・Owner: レコードの所有者（UserまたはQueue）。
・CreatedDate / LastModifiedDate: レコードの作成日時と最終更新日時。

これらに加えて、ビジネス要件に合わせて Custom Fields (カスタム項目) を作成します。Text, Number, Date, Checkbox, Picklist, Formulaなど、多様な Data Type (データ型) が用意されており、格納したい情報に最適な形式を選択することが重要です。

2. Relationships (リレーション)

オブジェクトの真価は、他のオブジェクトとの関連性を定義することで発揮されます。Salesforceには主に2つの強力なリレーションタイプがあります。

Lookup Relationship (参照関係)

2つのオブジェクトを緩やかに結合するリレーションです。例えば、「物件」カスタムオブジェクトと「取引先」標準オブジェクトを関連付け、「この物件の仲介不動産会社はどこか」を示すことができます。親レコード（取引先）が削除されても、子レコード（物件）は削除されません（オプションで変更可能）。セキュリティ設定や所有者は、親子で独立しています。

Master-Detail Relationship (主従関係)

2つのオブジェクトを緊密に結合するリレーションです。Detail側（従）のレコードは、Master側（主）のレコードが存在しなければ存在できません。例えば、「請求書」と「請求書明細」の関係がこれにあたります。「請求書」というMasterレコードが削除されると、それに関連する全ての「請求書明細」Detailレコードも自動的に削除されます（カスケード削除）。また、Detailレコードの所有者とセキュリティ設定は、Masterレコードの設定を継承します。このリレーションにより、Roll-Up Summary Fields (積み上げ集計項目) をMasterオブジェクトに作成でき、Detailレコードの集計値（合計、件数、最大、最小）を自動計算できます。

この2つのリレーションを組み合わせ、Junction Object (連結オブジェクト) を作成することで、多対多のリレーションシップを表現することも可能です。

3. Page Layouts (ページレイアウト) と Record Types (レコードタイプ)

Page Layouts は、ユーザーがレコードを閲覧・編集する際の画面構成を定義します。どの項目をどこに表示するか、必須項目にするか、読み取り専用にするかなどを制御します。

Record Types は、1つのオブジェクトに対して複数のビジネスプロセスやページレイアウトを割り当てるための機能です。例えば、同じ「サポートケース」オブジェクトでも、「製品に関する問い合わせ」と「請求に関する問い合わせ」では表示したい項目や選択できる状況（Status）の選択リスト値が異なる場合があります。このような場合にレコードタイプを使用します。

これらの要素を、Schema Builder (スキーマビルダー) という視覚的なツールを使って設計・確認することもでき、複雑なデータモデルを直感的に把握するのに役立ちます。

示例コード

Salesforce管理者は直接コードを書く機会は少ないかもしれませんが、データの確認や一括更新のために SOQL (Salesforce Object Query Language) を使用することがあります。SOQLは、Salesforceのデータベースからレコードを問い合わせるための言語です。以下に、`Project__c` というAPI参照名を持つカスタムオブジェクトからデータを取得する基本的なSOQLクエリの例を示します。

この `Project__c` オブジェクトには、プロジェクト名を格納する `Project_Name__c`、状況を管理する `Status__c`、そして取引先への参照関係を持つ `Account__c` というカスタム項目があると仮定します。 

// Developer ConsoleのQuery Editorなどで実行可能なSOQLクエリの例

SELECT
  Id,                       // レコードの一意のIDを取得
  Name,                     // プロジェクトのレコード名（自動採番など）を取得
  Project_Name__c,          // 「Project Name」というカスタム項目を取得
  Status__c,                // 「Status」というカスタム項目を取得
  Account__r.Name           // 参照関係(Account__c)を介して、関連するAccountオブジェクトのName項目を取得
FROM
  Project__c                // 「Project」カスタムオブジェクトからデータを取得
WHERE
  Status__c = 'In Progress' // 「Status」が「In Progress」のレコードのみに絞り込む
ORDER BY
  CreatedDate DESC          // 作成日が新しい順に並び替える
LIMIT 10                    // 最大10件まで取得する

コードのポイント：

・`__c` suffix: `Project__c` や `Status__c` のように、カスタムオブジェクトやカスタム項目のAPI参照名の末尾には `__c` が付きます。これは「custom」を意味し、標準のオブジェクトや項目と区別するための重要なルールです。

・`__r` suffix: `Account__r.Name` のように、リレーションを辿って親オブジェクトの項目を取得する場合、リレーション項目のAPI参照名の末尾を `__c` から `__r` に変更します。これは「relationship」を意味します。

このSOQLは、Salesforceの管理者としてData Loaderなどのツールでデータを抽出したり、Developer Consoleで特定のデータを素早く確認したりする際に非常に役立ちます。

注意事項

カスタムオブジェクトを設計・運用する際には、いくつかの重要な注意点があります。これらを無視すると、将来的にパフォーマンスの低下やメンテナンス性の悪化を招く可能性があります。

1. 権限とセキュリティ (Permissions and Security)

カスタムオブジェクトを作成しただけでは、どのユーザーもそのオブジェクトにアクセスできません。Profile (プロファイル) や Permission Set (権限セット) を通じて、オブジェクトレベルの権限（作成、参照、編集、削除）と、Field-Level Security (項目レベルセキュリティ) を明示的に設定する必要があります。誰がどのデータにアクセスできるかを厳密に管理することは、データガバナンスの基本です。

2. API制限とガバナ制限 (API and Governor Limits)

Salesforceには、プラットフォームの安定性を保つための様々なガバナ制限が存在します。カスタムオブジェクトに関しても、組織のエディション（Enterprise, Unlimitedなど）によって作成できる総数に上限があります。また、1つのオブジェクトに作成できるMaster-Detailリレーションの数（通常は2つまで）や、Roll-Up Summary項目の数にも制限があるため、設計段階でこれらの制約を考慮に入れる必要があります。

3. 命名規則 (Naming Conventions)

オブジェクトの Label (表示ラベル) は後から変更可能ですが、API Name (API参照名) は一度作成すると変更できません（※）。API参照名は、コードや数式、連携ツールなどで内部的に使用されるため、一貫性のある命名規則（例: `Project_Management__c` のように単語をアンダースコアで区切る）を組織全体で定めることが強く推奨されます。また、オブジェクトや項目の「説明(Description)」欄を必ず入力し、その目的を後から誰が見てもわかるようにしておくことが重要です。
※ 注意：API参照名の変更は技術的には可能ですが、多くの参照先を手動で修正する必要があり、多大な影響を及ぼすため、事実上「変更不可」と考えるべきです。

4. データ型の変更 (Changing Data Types)

項目のデータ型は、後から変更するとデータ損失を引き起こす可能性があります。例えば、「テキスト」型を「数値」型に変更しようとした際に、数字以外の文字が含まれているデータは失われます。項目のデータ型は、将来の利用方法をよく検討した上で、慎重に決定する必要があります。

まとめとベストプラクティス

Custom Objectは、Salesforceをビジネス要件に完璧に適合させるための、最も強力で基本的なツールです。標準機能では満たせない独自のデータ管理のニーズに応え、ビジネスプロセスを自動化し、より深いデータ分析を可能にします。

Salesforce管理者としてカスタムオブジェクトを成功させるためのベストプラクティスは以下の通りです。

・構築前の計画 (Plan Before You Build): いきなりSalesforce上で作成を始めるのではなく、まず要件を整理し、紙やホワイトボード、Schema Builderなどでデータモデルを設計図として描きましょう。どのオブジェクトが必要か、オブジェクト間のリレーションはどうあるべきかを明確にします。

・再作成せず、再利用する (Reuse, Don't Recreate): 新しいオブジェクトを作成する前に、既存の標準オブジェクトやカスタムオブジェクトが利用できないか必ず検討してください。オブジェクトの乱立は、システムの複雑化とユーザーの混乱を招きます。

・説明を提供する (Provide Descriptions): オブジェクトや項目を作成する際には、必ず「説明」欄にその目的や用途を詳細に記述してください。これは、将来の自分や他の管理者のための重要なドキュメントとなります。

・レポートを考慮する (Think About Reporting): データをどのように分析し、レポートやダッシュボードで可視化したいかを設計の初期段階から考慮に入れてください。必要なレポートが作成できるようなリレーションや項目設計が不可欠です。

・最小限から始める (Start with the Minimum): 最初から完璧なオブジェクトを作ろうとせず、まずは必要最小限の項目でリリースし、ユーザーからのフィードバックを元に反復的に改善していくアプローチが効果的です。

これらの原則に従うことで、スケーラブルで保守性が高く、ビジネス価値を最大化するデータモデルを構築することができるでしょう。

コメント

コメントを投稿