取引先と案件のデータモデル設計：1対1の紐づけが破綻するケースと対処
CRMやSFAを構築する際、取引先と案件を1対1で紐づける単純な設計では対応しきれない業務が出てくることがあります。データモデルが破綻する典型パターンと、設計時に押さえておきたい考え方を解説します。
「取引先マスタと案件を1対1で紐づけていたら、途中で管理しきれなくなった」——CRMやSFAの設計・運用を担当する方から、こうした相談を受けることがあります。取引先ごとに案件を1つずつ紐づけるシンプルな設計は、事業の初期段階では問題なく機能しますが、取引が拡大し、部門や担当窓口が複数に分かれるようになると、データモデルの前提が崩れ、無理やりデータを詰め込むような運用になってしまいがちです。
このようなデータモデルの破綻は、システム導入後しばらく経ってから顕在化することが多く、気づいた時にはすでに大量のデータが蓄積されており、修正のハードルが高くなっているケースも少なくありません。
この記事では、取引先と案件の1対1紐づけが破綻する典型的なパターンと、設計段階で押さえておきたい考え方を解説します。
この記事の要点（30秒でわかるまとめ）
- 取引先と案件を1対1で固定する設計は、取引構造が複雑化すると破綻しやすい
- 破綻の典型パターンは複数拠点・複数部門との取引やグループ会社間の取引
- 対処の基本は、取引先を「階層構造」として持たせる設計への見直し
- データモデルの見直しは、既存データの移行方針とセットで検討する必要がある
1対1紐づけが破綻する典型パターン
結論：取引先と案件の1対1紐づけは、取引先が複数の拠点・部門を持つようになったり、グループ会社間で取引が発生したりすると、実態を正しく表現できなくなります。
例えば、ある取引先の本社と支社が別々に発注してくる場合、同じ取引先名でありながら実質的には異なる担当者・異なる商流の案件が発生します。1対1のデータモデルでは、この違いを表現する手段がないため、担当者名や拠点情報を案件側の自由記述欄に書き込むような運用でしのぐことになり、集計や検索の精度が下がっていきます。また、グループ会社間で取引先をまたいだ案件が発生するケースも、単純な1対1構造では正しく表現できません。
| 破綻パターン | 具体例 |
|---|---|
| 複数拠点との取引 | 本社と支社が別々に発注してくる |
| 複数部門との取引 | 購買部門と現場部門が個別に窓口になる |
| グループ会社間取引 | 親会社経由で子会社の案件が発生する |
| 取引先の合併・分割 | 取引先自体の組織構造が変わる |
対処の基本：取引先の階層構造化
結論：取引先マスタを単一のレコードではなく、親子関係を持つ階層構造として設計することで、複雑な取引実態を表現しやすくなります。
具体的には、取引先マスタに「親取引先」「関連拠点」といった参照関係を持たせ、案件はその階層のどのノードに紐づくかを選べるようにします。これにより、本社としての取引実績と、支社単位での取引実績の両方を、同じデータモデルの中で矛盾なく集計できるようになります。こうしたデータモデルの再設計は、既存のカスタマイズをどこまで引き継ぐかという判断とも関わってきます。カスタマイズの移行可否の切り分け方については、作り込んだカスタマイズは移行できるか：再現・簡素化・廃止の切り分け方で解説しています。
案件側の設計も合わせて見直す
結論：取引先を階層構造にするだけでなく、案件側にも「どの窓口・担当者が起点の案件か」を明示的に持たせる設計が必要です。
取引先マスタを階層化しても、案件側が単純に取引先IDだけを参照する構造のままでは、実態の改善にはつながりません。案件のレコードに、対応する拠点・部門・担当窓口の情報を明示的に持たせることで、後から集計・分析する際にも実態に即した粒度でデータを扱えるようになります。
設計を見直すタイミングと移行の考え方
結論：データモデルの見直しは、既存データの移行方針とセットで検討する必要があり、後回しにするほど移行の難易度が上がります。
すでに大量の案件データが1対1構造で蓄積されている場合、階層構造への移行には、どの案件をどの階層ノードに紐づけるかを判断するデータクレンジングの作業が発生します。取引先数や案件数が少ないうちに設計を見直すほど、この移行コストは小さく済みます。移行前のデータ整理の進め方については、移行前のデータクレンジング：重複・表記ゆれ・死蔵項目の整理手順で詳しく解説しています。
顧客データを資産として活かす視点
結論：取引先・案件のデータモデルを適切に設計することは、単なるシステムの都合ではなく、顧客データを経営資産として活用するための土台づくりでもあります。
階層構造を正しく持たせたデータは、取引先グループ単位での売上分析や、拠点ごとの取引傾向の把握といった、経営判断に資する分析を可能にします。顧客データを資産として蓄積・活用する考え方については、顧客データを「資産」に変える：蓄積と活用のデータ設計もあわせてご覧ください。
よくある質問（FAQ）
Q. すでに1対1構造で運用しているシステムを途中から階層構造に変更できますか？ A. 技術的には可能ですが、既存データをどの階層ノードに紐づけるかを判断する整理作業が必要になります。取引先数が少ないうちに検討することをおすすめします。
Q. 階層構造にすると、かえって入力が複雑になりませんか？ A. 案件登録時に選択する階層のノードを絞り込みやすいUIにすることで、入力の負担を抑えながら実態に即したデータを蓄積できます。
Q. 既製のCRM/SFAパッケージでも階層構造に対応できますか？ A. 製品によって対応の柔軟性は異なります。自社の取引構造が複雑な場合は、既製パッケージのカスタマイズの範囲で対応できるか、事前に確認しておくことが重要です。
Q. 小規模な会社でも階層構造を検討すべきですか？ A. 現時点で取引先がすべて単一窓口であれば、無理に階層構造にする必要はありません。将来的に拠点や部門が増える見込みがある場合は、早い段階で拡張しやすい設計にしておくと安心です。
まとめ
取引先と案件を1対1で紐づける単純なデータモデルは、取引構造が複雑化すると実態を表現できなくなります。取引先を階層構造として設計し、案件側にも拠点・担当窓口の情報を持たせることで、複雑な取引実態を矛盾なく管理できるようになります。見直しは早いタイミングほど移行コストを抑えられるため、取引先数が増える前の検討をおすすめします。
Irwin&co株式会社は、自社の取引構造に合わせたCRM/SFAのスクラッチ開発を手がけており、初回商談では実際に動くデモを無償で提示しています。データモデルの見直しを検討されている場合は、お問い合わせからご相談ください。
執筆者プロフィール
アーウィン 海Irwin&co株式会社 代表取締役
生成AIを活用したシステム開発・コンサルティング・研修サービスを提供するIrwin&co株式会社を創業し、IT専任者のいない中小企業を中心に、業務システムの構築とSaaSからの移行を支援している。「SaaSの標準機能に業務を合わせるのではなく、業務に合わせたシステムを自社の資産として持つ」という考え方のもと、不動産をはじめとする業界で、生成AIを前提とした業務システムの設計・開発を数多く手がける。