当時の判断と、その時々の理由
当時の私は、FSCの公式ドキュメントや多くのベストプラクティス系の記事を読み込み、「金融機関の個人顧客はPerson Accountで表現するのが最もシンプルで標準的である」という確信を持っていました。既存システムでは、個人顧客はカスタムオブジェクト、または標準のAccountオブジェクトを「法人ではない個人」と見立てて利用しており、その関係性はカスタムリレーションオブジェクトで表現されていました。これをFSCに移行するにあたり、
- Person AccountはAccountとContactの両方の特性を併せ持つため、既存の「個人情報」と「契約主体情報」を一つのオブジェクトで管理できるという合理性。
- FSCのHouseholdやFinancial Account Roleといった機能が、Person Accountを前提としているかのように見えたこと。
- 将来的な標準機能の拡張やアップグレードを考えた際、極力標準データモデルに準拠すべきというアーキテクトとしての信念。
これらの理由から、迷わずPerson Accountを主要な個人顧客表現として設計に組み込みました。具体的には、既存の個人顧客レコードはPerson Accountとして移行し、それに紐づく様々な金融商品契約をFinancial Accountとして管理する、という絵を描きました。
後から「やらなければよかった」と思った設計：Party Recordとの乖離
しかし、これが後々大きな後悔へと繋がりました。特に頭を悩ませたのは、FSCのコアコンセプトの一つである「Party Record (Account-Contact Relationship)」との整合性でした。Person Accountを採用したことで、
- Party Recordの必要性の見落とし: Person Accountはあくまで「個人として取引するAccount」です。しかし、FSCが真に意図しているのは、AccountとContactという基本的なデータモデルを基盤とし、それらの間に多対多の関係性を「Account-Contact Relationship（Party Record）」で表現する、というアプローチでした。私はPerson Accountがその多くを吸収してくれると誤解していました。
- 複雑なリレーションシップの表現不足: 金融機関では、「顧客」が世帯の代表者でありながら、個別の契約者でもあり、時には未成年者の保護者や代理人である、といった多面的な役割を持ちます。Person Accountだけでは、これらの複雑な多対多の関係性を十分に表現できませんでした。例えば、あるPerson Accountが複数のHouseholdに属する場合や、複数の金融商品で異なるロールを持つ場合など、Person Account単体では破綻することが判明しました。結局、Additional Party Roleといった関連オブジェクトや、さらなるカスタムオブジェクトで無理やり対応せざるを得なくなりました。
- データ移行のロジック複雑化: 既存システムからのデータ移行においても、Person Accountの特性が足枷となりました。Person Accountは内部的にはAccountレコードの一種でありながら、Contactレコードも自動的に作成されます。既存の「個人」データが、Account的な属性とContact的な属性を混在させていたため、どちらを主としてPerson Accountにマッピングし、どちらをContactにマッピングするかという判断が難航しました。特に、既存データで個人に複数のメールアドレスや電話番号があった場合など、どの情報をPerson Accountの直接的なフィールドにマッピングし、どの情報を関連オブジェクト（例: Person Email）に移動させるかで、移行スクリプトが肥大化しました。
当時の私は、Person Accountを「個人顧客の万能薬」のように捉えていましたが、実際にはFSCが提供するRelationship ReciprocityやGroup、Householdの概念と、Account-Contact Relationshipが織りなすParty Modelの全体像を深く理解していなかったのだと痛感しました。
今なら別の選択をする
もし今、FSCで個人顧客のデータモデリングを再設計する機会があるなら、私はPerson Accountの採用にはより慎重になります。まず、
- 標準Account/ContactとAccount-Contact Relationshipを基盤とする: 基本的には標準のAccountオブジェクトを「法人」や「世帯（Household）」、Contactオブジェクトを「個人」として利用することを第一に検討します。そして、これらの間の複雑な関係性をAccount-Contact Relationship（FSCではParty Record）で構築します。FSCの多くの標準機能は、このモデルを前提としているからです。
- Person Accountは「真に個人が取引主体となるアカウント」に限定: Person Accountは、本当に「個人が直接的な契約主体として、法人と同等の振る舞いをする必要がある」場合にのみ採用を検討します。例えば、自営業者で個人名義と屋号名義を使い分けるケースなど、非常に限定的なユースケースに絞り込むでしょう。
- FSCのグループ化機能を最大限活用: HouseholdやGroupといったFSC独自のグループ化機能を、個人顧客の関係性表現の中心に据えます。これにより、Person Account単体で無理やり表現しようとしていた多対多の関係性や、世帯全体の情報をより自然に管理できるはずです。
- データ移行前の徹底的な要件定義: 既存データの「個人」が、FSCのどのオブジェクト（Account、Contact、Household、Person Account、Party Record）のどのロールにマッピングされるべきかを、データクレンジングと同時に詳細に定義します。特に、FSCのFinancial Account RoleやParty Roleが既存の契約関係とどう紐づくかを、Person Accountの有無にかかわらず、徹底的に洗い出します。
当時の私は「FSCの推奨はPerson Account」という表面的な情報に囚われすぎて、その裏側にあるデータモデルの真髄を見落としていました。結果として、システムの柔軟性が損なわれ、後からの改修コストが増大したという苦い経験です。これは当時の自分向けのメモだと思って、書き残しておきます。
コメント
コメントを投稿