# 営業からGTM Engineerへ移るには > 営業経験をGTM Engineerにつなげるために、何を学び、どんな小実験を作り、どの実績を語ればよいかを実務目線で解説します。 - Canonical: https://aicareer.biz/how-to-become-a-gtm-engineer-from-sales - Category: キャリア戦略 - Published: 2026-04-23 - Updated: 2026-04-23 - Tags: 営業, GTM Engineer, キャリア転換, CRM, 自動化 ## 営業からGTM Engineerへ移るには 営業からGTM Engineerへ移るには、営業経験を捨てる必要はありません。むしろ、顧客理解、商談の詰まり、提案準備の重さ、受注後の引き継ぎ不全を知っていることが強みになります。 GTM Engineerは、売上プロセスの詰まりをデータ、ワークフロー、自動化で直す役割です。コードを書く仕事に見えますが、出発点は現場の痛みを正しく見つけることです。職種の輪郭は [GTM Engineerとは](/what-is-gtm-engineer) を先に読むと整理しやすいです。 より広い越境論は [営業からGTM Engineerへ、どう越境するか](/sales-to-gtm-engineer) にまとめています。このページでは、検索して最初に知りたい「何から始めるか」に絞ります。 ## 1. 営業経験を棚卸しする 最初にやるべきことは、営業実績を売上プロセスの言葉に変換することです。 「受注した」「達成した」だけでは、営業としての実績で止まりやすいです。GTM Engineerに近づけるなら、どのプロセスで詰まりを見つけ、何を改善し、どの情報が不足していたかを説明できるようにします。 たとえば、提案準備に時間がかかったなら、必要情報がどこに散らばっていたのか。失注理由が活かされないなら、CRM項目や会議体のどこで止まっていたのか。こうした棚卸しが、そのまま改善テーマになります。 ## 2. 売上プロセスを一枚で書く 次に、問い合わせから受注後の引き継ぎまでを一枚で書きます。問い合わせ、初回接触、商談化、提案、受注、CS引き継ぎの順に、誰が何を持ち、どこで情報が欠けるかを見ます。 この時点で、きれいな図を作る必要はありません。大事なのは、個人の営業スキルではなく、複数人が関わる流れとして売上を見られることです。 GTM Engineerに向いているか不安な人は [GTM Engineerに向いている人](/who-is-suited-for-gtm-engineer) も読み比べると、自分の強みを見つけやすくなります。 ## 3. CRMと自動化を小さく学ぶ 営業からGTM Engineerへ移るとき、いきなり高度な開発を始める必要はありません。まずはCRMの項目、商談ステージ、担当者、日付、リードソース、失注理由のような基本項目を理解します。 そのうえで、小さな自動化を試します。たとえば、問い合わせ内容に応じたSlack通知、商談ステージ変更時のタスク作成、受注後の引き継ぎテンプレート生成などです。 ツールの学び方は [n8n・Dify・HubSpot・Salesforceをどう学ぶか](/automation-stack-learning-map) が参考になります。 ## 4. 成果物を作る 面接や社内異動で効くのは、大きなアプリではなく、現場の詰まりを改善した証拠です。 持っておきたい成果物は、現状フロー、改善後フロー、動く小さな自動化、改善理由メモの4つです。「誰のどの手間を減らしたか」「どの判断が早くなったか」「どの例外が残ったか」まで説明できると、営業経験がGTM Engineerの実績として伝わります。 ## 30日・90日の進め方 30日では、営業プロセスの中から一つだけ改善テーマを選びます。提案準備、失注理由管理、受注後引き継ぎのどれかで十分です。 90日では、そのテーマに対して小さな改善を作ります。CRM項目を整理する、Slack通知を作る、引き継ぎテンプレートを整える。成果が小さくても、前後の変化を説明できれば意味があります。 ## まとめ 営業からGTM Engineerへ移るには、営業経験をコードに置き換えるのではなく、営業経験を仕組みの改善テーマに変えることが重要です。 顧客理解と案件理解は、GTM Engineerにとって大きな武器です。そこに売上プロセス、CRM、自動化の基礎を足し、小さく動く成果物を作れば、現実的な越境ルートになります。 ## 営業経験を仕組み化へ変える視点 営業からGTM Engineerへ移るにはを考えるとき、最初に捨てるべきなのは「今の職種をリセットしないと次へ行けない」という見方です。AI時代の越境は、まったく別の職種へ飛ぶ話ではなく、今の仕事で見えている問題を別の責任範囲へ移す話です。営業、マーケ、CS、PM、エンジニアの経験は、それぞれ違う入口になります。 大事なのは、今の経験を成果名だけで語らないことです。「売った」「集客した」「導入支援した」「機能を作った」だけでは、既存職種の実績で止まります。次の役割へつなげるには、どの業務の流れを理解しているのか、どこに摩擦があり、何を直せるのかまで言語化する必要があります。 GTM Engineerに近い役割では、個人の成果よりも再現性が問われます。自分が頑張ったからできたのではなく、他の人も同じ品質で進められる状態をどう作るか。ここに視点を移せると、越境の説得力が一段上がります。 ## 棚卸しする営業経験 最初に棚卸しするのは、成功体験ではなく摩擦です。商談前に何を毎回探していたのか。マーケ施策の後工程でどこが見えなくなっていたのか。CSで何度も同じ説明が必要だったのか。PMとしてAI機能を企画するとき、誰が品質や運用責任を持つのかが曖昧だったのか。こうした摩擦は、次の職種のテーマになります。 棚卸しでは、経験を三つに分けると整理しやすくなります。一つ目は現場理解です。顧客、営業、マーケ、CS、開発、運用のどこを知っているのか。二つ目は設計経験です。業務フロー、KPI、データ、要件、権限、引き継ぎをどう整理したことがあるか。三つ目は改善実績です。小さくても、何を変え、何が前より良くなったかです。 この三つがそろうと、肩書きがまだなくても越境の説明ができます。逆に、ツールを学んだだけでは弱いです。ツールは使えるが、何を直すべきかを説明できない状態だと、次の役割として評価されにくくなります。 ## 営業現場で作れる小さな実績 最初の実績は、社内の小さな改善で十分です。問い合わせ初動、提案準備、リード引き継ぎ、商談ステージ、受注後のCS引き継ぎ、AI下書きの確認ルール、ナレッジ検索の整理など、対象は一つに絞ります。 実績にするときは、改善内容だけでなく、改善前の不便さを残してください。誰が困っていたのか、どれくらい手戻りがあったのか、どの判断が遅れていたのか。この前提があると、改善後の価値が伝わります。 また、成果物は「動くもの」と「説明できるもの」の両方が必要です。簡単な自動化、テンプレート、ダッシュボード、業務フロー図だけでなく、なぜその形にしたのかを説明するメモを残します。転職でも社内異動でも、評価されるのは完成度だけではなく、判断の筋道です。 ## 越境準備を実績に変える90日 30日では、今の仕事の中で繰り返し発生している摩擦を一つ選びます。次に、その摩擦が個人のスキル不足なのか、情報の不足なのか、定義のズレなのか、ツールや運用の問題なのかを分けます。この分解ができるだけで、越境先の役割に近づきます。 90日では、その摩擦を一つだけ直します。大きなプロジェクトにしないことが大切です。入力項目を一つ減らす、確認ルールを決める、通知を整える、AIの出力を使う場面を限定する、引き継ぎ項目をそろえる。こうした小さな改善を、前後比較で説明できるようにします。 最後に、次の一歩を決めます。GTM Engineerへ寄るなら、現場理解だけでなく、仕組み化、データ、運用、評価指標のどれを足すべきかを選んでください。学ぶ範囲を広げすぎるより、今の経験に一番近い隣接領域から積む方が現実的です。