SalesOpsの限界 — なぜ営業企画だけではDXが進まないのか

営業企画・営業推進部門は、多くの日本企業において営業組織の司令塔として機能してきた。ターゲティング戦略の策定、KPIの設計、営業プロセスの標準化——これらは間違いなく重要な仕事だ。しかし、営業DX（Digital Transformation）の文脈では、営業企画だけではどうしても越えられない壁がある。本記事では、SalesOps（営業推進・営業企画）がDXを推進できない構造的理由と、GTMエンジニア（Go-To-Market Engineer）による解決策を具体的に解説する。

日本企業の営業企画が直面する典型的な課題

まず、日本企業の営業企画部門が抱える課題を整理する。筆者がこれまで支援してきた企業で繰り返し目にしてきたパターンだ。

課題1：CRMが「入力ツール」で止まっている

SFA/CRM（Sales Force Automation / Customer Relationship Management）を導入した企業の多くが、同じ壁にぶつかる。営業担当者が入力しない、入力しても粒度がバラバラ、データがあっても活用されない。総務省の「情報通信白書」によれば、CRMを導入している日本企業の約6割が「十分に活用できていない」と回答している。

営業企画はダッシュボードのあるべき姿を描ける。しかし、「入力されない」問題の根本解決——例えばメールやカレンダーの情報を自動でCRMに同期する仕組みの構築——は営業企画のスキルセットの外にある。

課題2：ツール導入が「点」で終わる

MA（Marketing Automation）、SFA、BI（Business Intelligence）ツール、名刺管理、オンライン商談ツール——日本企業の営業部門は平均で7〜8個のツールを利用しているとされる。しかし、それぞれのツールが独立して動いており、データが分断されている。

営業企画はツールの選定と導入は推進できる。しかし、ツール間のデータ連携——APIを使ったリアルタイム同期やETL（Extract, Transform, Load）パイプラインの構築——は技術的な実装力が必要だ。

課題3：改善サイクルが四半期単位になる

営業プロセスの改善施策を立案しても、実装にはIT部門やベンダーの対応が必要だ。「CRMのワークフローを1つ追加したい」だけで、要件定義に2週間、開発に1ヶ月、テストに2週間。合計で2ヶ月。四半期の施策を翌四半期にやっと実装できる——これでは、市場の変化に追いつけない。

「企画はできるが実装ができない」構造問題

上記の課題は、すべて1つの構造的問題に帰着する。営業企画は「何をやるべきか」は設計できるが、「それをシステムとして動かす」能力を持っていないということだ。

これは営業企画担当者の能力不足ではない。組織設計の問題だ。日本企業では伝統的に「企画する人」と「作る人」が完全に分離されている。営業企画は経営学やマーケティングのバックグラウンドを持つ人材が配置され、IT実装はシステム部門やベンダーが担う。この分業が、営業DXのボトルネックになっている。

具体的なデータで見てみよう。ある製造業（従業員500名）の営業企画部門では、年間で約30件の改善施策を立案していた。しかし、IT部門のリソース制約とベンダーの対応待ちにより、実際に実装されたのは年間わずか8件。**実装率はわずか27%**だった。残りの22件は「企画倒れ」として翌年に持ち越されるか、消滅していた。

ベンダー丸投げの弊害

「IT部門のリソースが足りないなら、外部ベンダーに任せればいい」——そう考える企業は多い。しかし、営業プロセスのシステム化をベンダーに丸投げすることには、3つの重大な弊害がある。

弊害1：仕様の翻訳コスト

営業企画が「こういう営業プロセスにしたい」という要望を、ベンダーが「システム要件」に翻訳する。この翻訳プロセスで、必ず情報のロスが発生する。営業現場のニュアンス、例外処理の判断基準、優先順位の微妙な違い——これらは仕様書に落とし切れない。結果として、「頼んだものと違う」が頻発する。

弊害2：スピード感の欠如

前述の通り、ベンダー経由では小さな変更でも数週間〜数ヶ月を要する。営業プロセスは生き物だ。顧客の反応、競合の動き、社内の人事異動——様々な要因で常に変化する。このスピード感のミスマッチが、営業DXを「一度構築して終わり」のプロジェクトにしてしまう。

弊害3：ナレッジの外部流出

営業プロセスの設計ノウハウとシステム実装の知見が、ベンダー側に蓄積されていく。ベンダーを変更した瞬間、ゼロからやり直しになるリスクがある。また、自社の営業データと営業プロセスの詳細を外部に渡すことのセキュリティリスクも無視できない。

