「営業を増やしても売上が伸びない」中堅B2Bへ——海外で急拡大する『GTMエンジニア』という新職種から見える次の一手

はじめに：人を増やす号令を、もう何度出しただろうか

「来期は営業を10人増やす」「インサイドセールスを倍にする」——中堅上場企業の事業部長や事業本部長の方々と話していると、こうした打ち手がここ数年、繰り返し語られてきたように感じます。それでも売上の伸びが期待ほどではない、という声も同じくらい多く耳にします。

人を増やしても、思ったほどパイプラインが太くならない。CRM（顧客管理システム）には案件が入っているはずなのに、現場感覚と経営ダッシュボードの数字が一致しない。マーケが集めたリードの大半が営業に渡る前に止まっている——。「人を足せば成長する」という前提そのものが、静かに賞味期限を迎えつつあるのではないでしょうか。

その変化を最も先鋭的に映し出しているのが、海外で急速に立ち上がりつつある「GTMエンジニア（Go-To-Market Engineer）」という新しい職種です。日本ではまだほとんど知られていませんが、北米のBtoB企業の現場では、この1〜2年で求人数が2倍に拡大しているとされます。

本稿では、この新職種の輪郭を整理した上で、日本の中堅B2B企業の事業責任者にとって、何がヒントになるのかを考えてみたいと思います。結論を先にお伝えすると、答えは「GTMエンジニアという人を急いで採れ」ではありません。むしろその手前にやるべきことがあります。そこが本稿の要点です。

1. 海外で起きているのは「人で売る」から「仕組みで売る」への構造シフト

求人が半年で倍増した職種

GTMエンジニアという職種名は、2023年にデータエンリッチメントツール「Clay」の社内で生まれたとされています。当時、ClayではRevOps（レベニューオペレーション：収益プロセス全体の最適化を担う職能）、インサイドセールス、データ分析を一人の担当者が兼務しており、その「複数ツールを束ねて回す配管工」的な役割に名前が必要になったことがきっかけです。

そこからわずか2年。LinkedInに掲載される「GTM Engineer」関連の求人数は、2025年中頃の約1,400件から2026年1月には3,000件超へと、半年で約2倍に拡大しています（GTM Strategistの調査（The 2026 State of GTM Engineering）、北米中心）。OpenAI、Stripe、Vercel、Ramp、Figmaといった、いま最も成長している米系テック企業群が積極的に採用に動いています。

絶対数としての3,000件は、米国労働市場全体で見れば決して大きな数字ではないかもしれません。ただ、「半年で倍」という変化率は、新しい職種が市場に定着しつつあることを示す典型的なシグナルです。市場が「これは一過性の流行ではない」と判定し始めている、と読んでよいと思います。

なぜ「いま」立ち上がったのか

この職種の急拡大は、偶然の産物ではないと考えています。背景には、3つの構造的な圧力が同時にかかっています。

ひとつは、顧客獲得コスト（CAC：Customer Acquisition Cost）の上昇圧力です。Benchmarkitのレポート（The 2025 B2B SaaS Operating Metrics Report）によれば、米系B2B SaaSのS&M効率（Magic Number、新規ARRに対する販管費効率の指標）は中央値で約0.5、つまり新規ARR（年間経常収益）1ドルを獲得するために営業・マーケティングへ約2ドルを投じる構造が一般化しています。「人を雇って解決する」モデルでは、もはや経済合理性が成立しにくい水準まで来てしまっているわけです。

ふたつめは、マーテック（マーケティング・テクノロジー）ツールの爆発的増加です。2025年時点でその数は15,000を超え、平均的な中規模企業でも150種類以上のソフトウェアを業務に組み込んでいるとされます。ツールが増えるほど、それらを「つなぐ人」がいないと、データはサイロに閉じ込められたまま動きません。

みっつめは、AIと自動化ツールの民主化です。Clay、Make、n8n、AIセールスシーケンサーといったツールの登場で、かつてエンジニアリングチーム総出だった作業を、ビジネス側の人間が一人で組み上げられる土壌ができました。

この3つが重なったところに「人を足すのではなく、仕組みを設計する」という発想の担い手として、GTMエンジニアという職種が立ち上がってきた——というのが、海外で起きていることの全体像だと言えるでしょう。

2. GTMエンジニアとは何をする人なのか

「収益を生む機械を作るエンジニア」

GTMエンジニアを一言で表すなら、「収益を生む機械を作るエンジニア」と言えると思います。

