「データ統合に数億円かけて動かない」を避ける設計の勘所

この記事でわかること

「動かないデータ統合」が生まれる3つの典型パターン: 技術導入先行・完璧主義による停滞・営業アクション不在という失敗の構造と根本原因を整理します。
なぜデータ整備だけではクロスセルが実行されないか: 6Cフレームワーク（McKinsey）との対応表で、データ整備が充足できる条件と充足できない条件を明確にします。
設計の3つの勘所（ユースケース先行・80%精度スタート・翌週月曜日テスト）: 失敗を防ぐ具体的な設計方針と、プロジェクトを動かし続けるための自己検証基準を提示します。

基本情報

項目	内容
対象	大企業グループの経営企画部長・IT企画部門長・DX推進担当（部長〜GMクラス）
難易度	中級
関連クラスター	C5：データ統合・顧客理解
読了目安	8分

大企業グループのデータ統合プロジェクトが、多大な投資を経ても営業現場で使われないケースは少なくありません。失敗の根本原因の多くは、技術の問題ではなく「何のためにデータを統合するか」が定義されないまま着手されたことにあります。この記事では、失敗の典型パターンを整理し、動くデータ統合を設計するための3つの勘所を解説します。

「動かないデータ統合」が生まれる3つの典型パターン

数億円規模の投資を経ても、データ統合プロジェクトが営業現場で活用されないケースは構造的に繰り返されます。失敗には共通のパターンがあります。

動かないデータ統合の3つの典型パターン概念図

パターン1——技術導入が先行し、ユースケースが後付けになる

データ統合プロジェクトが失敗する最も典型的なパターンは、「まず技術基盤を整えてから活用方法を考える」という順序です。ある大手製造業グループのデータ統合プロジェクトを知るビジネスパーソンは、失敗の根本原因をこう指摘します。「技術要件を先に決めてデータ基盤を構築し、その後でユースケースを考えようとした。その瞬間に迷走が始まる」と。

McKinseyの2018年調査（M&A幹部200名対象）でも、クロスセルが動かない主要な躓きとして「営業担当者に拡張ポートフォリオを販売する知識・余力・インセンティブがない」「リーダーシップのコミットメントが不足している」が挙げられており、これらはすべてデータの問題ではなく組織・人材・設計の問題です。

パターン2——完璧なデータ品質を目指してプロジェクトが止まる

100%の精度を目指すあまり、プロジェクトが前進できなくなるのも典型的な失敗です。グループ横断のデータ統合実務に詳しいビジネスパーソンは「LLMによる名寄せで80%程度の精度をまず実現し、残りは現場と協力しながら修正していく方が、結果的に早く成果が出る。完璧を目指すあまり、始めることができなくなることの方が大きなリスクである」と語ります。

最初から100%の精度を要求すると、プロジェクトが動き出すまでに半年以上かかることがあります。その間、組織の優先事項が変わり、結果的にプロジェクト自体が凍結されるリスクがあります。

パターン3——データ整備が完了しても、営業が「何をすればいいか」わからない

ダッシュボードや分析基盤が完成しても、営業担当者がそのデータを使って具体的なアクションを取れないケースが多くあります。海外の医療機器企業の統合事例（Bain掲載）でも、CRMなどによるデータ整備が済んでいたにもかかわらず、90%の直販営業体制への移行と営業責任の再配置が別途必要であることが判明し、データがあっても営業モデルの再設計なしには実行できなかったとされています。

データを整備することと、そのデータを基に営業が動けることは、別の設計課題です。

なぜデータ整備だけではクロスセルが実行されないのか——6Cで見る構造

データ統合プロジェクトへの投資がなぜ成果に結びつかないのか、McKinseyの6Cフレームワークで構造的に整理できます。

データ整備が充足する6CとしないCの比較図

6Cのうち、データ整備が充足するのはC1とC2の一部のみ

6Cフレームワーク（McKinsey）は、クロスセルが成功するために必要な6条件（Complementarity：補完性、Connection：関係性、Capacity：営業余力、Capability：スキル、Compensation：インセンティブ、Commitment：経営コミットメント）を体系化したものです。

