「AIを入れたのに、売上が変わらない」の正体

生成AIを現場に配った。ツールも増やした。それでも売上の伸び方は変わっていない。そういう声をよく耳にします。

SFAもMAも入っています。ダッシュボードを開けば、商談化率も、ファネルのどこで落ちているかも見えます。それなのに、数字が動かない。

原因の多くは、AIの性能でも、ツールの選定ミスでもありません。見えるようになった、その先が空白のままだからです。

商談化率が下がっていると分かる。どのセグメントで落ちているかも分かる。しかし、それを受けて誰に何を届けるかは、結局のところ現場の担当者が手で判断して、手で実行している。整えることと、見えるようにすることは進みました。動かすところが、人の手に残ったままなのです。

この空白を埋める役割に、海外では名前が付き、採用が急増しています。GTMエンジニアです。

本レポートでは、この職種が既存のRevOpsや営業企画と何が違うのかを整理し、実際に何を作るのかを、データ・AI・システムの三つのレイヤーとして示します。そのうえで、自社で何から着手すべきかまで踏み込みます。

RevOpsと、何が違うのか

収益最大化を担う本来の機能は、RevOps（レベニューオペレーション）です。営業・マーケティング・カスタマーサクセスの各オペレーションを横断し、データ・プロセス・システム・組織を統合・最適化して、顧客価値と収益を最大化する機能を指します。

国内でRevOps専任を置いている会社は多くありませんが、機能としては営業企画や販促企画、情報システム部門が部分的に担っているはずです。

この機能が担うべき役割は、次の三つに整理できます。

役割内容問い
① 統合・最適化データ、ツール、業務プロセス、部門間の引き渡しを整える正しく、無駄なく動けるか
② 可視化・分析・意思決定支援KPI、ファネル、顧客状態、予測を把握し、意思決定に必要な材料を提供する何が起きており、何を検討すべきか
③ 収益プロセスの設計・改善決定されたGTM戦略を、顧客接点と業務フローへ落とし込み、実行結果から改善するどう動かし、伸ばすか

多くの企業は、①と②で止まっています。

冒頭で述べた状態が、まさにこれです。データは繋がり、ダッシュボードは整った。しかし③、つまり決めた方針を現場で動く仕事の流れに変えるところは、担当者の力量と気合いに委ねられている。

整える。見える化する。それだけでは、収益は動かない。

商談化率が下がっていると分かっただけでは、数値は改善しません。優先すべきリードの条件、連絡のタイミング、営業への引き渡し、フォローの内容を設計し、現場で実行できる形にする必要があります。ここまでやって、初めて数字が動きます。

GTMエンジニアリングは、この③を、データ・AI・システムによって強化する実装機能です。米国のベンチャーキャピタルNorwest Venture Partnersの解説（What Is a GTM Engineer?）は、この違いを「RevOpsは維持し最適化する。GTMエンジニアは新しいシステムを作る」と端的に整理しています。

誤解のないように申し添えると、これはRevOpsを否定する話ではありません。①と②がなければ、③は成立しないからです。データが不正確なら、AIの判断も誤ります。プロセスが曖昧なら、誤った処理を速く広げるだけになります。違いは組織名ではなく、意思決定を実際に動く収益プロセスへ変えられているかにあります。

すでに③まで担えている組織であれば、GTMエンジニアリングはAIによって実行できる範囲を広げ、業務の量・質・速度を高める役割になります。

GTMエンジニアとは何者か

一言でいえば、市場や顧客のシグナルを捉え、データ・AI・システムを横断して、収益プロセスを設計・実装・改善する人です。

まず、紛らわしい2つの言葉を整理させてください。GTMエンジニアリングが営み（何をするか）で、GTMエンジニアがそれを担う人です。以降、この区別で進めます。

GTMエンジニアリングは「自動化」では狭すぎる

GTMエンジニアリングは、もともと収益プロセスの自動化を指す言葉でした。外部データ、シグナル、ワークフロー、AI。これらを掛け合わせて、インサイドセールスや営業が手で進めていた業務を自動化する。この文脈から言葉は広まり、いまもこの意味で語られることが少なくありません。

