私が当時考えたこと：「Individual Account + カスタムオブジェクトで世帯を表現」
まず、個人顧客はSalesforceのPerson Accountが最適。FSCではこれをIndividual Accountというレコードタイプで提供している。ここまでは間違いない。
問題は「世帯」の表現でした。FSCには「Household」というAccount Record Typeが用意されていますが、これはB2Cの個人顧客そのものではなく、あくまで「グループ」としてのAccountです。私は当時、Accountレコードが増えることによるシステムの複雑化や、従来のSalesforceのB2Cモデル（Person Account中心）との乖離を懸念しました。
そこで、私は「Individual Accountを顧客の中心とし、世帯はカスタムオブジェクトで表現する」という設計を提案しました。
- Individual Account (Person Account): 各個人顧客のMasterレコード。氏名、連絡先、各Financial Account（証券口座など）を紐付け。
- Custom Object「Household__c」: 世帯名、世帯主、世帯内のFinancial Accountの集計値などを保持。各Individual AccountからはLookupでこのHousehold__cに紐付ける。
- Individual Account間の関係性: 同じHousehold__cに属するIndividual Account同士を、別途Junction Objectなどで「家族関係」を表現するか、FSC標準のContact-Contact Relationshipを使うか検討しました。
なぜこんな設計を選んだのか。 当時、Salesforceの標準機能を最大限に活用しつつ、余計な複雑性を持ち込みたくない、という思いが強かったのを覚えています。特に「世帯」という概念を、Accountレコードの多重利用のように感じることに抵抗がありました。Individual Accountが顧客の本体であり、それらを“まとめる”ための概念として、Accountではない別のオブジェクトが望ましい、という直感があったのです。
後から「やらなければよかった」と思った設計のポイント
この設計は、いくつかの点でプロジェクト後半に大きな後悔を生みました。
-
Rollup Summary Fields (RSF) の課題:
FSCは、世帯全体の金融資産合計や負債合計などを集計する標準のRSFを多数提供しています。しかし、私の設計ではIndividual Accountに紐づくFinancial Accountを、さらにカスタムオブジェクトであるHousehold__cに集計する必要がありました。
これは、FlowやApex Triggerで自前で実装するしかなく、以下のような問題が発生しました。
- パフォーマンスボトルネック: Financial Accountの数が多いと、更新時に連鎖的なトリガーが走り、ガバナーリミット（特にSOQLクエリやDMLステートメントの制限）に抵触しやすくなりました。特に、複数のFinancial Accountが一括で更新されるバッチ処理などでは、頻繁にエラーが発生し、再設計を余儀なくされました。
- 実装の複雑性: カスタムRSFのロジックは、Financial Accountだけでなく、AssetやLiabilityといったFSC固有のオブジェクトの階層構造も考慮する必要があり、コードが非常に複雑になりました。途中でFSCの標準RSFが計算しているスコープやロジックとの整合性を取るのに苦労しました。
- メンテナンスコスト: FSCのバージョンアップや新しいFinancial Services Cloudの機能が追加されるたびに、自作のRSFロジックを見直す必要がありました。
- Relationship Map の活用不足: FSCの目玉機能の一つであるRelationship Mapは、Account間の関係性やContact間の関係性を視覚的に表現するのに非常に強力です。 私の設計では、Individual Accountが中心であり、世帯はカスタムオブジェクトに紐づいているため、このRelationship Mapを世帯全体の構造把握に使うことができませんでした。 「誰が世帯主で、誰がその配偶者で、誰が子供か」といった世帯内の関係性を一目で把握するには、Relationship Mapの恩恵をフルに受けるべきでした。しかし、カスタムオブジェクトを経由した関係性では、標準のRelationship Mapが期待通りに動作せず、結局、別のカスタムコンポーネントを開発する羽目になりました。
- ユーザー体験の複雑化: Salesforceユーザーにとって、顧客情報が「Individual Account」と「Household__c」の二つのオブジェクトに分かれて管理されていることは、直感的な理解を妨げました。 「この人の世帯情報を見るには、まずIndividual AccountからHousehold__cに飛んで…」という操作導線は、Salesforceの単一ビューの原則から外れていました。
今なら別の選択をする：Household Accountを基盤としたFSC標準モデル
今なら、迷わずFSCが想定している「Household Account (Record Type: Household)」を軸にした設計を採用します。
- Household Account (Record Type: Household): これを「世帯」のメインの入れ物として定義します。世帯名や世帯の集計値（FSC標準RSFを活用）はここに保持させます。
- Individual Account (Record Type: Individual): 各個人顧客のMasterレコードとして、既存のPerson Accountと同様に利用します。そして、このIndividual Accountを、適切な関係性（例えば「世帯メンバー」）でHousehold Accountに紐付けます。FSC標準の「Party Relationship Group」オブジェクトや「Account-Account Relationship」機能を使って、この紐付けを行います。
- Party Relationship Group & Party Relationship: 世帯内のメンバー間の関係性（例: 「妻」「夫」「子」「父」など）は、このFSC標準オブジェクトで詳細に定義します。これにより、Relationship Mapが世帯全体の人間関係と金融口座の関連性を視覚的に美しく、かつ直感的に表示できるようになります。
この設計であれば、FSCが提供するRollup Summary Fieldsを最大限に活用でき、集計ロジックの自前実装に伴うパフォーマンス問題やメンテナンスコストから解放されます。また、Relationship Mapという強力なツールを世帯管理の根幹に据えることで、営業担当者やアドバイザーは顧客の全体像をより早く、深く理解できるようになります。
当時の私は、「Accountオブジェクトをグループの入れ物として使う」という発想が、一般的なSalesforce設計の固定観念に邪魔されていたのだと思います。FSCは「金融機関向け」の特殊な機能セットであり、そのデータモデルの意図を深く理解することが何よりも重要だと痛感しました。
「シンプルに保ちたい」という思いは正しいが、それがFSCの設計思想と乖離している場合は、結果として複雑性を生む、という典型的な例でした。
これは当時の自分向けのメモだ。
コメント
コメントを投稿