このうち、データ整備によって充足できるのはC1（補完性）——どの顧客にどのサービスを提案できるかの把握——と、C2（関係性）の一部にとどまります。6Cの詳細は6C（Six Cs）フレームワークとはで解説していますが、本記事ではデータとの関係性に絞って整理します。

最も成功に直結するC6（経営コミットメント）はデータとは別次元の問題

Bain（2022年、281名の経営幹部調査）は、「既存製品を既存顧客にクロスセルする最も単純なケースでさえ、データ可視性の欠如・調整不足・動機のミスマッチによって頓挫する」と指摘しています。

特にC6（Commitment：経営コミットメント）は、最も成功との相関が高いとされながら、データ整備では充足できません。役員レベルの合意形成と意思決定は、データ基盤の整備とは別次元の経営課題です。

C3〜C5（営業余力・スキル・インセンティブ）を設計しないと実行には至らない

C3（Capacity：営業余力）——担当者がクロスセル提案に割ける時間があるか、C4（Capability：スキル）——他社製品を理解して提案できるか、C5（Compensation：インセンティブ）——子会社間クロスセルの利益が適切に分配されるか、これらは現場設計フェーズで充足される課題であり、データ整備だけでは解決できません。

これが「データがあってもクロスセルが動かない」問題の構造的原因です。

設計の勘所1——ユースケースとKPIを最初に定義する

3つの失敗パターンのうちパターン1（技術導入先行）を防ぐための、最も重要な設計原則です。

ユースケース起点のデータ統合設計フロー

「誰が、どの顧客に、いつ、何を提案するか」を先に決める

ユースケース先行設計とは、「誰が（どの営業担当が）、どの顧客に、いつ、何を提案するか」という具体的な営業アクションのシナリオを先に決めてから、そのシナリオに必要なデータ要件を定めることを指します。技術要件やシステム選定はその後です。

この順序を逆にすると、後から「このデータがないと提案できない」「この精度では判断に使えない」という仕様変更が連鎖し、プロジェクトが長期化します。

KPIは先行指標と結果指標の二段構えで設計する

ユースケースが定まったら、KPIを先行指標（紹介件数・提案実施率など計測しやすい中間指標）と結果指標（受注額・クロスセル成約件数）の二段構えで設定します。先行指標は週次・月次で追えるため、プロジェクトの進捗確認に適しています。結果指標だけを設定すると成果が見えるまでに時間がかかり、途中でモチベーションや優先度が下がるリスクがあります。

クロスセルROIの設計についてはクロスセルROIを「合成型」で語る方法も参考にしてください。

ユースケース定義なしにデータ要件を定めると、後から仕様変更が連鎖する

ユースケースが曖昧なまま進めると「やっぱりこのデータも必要」「あの顧客セグメントも対象にしたい」という要件変更が発生しやすくなります。PwC「M&A実態調査2019」によれば、クロスボーダーM&Aを経験した174社のうち、買収先の業績が当初計画を上回った割合はわずか12%とされており、計画段階の設計精度がその後の成果を大きく左右します。

設計の勘所2——80%の精度で動き始め、運用しながら高める

パターン2（完璧主義による停滞）を防ぐ設計方針です。

100%精度を追うと、プロジェクト着手まで半年以上かかることがある

グループ横断のデータ統合で100%の精度を最初から要求すると、データクレンジング・名寄せ検証・例外処理の設計に膨大な工数がかかります。その間、組織の関心や優先度が変わり、完成した時点でプロジェクトが形骸化するリスクがあります。

80%の精度で始めると何が見えるか

80%程度の精度でも「どの顧客グループに優先してアプローチするか」という経営判断の感覚的な理解を得ることは十分に可能です。グループ横断のデータ統合実務に詳しいビジネスパーソンによれば、「精度は上げすぎない方がよい。経営判断の感覚的な理解ツールとして使うのであれば、80%で十分に機能する」とされています。

残りの20%は運用フェーズで現場フィードバックによって埋める

