今年お話しするどの創業者も、同じ問いの変奏を投げかけてきます。GTM engineer を採るべきか、それとも RevOps の人材か、というものです。彼らはあなたと同じ記事を読んでいます。GTM engineer は今まさに注目の役割で、Clay を HubSpot につなぎ、AI Outbound を構築し、かつて一四半期かかったものを一週間で届けます。RevOps はより古く遅いものに聞こえるため、飛ばしたくなります。問題は、これらが同じ仕事の別名ではないこと、そして片方だけを誤って採用することが、速い Revenue チームが自社の CRM から静かに乖離していく道筋だということです。
なぜこれが 2026 年の問いなのか
今この問いが切実なのは、Go-to-Market 組織が同時により無駄なく、よりテクニカルになっているからです。ICONIQ Growth による 2026 年の現代的 GTM 組織の読み解きでは、中央値の企業が今年の RevOps の人員増をゼロと計画する一方、十八か月前には存在しなかった AI 実験に RevOps の時間の約一割を割いています。AI を完全に組み込んだ企業は、一人当たりの Net-new Revenue がおよそ二倍です。つまり圧力は本物です。同じ人員で、より良いツールで、より多くを成す。まさにそれを約束する肩書き、GTM engineer が、その真ん中に降り立つわけです。
GTM engineer とは実際に何か
GTM engineer はビルダーです。データと自動化の出身で、ツーリングに精通し、その本能はシステムを配線して届けることです。First Round が Clay のスケールを描写して述べたとおり、その動きは エンジニアリングの規律を取り、それを Go-to-Market に持ち込むことです。これは本物の価値です。Pre-call Research、Lead Scoring、そして Outbound の Motion を構築できる一人が、かつては三つの役割とバックログだったものを置き換えます。ベルリンのような都市では、市場の GTM engineer はそのエンジニアリング志向とスピードを携えてやって来ます。彼らが通常携えてこないもの、それが Revenue Operations のベストプラクティスです。
RevOps が実際に所有するもの
RevOps は遅い GTM engineer ではありません。所有するのは別のもの、すなわち System of Record と、それがまだ真実を語っているかという問いです。それは Customer Journey、各 Stage と各 Field の背後にある定義、Forecast が読み取る Reporting、そしてそのすべてを「実際にどう売っているか」に揃え続ける規律を意味します。私が使うテストは単純です。GTM engineer はマシンにより多くをさせます。RevOps はマシンがまだ現実と一致していることを確かめます。これらは別の仕事であり、数百人未満のほとんどのチームでは、一人はどちらか一方が本当に得意です。
失敗のかたち：System of Record のない自動化
先日、DACH 地域の Series B の B2B SaaS チームと仕事をしました。彼らは現代的なやり方を選び、まず優秀な GTM engineer を採用していました。六か月後、自動化は見事でした。Signup はエンリッチされ、Deal は作成され、シーケンスは発火し、Dashboard はどこにでもありました。問題は、事業は静かに動いたのに CRM は動かなかったことです。新しい Sales Motion はチャットとスプレッドシートで回っていました。きちんとモデル化するより立ち上げるほうが速かったからです。Stage は Rep ごとに違う意味を持ち、Forecast は誰も所有しない Field の上に立っていました。これらはどれも engineer のせいではありません。誰も彼にもう一方の仕事を与えなかったのです。事業のアクションと CRM が揃わなくなり、それを揃えるのが仕事の人が誰もいないとき、ギャップは毎週広がり、最も多く自動化しているチームで最も速く広がります。
誰が何を所有するか
ですから、ほとんどの成長中のチームにとっての答えは、どちらか一方ではありません。両方であり、その間に明確な線を引きます。私が引く線はこうです。
- RevOps は System of Record を所有します。Customer Journey、Stage と Field の定義、データ品質、そして Revenue Reporting です。これは安定すべき役割で、離職させてはいけません。
- GTM engineer は速度を所有します。自動化、AI Workflow、Integration、そして今週本番に出さねばならない実験です。
- RevOps は engineer が構築する内側のガードレールを設け、速度がドリフトにならないようにします。
採用が一人分の予算しかないなら、自分の問題に合わせて寸法を決めます。CRM が混乱し Forecast が空想なら、まず RevOps の Owner が必要です。信頼できないシステムの上に自動化を重ねても意味がないからです。データが綺麗なのに遅く手作業なら、GTM engineer のほうが効きます。複雑にしすぎないこと。本当に壊れているものを直してください。
より多くのクライアントが選んでいる第三の選択肢があり、正直に言えばそれは当社のサービスの一つです。GTM engineer は社内に置き、速く製品固有の構築をそこに住まわせ、自前で雇えるほど大きくなるまで RevOps の責任をフラクショナルで借りるのです。私たちが機能していると見る構成は、System of Record と Reporting を握るフラクショナルな RevOps Owner と、そのガードレールの内側で速く構築する社内の GTM engineer です。システムをドリフトさせずに速く革新を続けられ、初期のクリーンアップが済めば軽くなる役割にフルタイムの給与を払わずに済みます。
私ならこうする
- 肩書きではなく仕事に名前を付ける。二つのうち実際に欠けているのはどちらか書き出してください。マシンにより多くをさせる人か、マシンを誠実に保つ人か。ほとんどのチームは一文で分かります。
- 自動化の前に監査する。まず CRM と Customer Journey の本当の Discovery を行ってください。事業のアクションとシステムがすでにずれているなら、自動化を増やすとギャップは縮まるどころか広がります。
- 役割を分ける。System of Record には RevOps、速度には GTM engineering、そして両者を決して混ぜない。安定の役割と速さの役割は気質が違います。一人に両方を求めてはいけません。本当に両方をやり切った人でない限り。
- 一人しか資金を出せないなら、壊れ具合に合わせて寸法を決める。データが壊れ Forecast が空想なら RevOps が先。データが綺麗で実行が遅いなら GTM engineer が先。
- まだ採用を正当化できない役割は、借りることを検討する。フラクショナルな RevOps Owner に社内の GTM engineer を足す構成が、当社では Series A から Series C のあいだで最もよく持ちこたえます。
GTM engineer は、ここ数年で Revenue チームに起きた最良の出来事の一つであり、おそらく一人は採るべきです。ただ、構築物とその下のシステムを混同しないでください。2026 年に火傷を負うのは、動きが遅すぎたチームではありません。誰も所有しない CRM の上で最速に自動化したチームです。engineer が届け続ける間、System of Record にもう一組の手が欲しいなら、まさにそのために当社の Revenue Operations の仕事があります。あるいは ご連絡ください。最もドリフトしているところから始めます。システムが整った後、どこで Revenue が静かに漏れるかという関連の問いについては、誰も所有しない二つの引き継ぎに関する関連記事をお読みください。
出典
- SaaStr が ICONIQ Growth の 2026 年 GTM 組織レポートを要約。「The Modern GTM Org in 2026: 20-30% Leaner, 9x Flatter, ~2x More Net New Revenue Per Rep.」2026 年 5 月。saastr.com
- First Round Review.「The GTM Inflection Points That Powered Clay to a $1B+ Valuation.」firstround.com
- SaaStr.「How Owner.com’s CRO Is Closing $2M+ in ARR Per Rep With AI.」2026 年。saastr.com