ただ、その範囲は広がっています。

この言葉を最初に広めたClayの解説（GTM Engineering: What It Is and How to Hire in 2026）は、GTMエンジニアがRevOps・グロース・カスタマーサクセスの三領域を横断して働くとしています。米国のベンチャーキャピタルGradient Venturesの論考（The Rise of the GTM Engineer）は、この役割をリード獲得やアウトバウンドの自動化に限定する見方を明確に「狭い」と退け、顧客ライフサイクル全体を対象とすべきだと論じます。

前述のNorwestを含め、三者に共通しているのは、次の三点です。

  • ツールの導入ではなく、システムの構築であること
  • 顧客ライフサイクル全体が射程にあること
  • AI・データ・ワークフローを組み合わせること

当社は、この広い意味のほうを採っています。

GTMエンジニアリングとは、データ・AI・システムを組み合わせ、GTMプロセスを自動化・最適化することで、再現性のある収益システムへと進化させる活動である。

「ツールをつないで自動化する」との違いは、対象範囲だけではありません。作ったものを運用し、改善し続けるところまでが含まれる点です。自動化は完成したら終わりますが、収益システムは市場が変われば作り替える必要があります。

自動化は、実行できる量とコストを変えます。最適化は、誰に、いつ、何を届けるかの精度を変えます。GTMエンジニアリングは、この両方を扱います。

仕組みの中身は「シグナル→評価→行動」

GTMエンジニアが作る仕組みは、三つの動きでできています。市場や顧客の変化をシグナルとして捉える。そのシグナルが何を意味し、どれを優先すべきかを評価する。評価の結果を、人・AI・システムの行動につなげる。

シグナルとは、市場や顧客に起きた「変化」や「差分」のことです。顧客が自ら示すもの（Webの閲覧ページ、サイト内検索やチャットの質問、資料への反応、プロダクトの利用量）もあれば、外から捉えるもの（採用の動き、組織や体制の変更、資金調達、検索需要や競合の変化）もあります。評価は、点数を付けることだけではありません。ルールでの判定やAIによる分類を組み合わせ、自社に合う相手か、今動くべきか、どう働きかけるかまでを決めます。

同じAIツールや同じ外部データは、競合も使えます。差がつくのは、自社ならではのシグナルを捉え、自社の基準で評価し、他社とは違う行動に変えられるかどうかです。GTMエンジニアは、この流れを一つずつ設計し、動く形にしていきます。

自社の「営業企画」と、どう違うのか

国内で、RevOps専任を置いている会社はほとんどありません。近いのは営業企画や販促企画でしょう。この違いが、採用や体制を考えるときの実務的な論点になります。

営業企画・販促企画GTMエンジニア
主な仕事数字の集計、施策の企画、会議体の運営収益プロセスを動かす仕組みの設計・構築
扱うもの出てきたデータデータが出てくる経路そのもの
成果物レポート、施策案稼働し続けるシステム
射程多くは営業組織の中マーケからカスタマーサクセスまで横断

営業企画のレポートは、「何が起きたか」を人に伝えるところで終わります。GTMエンジニアは、その数字の変化そのものをシグナルとして拾い、評価し、次の行動が自動で始まるところまでを作ります。営業企画は、施策の企画と、仕組みが拾えない例外の判断に時間を使えるようになります。対立ではなく、分業の組み替えです。

ソフトウェアエンジニアとの違いも押さえておきます。SQLとPythonでデータを扱い、APIを叩き、CRMやデータウェアハウスをつなぐ。技術スタックは重なりますが、作るものが違います。顧客に届けるプロダクトではなく、社内の営業・マーケティング・カスタマーサクセスが動く仕組みを作る。評価されるのもコードの品質ではなく、商談数や受注率、拡大売上といった事業の数字です。

GTMエンジニアが作るのは、プロダクトではありません。売れる仕組みです。

GTMエンジニアに求められる四つのスキル

