GTM Engineerとはどんな仕事か？役割・必要スキル・育成と採用の考え方

答えは、営業担当が判断する工程と仕組みが回す工程の線を引き、後者を台帳と処理として実装し、動き続ける状態に保つことである。

用語の固定は地味だが外せない。「アウトリーチ」が下書きの生成までなのか送信までなのか、「リード」が自社への問い合わせなのか候補の発掘なのかが揺れると、仕組みが勝手に送信したり、候補と問い合わせを混ぜて集計したりする。定義に無い用語が出たら推測せず、営業担当に確認して定義に足す。

答えは、仕事の単位が「タスク」ではなく「仕組み」で、評価が「処理件数」ではなく「商談数と削減した時間」である点である。

線の引き方には順番がある。当社では、人に残す仕事（送信・公開・契約・価格の承認、商談、見極め、交渉）を先に決め、準備・調査・下書き・集計を仕組みに渡す順で設計している。この順番を逆にして自動化から始めると、送ってよいかの判断が仕組みの中に埋もれ、後から取り出せなくなる。GTM Engineerの日常は、工程ごとの「落ちた数」を読み、次の発掘条件や検証基準に戻す作業である。

答えは、コードより先に、選定条件の意味を理解する営業の理解と、応答が成功でも中身を確かめるデータの扱いである。

第一は営業の理解である。「どの市場の、どんな段階の企業を狙うか」という条件は営業上の判断で、仕組み側はそれを列と処理に落とす。条件の意味が分からなければ、参入済みの企業を検証で外す処理も設計できない。営業担当が候補を見て「これは違う」と言った理由を、列と判定条件に翻訳できるかが問われる。

第二はデータの扱いと、失敗を調べる力である。業務データベースに書き込むとき、存在しない選択肢を渡すとエラーにならず無視され、レコードは作られるがその列だけ空になる、ということが起きる。応答は成功を返す。成功応答だけを信じず、保存先の件数と主要項目を見て完了と判定する習慣は、ノーコードであっても省けない。

第三は手順を残す力である。手で直した箇所が出たら、次から同じ手直しが出ないように処理の定義に書き戻す。書き戻さないと、手順が担当者の頭の中にだけ残り、その人が抜けた日に止まる。処理の定義に残っていれば、担当者が替わっても同じ条件で回る。

採用と育成は、一つの工程を改善した過程を、前提と限界を含めて説明できるかで見る。ツールの経歴より、営業担当と条件を詰めた経験と、失敗を数字で報告した経験を重く見る。面接では、直した工程を一つ選んで前後の数字を語ってもらう。社内で育てるなら、営業かオペレーションの担当者に一つの工程の台帳化を任せ、落ちた数を毎週読ませるところから始める。商業判断と現場の実行へ範囲を広げる職種としては、Forward Deployed Business Builderが隣接する。

答えは、自動化の本数ではなく、商談数、削減した時間、仕組みが止まらずに回った期間で測ることである。

自動化の本数を成果にすると、使われない仕組みが増える。削減した時間は、準備の側で減った分と、確認の側で増えた分を分けて数える。仕組みが用意し、人が決める。その線が動いている限り、GTM Engineerの仕事は続いている。

明日からやることは3つで足りる。いまの営業から、人に残す判断を書き出して営業担当と合意する。一つの工程を選び、出力を台帳の列として定義する。次の書き込みで、成功応答ではなく保存先の件数を見て完了とする。工程の設計手順そのものは、GTM Engineeringの実務記事で扱っている。