KOTOFORIO
← お役立ち情報一覧

「うちのツール、全部で何個あるか分かりますか」「……数えたことないです」

この質問を投げると、たいてい沈黙が返ってきます。GTMエンジニアリングやデータ連携基盤の構築に関わっていると、ツールが部門ごとにバラバラに導入され、全体像を把握している人が誰もいない状態によく出会います。ここでは一般的な構成例をもとに、自社のツール一覧を数える出発点を示します。

部門別の一般的な構成例

マーケティング
MA(HubSpot、Marketo等)、Web解析(Google Analytics等)、広告管理、SEOツール。リード獲得〜スコアリングの起点となるデータが集まる領域
セールス
SFA(Salesforce Sales Cloud等)、商談録音・分析(Gong等)、電子契約(DocuSign等)。パイプライン・商談データの中心
インサイドセールス(SDR/BDR)
セールスエンゲージメント(Outreach、Salesloft等)、企業データベース(ZoomInfo等)。アウトバウンドの実行と接触履歴の記録
全社共通基盤
コミュニケーション(Slack等)、ドキュメント・ナレッジ(Notion等)、業務基盤(Google Workspace等)。部門を横断して使われるインフラ
データ連携基盤・分析
ETL/ELT(Fivetran等)、データウェアハウス(Snowflake、BigQuery等)、BI(Looker、Tableau等)、iPaaS(Zapier、Workato等)。各部門のツールから流れ込んだデータを統合・可視化する層
AI
生成AIアシスタント(ChatGPT Enterprise、Claude等)、商談分析AI、インテントデータ・予測スコアリング(6sense等)。近年は既存カテゴリの中にAI機能が組み込まれる形も増えている
ミドルオフィス
ERP・基幹システム(NetSuite等)、プロジェクト管理、人事管理(Workday等)。事業運営を支える管理業務の基盤
バックオフィス
会計(freee、マネーフォワード等)、労務・人事(SmartHR等)。財務・法務・労務の記録システム

呼び方の使い分け:System Map / DFD / Integration Map / Service Blueprint

「システム同士のつながりを可視化する」という行為自体にも、ニュアンス別にいくつかの呼び名があります。BizOps/RevOps文脈で作図を依頼したり資料を探したりする際、どの言葉を使うかで出てくるものが変わるため、使い分けを整理しておきます。

System(s) Map/システムマップ
ツール・システム同士のつながりの全体像を描くもの。BizOps/RevOpsで最も汎用的に使われる呼び方で、上記の部門別ツールマップもこれに近い
Data Flow Diagram(DFD)/データフロー図
データが「どのシステムから→どこへ」流れるかを矢印の向きで示すもの。連携の方向性・データの発生源(Source of Truth)を明確にしたいときに使う
Integration Map/インテグレーションマップ
各システムの連携ポイント(API・iPaaS経由など)を線でつなぐもの。ツール間の依存関係(どれが止まると何が止まるか)を洗い出す用途に向く

隣接する上位概念として、保有システムを俯瞰するSystem Landscape(アプリケーションランドスケープ)はエンタープライズアーキテクチャ寄りの言い方、業務プロセスとその裏で動くシステムを縦に対応させて描くService Blueprint(サービスブループリント)はプロセス×システムの対応関係を見たいときに使われます。「システム間の連関」だけを描きたいならSystem Map/Integration Mapが最も近く、「業務プロセスとシステムの対応」まで含めたいならService Blueprint、「データの流れの方向」を強調したいならDFDが正確な選び方です。

実際にSalesforce周りでこの手の図を作る場合、専用の記法(BPMN・ArchiMate等)を厳密に使う必要は薄く、Miro・Lucidchart・draw.io等でボックス(システム)と矢印(データの向き)を並べるだけで実務上は十分機能します。矢印には「連携方式(リアルタイムAPI/バッチ/手動CSV等)」をラベルとして添えておくと、後から見返したときに詰まりどころが一目で分かります。

ここで先に反論しておきます。「BPMNやArchiMateのような正式な記法を使わないと、図としての信頼性に欠けるのでは」と思うかもしれません。専門的な記法には確かに厳密さの利点がありますが、まず必要なのは「誰が見ても同じ理解にたどり着けるか」です。箱と矢印だけの簡素な図でも、部門間の認識が揃うなら、それだけで多くの分断は解消します。記法の正しさより、まず1枚描いてみることの方が優先です。

この構成図をデータカタログ作りにどう使うか

部門別のツール一覧は、そのまま「企業活動のデータ×管理システム全体マップ」記事にあるデータカタログの項目テンプレート(システム/データ種類/担当部門/更新頻度/アクセス方法/保管場所)を埋める出発点になります。まずは自社に実在するツールをこの8カテゴリに当てはめてみるところから始めると、抜け漏れに気づきやすくなります。

特に見落とされやすいのが「データ連携基盤・分析」のレイヤーです。各部門のツールが個別に存在していても、それらをつなぐETL/iPaaSやウェアハウスが未整備だと、部門間のデータ分断はいつまでも解消しません。ツール一覧を作った後、「このツール間はどうやってデータが行き来しているか(手動CSVか、自動連携か、そもそも連携していないか)」まで書き添えると、詰まりどころが見えてきます。

部門ごとに便利なツールを個別導入していく状態は、家族それぞれが自分の部屋にだけ合う家電を買い足していくのに似ています。個々の部屋は快適でも、家全体としての電力配線(データ連携)を誰も設計していなければ、いずれどこかでブレーカーが落ちます。

「企業活動のデータ×管理システム全体マップ」のデータカタログ項目テンプレートを、自社のツール一覧にそのまま適用したフォーマットです。

システムデータ種類担当部門更新頻度アクセス方法保管場所
記入例Salesforce Sales Cloud記入例商談・取引先・パイプラインデータ記入例セールス記入例リアルタイム記入例SFA管理画面/API記入例Salesforce org内

よくある質問

小規模な会社でもこの8カテゴリすべて必要ですか
必要ありません。事業フェーズが早い段階では、SFA・全社共通基盤・会計ツール程度から始まり、事業が拡大するにつれてインサイドセールス向けツールやデータ連携基盤が追加されていくのが一般的な順序です。今ないカテゴリは「まだ不要」と捉えて問題ありません
AIツールはどのカテゴリに分類すればいいですか
独立したAIカテゴリとして管理するか、既存カテゴリ(例:商談分析AIならセールス)に紐づけて管理するかは会社によって異なります。重要なのは、AIツールが読み書きしているデータソースが何かを明確にしておくことです

問い

自社で使われているツールを、今すぐ紙に書き出せるでしょうか。書き出せたとして、その中で「他のツールとデータが自動連携している」と自信を持って言えるものはいくつあるでしょうか。答えに詰まる部分こそが、次に手を付けるべき場所です。