では、そのために何が求められるのか。四つのスキルに整理できます。ビジネス設計力、データ設計力、AI活用力、システム実装力です。

GTMエンジニアに求められる4つのスキル：ビジネス設計力、データ設計力、AI活用力、システム実装力

四つすべてを一人で揃える必要はありません。エンジニア出身の方はAIとシステムに、営業企画やマーケティング運用の出身の方はGTMの設計とデータに、強みを持つことが多いはずです。どちらの出身でも、足りない側を伸ばせば、この役割を担えます。

GTMエンジニアは何を作るのか ── データ・AI・システムの三つのレイヤー

GTMエンジニアが作る収益システムは、データ・AI・システムの三つのレイヤーを組み合わせて動きます。先ほどの③は、どれか一つのレイヤーに置くものではありません。三つのレイヤーをまたいで、シグナルから評価、行動までを一本の流れとして通すこと。それが③を実装するということです。

レイヤー担うことこれが無いと起きること
データレイヤー市場・顧客・競合・利用状況の事実と知識を、共通の顧客キーで揃え、AIが使える状態にする出力が一般論になり、信用されなくなる
AIレイヤーデータからシグナルを捉え、意味と優先順位を評価し、次の行動を組み立てる見えても判断が仕組みにならず、人が手で決め続ける
システムレイヤーCRM・MA・広告・メールなどの顧客接点で行動を実行し、結果を記録する施策が担当者の手作業に戻る

冒頭で触れた「AIを入れたのに売上が変わらない」は、データレイヤーとAIレイヤーを飛ばして、システムレイヤーの個別作業だけを速くした状態だと考えると、説明がつきます。部署の中の作業は速くなるが、部署と部署の間は人が運んだままなので、事業の数字は動きません。

データレイヤー：AIが使える形にデータを揃える

GTMのデータは、性質の違う二種類に分かれます。

ひとつは構造化された数値データです。CRMの顧客・リード情報、MAのアクセス・行動ログ、商談履歴と受注データ、プロダクトの利用ログ、外部の市場・競合データ。もうひとつは非構造化の知識データです。仕様書、提案資料、FAQ、事例、業界のノウハウ。人の頭と、誰も開かないフォルダの中にあるものです。

前者はデータレイクやDWH（データウェアハウス）に統合し、後者はRAG（検索拡張生成、外部の文書を検索してAIの回答に反映させる仕組み）として参照できる基盤に載せます。

この層で、最初に経営として決めるべきことがあります。何を主キーにするか。つまり、1つの会社を一意に特定する番号を何に決めるか、です。

同じ会社が、CRMには「株式会社ABC」、MAには「ABC（株）」、請求システムには自社の顧客コードで入っている。この状態では、どのシステムの数字も突き合わせられません。法人番号（国税庁が全法人に付与する13桁の番号）を使うのか、企業ドメインを使うのか、自社の顧客コードに寄せるのか。ここが決まっていない会社は、どのベンダーに頼んでも同じところで止まります。当社が自社のデータ基盤で法人番号13桁を主キーに据えているのも、この理由からです。

そのうえで、決めた主キーで各システムを突き合わせ、APIやMCP（Model Context Protocol、AIが外部システムを参照するための接続規格）でつなぎます。外部データで欠けている情報を補い、重複や表記ゆれを解消して、使える品質に揃えます。

重要なのは、全部を揃えようとしないことです。最初に手を付ける業務が使う範囲だけ、主キーで寄せる。全社のデータ統合を先に終わらせようとすると、たいてい終わりません。

AIレイヤー：評価し、行動を組み立てる

揃えたデータの上に、AIが判断して動くための土台を置きます。多くの組織では、RevOpsの取り組みは②の判断材料を揃えるところで止まっています。GTMエンジニアリングは、その判断材料を評価にかけ、行動まで動かすところを作ります。

