前章（B5）で、ダッシュボードに載っているのは「結果指標」であって、パートナーセールスの本質である「先行指標」は見えていない、という話をしました。 では、その先行指標を どこに、どう持つべきか。この問いに答える概念が、SoR事実の唯一の記録元（System of Record）です。
この章では、SoR とは何か、CRM顧客管理システム や SFA営業活動を効率化するシステム とは何が違うのか、そしてパートナーセールスにおける SoR の不在が何を引き起こしているのかを整理します。
SoR の語源 ── 「記録の唯一の体系」
SoR は System of Record の略で、直訳すれば「記録の唯一の体系」です。組織内で「ある事実について、最終的に正しい値はここに書いてある」と全員が合意できる場所、という意味になります。
重要なのは 「データが置いてある」 ことではなく、「ここを見れば判断できる」 という合意がある、ということです。同じ事実が複数のシステムに散在しているなら、それは SoR ではありません。どれが正しいかで議論が始まる時点で、組織は判断を保留せざるを得なくなります。
逆に言えば、SoR が成立すると、組織の意思決定速度は飛躍的に上がります。会計の SoR が ERP経営資源の統合管理 に統一されているから、決算が締められる。人事の SoR が HRMS にあるから、異動・昇給を実行できる。これらは「データが揃った」のではなく「合意点が一つに集約された」結果です。
CRM や SFA は SoR か？
ここで、よくある問いが出ます。「うちには CRM も SFA もある。それで十分では？」── 答えは、領域による、です。
CRM（Customer Relationship Management）は、コンタクトの SoR としてはよくできています。誰がいて、どの会社に所属していて、いつ連絡したか。ここまでは記録できます。
SFA（Sales Force Automation）は、案件の SoR として有効です。どの案件がどのフェーズで、いくらで、いつクローズ予定か。これも記録できます。
ところがパートナーセールスは、「案件になる前」の関係性 が成果を決める領域です。案件発生時点では、すでに勝負はついています。CRM の Contact / Company / Deal商談・案件 という3要素データモデルでは、その手前の「誰がどのプロダクトをどこまで売れるようになっているか」「直近の活動量はどう推移しているか」「組織内の影響力は誰が持っているか」── こうした先行指標を構造的に持てません。
つまり、直販向けに作られた CRM/SFA をそのままパートナーセールスの SoR として使うと、見える化されるのは 結果指標だけ になります。これが B5 で扱った「ダッシュボードで見えないもの」の正体です。
SoR の3条件
ある記録が SoR として機能するためには、3つの条件を満たす必要があります。
- 唯一性（Single Source of Truth） 同じ事実が複数箇所に書かれていない。Excel と Salesforce と担当者の頭の中、で食い違っているなら、それは SoR ではない
- 一次データであること 誰かの解釈や要約ではなく、起きたこと自体の記録。「商談で前向きだった」ではなく「○月○日 14:00 オンライン MTG、参加3名、議題3点、次回アクション2件」
- 構造化されていること 自由記述ではなくフィールド単位で分解されている。最小5要素（type / who / when / what / outcome）が揃って初めて、機械が読める
この3条件は、AI が読み解いて次の判断につなげるための前提でもあります。自由記述のメモがいくら大量にあっても、構造化されていなければ集計もパターン認識もできません。逆に、フィールドが揃っていれば、人手で書かれていても機械的に処理できます。
言い換えると、SoR は 「人が読むための記録」 から 「人と機械が同時に読める記録」 への引き上げです。
業務領域ごとの SoR ── では、パートナーセールスは？
業務領域ごとに、SoR の構造は異なります。
- 人事 ＝ HRMS 誰がどの部署で、いくらの給与で、何の評価を受けたか。社員に関する唯一の正解
- 会計 ＝ ERP いつ、どの勘定科目に、いくら計上したか。仕訳の唯一の正解
- 製造 ＝ MES どのラインで、何個、どの品質で生産したか。製造工程の唯一の正解
- 顧客対応 ＝ CRM 誰と、いつ、何の話をしたか。コンタクトの唯一の正解
では、パートナーセールスの SoR は何でしょうか。
業界として、まだ確立していないのです。多くの企業で、パートナーに関する情報は「Excel ＋ Salesforce ＋ Slack ＋ 担当者の頭の中」に分散しているのが実態です。担当者が異動すれば、その人の頭の中にあった情報は失われ、関係性は事実上リセットされる ── これは前章までで扱った「属人化」の正体です。
パートナーセールス担当者の典型的な1日 ── 朝の前日商談メモ、午前の定例、午後の新規パートナー調査、夕方の社内報告 ── を思い浮かべてください。この情報粒度は、本来そのまま組織の SoR の蓄積源になるはずのものです。けれど現状、その大半は構造化されないまま、個人のメモや Slack の流れの中に消えていきます。
さらにパートナーセールス固有の難しさは、関係者が4層（ベンダー → パートナー企業 → パートナー内担当者 → エンドユーザー）にまたがり、情報が双方向で劣化することです。SoR がなければ、どの層で何が起きたかを追跡することすらできません。
しかし、パートナーセールスの SoR は 業界として未確立 です。これがパートナーセールスが属人化する根本原因であり、ダッシュボードに先行指標が載らない構造的理由でもあります。
では、パートナーセールス専用の SoR はどんなデータモデルを持つべきか。次章では、CRM の3要素では足りない理由と、必要な 5軸コンテキスト を提示します。
- SoRエス・オー・アール
- System of Record。業務における "事実の唯一の記録元" を担うシステム。顧客情報なら CRM、商談なら SFA。パートナーセールス領域ではこれまで SoR 自体が存在していなかった、というのが synergeee の出発点。
- CRMシー・アール・エム
- Customer Relationship Management。顧客との関係を一元管理するシステム。Salesforce や HubSpot が代表。コンタクト・案件・商談を扱うが、パートナー構造は持たない。
- SFAエス・エフ・エー
- Sales Force Automation。営業活動を効率化するシステム。商談パイプライン管理が中心。
- ERPイー・アール・ピー
- Enterprise Resource Planning。企業の経営資源（人・物・金）を統合的に管理するシステム。SAP・Oracle 等。
- Dealディール
- 営業上の取引機会・案件。CRM・SFA で管理される基本単位。