営業からGTM Engineerへ移るには
営業からGTM Engineerへ移るには、営業経験を捨てる必要はありません。むしろ、顧客理解、商談の詰まり、提案準備の重さ、受注後の引き継ぎ不全を知っていることが強みになります。
GTM Engineerは、売上プロセスの詰まりをデータ、ワークフロー、自動化で直す役割です。コードを書く仕事に見えますが、出発点は現場の痛みを正しく見つけることです。職種の輪郭は GTM Engineerとは を先に読むと整理しやすいです。
より広い越境論は 営業からGTM Engineerへ、どう越境するか にまとめています。このページでは、検索して最初に知りたい「何から始めるか」に絞ります。
1. 営業経験を棚卸しする
最初にやるべきことは、営業実績を売上プロセスの言葉に変換することです。
「受注した」「達成した」だけでは、営業としての実績で止まりやすいです。GTM Engineerに近づけるなら、どのプロセスで詰まりを見つけ、何を改善し、どの情報が不足していたかを説明できるようにします。
たとえば、提案準備に時間がかかったなら、必要情報がどこに散らばっていたのか。失注理由が活かされないなら、CRM項目や会議体のどこで止まっていたのか。こうした棚卸しが、そのまま改善テーマになります。
2. 売上プロセスを一枚で書く
次に、問い合わせから受注後の引き継ぎまでを一枚で書きます。問い合わせ、初回接触、商談化、提案、受注、CS引き継ぎの順に、誰が何を持ち、どこで情報が欠けるかを見ます。
この時点で、きれいな図を作る必要はありません。大事なのは、個人の営業スキルではなく、複数人が関わる流れとして売上を見られることです。
GTM Engineerに向いているか不安な人は GTM Engineerに向いている人 も読み比べると、自分の強みを見つけやすくなります。
3. CRMと自動化を小さく学ぶ
営業からGTM Engineerへ移るとき、いきなり高度な開発を始める必要はありません。まずはCRMの項目、商談ステージ、担当者、日付、リードソース、失注理由のような基本項目を理解します。
そのうえで、小さな自動化を試します。たとえば、問い合わせ内容に応じたSlack通知、商談ステージ変更時のタスク作成、受注後の引き継ぎテンプレート生成などです。
ツールの学び方は n8n・Dify・HubSpot・Salesforceをどう学ぶか が参考になります。
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へ寄るなら、現場理解だけでなく、仕組み化、データ、運用、評価指標のどれを足すべきかを選んでください。学ぶ範囲を広げすぎるより、今の経験に一番近い隣接領域から積む方が現実的です。