具体的には、次の四つを作ります。

  • シグナルの定義：何の「変化」を見るかを決める。Web訪問やチャットの質問、利用量の低下、組織変更や採用、問い合わせの内容など、ふだん人が経験で嗅ぎ取っている変化を、機械が検知できる形にする
  • 評価：そのシグナルが何を意味し、どれを優先するかを判断する。スコアだけでなく、ルール判定やAIによる分類を組み合わせ、自社に合うか・今か・確度はどうかを見る
  • 行動の組み立て：評価の結果を受けて、誰が、何を、いつ行うか。人とAIの役割分担、承認、例外処理まで決める
  • セキュリティとガバナンス：権限・ログ・監査を担保する

これまで人の頭にあった判断基準を、機械が評価できる形にして、行動まで組み立てる。人が経験で判断し、手で動かしていたものを、ここに載せ替えます。

この層があって初めて、AIエージェントは「状況を理解し、判断し、実行する」ところまで担えます。逆にここが無いまま生成AIを現場に配っても、個々の業務は速くなりますが、収益の流れそのものは変わりません。

システムレイヤー：顧客接点で実行する

AIレイヤーで組み立てた判断が、CRM・MA・広告・メールといった顧客接点のシステムで実行されます。

顧客シグナルをもとにパーソナライズされたメールが自動で届く。提案に必要な情報の収集や資料作成が自動化される。顧客の利用状況や解約リスクが可視化され、いま取るべきアクションが提案される。

ここだけを見ると、部署ごとの自動化に見えます。ただ、AIレイヤーがあるかないかで意味がまるで変わります。AIレイヤーがなければ、それぞれの部署が自分の持ち場を速くしただけです。AIレイヤーがあれば、見えた情報がそのまま次の行動になり、収益プロセスとして動き出します。

海外の先行事例から実態を捉える

では実際に、何が起きているのか。3つの収益プロセスの順に、海外の事例を見ていきます。

なお、あえて組織名ではなくプロセスで並べています。営業組織を持たないプロダクト主導（PLG）型の企業では、組織名で語ると当てはまらなくなるからです。組織がなくても、プロセスは存在します。

マーケティング｜Anthropic

Anthropicのグロースマーケティングチームは、Claude Codeで広告制作のワークフローを構築しました（How Anthropic uses Claude for marketing、How Anthropic teams use Claude Code）。数百本の広告の成績データから成績の悪い広告を洗い出し、文字数制約を守った新案を作る仕組みと、Figmaで最大100パターンを一括で作るプラグインを組んでいます。担当者の一人は、それまでコードを書いたことがなかったといいます。本人の言葉では、広告1本に30分かかっていた作業が30秒になりました。

ここで繋がったのは分析と制作の間です。「どの広告が効かなかったか」という分析結果が、これまでは人の解釈を経て次の制作に渡っていました。それが直接繋がった。そして繋いだのは、業務を最もよく知る本人でした。実装のハードルが下がると、誰が設計者になれるかが変わります。

営業｜Vercel（インサイドセールス）

Vercelで注目すべきは、商談データの扱い方です。SaaStrの取材記事（How Vercel Runs on AI Agents）によると、通話が終わるとWebhookでワークフローが起動し、書き起こしをAIが構造化します。論点、反論、商談ステージ、関係者を抽出して検索基盤に蓄積し、他のツールが同じコンテキストを参照する。

一度構造化したデータが、別の用途で何度も使われる設計です。商談で得た文脈が、次のプロセスでもそのまま使える形になっています。

インバウンドの一次対応にもAIエージェントを入れています。Tomasz Tunguz氏の記事（Vercel's AI Sales Agent: 10 SDRs Down to 1 in Six Weeks）によれば、同社はインバウンドSDR10人体制を6週間で組み替え、9人をアウトバウンドへ配置転換しました。リードから商談への転換率は横ばいのまま、初動のスピードは改善しています。

営業｜OpenAI（商談準備）

OpenAIは、GTM Assistantという社内向けの仕組みを構築しました。同社の発表（OpenAI GTM Assistant）によれば、顧客情報、商談の会話、社内ナレッジを連携させ、Slack上で商談前のブリーフ、通話後の要約、出典付きの製品Q&Aを担当者に届けます。