80%で動き始めた後は、現場担当者が「この名寄せは誤っている」「この顧客は別会社だ」というフィードバックを日常業務の中で返してくれる仕組みを設けることで、精度が自然に高まっていきます。データ品質の段階的な向上については顧客マスタの整備で躓く3つの瞬間｜データ品質80%から始める方法で詳しく解説しています。

設計の勘所3——データを「翌週月曜日の営業アクション」に直結させる

パターン3（営業アクション不在）を防ぐ最も独自性の高い設計原則です。

翌週月曜日アクション連鎖の階層図

データ統合の成否を問う問いは「翌週月曜日に営業が何をするか明確か」

クロスセルのためのデータ整備が機能するかどうかは、そのデータを受け取った営業担当者が翌週月曜日に何をするかが明確かどうかで問うことができます。データがあっても次の行動が見えなければ、分析結果は参照されないまま時間が経過します。

候補リストを受け取った営業担当者が「この会社のこの部門に、この子会社のサービスを提案してみたい」と具体的な初動が取れる状態になっているかどうかが、設計の完成度の基準です。

名寄せ・ティアリング・候補リストは全て「アクションの起点」として設計する

データ統合のアウトプットは、名寄せされた顧客リスト、ティアリング（Core/Next/General/Hold の優先度分類）、ホワイトスペース（未取引領域）を踏まえた候補リスト、そして提案ストーリーへと連鎖します。各ステップは「翌週月曜日に営業が動ける状態」を作るための前工程として位置づけます。

顧客スコアリングの具体的な手法については顧客スコアリングとは｜BtoBクロスセルでの確度予測の作り方が参考になります。

「ダッシュボードが完成する」ではなく「提案ストーリーが動く」が完了の定義

「ダッシュボードが完成する」「分析基盤が整う」ではなく、「候補リストを受け取った営業担当者が具体的な提案ストーリーを持って顧客にアプローチできる状態になる」ことをデータ統合プロジェクトの完了と定義します。

McKinseyの調査では、売上シナジー目標を達成した組織は約30%（グローバル、M&A幹部200名調査）とされており、大半の組織が目標を達成できていません。この差を生む要因の一つが、データ整備で止まってしまい、実行に至らないことです。

よくある質問（FAQ）

Q1. データ統合プロジェクトが「動かない」最大の原因は何ですか？

最大の原因は、「何のためにデータを統合するか」のユースケースとKPIを定義しないまま技術導入を先行させることにあります。技術的な基盤が整っても、どの顧客に何を提案するかが明確でなければ、データは参照されないまま時間が経過します。McKinseyの調査（2018年、M&A幹部200名対象）でも、クロスセルが動かない主要な躓きはすべてデータの問題ではなく、組織・人材・設計の問題であることが示されています。

Q2. データ品質が80%でも、実際に経営判断に使えるのでしょうか？

80%の精度でも、「どの顧客グループに優先してアプローチするか」という経営判断の感覚的な理解を得ることは十分に可能です。100%の精度を追うと、プロジェクトが動き出すまでに半年以上かかることがあります。80%で始めて、運用しながら現場のフィードバックをもとに残りの20%を埋めていく方が、結果的に早く成果が出ることが多いとされています。残りの精度向上の具体的な方法は顧客マスタの整備で躓く3つの瞬間｜データ品質80%から始める方法で詳しく解説しています。

Q3. ユースケースを先に定義するとはどういう意味ですか？

ユースケース先行設計とは、「誰が（どの営業担当が）、どの顧客に、いつ、何を提案するか」という具体的な営業アクションのシナリオを先に決めてから、そのシナリオに必要なデータ要件を定めることを指します。技術要件やシステム選定はその後です。この順序を逆にすると、後から「このデータがないと提案できない」「この精度では判断に使えない」という仕様変更が連鎖し、プロジェクトが長期化します。

Q4. CRM統合とデータ統合は何が違うのですか？

