この記事の要約
GTM エンジニアを採用・依頼する際、多くの企業が「戦略資料」や「提案書」を成果物としてイメージしてしまいます。しかし本来求めるべき成果物は、日々の営業・マーケティング活動を実際に動かす「運用されるシステム」です。
本記事では、その成果物を構成する5つの要素（要件定義、データ設計、ワークフロー、運用ルール、検証と引き継ぎ）を分解し、それぞれが何を意味し、なぜ資料と混同されやすいのかを整理します。
読み終えたとき、採用面接や外部依頼の場面で「何を納品物として定義すべきか」「何をもって完了とみなすか」を、職務名ではなく成果物の形で言語化できるようになります。判断基準を持たないまま依頼すると、立派なスライドだけが残り、現場は何も変わらないという事態を招きます。
この記事でわかること
- GTM エンジニアの成果物が「戦略資料」ではなく「運用されるシステム」である理由
- 成果物を構成する5つの要素(要件・データ・ワークフロー・運用ルール・検証と引き継ぎ)の内容
- 採用・外部依頼の際に、成果物の完了条件をどう定義すればよいか
- 資料止まりのGTM施策が起きる典型パターンと、その見分け方
はじめに
「素晴らしい戦略資料をもらったのに、3か月後には誰も見ていない」——
採用担当や経営者であれば、一度はこうした状況に心当たりがあるのではないでしょうか。GTM(Go-To-Market、市場に製品・サービスを届けるための一連の活動)の専門人材を採用したり、外部のGTM エンジニアに依頼したりする際、多くの企業は「良い提案書」や「精緻な戦略スライド」を期待しがちです。
しかし、資料は現場を動かしません。動かすのはシステム、つまり日々のデータとワークフローと運用ルールが噛み合った仕組みです。この違いを理解しないまま依頼すると、成果物の定義自体がずれてしまいます。
GTM エンジニアという職種は、マーケティング・営業・データの境界にまたがって、売上創出のプロセスを技術的に組み立てる役割を指します。
この記事では、その職種が「本来何を納品すべきか」を、資料ではなくシステムという観点から具体的に解き明かしていきます。
戦略資料とシステムは何が違うのか
まず結論から述べます。GTM エンジニアに求めるべき成果物は、次の5つの要素がひとつながりになった「運用されるシステム」です。
- 要件定義:誰が・何を・どの条件で必要としているかの明文化
- データ設計:CRM(顧客関係管理システム)や関連ツール間でデータがどう流れるかの設計
- ワークフロー:リード獲得から商談・受注・引き継ぎまでの自動化された処理の流れ
- 運用ルール:誰が何を判断し、誰が実行するかの役割分担
- 検証と引き継ぎ:実際に機能しているかの確認方法と、社内担当者への移管手順
戦略資料は、この5つのうち「要件定義」の一部だけを言葉と図で説明したものにすぎません。一方でシステムは、要件定義で決めたことがデータとワークフローに実装され、運用ルールのもとで人が動き、検証によって機能が確認され続けている状態を指します。
この違いを図式的に整理すると、次のようになります。
| 観点 | 戦略資料 | 運用されるシステム |
|---|---|---|
| 存在する場所 | スライド・ドキュメント | CRM・自動化ツール・運用マニュアル |
| 更新される頻度 | 依頼時に一度 | 実績データに応じて継続的に |
| 責任の所在 | 曖昧(誰が実行するか書かれていない) | 明確(誰が何を判断・実行するか定義済み) |
| 完了の定義 | 納品(提出したら終わり) | 稼働(数字が回り続けているか) |
| 価値が消える条件 | 担当者が読むのをやめた瞬間 | 運用ルールが守られなくなった瞬間 |
採用担当や経営者がここで押さえておくべきなのは、「資料の出来栄え」で候補者や依頼先を評価してはいけない、という点です。評価すべきは、資料の先にあるシステムを実際に組み立て、動かし、引き継げるかどうかです。
成果物を構成する5つの要素を分解する
ここからは、先ほど挙げた5つの要素をひとつずつ具体的に見ていきます。全体の対応関係としては、要件定義で「何を実現するか」を決め、データ設計とワークフローで「どう動かすか」を作り、運用ルールで「誰が担うか」を定め、検証と引き継ぎで「機能し続けるか」を保証する、という流れになります。
要件定義:成果物の輪郭を決める最初の作業
要件定義とは、GTM施策が解決すべき課題と、その課題に関わる関係者・条件・制約を明文化する作業です。例えば「リード(見込み客の連絡先情報)獲得数を増やしたい」という漠然とした要望に対して、要件定義では次のような分解を行います。
- どの部署が、どのタイミングで、どんな条件のリードを必要としているか
- 既存のCRMやツールに、どのようなデータがすでに存在するか
- 成果を測る指標(例えば商談化率や受注率)は何を採用するか
ここで注意したいのは、要件定義そのものは資料の形をとる、という点です。しかし戦略資料と違うのは、要件定義がこのあとのデータ設計・ワークフロー構築に直接接続されている点にあります。要件定義だけで終わってしまう資料は、いくら精緻であっても「宙に浮いた計画」にすぎません。
データ設計:システム全体の土台を作る工程
データ設計は、GTMに関わる複数のツール(CRM、広告管理、メール配信、問い合わせフォームなど)の間で、どのデータをどう連携させるかを決める工程です。ここが曖昧なままワークフローだけを作ろうとすると、後になって「そもそもこのデータが正しく入っていない」という問題が頻発します。
具体的には、次のような設計判断が含まれます。
- リードの重複をどう防ぐか(同じ人物が複数回登録された場合の統合ルール)
- 営業チームとマーケティングチームで、どの項目を共有し、どの項目を分けるか
- データの入力ミスや欠損が起きたとき、誰がどう修正するか
データ設計を軽視した状態でワークフローを組むと、自動化された処理が誤ったデータをもとに動き続けるという事態が起こり得ます。これは仮想的な例ですが、例えばイベント参加者のリストが手動でCRMに取り込まれる際、部署名や役職の表記ゆれがそのまま残っていると、後続のワークフローで対象を絞り込む条件分岐が正しく機能しなくなる、といった状況が考えられます。
ワークフロー:日々の業務を実際に動かす仕組み
ワークフローとは、リードが発生してから商談・受注・引き継ぎに至るまでの一連の処理を、条件分岐とともに設計したものです。例えば次のような流れが一例として考えられます。
- Webサイトから資料請求があった場合、担当営業へ自動で通知する
- 一定期間反応がない場合、別の担当者へ再アサインする
- 商談化した場合、CRM上のステータスを更新し、関連部署へ共有する
ここで重要なのは、ワークフローは「一度作って終わり」ではないという点です。実際の運用データを見ながら、条件やルールを調整し続ける必要があります。この継続的な調整こそが、戦略資料には存在しない「運用」の実態です。
運用ルール:誰が判断し、誰が実行するかを固定する
ワークフローが自動化された処理の流れだとすれば、運用ルールはその流れの中で「人間が判断すべき部分」を明確にするものです。すべてを自動化できるわけではなく、例外的な案件や判断が分かれるケースは必ず発生します。
運用ルールで定めるべき項目の例を、チェックリストの形で整理します。
- 誰が最終的な承認権限を持つか
- 例外対応が発生した場合の連絡経路
- ワークフローの変更を誰が提案し、誰が承認するか
- 定期的な見直しのタイミング(週次・月次など)
このルールが曖昧なままだと、ワークフローは存在していても「誰も責任を持って動かしていない」状態に陥ります。採用担当者が候補者を評価する際は、この運用ルールまで設計・提案できるかどうかを確認する必要があります。
検証と引き継ぎ:システムが機能し続けるための最後の工程
検証とは、構築したシステムが実際に意図した通りに機能しているかを確認する作業です。引き継ぎとは、外部のGTM エンジニアが関与しなくなった後も、社内のメンバーがシステムを運用・改善し続けられるようにする作業を指します。
この2つは、実はセットで語られるべきものです。検証だけ行って引き継ぎを行わなければ、外部の担当者がいなくなった瞬間にシステムはブラックボックス化します。逆に、検証を経ずに引き継ぎだけを行うと、不具合を抱えたままのシステムを社内が受け取ることになります。
検証と引き継ぎで確認すべき内容を整理すると、次のようになります。
| 確認項目 | 検証の視点 | 引き継ぎの視点 |
|---|---|---|
| ワークフローの稼働状況 | 想定通りにデータが流れているか | 社内担当者が動作原理を説明できるか |
| 例外処理 | 想定外のケースへの対応が機能するか | 例外発生時の連絡先・手順が共有されているか |
| 指標の推移 | 施策開始前後で数値が変化しているか | 数値の見方・報告フォーマットが引き継がれているか |
5つの成果物を市場・ICP・データ・プロセスの全体設計へ接続する考え方は、次の記事を参照してください。
採用・外部依頼の場面でこの整理をどう使うか
ここまでの5要素を踏まえると、採用面接や外部依頼の提案評価の場面で確認すべきことが具体的に見えてきます。
まず、候補者や依頼先に対して「戦略資料を見せてください」と聞くのではなく、「過去に構築したワークフローと運用ルールを、稼働後どう検証し、誰に引き継いだか」を聞くことが有効です。この問いに具体的に答えられない場合、その候補者・依頼先は資料作成止まりの経験しか持っていない可能性があります。
また、契約や依頼のスコープを定める際は、次のような完了条件を明文化しておくことをおすすめします。
- 要件定義書だけでなく、実際に稼働するワークフローの構築までを契約範囲に含めるか
- 検証期間(例えば稼働後1〜2か月など)を契約に含めるか
- 引き継ぎ資料やトレーニングをどの形式(ドキュメント・実演・同席運用など)で行うか
このように成果物を分解して契約条件に落とし込むことで、「資料はもらったが何も変わらなかった」という事態を事前に防ぐことができます。
内製と外部の役割を90日単位で設計する際は、次の記事で進め方を確認できます。
まとめ
GTM エンジニアに求めるべき成果物は、戦略資料という「静止した説明」ではなく、要件定義・データ設計・ワークフロー・運用ルール・検証と引き継ぎという5要素がひとつながりになった「運用されるシステム」です。
採用や外部依頼の際は、資料の完成度ではなく、これらの要素がどこまで具体的に設計・構築・検証されているかを確認基準とすることが欠かせません。成果物の定義を職務名ではなく実際に動く仕組みとして言語化しておくことが、依頼後の失望を避ける最も現実的な方法です。
Q&A
- QGTM エンジニアと一般的なマーケティングコンサルタントは何が違うのですか?
- A
一般的なコンサルタントは分析や戦略提案を主な成果物とすることが多いのに対し、GTM エンジニアはデータ設計やワークフロー構築など、実際にツール上で動く仕組みまで作り込む点に違いがあります。ただし個々の契約範囲によって差があるため、依頼時に成果物の範囲を確認することが重要です。
- Q社内にGTM エンジニアを採用する場合と、外部に依頼する場合はどちらが良いのですか?
- A
どちらが適しているかは、社内にデータ・ツール運用の知見がどの程度蓄積されているか、また継続的な改善をどの体制で行いたいかによって変わります。一般論として、初期構築を外部に依頼し、運用フェーズを社内へ引き継ぐという段階的な進め方も選択肢の一つです。
- Q運用ルールや引き継ぎが不十分だと、具体的にどのような問題が起きやすいのですか?
- A
担当者の異動や契約終了のタイミングでシステムの運用が止まってしまう、例外対応の判断が誰にもできなくなる、といった問題が典型的に挙げられます。そのため、構築段階から検証と引き継ぎの計画をあらかじめ組み込んでおくことが望ましいとされています。
専門用語解説
- GTM(Go-To-Market):製品・サービスを市場に届けるための一連の活動
- CRM:顧客との関係やデータを一元管理するシステム
- リード:見込み客としての連絡先情報
- ワークフロー:業務上の処理を条件分岐とともに自動化した流れ
- 商談化:見込み客が具体的な検討・交渉の段階に進むこと
- 引き継ぎ:担当者や外部支援者から社内メンバーへ運用・管理を移管すること