特徴的なのは、トップ担当者を巻き込んで「良い出力とは何か」を評価基準として定め、毎週、出力のサンプルを専門家が点検して、足りない知識や品質を仕組みに戻し続けたことです。トップ営業の頭の中にあった判断が、仕組みの中に組み込まれ、全員に渡るようになりました。

GTMチームが1年で3倍に拡大するなかでも、担当者は平均で週22回この仕組みとやり取りし、生産性は約20%（週あたり約1日分）高まったとしています。人を減らす話ではなく、急拡大する組織で立ち上がりを早め、成果のばらつきを抑えた事例です。

カスタマーサクセス｜HappyFox

HappyFoxは、サポートチケットがクローズされるたびにAIエージェントが全件を読み、AI導入の兆しや部門横断での利用拡大、買収といった拡張シグナルを抽出する仕組みを作りました。SaaStrの取材記事（How HappyFox Closed $1M in Expansion on a $20 AI Agent Spend）によると、最初はサポート担当が確認する監督モードから始め、確度の高いものだけを営業へ通知。その後、過去5年分の営業・オンボーディングの通話記録にも対象を広げています。

結果、1月から3月の3カ月間に、AIエージェントを起点として100万ドルの拡張売上が受注に至りました。エージェントの費用は20ドル未満です。CEOは「B2B企業を13年経営してきて、20ドルの投資で100万ドルのリターンは見たことがない」と語っています。

この事例が分かりやすいのは、②で止まらなかったことが明確だからです。サポートの会話から拡張シグナルを抽出するだけなら、それはレポートです。ダッシュボードに「拡張の見込みがある顧客リスト」が並ぶだけで終わったかもしれません。しかし彼らは、そのシグナルが営業のパイプラインに入り、商談として動き出すところまでを作りました。それが100万ドルの売上につながりました。

共通しているのは、「見えた」で止めなかったこと

この4つの事例は、一見すると別々の自動化に見えます。しかし、どれも「見えるようにした」で止まっていません。見えたものが、そのまま次の行動になるところまでを作っています。

Anthropicは分析の結果を次の制作へ。Vercelは商談で得たデータを他の業務へ。OpenAIはトップ営業の判断を全員へ。HappyFoxはサポートの会話を営業のパイプラインへ。いずれも③まで到達しています。

事例シグナル評価行動
Anthropic数百本の広告の成績成績の悪い広告を特定制約を守った新案を作り、Figmaで一括制作
Vercel商談の会話、インバウンドの問い合わせ論点・反論・ステージを構造化し、一次対応を判断他の業務で再利用、一次応答と振り分け
OpenAI商談予定と顧客の履歴、社内ナレッジトップ担当者の基準で出力を評価商談前ブリーフ、要約、製品Q&AをSlackに届ける
HappyFoxクローズしたチケットに出る拡張の兆し監督モードで確度の高いものだけ選別営業へ通知し、パイプラインへ

どの事例も、同じAIを使っています。違いは、何をシグナルとし、どの基準で評価したかにあります。

GTM Consortium（Pavilion・GTM Partners・Winning by Designの3社が立ち上げた団体）は、2024年に公開した宣言（The GTM Manifesto）で、企業が陥る停滞を「5つのGTMの死の谷」として整理しました。作れるが需要を作れない。需要はあるが売れない。売れるが届けられない。届けられるが更新されない。更新されるが拡大しない。

重要なのは、この5つが見えていないから起きているのではないということです。多くの企業は、需要が作れていないことも、更新されていないことも、ダッシュボードで把握しています。把握したうえで越えられない。動かす仕組みがないからです。

可視化と収益創出を分ける線は、ここにあります。見えた情報を、誰かの次の行動につなげるところまで作ったかどうか。

なお同宣言は、GTMの定義も示しています。「収益を生む戦略と、顧客が価値を受け取る体験とを接続する、一連のプロセスと活動」。ローンチの計画ではなく、プロセスと活動の集合。接続する先は「販売」ではなく「顧客が価値を受け取る体験」です。当社がGTMを「マーケティング・営業・カスタマーサクセスを通じて、市場・顧客と関わり、収益を生み続ける活動全体」と定義しているのも、同じ捉え方です。

