検索すると、GTMエンジニア（Go-To-Market Engineer）の解説記事はいくつも出てきます。 定義、必要なスキル、年収、キャリアパス。どれもよく整理されています。
ここに書くのは、そういう整理ではありません。 実際に社内でそう呼ばれるようになった人間が、日々何をしていて、どこで詰まっているかの記録です。
まず、私の制度上の職種はエンジニアではありません
上場企業の会社員で、職位はマネージャー。 そして人事制度上の職種は「BusinessOperation」です。エンジニア職ではありません。
この一点に、日本におけるGTMエンジニアの現状がそのまま出ていると思っています。
「日本にはGTMエンジニアがほとんど存在しない」と言われます。 ただ、正確には人がいないのではなく、制度として存在していないのだと思います。 近いことをやっている人はいて、ただその役割に名前が付いていない。 だから求人票にも、等級表にも、評価シートにも出てこない。
名前は、後から来ました
自分から名乗ったわけではありません。 上司がそう呼び始めたのが最初で、1〜2か月前のことです。
順序はこうでした。
- 事業部の課題があった
- AI導入・DX推進で、自分で手を動かして解決していった
- 1日にいくつも実装するような進め方をしていた
- あるとき上司が「GTMエンジニア」と呼び始めた
職種の定義があって、それに合わせて働いたのではありません。 やっていることに名前が付いていなかったので、後から名前のほうが来たという順番です。
解説記事を読んでから「これは自分のことだ」と思ったのではなく、 呼ばれてから「そういう名前があるのか」と知りました。
上司がなぜその言葉を知っていたのかは、直接確かめたわけではありません。 ただおそらく、業務上の情報収集の中で、 海外で使われている職種名として目にしたのだと思います。 そこに私の動き方と出していた成果が近かったので、その名前を当てた。
だとすると、この言葉が私に貼られた経路はこうなります。 日本の人事制度から生まれたのではなく、 海外で確立した職種名が情報として入ってきて、 実際にそう動いている人間に後から当てられた。 制度が先にあるのではなく、実態のほうが先にありました。
マネージャーが、1日にいくつも実装できる理由
管理職が自分で実装するのは、本来あまり効率的ではありません。 それでも成立しているのは、時間の使い方がここ数年で変わったからです。
裁量労働制で、だいたい9時から18時。 会議の量は日によってまったく違い、1日の半分以上が会議の日もあれば、2割程度の日も、丸一日会議だけの日もあります。 自分の予定を自分で決めきれないのは、横断的な役割の宿命だと思っています。
それでも、その日のうちに終わらせるべきタスクは終わります。やり方は3つの組み合わせです。
- 会議中に並行して進める
- AIに投げる
- 内容によっては人に渡す
この働き方はAIがなければ成立しません。 会議に入る前に投げておいて、終わったら結果を確認する。その繰り返しです。 「1日にいくつも実装する」の実態は、自分の手が速いという話ではなく、この構造のほうです。
使っているもの
道具の話は本質ではありませんが、具体がないと伝わらないので書いておきます。
- 生成AI（Claude / ChatGPT / Codex / Cursor）
- Google Workspace（スプレッドシート、GAS、フォーム）
- Salesforce、kintone
- n8n（ワークフローの自動化）
- Redash（データを見る）
- Slack
データを見て、プロセスを設計して、自動化を実装して、結果をまた見る。 領域ごとに分業されていることが多い工程を、一人で横断しているのが実態に近いです。
技術は、いちばん簡単な部分でした
ここが、この記事でいちばん書きたかったことです。
自分一人で完結する範囲では、失敗がほとんどありません。 調べれば分かるし、動かなければ直せばいい。実装は、やれば終わります。
詰まるのは、いつも人と組織のほうです。
仕組みが完成しても現場で使われない。必要性が伝わらない。 変える必要性は理解されても、日々の業務が忙しくて新しいやり方を覚える時間が取れない。 成果が、自分でコントロールできない領域に依存している。 これが横断的な役割の構造的な難しさだと思います。
そして、これは個人の資質の問題ではありません。 新しいツールへの切り替えには学習コストとスイッチコストが必ずかかります。 そのコストを現場の個人が負担する構造になっている限り、 「便利だから使うはず」という前提は成立しません。
ツールを配っても、生産性は上がりません
推進する立場としていちばん考えているのは、この点です。
AIやDXに前向きな人が、自分でn8nを触ってワークフローを組み始めることがあります。 姿勢としては理想的です。ところが作っては直し、作っては直しを繰り返して、 かえって時間を使ってしまうことがある。
原因はツールの習熟度ではないと見ています。 その前段にある、オペレーション設計のほうです。
- その業務は、そもそも本当に必要なのか
- 必要だとして、人がやらなければならないのか
- どこがボトルネックになっているのか
この3つを詰めないまま自動化すると、いらない業務を、速く回せるようにしただけになります。 設計が変わっていないので、途中で必ず作り直しが発生する。 AI・DXを入れたのに生産性が下がる、という逆説はここから生まれます。
オペレーション設計は、これまで多くの現場で明示的に求められてこなかったスキルだと思います。 評価項目にもなりにくい。だから鍛える機会がないまま、 「ツールを使えること」だけが先に求められる状況になっている。
AI・DXは手段です。 構築スキルの前に、正しいオペレーション設計ができるかどうかで結果が決まります。 私が「GTMエンジニア」と呼ばれるようになった順序も、たぶんここに関係しています。 技術ができる人間が業務を学んだのではなく、 業務設計が本職の人間が、技術を持ったという順序でした。
この課題は、いまも解決していません
ここまで書いておいて何ですが、解決策を提示できる段階にはいません。
構造の問題だと分かっていることと、それを動かせることは別です。 いまも現在進行形で詰まっています。 進んだことがあれば、また書きます。
だから副業では、自分の判断だけで回る体制を試しています
本業では、正しく設計できても、人と組織が動かなければ進みません。 それは組織で仕事をする以上、当たり前のことでもあります。
一方で、自分の判断だけで完結する環境なら、設計から実装まで一気に通せるはずです。 それを確かめるために、AIに6つの役割を持たせて、人間の判断を終業後の1日30分に絞った副業の実験をしています。
秘書、マーケター、コンテンツ制作、エンジニア、法務、経理。 本業でAIに仕事を渡している延長線上に、この体制があります。
工数、経費、売上、失敗。実測値は このサイトのトップに置いていて、 判断や失敗の中身は noteに書いています。 現時点の売上は0円です。それも、そのまま出しています。
この記事は、状況が変わったタイミングで更新します。
最終更新: 2026年8月21日