TOPPAN データ統合顛末記②
ツール&データ統合基盤開発編
デジタルマーケティングの推進と営業高度化を目指し、2年の歳月をかけて全社規模のデータ統合基盤「One TOPPAN Platform」を構築したTOPPAN。前回①では、プロジェクト開始の背景にあったビジネス課題と、データ統合によって目指す未来についてご紹介しました。
シリーズ②となる今回は、いよいよ核心に迫ります。データ基盤構築プロジェクトにおける試行錯誤、そしてそこで見えてきた新たな課題とは？ BtoB企業が挑むデータ統合のリアルな舞台裏を、余すことなくお伝えします。
経営企画本部 経営基盤改革部
情報武装化推進チーム 部長
内田 智宏
BtoBデジタルマーケティング活動を推進し、全社へと展開。
デジマ活動の中で営業における機会損失に課題を感じ、社内全体でデータを見える化すべく、データ統合を進める。
ビジネストランスフォーメーションセンター
マーケティングテクノロジー部 部長
三田 虎史
2001年入社以来ICT領域を担当。2017年頃よりクライアント向けにCDPやMAなどのマーケティング実行基盤の構築・運用を推進し、対応部門のリーダーを担当。社内データ活用に課題を感じ、本プロジェクトでデータ統合を推進。
※肩書は開発当時のものです。
なぜツール統合「だけ」ではダメなのか？
データ統合プロジェクト、その真意
構築プロジェクトのお話しの前に、改めて。なぜ、ツール統合だけではなく、データ統合が必要だと考えたのでしょうか？
内田:各ツールに散在しているデータを統合し、見える化することで、すべての社員にデータの有用性を示すことが重要であると考えたからです。
前回お話しした通り、当社は各事業部で「Ｗｅｂ創注」というデジタルマーケティング活動を推進しており、その中でＭＡ（Marketo）と名刺管理（Sansan）のツール間での連携は、すでに行っていました。営業高度化の実現という目標を考えた時、CRM/SFAであるSalesforceとの連携が必要不可欠です。しかし、ツール連携を重ねるのは開発の負荷が高い割に、その効果は限定的なのです。
三田:例えばSalesforceなど、どれか一つのツールにデータを統合・集約してしまうと、実施できることがそのツールの機能の制約に依存してしまいます。今回のようにさまざまなシステムのデータを集めて見える化するなら、データの基盤に統合したうえで、使いやすいBIツールを使ったほうが良いだろうと考えました。外部でデータが統合されていれば、個々のツールへの依存度が低くなるので、必要に応じて連携元のツールも柔軟に変えることが可能になります。
内田:これらの議論を重ねる中で、やはり、CDP（カスタマーデータプラットフォーム：顧客データを収集・統合・分析するためのデータ基盤）によるデータ統合が本質的な課題解決につながるとの思いを、強くしました。そこに事業統合の話が持ち上がり、今こそ実行するタイミングだと捉えたのです。
3ヶ月間の集中議論！要件定義と推進体制の確立
こうして2022年末、いよいよSFA、MA、名刺管理の３ツールの統合と並行して、データ基盤構築プロジェクトがスタートしました。
プロジェクトは、どのようなステップで進めましたか？
内田:2022年１2月下旬から、年度内である翌2023年３月末までの約３カ月間、週次で定例会を開催し、データ基盤構築の要件定義を行いました 。営業活動の高度化を目的に定め、CDPデータ構造の全体像を取りまとめると共にクライアント、営業、商品（サービス）を軸としてデータの持ち方を整理し、実施の優先順位付けも行いました。
併せて対象となりうる社内のシステム・データを洗い出し、連携対象システムのオーナー、管理部門に対する協力依頼と根回しも実施して、推進体制も確立させました。
■マイルストーン全体像
■TOPPAN CDP要件定義スケジュール
推進体制として、社内のどういった部門を巻き込んだのでしょうか？
内田:私が所属していた経営企画部門と、三田ら開発を行う推進チームが中心ですが、情報システム部門であるデジタルイノベーション本部、情報セキュリティ本部、連携対象となる各システムのオーナーも含め、計10部門以上に協力を仰ぎました。
セキュリティやプライバシー保護の観点での対応は？
三田:我々がクライアント案件でも多く経験してきた領域ですが、当社はもともと厳格にデータ管理、運用ルールも定められていましたので、他社に比べてやりやすい環境だと感じました。本プロジェクトでも、データ基盤へのアクセス範囲の管理などは、情報セキュリティ基準に則って進めました。
そうは言っても新たなケースも多く出ますので、データの利用範囲などの規定は情報セキュリティだけでなく、法務的な観点を確認するため該当部門の方々にもプロジェクトに参加してもらい、都度確認をしていきました。今回のデータの利用目的のために新たに許諾を取り直す、といった対応もありました。
内田:システム開発部門や情報セキュリティ部門だけで進めると、「危なそうだからとりあえずやめておこう」となり、結果的に使いにくいシステムになってしまいがちです。今回は専門部署の方々に諮問機関、アドバイザーとして加わっていただき、利便性とリスク排除のバランスを取るよう心がけました。
多岐にわたるデータを統合、CDP＆BIツールも選定
具体的に、どのようなデータを統合対象としたのでしょうか？
内田:基本的には営業の活動データであるSFA（Salesforce）と名刺管理システム（Sansan）、デジマ活動データであるMA（Marketo）の3ツールの統合が目的ですが、営業活動高度化のためにはGA4、Web広告、CMSなどのWebデータのほか、所属部署や事業部情報などを含む社員データ、一部の売上や取引先データ、さらに企業データベースなど外部データも対象となります。
三田:このように連携対象となるシステム、データが多岐に渡りますので、各システムオーナーに許可をもらってデータを提供してもらい、一部可能なシステムは接続させてもらって、できるところから実際のデータの調査、確認を進めていきました。どう連携させるかの協議も重要ですが、実態として各ツールがどんなデータを保有しているかを一刻も早く把握することが重要だと考えました。
■ONE TOPPAN PLATFORM 全体像
CDPとBIツールの選定は、どのように実行されたのでしょう？
内田:これまでのクライアント案件で培った選定基準の知見を用いて、本プロジェクトにおける優先度を基に、さまざまな観点で比較検討を重ねました。データ統合の基盤となるCDPについては複数のSaaSやPaaS（パブリッククラウド）から、選定を行いました。PaaSではAWSとGoogle Cloud、SaaSではTreasure Data CDPとSalesforce CDPなどが候補に挙がりました。
三田:具体的な評価項目は、導入実績、システム連携、データ構造の汎用性、データ整形・変換（ETL）、セキュリティ、ジョブ管理のしやすさ、セグメント作成のしやすさ、エラー検知やサポート体制などの保守性、機械学習、データ分析、そして料金体系、契約体系などさまざまです。単純に比較項目をフラットに並べるのではなく、プロジェクトの目的や体制などの実情に合わせて、優先する評価項目を見定めながら進めていきました。
各プラットフォームを採用した場合のシステム/サービス構成や、初期費用や月額のランニングコストなどの情報も収集して、最終的にはデータ構造の汎用性、データ整形と変換（ETL）の柔軟性に加えて、機械学習やデータ分析、そしてプロジェクトで見込まれるデータ量や、拡張予定なども加味した費用面を評価しました。当初はデータ基盤の固定の費用を抑えつつ、途中で拡張や変更を繰り返しながら拡大をしていきたいという要望がありましたので、Google Cloudが選定されました。
内田:BIツールについては、Google Looker Studio、Looker、Tableau、Power BI、Domoなどを比較検討しましたが、ダッシュボードの見える化という点では、各社そこまでの差はありませんでした。
最終的に、データソースへの対応が柔軟かつ、全社員が無料で利用できることで試行錯誤しやすいLooker Studioを選定しました。
いよいよ構築開始！怒涛のフェーズ1
約3か月間の要件定義および全体像への合意、予算承認を経て、2023年4月から同年9月末までの6か月間をフェーズ1として、構築がスタートしました。
■TOPPAN CDP Phase1） 構築スケジュール
構築は、どのように進めましたか？
三田:４か月ほどかけてインフラ側の設計と構築、CDPでの各システムからのインポート設計と開発、テストと、BIのダッシュボードとデータマート設計を並行して行い、後半の2か月で結合テストと受入試験を経て、2023年9月末に本番リリースとなりました 。対象システムも多く、フェーズ分けによる実施のため、それぞれの工程の中でも短サイクルでの設計と構築を繰り返して、範囲を増やしていきました。その中で、同時並行的に3ツールを統合したイメージです。
内田:この裏側では、将来的な統合を見据えて、各社が利用するツールの入力項目などを統一する動きも進めていました。
この段階で、技術的に苦労した点は？
三田:それぞれのシステムのデータフォーマットはさまざまでしたが、データクレンジングは我々の得意とするところなので、大きな困難にはつながりませんでした。
もっとも苦労した点は、異なるツールで取得した複数データの紐付けと、顧客データの名寄せです。一例では、Webサイトから得られたページビューや資料ダウンロードなどのマーケティング上の行動データと、営業が保有する名刺データと商談データを「同じ人」と名寄せして、横串で見せたいという要望の実現でした。
しかしそれを実現するには、異なるツールで取得したデータを何らかの情報を基に突合する必要がありますが、ツール間での仕様制限もあります。仕様の確認と共に技術検証や、得られたデータの調査を実施しながら精度を高めていきました。
各システム間のデータの統合について、名前やメールアドレスで人軸のデータはある程度が可能でしたが、ここで問題となったのが、企業軸でデータを統合するにあたって企業コードが複数存在することでした。
内田:当初は、帝国データバンクの企業コードに名寄せしようと考えましたが、既に取引のある企業しか登録されていない。新しいデータ基盤では、まだ取引のない企業の方の行動データを多く取り扱うため、それでは不十分でした。
ちょうどその折、デジタルイノベーション本部で同じ課題を解消する目的で「ユーソナーの法人データベースLBC」が導入されていたことが分かり、これを利用することで、ようやく解決しました。さらに、今後同様の問題が起こることを避けるため、名刺管理ツールを「mソナー」にリプレイスすることを決断しました。
そのほか、プロジェクトマネジメント面で直面した課題と、その乗り越え方について教えてください。
三田:データ基盤にありがちなこととして、連携元システムの改修スケジュールの影響を受けて「このデータを使いたいけど、まだ連携できない・データがたまっていない」ということが多くありました。そのため、その時点で使えるデータを見極めて、「何から着手するかを決めて、実行する」を細かく繰り返す必要がありました。
また、当初予定していなかった名刺管理ツールのリプレイスが発生したため、連携をやり直す必要もありました。このように、データ基盤構築においては周辺システムの動向に合わせて、柔軟にスケジュールを組み替えて対応することが求められます。
データに関しても、システムによって更新タイミングの違いや、運用によるイレギュラー対応なども多くありますし、元システム自体の更新も発生します。その都度、取り込んだデータの統合・更新ルールの整理が必要となりますが、しゃかりきにシステム・データの完全性を担保しようとこだわるのではなく、一部は運用リカバリーで対応するなど、精度と対応負荷のバランスを取るように心がけました。完全性を求めるのではなく、そういった事象がある、ということを把握して、プロジェクト内で共有しておくことが大切です。
データ統合で浮き彫りになった、BtoB企業データ活用における真の課題
データ連携基盤の構築を進める中で、どんなことを感じましたか？
内田:個々のシステムを連携させてデータを統合していく中で、連携の難しさよりも、むしろデータそのものの品質に大きな課題があることに気付きました。特に、Salesforceのデータ。部門によって入力率が低かったり、入力内容が不足していたりと大きな差があり、このままでは全社的に横並びでの分析が難しく、見える化しても効果は期待できないことが分かりました。
三田:これはシステム単体では大きな問題になっていなかった点でしたが、今回、複数のシステムを連携させ、データを統合することで露見した新たな課題でしたね。
内田:まさしくそうです 。非常に根深い問題ですが、データ連携を実行しなければ気づけなかったことでもあるので、このプロジェクトで解消するべき課題として捉えて、Salesforceのデータ品質を向上するための取り組みを開始することとしました。
今回は、データ統合基盤構築プロジェクトの過程でTOPPANが直面した課題と、その解決に向けた取り組みについてご紹介しました。ツール連携の壁、データの品質、部門間の調整…数々の困難を乗り越え、TOPPANは着実にデータドリブンな企業へと進化を遂げようとしています。
しかし、これで終わりではありません。次回③では、新たに浮上した課題である、「Salesforceのデータ品質向上」に向けた取り組みについて、さらに深く掘り下げていきます。ご期待ください！
2025.04.28