国内でも、兆しは生まれている

「海外の話でしょう」と思われたかもしれません。しかし、国内でも動きは始まっています。そして重要なのは、エンジニア組織を持たない会社でも起きていることです。

肩書きは、後から付いた

今年7月に開催された「PMM JAPAN CONFERENCE 2026」で、私はGTMエンジニアをテーマにしたパネルディスカッションのモデレーターを務めました。冒頭で「GTMエンジニアを聞いたことがある方」と挙手を求めたところ、手が挙がったのは約1割。9割近くの方にとって、初めて聞く職種名でした。

しかし、名前を知られていないだけで、その仕事はすでに動いています。

オープンエイトでデータスペシャリストを務める吉田氏は、ProductZineの記事（勝ち筋を「設計する」のがPMMなら、「実装する」のは誰か）で、こう語っています。「私の会社、まだGTMエンジニアという言葉はないんですよ。『吉田がやっています』みたいな感じ」。

コスト改善と業務効率化を追ううちに、気づいたらGTMエンジニアが見る役割を担っていた、と。吉田氏はSFAの内製化で年間数百万から数千万円の固定費を削減し、その分を売上を作る施策へ投資して目標達成につなげています。

興味深いのは、吉田氏自身が「全然コードとかも書けない」と語っていることです。実装を担うのはAIで、人が担うのは要件の言語化と、改善サイクルの設計でした。

LayerXでプロダクトマネージャー兼GTMエンジニアを務める守屋氏も、ProductZineの同じ記事（勝ち筋を「設計する」のがPMMなら、「実装する」のは誰か）で「GTMエンジニアという肩書きが先にあって、それに合う人がアサインしたというプロセスではない」と明かしています。先に素地があり、営業プロセスに関与するうちに「こういうことができる人がもっと必要だ」と明らかになり、あとから名前が付いた。順序が逆なのです。

同社では、手動で共有していた月2,000件ほどの顧客要望を自動化したところ、共有される要望が1.5万件を超えるまで増えました。顧客の声がプロダクトへ渡る経路を作ったら、流量が7倍以上になりました。

職種としての受け皿もできている

LayerXは、バクラク事業で「GTMエンジニア」のポジションを正式に開設しました。同社VP of Productの飯沼氏の記事（LayerX バクラク事業にてGo To Marketエンジニアの採用を行います）は、この職種を「エンジニアリングによってビジネスプロセスにレバレッジを効かせる」役割と説明したうえで、ポイントはコストを削減するのではなく収益をあげる点だと書いています。

overflowの発表（Offers、新職種「GTMエンジニア」を国内の転職サービスで初めて選択可能に）によれば、エンジニア転職プラットフォームのOffersが、国内の転職サービスとして初めて「GTMエンジニア」を職種カテゴリに追加しています。国内の想定年収は800万〜1,500万円です。

海外の水準はさらに上です。求人を追跡しているOneGTMの集計（GTM Engineer Jobs: Live Tracker and Hiring Trends）では、この職種の求人は2024年の63件から、2025年には3,300件超へと、1年で50倍以上に増えました。給与は、Cargoの分析（GTM Engineer Salary）によれば、2026年4〜7月に給与を開示した米国の求人509件の中央値が15万9,000ドルです。

ただし、ここまで見てきたとおり、新しい専門職を採用することは、始めるための前提条件ではありません。多くの企業は、この役職をもともと定義していたわけではなく、収益システムに向き合った結果、役割が生まれてきました。

自社では、何から着手すべきか

最初に着手すべきことを3つに絞ってお伝えします。順番に意味があります。

この3つは、GTMエンジニアリングの進め方そのものです。課題を特定し、収益へのインパクトと実現しやすさで優先順位を決め、新しい業務の流れを設計する（Design）。必要なデータを揃え、シグナルと評価を定義し、行動まで動く形にする（Build）。動かした結果を見て、シグナルと評価の当たり外れを検証し、効いた流れを次の業務へ広げる（Run & Improve）。