プロダクトエンジニアがプロダクトそのものを作るように、GTMエンジニアは「売れる仕組み」そのものを作ります。CRMを整備し、見込み客リストを自動生成し、パーソナライズされたアウトバウンドを送信し、その反応をダッシュボードに即時反映させる——こうした一連のシステムを、一人で設計から実装まで担える人材です。

必要なのは、技術力だけでも、営業・マーケティングの土地勘だけでもありません。両方を併せ持ち、「ビジネスの課題をシステムで解く」ことができる、ハイブリッドな人材です。事業責任者の右腕として、属人化したオペレーションを仕組みに置き換えていく現場寄りのエンジニア、という言い方もできるでしょう。

既存職種との違いはどこにあるのか

ここで多くの方が抱く疑問が、「それはRevOpsやマーケティングオペレーションと何が違うのか」ではないでしょうか。実際、職務記述書だけ見れば重なる部分は少なくありません。

ただ、決定的に違うのは「成果物の性質」です。RevOpsやマーケティングオペレーションが今あるプロセスをどう改善するかを仕事の主軸に据えているのに対し、GTMエンジニアは今ないシステムをどう構築するかを仕事の主軸にしています。一言で対比するなら、RevOpsはダッシュボードを診て詰まりを指摘する「診断医」、GTMエンジニアは詰まった配管そのものを切り開いて作り直す「外科医」に近い役割です。両者は対立関係ではなく、補完関係にあります。

GTMエンジニアの位置づけ既存職種は「改善」、GTMエンジニアは「構築」を担う縦軸：成果物の性質　／　横軸：カバー範囲マーケのみ営業＋マーケGTM全体横断構築・実装改善・運用GTM Engineerないものを作る横断 × 構築RevOpsあるものを改善プロセス最適化Marketing Opsマーケ領域に閉じる改善＋一部実装Sales Engineer顧客対面（社外）
図1：横軸にカバー範囲（マーケ単独〜GTM横断）、縦軸に成果物の性質（改善〜構築）をとると、GTMエンジニアは「横断 × 構築」という、これまで空白だった象限を一人で担う職種であることが見えてくる。既存職種と競合するというより、空白を埋める存在に近い。

報酬水準が映し出す市場の本音

もうひとつ印象的なのが、同じ肩書のなかでの報酬のばらつきです。FullFunnelが米国の現役GTMエンジニア228人を対象に行った調査（The State of GTM Engineering Talent in 2025）によれば、HubSpotとClayを中心にツール運用を行うタイプの平均年収は約$108,500、Pythonでカスタムスクリプトを書き自社専用のシステムを実装するタイプは約$210,000と、約2倍の差が生まれています。

同じ肩書でも報酬は約2倍——市場が払っているのは「実装力」FullFunnel 2025年調査・米国GTMエンジニア228人の平均年収$108,500ツール運用中心HubSpot＋Clay「使いこなす」層$210,000実装中心Python＋API活用「設計して作る」層約 +$100,000約1,500万円の差
図2：「肩書」ではなく「実装の深さ」に対して報酬が払われている。この約2倍の格差は、市場が求めているのが『ツール管理者』ではなく『システム設計者』であるという事実を、報酬という最も明快な形で物語っている。

市場が払っているのは肩書ではなく、実装の深さだ——この事実が報酬という最も明快な形で表れているのが興味深いところです。「ツールを並べただけでは価値は出ず、つなげて動かして初めて価値になる」という市場全体の合意が、ここに映し出されていると言えるでしょう。

3. 日本の中堅B2Bを覗くと見えてくる、もう一つの「同じ景色」

ここまで読んで、「面白い話だが、米系テックの話だろう」と感じた方もいらっしゃるかもしれません。ただ、私自身が中堅企業の事業責任者の方々とお話ししていて感じるのは、「人で売る」モデルの限界はすでに日本でも来ているということです。GTMエンジニアという職種名がないだけで、起きている現象は驚くほど似ています。

「データはあるのに、判断には使えない」

典型的なのは次のような構図です。マーケティング部はHubSpotやMarketoでリードを集めている。営業部はSalesforceやkintoneに活動を入力している。経営は「データが揃っているから、見れば何が起きているか分かるはず」と考えている。しかし実際には、ツールごとの定義がバラバラで、データの粒度もタイミングもズレており、ダッシュボードの数字を見ても「で、明日何をすればいいのか」が分からない——。

この詰まりは、製品にも、営業の根性にも、マーケティング戦略にも原因がありません。ツール側と人側をつなぐ「機構」が組織に欠落していることに原因があります。