CRM統合は複数のCRMシステムを1つの基盤に統合する技術的なプロセスを指します。一方データ統合は、CRM・基幹系・外部データを含む幅広いデータソースを横断的に整理することを指す、より広い概念です。大企業グループのクロスセル文脈では、M&A後に子会社ごとに異なるCRMを一本化しようとするアプローチが行き詰まるケースが多く、全社統合せずに横展する代替設計が現実的な場合があります。詳細はCRM統合とは｜M&A後によくある失敗と回避策で解説しています。

Q5. グループ各社のCRMを全社統合しなくても、クロスセルを進められますか？

進められます。全社CRM統合は多大な時間・コスト・調整工数を必要とする一方、クロスセルに必要なのは「どの顧客にどの子会社のサービスを提案できるか」というホワイトスペースの把握です。このためには全社統合ではなく、各社の顧客マスタを名寄せして補完性マトリクスを作成するアプローチが現実解として有効です。具体的な設計方法はグループ各社のCRMを「全社統合」せずに横展する方法｜現実解の設計で解説しています。

Q6. データ整備が終わったら次に何をすればよいですか？

データ整備の完了は出発点であり、次は「候補リストをどう営業アクションに変換するか」の設計が必要です。具体的には顧客ティアリング（Core/Next/General/Holdの優先度分類）を経営層と合意し、上位ティアの顧客について「なぜ・何を・どう提案するか」を記した提案ストーリーを準備することが有効とされています。ティアリングの合意形成方法は顧客ティアリングを経営層と合意形成する方法で詳しく解説しています。

Q7. 6Cフレームワークとデータはどのような関係にありますか？

6Cフレームワーク（McKinsey）のうち、データ整備によって充足できるのはC1（Complementarity：補完性）とC2（Connection：関係性）の一部にとどまります。最も成功との相関が高いC6（Commitment：経営コミットメント）はデータとは別次元の経営意思の問題であり、実行に直結するC3（Capacity：営業余力）・C4（Capability：スキル）・C5（Compensation：インセンティブ）も組織設計の問題です。これが「データがあってもクロスセルが動かない」問題の構造的原因です。6Cの詳細は6C（Six Cs）フレームワークとはで解説しています。

Q8. 翌週月曜日テストとは何ですか？

翌週月曜日テストとは、データ整備やクロスセル施策の設計が完了した時点で「翌週月曜日に営業が何をするかが明確か」を問う検証の考え方です。候補リストを受け取った営業担当者が、翌週月曜日に「この会社のこの部門に、この子会社のサービスを提案してみたい」と具体的な初動が取れる状態になっているかどうかで、設計の完成度を問います。データ統合・ティアリング・提案ストーリー生成はすべて、この最終アクションの起点として設計されることが重要です。

まとめ——データ統合は「使われること」をゴールに設計する

主要ポイント

失敗の根本はユースケース不在: 技術先行・完璧主義・アクション不在という3つの失敗パターンはいずれも、「何のために統合するか」が先に定まっていないことから生まれます。
80%精度スタートが停滞を防ぐ: 100%を目指すと着手できなくなります。80%で始めて運用しながら高める方が、結果的に早く成果が出ます。
翌週月曜日テストが完了の定義: ダッシュボードが完成することではなく、候補リストを受け取った営業担当者が具体的な初動を取れる状態になることが、データ統合プロジェクトの本当の完了です。

次のステップ

「誰が、どの顧客に、いつ、何を提案するか」のユースケースを文書化する
Phase 0（Excel形式の手動連携）で試験的にグループ横断の顧客データの突き合わせを実施する
顧客マスタの整備で躓く3つの瞬間｜データ品質80%から始める方法を読んで、名寄せの具体的な手順を把握する

参考リソース

McKinsey "Seven rules to crack the code on revenue synergies in M&A" (2018)
Bain & Company "Bringing Science to the Art of Revenue Synergies" (2022)
PwC「M&A実態調査2019」

SINAJIについて SINAJI は AIを高度活用したクロスセル実行部隊として、大企業グループの横断シナジー創出を支援しています。「ユースケース起点の設計」から「翌週月曜日の営業アクション」まで、データ整備から実行フェーズを一気通貫でサポートします。詳しくはサービスサイトをご覧ください。