1. 最も大きな収益ボトルネックを、1つ選ぶ

自社のダッシュボードを開いて、「この数字を見たあと、誰が何をしているか」を追いかけてみてください。多くの場合、そこから先は人が手で判断し、手で動かしています。その手作業が、空白になっている③です。

商談数が足りないのか、受注率が低いのか、解約が多いのか。動かしたい数字を1つ決めます。範囲を欲張らないことが重要です。

選んだ数字によって、作るものは変わります。商談数なら、優先すべきリードの条件と、ナーチャリングから営業への引き渡し。解約なら、利用状況と問い合わせ履歴からリスク兆候を検知し、カスタマーサクセスが動く流れ。

2. その業務に必要な範囲だけ、データと判断基準をそろえる

全社のデータ基盤を作ってから始める必要はありません。

ここでいう「最小限」は、データを無条件に減らすことではありません。対象にする業務を絞り、その業務を動かすうえで必要な情報、判断基準、責任者をそろえるという意味です。既存リードへの対応であれば、同じ顧客を識別できること、過去の接触状況を確認できること、次の対応を担う人が決まっていること。この3つが出発点になります。

全社基盤の構想から入ると、たいてい何も動かないまま1年が過ぎます。小さく通した経路は、次の業務でも再利用できます。

3. 何が変われば前進か、先に決めておく

仕組みが動いたという確認と、成果につながったという検証は、別物です。

対応を早めることが目的なら、対応までの時間に加えて、商談化の状況まで見ます。カスタマーサクセスの介入を改善するなら、リスクの検知件数だけでなく、実際に支援につながったか、その後の顧客状態がどう変わったかを見る。ここを決めずに始めると、「動いてはいるが、効いているか分からない」状態になります。結果は、次のシグナルと評価の精度を上げる材料として、仕組みに戻します。

なお、設計者は、その業務を最もよく知っている人に置いてください。実装を外部のパートナーや情報システム部門に任せることは、まったく問題ありません。精度が落ちるのは、要件まで外に出したときです。どこで何が止まっていて、何が変われば仕事が進むのか。これを言語化できるのは現場だけです。

実践ポイント ・全社の基盤構想から入らず、動かしたい数字を1つ決めて小さく始める ・必要なのは、情報・判断基準・責任者の3点セット ・実装は外に出してよい。要件は現場が書く

オープンエイトの吉田氏が「コードは書けない」と語りながら成果を出したように、いまいる人と、すでにあるデータや仕組みから始められます。専任のGTMエンジニアを採用するのは、その後で構いません。

まとめ：見えている。動いていないだけ

GTMエンジニアとは、市場や顧客のシグナルを捉え、データ・AI・システムを繋いで、収益を生む仕組みを作り出す人です。作るのはプロダクトではなく、売れる仕組み。評価されるのはコードではなく、事業の数字です。

RevOpsが担うべき三つの役割のうち、多くの企業は①統合・最適化と②可視化・分析で止まっています。そして③収益プロセスの設計・改善が空白のまま、AIツールだけが配られている。これが「AIを入れたのに売上が変わらない」の正体です。

SFAもMAも導入済みで、ダッシュボードも整っている。見えてはいます。動いていないだけです。そう捉え直すと、次に投資すべき場所が変わります。

まずは自社のダッシュボードを開いて、その数字を見たあと誰が何をしているかを、一度追いかけてみてはいかがでしょうか。

ご相談について

当社は、GTMの実践知とエンジニアリングを掛け合わせ、事業の実行力を引き上げることを仕事にしています。

どこから手を付けるべきか判断に迷う場合は、GTMアーキテクチャ診断をご用意しています。現状のGTMプロセスとデータを棚卸しし、①〜③のどこが空白になっているか、どこから着手すれば数字が動くかを整理してお渡しします。

まずは現状をお聞かせください。お問い合わせはこちら

参考情報