この記事の要約
GTMエンジニアリングの導入を検討するCEO・GTM責任者が最初に迷うのは、ツール選定ではなく「何を内製し、何を外部に任せるか」という役割分担です。丸ごと外注すれば担当者交代のたびに仕組みがブラックボックス化し、全て内製しようとすれば実装まで到達しないまま予算期が終わります。
この記事では、導入初期の90日間を基盤設計・実装自動化・計測移管の3フェーズに分け、フェーズごとに内製と外部の主担当を入れ替える設計を提示します。あわせて、フェーズごとに合意しておくべき成果物の具体例と、感覚ではなくチェック項目で判定する移管条件の考え方を整理しました。
読み終えると、契約や採用の意思決定を始める前に、社内で「誰が」「何を」「いつまでに」持つべきかを言語化できる状態になります。90日後に内製化を進めるか外部活用を継続するかの判断軸も併せて解説します。
この記事でわかること
- GTMエンジニアリング導入で「内製か外部か」の判断が揺れる根本原因
- 90日間を3フェーズに分け、フェーズごとに主担当を入れ替える設計の考え方
- フェーズごとに合意しておくべき具体的な成果物のリスト
- 感覚ではなくチェック項目で移管の可否を判定する方法
- 90日後に内製化を進めるか外部活用を継続するかの判断基準
はじめに
「GTMエンジニアリングを導入しよう」と経営会議で決まった翌週、真っ先に降ってくる質問は「それ、誰がやるんですか」ではないでしょうか。社内にRevOpsの専任者はいない。かといって、戦略の中身も分からない相手に丸投げするのは怖い。そんな板挟みの中で、とりあえず知り合いのパートナーに声をかけてみたものの、契約範囲のすり合わせだけで最初の数週間が過ぎてしまった、という経験をお持ちの方も多いはずです。
この記事は、そうした「決めきれないまま走り出す」状態を避けるために、90日という具体的な期間の中で内製と外部の境界線をどこに引くべきかを、フェーズごとに整理します。
なぜ「内製か外部か」で最初につまずくのか
GTMエンジニアリングの導入でCEOやGTM責任者が最初にぶつかる壁は、技術的な難しさではありません。「どこまで自社でやり、どこから外部に任せるか」を決めきれないまま走り出してしまうことです。結論からいえば、内製と外部の境界線は、90日という期間の中でフェーズごとに変わるものであり、最初に一度決めて終わりにできる話ではありません。
「とりあえず外注」が招く失敗パターン
よくあるのが、GTM戦略の設計から実装、運用の引き継ぎまでを丸ごと外部パートナーに委託してしまうケースです。導入直後は自動化されたワークフローやダッシュボードが次々と形になり、経営会議での報告資料も充実します。しかし3ヶ月、半年と経つうちに、現場から「このワークフローはなぜこの条件で動いているのか分からない」「担当者が変わったら誰も触れなくなった」という声が上がり始めます。
これは外部パートナーの実力不足ではなく、移管条件を最初に決めていなかったことが原因です。仕組みを作ってもらうことと、その仕組みを自社で運用し続けられる状態にすることは、まったく別の成果物だと捉える必要があります。
実際、あるBtoBサービス企業では、契約終了と同時に担当者が社内に一切残らず、ワークフローの改修が半年間止まったままになっていました。原因を辿ると、契約書には「実装」の範囲しか明記されておらず、「引き継ぎ」が成果物として定義されていなかったのです。
「全部内製」が失速する理由
逆に、「外部に依存したくないから」という理由だけで全工程を内製しようとする組織も少なくありません。この場合、最初の1ヶ月はデータ設計やツール選定の議論に費やされ、実装フェーズに入る頃には担当者の工数が枯渇し、優先順位の高い施策から後回しになっていく、という展開をよく見ます。GTMエンジニアリングに必要なのは、CRMの設定スキルだけでなく、営業現場の言葉を仕組みに翻訳する経験値です。この経験値がゼロの状態から社内だけで積み上げようとすると、90日という期間の中では検証まで到達しないまま予算期が終わってしまいます。
フェーズ間の橋渡しで摩擦が生まれる理由
内製と外部の対立は、フェーズの内部よりも「フェーズの継ぎ目」で起きやすいという特徴があります。基盤設計フェーズを社内主導で終えたのに、実装フェーズに入った途端に外部パートナーが独自の解釈でワークフローを組み始めてしまう、というのが典型例です。継ぎ目でのすれ違いを防ぐには、フェーズが切り替わるタイミングで必ず双方が同じ資料を見ながら前提を確認する場を設けることが欠かせません。
90日を3フェーズに分けて考える
内製と外部の役割分担を決める前に、90日をひとつの塊として扱うのをやめることが出発点になります。フェーズごとに「誰が何を持つか」を変える設計にすることで、外部への依存も、内製の空回りも避けられます。
Day1〜30：基盤設計フェーズ
最初の30日間は、GTM戦略をデータとプロセスに翻訳する期間です。ICP（理想の顧客像）の定義、パイプラインステージの再設計、ライフサイクルステージの合意形成など、意思決定の比重が大きい工程が中心になります。ここは、GTM戦略そのものを理解している社内の意思決定者（CEO、CRO、CMOなど）が主導権を持ち、外部パートナーは選択肢の提示と実装イメージのすり合わせに徹するのが機能しやすい分担です。
Day31〜60：実装・自動化フェーズ
基盤設計が固まったら、ワークフローの構築、リードスコアリングの実装、ダッシュボードの設計といった実務作業に移ります。この工程は、CRMツールの機能を熟知していることが成果のスピードを左右するため、外部パートナーの専門性を最大限に活用したいフェーズです。ただし、実装を丸投げにするのではなく、社内担当者が並走して「なぜこの条件でこのアクションが起動するのか」を理解する時間を確保することが、次のフェーズへの布石になります。
Day61〜90：計測・移管フェーズ
最後の30日間は、構築した仕組みが実際に機能しているかを検証し、日常運用を社内に戻す期間です。KPIダッシュボードの数値を見ながら、想定通りにワークフローが動いているか、例外処理でつまずいていないかを確認します。ここで初めて「移管」という言葉が具体的な意味を持ちます。単にマニュアルを渡すのではなく、トラブル発生時に社内担当者だけで一次対応できる状態まで持っていけるかどうかが、このフェーズの成否を分けます。
内製と外部、フェーズごとの役割分担表
抽象的な方針だけでは、実際のプロジェクトでは揺れ戻しが起きます。あらかじめ役割分担を言語化しておくことで、途中の「これは誰の仕事か」という摩擦を減らせます。
| フェーズ | 主担当 | 社内が持つべき役割 | 外部が持つべき役割 |
|---|---|---|---|
| Day1〜30 基盤設計 | 社内（意思決定者） | ICP定義、戦略の言語化、優先順位の決定 | 実装可能性の助言、選択肢の提示 |
| Day31〜60 実装・自動化 | 外部（実装専門性） | 要件のレビュー、並走による理解の蓄積 | ワークフロー構築、データ設計の実装 |
| Day61〜90 計測・移管 | 共同 | 一次対応の習得、運用マニュアルの内製化 | 例外対応の設計、引き継ぎ資料の整備 |
この表が示しているのは、内製と外部を「二者択一」で語るのではなく、フェーズごとに主担当を入れ替える設計にすることの重要性です。特にDay61〜90を「外部が去っていくだけの期間」にしてしまうと、移管は失敗します。共同で運用しながら権限を少しずつ移していく設計が現実的です。
GTMエンジニアが設計・実装・運用へ残す成果物は、次の記事で確認できます。
成果物を先に決めておく
内製と外部の役割分担が曖昧になる最大の原因は、「何ができたら完了なのか」という成果物の定義があいまいなことです。プロジェクト開始時点で、フェーズごとの成果物を具体的な形で合意しておく必要があります。
フェーズごとの成果物リスト
- 基盤設計フェーズ：ICP定義書、パイプラインステージ図、ライフサイクルステージの合意文書
- 実装・自動化フェーズ：稼働中のワークフロー一覧（5〜10本を目安）、リードスコアリングのロジック仕様書、KPIダッシュボードのプロトタイプ
- 計測・移管フェーズ：運用マニュアル、例外対応フローチャート、月次KPIレビューのテンプレート
例えば、実装フェーズの成果物を「ワークフローが動いていること」だけで定義してしまうと、なぜそのロジックになっているかが記録されず、担当者交代のたびに仕組みがブラックボックス化していきます。ロジック仕様書という形で言語化しておくことが、後々の内製化の土台になります。
移管条件をいつ、何で判定するか
「そろそろ内製に切り替えられそうだ」という感覚だけで移管を進めると、多くの場合、想定より早く社内が対応しきれなくなります。移管条件は、感覚ではなく具体的なチェック項目で判定するべきです。
移管のチェック項目
移管の可否を判断する際は、以下のような項目を確認します。
- 社内担当者だけで、稼働中のワークフローの設定画面を開き、条件分岐を説明できるか
- KPIダッシュボードの数値が異常値を示したとき、原因の切り分けを自力で行えるか
- 新しいセグメントやキャンペーンを追加する際、既存の設計を壊さずに拡張できるか
- 例外パターン（データ不備、重複、条件の競合など）への対応手順が文書化されているか
これらの項目に「まだ自信がない」という回答が複数残っている状態で移管を強行すると、運用が止まった際に誰も直せないという事態に陥ります。
移管が失敗する典型パターン
移管が失敗するプロジェクトには共通点があります。ひとつは、移管のタイミングを外部パートナーとの契約終了日に合わせてしまい、準備状況とは無関係に区切りを迎えてしまうことです。もうひとつは、移管を「資料の受け渡し」で完了とみなし、実際の運用を任せてみるテスト期間を設けないことです。移管とは、権限と情報を渡すことではなく、社内担当者が一人で判断できる状態を作ることだと定義し直すと、必要な準備の量が見えてきます。
理想的には、Day61〜90の中で1〜2週間ほど「社内担当者が主導し、外部パートナーが横で見守る」という逆転した体制を試す期間を設けることをお勧めします。この期間にトラブルが起きなければ、移管後の運用リスクは大きく下がります。
自社が先に投資すべき領域を見極める際は、次の記事を参照してください。
90日後の判断：内製チームを育てるか、外部を継続活用するか
90日間の実装が一段落した後にもう一つ避けて通れないのが、「これから先も外部パートナーと契約し続けるのか、専任の内製担当者を採用するのか」という判断です。ここを移管フェーズの最中に決めておかないと、90日目を迎えてから慌てて議論を始めることになります。
内製チームを育てる選択肢が向いている組織
GTM施策の数が多く、四半期ごとに新しいセグメントやキャンペーンを追加し続ける組織では、専任の内製担当者を置く選択肢が現実的です。CRM管理者やマーケOps担当者を1名採用し、外部パートナーには新しい施策の設計や高度な自動化のスポット支援に役割を絞ってもらう形が機能しやすくなります。ポイントは、採用のタイミングをDay61〜90の移管フェーズに重ねておくことです。移管の相手が「これから入る新人」ではなく、実装段階から並走してきた既存の担当者であるほど、引き継ぎの精度は上がります。
外部活用を継続する選択肢が向いている組織
一方、GTM施策の変更頻度がそれほど高くなく、四半期に一度程度の見直しで十分な組織では、専任担当者を採用するコストに見合わない場合があります。この場合は、月次や四半期単位での保守契約に切り替え、運用の主担当は社内、トラブル対応と改善提案は外部という体制を継続する方が合理的です。いずれの選択肢を取るにせよ、判断基準になるのは「施策の変更頻度」と「社内に蓄積したい専門性の範囲」の2軸だと整理しておくと、経営会議での意思決定がスムーズになります。
まとめ
GTMエンジニアリング導入の成否は、技術力よりも「何を内製し、何を外部に任せるか」の設計にかかっています。90日を基盤設計・実装自動化・計測移管の3フェーズに分け、フェーズごとに主担当を入れ替える。成果物とチェック項目ベースの移管条件をあらかじめ合意しておく。
この2点を最初に言語化しておくだけで、途中の役割の押し付け合いや、移管後に誰も触れなくなる仕組みを大きく減らせます。90日後の内製・外部継続の判断も、移管フェーズの最中から準備を始めることが、無理のない体制づくりにつながります。
Q&A
- QGTMエンジニアリングの導入に、専任のRevOps担当者は必須ですか?
- A
必須ではありません。GTM戦略の意思決定は社内の経営層や事業責任者が担い、システムへの実装は外部パートナーに委託するという分業で進めることは可能です。ただし、移管フェーズで一次対応を引き継ぐ担当者だけは、早い段階で決めておく必要があります。
- Q90日という期間はどんな組織にも当てはまりますか?
- A
施策の規模や複雑さによって前後しますが、基盤設計・実装・移管という3段階の考え方自体は、規模を問わず応用できます。施策数が多い組織では各フェーズの期間を伸ばし、小規模な組織では並行して進めることで、短縮することも可能です。
- Q外部パートナーとの契約に、移管条件をどう盛り込めばよいですか?
- A
「実装が完了すること」だけでなく、「社内担当者が特定のチェック項目を満たした状態で引き継ぎが完了すること」を成果物として契約書に明記するのが有効です。抽象的な「引き継ぎ支援」ではなく、具体的な確認項目を事前にすり合わせておくことで、双方の認識のずれを防げます。
専門用語解説
- GTMエンジニアリング：GTM（市場参入）戦略をCRMやMAなどのシステムに実装し、現場の行動に落とし込む取り組み
- RevOps：マーケティング・営業・カスタマーサクセスの収益プロセスを組織横断で最適化する概念
- ICP：自社にとって理想的な顧客像を定義したもの
- ライフサイクルステージ：見込み客が顧客になるまでの段階をCRM上で分類する仕組み
- MQL：マーケティング活動によって一定の基準を満たし、営業に引き渡す対象と判断されたリード
- ワークフロー：条件に応じてメール送信やタスク生成などのアクションを自動で実行する仕組み
- ダッシュボード：複数のKPIを一画面でまとめて確認できるようにした画面