中堅B2Bに共通する「3つの島」とその間の空白ツールも人もあるのに、つなぐ機構が欠けているマーケティング部MAツールを動かしているリードは集まる↓ ただし営業に渡せない営業部CRMに入力している活動は記録されている↓ データを活かせない経営層ダッシュボードはある数字は揃っている↓ 意思決定に使えない空白：3つの島をつなぐ「機構」が組織に存在しないデータの定義・粒度・タイミングを揃え、自動で流通させる仕組み＝海外でGTMエンジニアが担っている領域この空白を「人を増やす」では埋まらない
図3：中堅B2Bでよく見る構図。マーケ・営業・経営はそれぞれにツールを動かしているが、3つの島の間に「データを揃えて流通させる機構」がなく、結果としてデータはあっても意思決定に使えないという状態が常態化する。

経営が「DXを進めろ」と号令をかけても、現場は新しいツールを増やすか、既存ツールに手作業での入力を増やすかのいずれかにしかならず、むしろ運用負荷が上がるということが起きがちです。号令と現場の間を、誰かが「仕組みに翻訳する」必要がある——その担い手こそが、海外でGTMエンジニアと呼ばれている職能だと言えるでしょう。

ある売上150億円規模の製造業の事業部長から、こんな相談を受けたことがあります。「3年前にHubSpotを入れた。Salesforceも入っている。BIツールでダッシュボードも作った。でも、毎月の経営会議で『先月の有効商談数は何件か』を聞くと、マーケが言う数字と営業が言う数字と、ダッシュボードに出ている数字が、3つとも違う」。これは決して例外的な話ではなく、同規模帯の中堅B2Bではむしろ標準的な景色と言ってよいと感じています。ツールを買ったのに、そのツールが組織の意思決定に貢献していない——この距離を埋めるのが、本来GTMエンジニアの仕事です。

なぜ日本では「職種」として立ち上がらないのか

ここで日本特有の事情があります。中堅B2Bの中で、この「翻訳」の仕事は、実は誰かがやっています。多くの場合、マーケティング部の中堅社員、情シス出身でビジネスサイドに来た人、あるいは事業企画の担当者が、本来の業務の傍らで属人的に処理しています。

ただ、その存在が職種として独立しないのには、いくつかの構造的な理由があります。第一に、日本企業の職能等級制度の中に「GTMエンジニア」という職種コードが存在せず、評価軸が用意されていないこと。第二に、情シス部門とビジネス部門が伝統的に分断されており、両方を行き来する人材が育ちにくいこと。第三に、長らく続いてきたSIer依存文化のなかで、「業務システムは外注で作る」という発想が根深く、「ビジネス側の人間が自分でツールをつないで仕組みを作る」という発想自体が、組織の標準動作になっていないこと——。

結果として、GTMエンジニア的なスキルを持った人材は社内で正当に評価されないか、あるいは外資系・スタートアップへ流出していきます。「GTMエンジニアを採用する」以前に、「自社にすでにいるGTMエンジニア的人材を、職種として再定義する」ことが必要なのではないか、というのが私の感じているところです。

4. 日本の事業責任者にとっての示唆——人を採る前にやるべき「棚卸し」

海外の流行を直輸入してはいけない理由

ここでよくある失敗パターンを一つ挙げておきたいと思います。海外でGTMエンジニアが流行っていると聞いた経営層が、「うちも一人採れ」と号令をかけ、人材紹介経由で高給で採用する。ところが入社後、その人は社内のCRMを開いた瞬間に絶句する——データがあまりにも汚く、定義がバラバラで、何から手をつけてよいか分からない。半年後、その人は退職する。

これは仮想的な話ではなく、海外でも先行して起きている失敗パターンです。FullFunnelの2025年調査でも、「GTMエンジニアを採ったが定着しない」企業の多くで、入社前のデータ環境・ツール環境が著しく整っていなかったという指摘がなされています。

つまり、GTMエンジニアという「人」は、ある程度のデータ衛生状態と統合環境がある場所でしか機能しないのです。中堅B2Bがいきなり一人採用しても、その人が能力を発揮できる土壌がないところからスタートすることになります。

では、何から始めるべきか

私の提案は明快です。人を採る前に、自社のGTMスタックを棚卸しすることから始めてください、ということです。具体的には、次の問いに即答できるかを確認することから始まります。

実践ポイント 自社のリードがどこで何件止まっているか、データで答えられますか？
CRMに入っている案件のうち、過去12ヶ月で動いていない案件は何割ですか？
マーケがHubSpotで作ったリードが、Salesforceに渡るときに何が抜け落ちていますか？
営業ダッシュボードと、経営ダッシュボードで、同じ「商談数」の数字が一致していますか？

