「それ、RevOpsの仕事？GTMエンジニアの仕事？」

GTMエンジニアとは、RevOpsとソフトウェアエンジニアの中間に立ち、営業・マーケ・CSの収益システムを「設計・構築・自動化・計測」する技術職です。戦略判断（例：MQL定義の変更）はRevOpsの領分であり、その実装と効率化（例：エンリッチメント単価の削減）がGTMエンジニアの領分になります。営業の依頼を技術仕様に翻訳し、実現性の低い依頼には代案で押し返すコミュニケーションが仕事の半分を占めます。

ここで先に反論しておきます。「役割を細かく分けるほど、伝言ゲームで遅くなるのでは」と思うかもしれません。小規模なチームでは実際、1人が両方を兼務することも珍しくありません。ですが兼務する場合でも、「これは戦略判断なのか、実装の話なのか」を頭の中で意識的に切り替えられているかどうかで、依頼のさばき方の質は変わります。役割の線引きは組織図の話である以上に、思考の切り替えの話です。

第1層が崩れていると上位層はすべて機能しません。データが汚れたままスコアリングモデルを作っても、その出力は信頼できず、自動化に接続すれば誤ったアクションを量産するだけです。施策の不調を相談されたときは、まずどの層の問題かを切り分けることが最初の一手になります。横断レイヤーとして「自動化基盤」「AI」「計測」「ガバナンス」が全層を貫きます。

この3層は、建物の基礎・骨組み・内装の関係に近いです。内装（アクティベーション）をどれだけ豪華にしても、基礎（データ基盤）が傾いていれば、いずれ全体が歪みます。逆に、基礎だけ完璧でも内装まで手が回っていなければ、誰もその建物を使いません。

この領域はツールの入れ替わりが6〜12ヶ月周期で起きるため、特定ツールの操作知識より「レイヤー構造とデータフロー」の理解を優先すべき領域です。必須技術としてはSQL（CRM／ウェアハウスの照会・監査）、PythonまたはTypeScript（データ変換・API連携・カスタムスコアリング）、REST API／Webhookの理解が挙げられます。ワークフロー自動化ツール・CRM・シーケンサー・LLM APIのいずれかに実務レベルで習熟していることも実装力の土台になります。

例えば、「アウトバウンドの返信率が下がった」という相談を受けたとき、シーケンス文面の改善から着手したくなりますが、実際にはデータ基盤（第1層）の企業情報が古く、担当者がすでに転職済みのアドレスに送り続けていた、というケースは珍しくありません。層を切り分けずに上位層から手を付けると、根本原因を見逃します。

層ごとに1つずつ問いに答えると、どの層から手を付けるべきかが見えてきます。上から順に、答えられなくなった層が着手すべき層です。第1層が崩れている状態で上位層に投資しても、出力は信頼できません。

第1層（データ基盤）を診断する問い

「CRM・ウェアハウスのレコードは重複なく、クリーンな状態と言えるか」。良い状態の例：同じ会社・同じ人物のレコードが1件に統合され、必須項目の欠損率が把握・管理されている。詰まっている状態の例：同じ会社が表記ゆれで何件も登録されている、そもそも何件重複しているか分からない。重複や欠損が常態化しているなら、他の層に着手する前にここを直す

第2層（データモデリング）を診断する問い

「購買・拡大・解約を予測する独自データポイント（ICPスコア・シグナル・ヘルススコア）を持っているか」。良い状態の例：「このセグメントは受注率が高い」を勘ではなく実績データの相関で説明できる。詰まっている状態の例：「大手の方が決まりやすい気がする」等、現場の肌感だけで運用されている。第1層が崩れたままここに投資しても、出力が信頼できない点に注意する

第3層（データアクティベーション）を診断する問い

「モデリングの結果は、アウトバウンド・ルーティング・CS介入といった実際のワークフローに接続されているか」。良い状態の例：スコアが高い商談は自動的に優先度の高いキューに入る、解約リスクが上がった顧客にはCSが自動で介入する。詰まっている状態の例：スコアやシグナルは存在するが、Excelやダッシュボードで眺めるだけで実際のアクションに繋がっていない

横断レイヤーを診断する問い

「自動化基盤・AI・計測・ガバナンスは、3層すべてを一貫して支えているか」。良い状態の例：層をまたいだ計測が同じ定義でつながっており、誰が・いつ・何を変更したかが追跡できる。詰まっている状態の例：層ごとにツールがバラバラで数字の定義が部署によって違う、変更履歴が残っていない

層ごとに現状と次のアクションを書き込むフォーマットです。

GTMエンジニアとRevOpsはどう役割分担すればいいですか

戦略判断（例：MQLの定義変更）はRevOpsの領分、その実装と効率化（例：エンリッチメント単価の削減）はGTMエンジニアの領分とされています。どちらが欠けても機能不全になりやすく、営業の依頼を技術仕様に翻訳する橋渡し役が重要になります

施策の効果が出ないとき、まずどの層を疑うべきですか

第1層（データ基盤）から順に確認するのが定石です。データが汚れたままスコアリングモデル（第2層）を作っても出力は信頼できず、それを自動化（第3層）に接続すれば誤ったアクションを量産するだけです。上位層の不調は、多くの場合下位層の問題が原因になっています

小規模なチームでも3層すべてを整備する必要がありますか

規模に応じて簡素化してよいとされています。ただし「データ基盤が崩れていると上位層はすべて機能しない」という順序の原則は規模を問わず共通です。小規模なら3層それぞれを最小限の仕組みで済ませつつ、順序だけは守るのが実務的です

直近で施策がうまくいかなかったとき、原因をどの層に求めたでしょうか。「営業のトーク力が足りない」「マーケの訴求が弱い」と、施策の上澄みだけを疑っていなかったでしょうか。3層のうち、最後に自信を持って「大丈夫」と答えられたのはどの層だったかを振り返ってみてください。