GTMエンジニアが解決する3つのユースケース

では、GTMエンジニアがいれば具体的に何が変わるのか。3つの実践的なユースケースで示す。

ユースケース1：リードの自動エンリッチメントと即時アサイン

課題: Webフォームからのリード情報が名前とメールアドレスだけ。営業担当者が手動で企業情報を調べ、上長が手動でアサインしている。リードの対応開始まで平均48時間。

GTMエンジニアの実装:

• Webフォーム送信をトリガーに、企業データベースAPI（法人番号API等）を使って自動で企業規模・業種・所在地を取得
• スコアリングロジックを実装し、スコアに応じて担当者を自動アサイン
• 担当者のSlackに即時通知、Googleカレンダーにフォローアップタスクを自動登録

結果: リード対応開始時間が48時間から15分に短縮。初回アポイント率が1.8倍に向上。

ユースケース2：商談進捗の自動追跡と異常検知

課題: 営業マネージャーが週次の1on1で商談状況をヒアリングし、手動でパイプラインを更新。停滞案件の発見が遅れ、失注が増えている。

GTMエンジニアの実装:

• メールの送受信データとカレンダーのミーティング履歴をCRMに自動同期
• 一定期間アクティビティがない商談を自動検出し、マネージャーにアラート通知
• 商談ステージごとの平均滞留日数を超過した案件を自動でフラグ付け

結果: 停滞案件の発見が平均2週間早まり、四半期の失注率が12%改善。

ユースケース3：営業ナレッジのAI自動構造化

課題: トップセールスのノウハウが属人化している。新人の立ち上がりに6ヶ月以上かかる。

GTMエンジニアの実装:

• 商談録画ツール（tldv等）のトランスクリプトをLLM（Large Language Model / 大規模言語モデル）で自動要約
• 「課題ヒアリング」「提案内容」「懸念への対処」などの構造でタグ付け
• 商談ステージ別のベストプラクティスとして自動でナレッジベースに蓄積

結果: 新人の初受注までの期間が6ヶ月から3.5ヶ月に短縮。

営業企画からGTMエンジニアへのキャリアパス

ここまで読んで「自分も営業企画の限界を感じている」と思った方もいるだろう。営業企画の経験者がGTMエンジニアへとキャリアを拡張するパスは確実に存在する。

ステップ1：CRMの「管理者権限」を握る（0〜3ヶ月）

まず、自社のCRM（HubSpotやSalesforce）の管理者権限を取得し、ワークフロー設定やプロパティ作成を自分で行えるようにする。CRMの管理画面はノーコードで操作できるため、プログラミング経験がなくても始められる。

ステップ2：iPaaSツールで「つなぐ」力を身につける（3〜6ヶ月）

n8n、Zapier、Makeなどのツールを使い、CRMと他のツール（Slack、Gmail、スプレッドシート等）の連携を構築する。APIの基本概念とJSONの読み方を覚えれば、かなりの範囲の自動化が実現できる。

ステップ3：PythonまたはJavaScriptの基礎を習得（6〜12ヶ月）

ノーコードツールでは対応できない複雑なロジックやデータ加工が出てきたら、スクリプティングの出番だ。完璧なプログラマーになる必要はない。API呼び出し、CSV処理、簡単なデータ変換ができれば、営業プロセスの自動化において強力な武器になる。

ステップ4：AI/LLM活用に踏み込む（12ヶ月〜）

ChatGPT API（OpenAI API）やClaude API（Anthropic API）を営業プロセスに組み込む実装力を身につける。メール文面の自動生成、商談議事録の要約、リードの自動分類など、AI活用の実装ができるGTMエンジニアは市場価値が極めて高い。

まとめ

SalesOps（営業企画）が不要なのではない。営業企画の「設計力」は、GTMエンジニアの前提条件として不可欠だ。問題は、設計と実装の間にある深い溝を、日本企業の多くが埋められていないことにある。

GTMエンジニアは、その溝を自ら埋める存在だ。営業プロセスを理解し、テクノロジーで即座に形にする。営業DXが「スローガン」から「実行」に変わるために必要なのは、もう一つの戦略文書ではない。手を動かして仕組みを作れる人材だ。

営業企画として培った業務知識は、GTMエンジニアとしてのキャリアにおいて最大の差別化要因になる。足りないのは技術力だけ——そしてそれは、今から身につけられるものだ。