これらの問いに即答できないのであれば、それは「人を増やす」フェーズではなく、「現状を可視化する」フェーズにいるということです。GTMエンジニアを採用するのも、AIエージェントを導入するのも、すべてはここから先の話になります。

棚卸しは、3週間あれば概形を掴めます。具体的には、次の3つのアウトプットを揃えることをお勧めしています。

  • ファネル消失率マップ：リード→MQL→SQL→商談→受注の各段階で、どの遷移率が業界平均から何ポイント低いか、どこに最大の漏れがあるかを1枚のフローチャートで可視化する
  • ツール重複・空白マップ：自社が契約しているSaaSのうち、実際にリードが流れているのは何種類か、機能が重複しているツールはどれか、逆にデータが断絶している箇所はどこかを棚卸しする
  • 入力負荷スコア：営業1人あたりの月間入力工数、ダッシュボード閲覧頻度、現場が「結局Excelに戻している」業務の量を実測する

CRMとMAツールのデータ品質を診断し、ファネル各段階での消失率を実測し、現場の入力負荷とダッシュボード活用度を10名前後にヒアリングする——この3点セットを揃えるだけで、「うちの一番の詰まりはここだ」という現実が浮かび上がってきます。多くの中堅B2Bにとって、この棚卸しを真剣にやり切ることが、最も投資対効果の高い最初の一手だと考えています。

「実装思想ベースのGTM設計」という発想

ところが、私自身が現場を回らせていただいて感じるのは、この棚卸しの問いに即答できる中堅B2Bは、体感で1割もないということです。社内に「ファネル消失率マップを描ける人」「ツール統合シナリオを描ける人」がいない——。だからこそ、人を採る前にまず外部の手を借りて型を作る、という選択肢が現実的になります。

ここで多くの企業が陥るのが、コンサルティングファームから分厚い戦略書を受け取ったものの、現場のCRMやMAツールに落とし込めず動かない、というパターンです。戦略書は美しいのに、月曜になっても何も変わらない——これは戦略策定と実装が分離していることから生まれる、典型的な詰まりです。

ギアソリューションズでは、この分断を埋めるために、戦略フェーズの最初から「実装難度」をシミュレーションに組み込むアプローチを取っています。社内では「実装思想ベースのGTM設計」と呼んでいますが、考え方はシンプルです。戦略立案の段階で「何をシステム化し、何を人力で担うか」を意思決定に組み込み、既存のCRM・MA・SFA環境の棚卸しを起点に現実的な統合シナリオを描き、戦略書の納品で終わらせず実装まで一気通貫で伴走する——。GTMエンジニアという「人」を社内にフルタイムで抱える前段として、外部の手を借りて型を作るための入り口、という位置づけです。

5. まとめ：分岐点に立っている

GTMエンジニアという職種の出現は、それ自体が答えではありません。もっと大きな構造変化——「人を増やして売上を伸ばす時代の終わり」を、最も鮮明に映し出している現象だと私は捉えています。

海外では、その変化に対する答えのひとつとして「人ではなくシステムで収益を生む」という発想が生まれ、その担い手としてGTMエンジニアという職種が立ち上がってきました。日本ではまだその名前は浸透していませんが、現象としての詰まりは、すでに多くの中堅B2Bで起きています。

事業責任者の方々にとっての分岐点は、この変化を「海外の話」として通り過ぎるか、自社の足元の問題として引き受けるかにあります。もし後者を選ぶのであれば、いきなり人を採るのではなく、自社のリードがどこで止まっているのかを問い直すことから始めてみていただきたいのです。最初の一歩は、いつも『現状の棚卸し』です。

ギアソリューションズが提唱する「GTM-Led Growth（GLG）」は、事業責任者自らが市場という現場に出て、GTM全体の設計から事業成長を牽引する考え方です。本稿で扱ったGTMエンジニアリングは、その実装レイヤーを支える重要なピースの一つだと位置づけています。海外の流行を追うためではなく、自社の詰まりを構造から解くための一手として、ぜひ検討していただければと思います。

本稿の実践ポイント（経営会議の議題にどうぞ）

  1. 自社のリードがどこで何件止まっているか、データで即答できますか
  2. CRMの過去12ヶ月で動いていない案件は、全体の何割を占めていますか
  3. 営業ダッシュボードと経営ダッシュボードで、同じ「商談数」の数字が一致していますか

即答できない項目が一つでもあれば、それが「人を増やす」より先にやるべきことの輪郭です。

ファネル消失率の可視化や、CRM/MAツールの統合シナリオ設計など、自社の棚卸しから一緒に進めていきたいというご相談がありましたら、お問い合わせフォームからお気軽にご連絡ください。

合わせて読みたい関連記事

参考情報