GTM Engineeringとは？Clayの考え方を営業の仕組みづくりに生かす

答えは、企業調査・選別・CRM更新を一回きりの作業ではなく、数百から数千件に同じ処理を走らせる仕組みとして扱う設計である。

GTMはGo-to-Marketの略で、誰に何をどう届けて売上につなげるかを決めて実行することを指す。仕組みを作る側にも、その前提を確認する役割がある。「どの市場の、どんな段階の企業を狙うか」という条件は営業上の判断で、仕組みはそれを列と処理に落とす。条件が曖昧なまま工程を自動化すると、落ちた数の理由が読めなくなる。

答えは、発掘・検証・意思決定者の特定・下書きの各工程の出力を同じ台帳の列にし、次の工程がその列を入力として動く形にすることである。

当社が海外ブランドへの直アプローチで検証した範囲では、1,000社以上の候補から深掘りした企業のうち、約3割は調べてみると既に日本進出済みで見送りになった。これは2026年9月時点の自社台帳からの読み取りで、対照実験ではなく、対象や条件が違う開拓に同じ比率は当てはまらない。それでも、検証の工程を持たないリストに下書きを書くと、その分の送信が無駄になることは分かる。工程をつないで初めて、「どこで落ちたか」が数字になる。

列を設計するときの注意は照合キーにある。会社名だけで突合すると略称や同名企業が混ざるため、公式ドメインなどで対象を確かめ、検証日と出典を残す。落ちた理由を列に持たせておけば、追加発掘のときに同じ検証を繰り返さずに済み、条件を変えたときの影響も列の差分で読める。台帳は成果の置き場ではなく、次の工程の入力である。

答えは、仕組みが「処理しました」と返した時点ではなく、保存先の件数と主要項目を見て完了とすることである。

データの品質は、思っているより低い。ハーバード・ビジネス・レビューが2017年9月に掲載した研究（Nagle、Redman、Sammon）では、基本的な品質基準を満たすデータを持つ企業は3%にとどまった。自動化はこの状態のデータに処理を走らせるため、入口と出口の両方で確かめる工程が要る。速く回る仕組みほど、誤りも速く広がる。

当社では、成功応答だけを信じず、保存先の件数と主要項目で完了を判定することを原則にしている。由来は、業務データベースに存在しない選択肢を渡したとき、エラーにならず無視され、レコードは作られるがその列だけ空になった経験にある。応答は成功を返していた。

答えは、送信・価格・契約など取り消せない判断を先に人に割り当て、残りを工程として設計することである。

1. 人に残す判断を書き出す。送信、価格の提示、契約条件、商談の場での判断は仕組みに渡さない。
2. 残りを工程に分け、各工程の出力を台帳の列として定義する。
3. 数十件で試し、落ちた数と理由を工程ごとに見る。
4. 書き込みごとに検証ゲートを通し、件数と主要項目で完了を判定する。
5. 手で直した箇所が出たら、次から同じ手直しが出ないように処理の定義に書き戻す。

順番を逆にして自動化から始めると、送ってよいかの判断が仕組みの中に埋もれる。速く作れるリストと、営業が実際に使えるリストを、同じものとして評価しない。 効果はリストの件数ではなく、工程ごとの残存数と、そこから生まれた商談数で見る。

明日からやることは3つで足りる。いまの営業から、人に残す判断を5つ以内で書き出す。候補リストに「落ちた理由」「検証日」「出典」の列を足す。次の書き込みで、成功応答ではなく保存先の件数を見て完了とする。この工程を担う人の職務はGTM Engineerの仕事で、送信前後の役割分担は営業AIエージェントの記事で扱っている。