第3章 GTMの設計：戦略から運用までの5ステップ
3-1 なぜ「間」が欠落するのか
GTM（Go-to-Market）とは、製品・サービスを市場に届け、継続的な収益に変えるまでの一連の設計である。本書ではその全体を、次の5つの階層で捉える。
戦略 →（ 戦術 → 実装 ）→ 実行 → 運用・PDCA
多くの企業が持っているのは、両端である。経営やコンサルタントが「戦略」を描き、現場が「実行」として施策を回す。しかし、その間にあるべき2つの層――戦略を実行可能な形に翻訳する戦術と、それをデータとシステムに具現化する実装――は、しばしば誰の責任範囲でもないまま放置される。
理由は組織構造にある。戦略は経営企画やコンサルの成果物として納品され、施策はマーケティングや営業の現場が日々のKPIに追われながら回す。だが「戦略をどうデータモデルとオペレーションに落とすか」を専門に担う機能は、伝統的な組織図のどこにも存在しない。結果として、戦略と施策は互いに接続されないまま並走し、各部門が部分最適に陥った状態で、第1章で述べたサイロ化・非SSOT状態という症状が現れる。
本章では、この5階層を順に解説する。読者にはぜひ、自社がどの層を持ち、どの層が欠けているかを照らし合わせながら読み進めていただきたい。
3-2 ステップ①戦略――「誰に・何を・なぜ自社が」を決め切る
戦略層の目的は、市場のどこで、誰に対して、どのような価値で戦うのかを決め切ることである。ここが曖昧なまま下の層に進むと、後続のすべての設計が「なんとなく」になる。戦略は次の工程を順に踏むことで、思い付きではなく論理として構築できる。
(1) 環境分析：PEST・SWOT
出発点はマクロ環境の把握である。PEST分析により、政治・法規制（Politics）、経済（Economy）、社会（Society）、技術（Technology）の4視点で、自社の市場に働く外部圧力を洗い出す。BtoBにおいては、業界規制の変化、景気による投資意欲の増減、労働人口の構造変化、そして生成AIのような技術非連続が、顧客の購買行動を根本から変える要因となる。
次にSWOT分析で、自社の強み（Strength）・弱み（Weakness）という内部要因と、機会（Opportunity）・脅威（Threat）という外部要因を整理する。ここで重要なのは、希望的観測を排し、顧客や競合の視点から見た事実を書くことである。「技術力が強み」と社内で信じられていても、顧客がそれを選定理由に挙げていなければ強みではない。
(2) クロスSWOT：分析を戦略オプションに変換する
SWOTの最大の落とし穴は、「4象限を埋めて満足してしまう」ことである。分析はそれ自体では何も生まない。クロスSWOTは、4要素を掛け合わせて戦略オプションを導出する工程である。
- 強み×機会（SO戦略）：最優先の攻め筋。強みを機会にぶつけて成長を最大化する
- 弱み×機会（WO戦略）：機会を逃さないために弱みを補強する（提携・採用・投資）
- 強み×脅威（ST戦略）：強みで脅威の影響を回避・軽減する
- 弱み×脅威（WT戦略）：最悪の組み合わせ。撤退・縮小も含めた守り筋
この工程を経ることで、「分析resultsの羅列」が「取りうる打ち手の選択肢」に変わる。経営が意思決定すべきは、このオプションのどれにリソースを集中するかである。
(3) STP：市場での立ち位置を決める
戦略オプションが定まったら、STPで市場での立ち位置を具体化する。市場を意味のある軸で分割し（Segmentation）、勝てるセグメントを選び（Targeting）、そのセグメントの顧客の頭の中で競合とどう差別化されて認識されたいかを定義する（Positioning）。
BtoBにおけるセグメンテーションの軸は、業種・企業規模といった属性だけでは不十分である。「どのような課題を、どの程度の切実さで抱えているか」という課題軸を組み合わせることで、後述するICPの解像度が決まる。
(4) ICP：ターゲットを実務の解像度に落とす
ここまでの工程を、BtoBの実務で使える解像度に落とし込むのが**ICP（Ideal Customer Profile：理想顧客像）**の定義である。STPのターゲティングが「セグメント」を選ぶのに対し、ICPは「企業」を特定できるレベルまで具体化する。
- 企業属性：業種、規模、売上レンジ、地域、使用テクノロジー
- 組織状態：抱えている課題、組織体制、変化の兆候（採用動向、投資領域）
- 購買体制：意思決定者と関与者（DMU）、稟議プロセス、予算サイクル
ICPの解像度は、GTM全体の効き目を左右する最大の変数である。「20〜100名規模で、営業部門のデータ活用に課題を持つBtoB SaaS企業の経営者」まで絞り込めていれば後続の設計はすべて具体化するが、「DXに関心のある大企業」のような曖昧さでは、どれだけ精緻なシステムを組んでも機能しない。
(5) ペルソナ設計――「企業」から「購買グループ」へ
ICPが「狙うべき企業」を定めたなら、次は「その企業の中の、誰に働きかけるのか」を定義する。ここで前提を改めねばならない。BtoBの購買は、もはや一人の担当者が決めるものではない。当社の調査では、1,000万円以上の案件において購買に関与する人数は平均18.3名に達する（BtoB購買プロセス白書2025）。単一のペルソナを描くだけでは、この複雑な合議体には届かない。
そこで有効なのが、意思決定に関わる複数人＝**購買グループ（DMU：Decision Making Unit／意思決定関与者群）**を、役割で捉える視点である。同じ企業の中でも、関与者はその立場によって関心事も懸念も動き方も異なる。実務上は、次の4つの役割に整理すると設計しやすい。
- 着火役：課題に最初に気づき、情報収集を始める人。多くの場合、最初に自社と接点を持つのはこの役割
- 旗振り役：社内で「これをやろう」と旗を立て、検討を推進する人。着火役がここへ育つこともある
- 門番役：情報システム・法務・調達など、要件や制約の観点から可否を判断する人
- 決裁役：最終的に予算を承認する人。関心は投資対効果とリスクに集約される
ペルソナ設計の要諦は、それぞれの役割が抱える課題（ペイン）と、意思決定における関心を言語化することである。着火役に響くコンテンツと決裁役に響くコンテンツは、まったく異なる。さらに購買プロセスが進むにつれ、関与する役割は増え、着火役が旗振り役へと変化していくといった動きも起こる。この「役割ごとの解像度」を持つことで、後続のカスタマージャーニーとコンテンツ設計が、一人の架空の担当者向けではなく、実際の合議プロセスに沿ったものになる。
(6) バリュープロポジション：選ばれる理由の言語化
狙うべき企業（ICP）と、その中の関与者（ペルソナ）まで解像度が上がって初めて、「その相手に対して、自社は何を約束するのか」を研ぎ澄ませられる。ポジショニングを顧客への約束として言語化したものがバリュープロポジションである。要件は3つ。①顧客が真に求めており、②自社が提供でき、③競合には提供できない――この3円の重なりに位置する価値だけが、選ばれる理由になる。「高品質・低価格・充実サポート」のような誰でも言える言葉はバリュープロポジションではない。さらにBtoBでは、同じ価値でも着火役に響く語り口と決裁役に響く語り口は異なるため、ペルソナの役割ごとに訴求の翻訳が要る点も押さえておきたい。
(7) GTMモーション：届け方の基本方針を選ぶ
戦略層の最後の工程が、**GTMモーション（市場への届け方の型）**の選択である。主要な選択肢は次の通り。
- インバウンド：コンテンツと検索・広告で見込み客を引き寄せる。ターゲットが数千社規模で、課題が顕在化しやすい商材に向く
- アウトバウンド：こちらから特定企業に働きかける。ターゲットが明確で単価が高い商材に向く
- ABM（Account-Based Marketing）：ターゲットが50社以下など限定的な場合に、企業単位で個別戦略を組む
- PLG（Product-Led Growth）：製品自体の無料利用体験を入口にする。セルフサーブで価値を体感できる商材に向く
- パートナー/代理店：商流や地域カバレッジを外部と組んで作る
重要なのは、モーションは択一ではなく組み合わせであり、ICPと商材特性（単価・購買プロセスの長さ・意思決定の複雑さ）から論理的に導かれるという点である。「競合がABMをやっているから」ではなく、「ターゲットが80社しかないからABM」でなければならない。
3-3 ステップ②戦術――戦略を「回せる形」に翻訳する設計図
戦術層の役割は、戦略をオペレーションとして回せる形に翻訳した設計図を描くことである。建築に喩えれば、戦略が「どんな建物をなぜ建てるか」の企画書だとすれば、戦術は設計図面にあたる。図面なしに施工（実装）はできない。
戦術層で描くべき設計図は5つある。
①チャネル設計。 選択したGTMモーションを、具体的な接点に展開する。インバウンドならSEO・広告・ウェビナー・展示会、アウトバウンドならメール・電話・紹介など、ICP・購買グループ（DMU）が実際に情報収集する場所に基づいてチャネルの優先順位と予算配分を決める。
②カスタマージャーニー設計。 ICP・購買グループ（DMU）が課題を認知してから契約・活用に至るまでの心理と行動の変遷を定義し、各段階で「顧客が必要とする情報」と「自社が取るべきアクション」を対応づける。ジャーニーは施策の羅列表ではなく、後述するKPIとデータ設計の骨格となる。
③レベニューモデル設計。 マーケティング・インサイドセールス・営業・カスタマーサクセスの4機能（必ずしもこうした部門編成が明確に存在しなくとも、部門や担当をまたいで協業が発生する場合を含む）が、リードをどの状態で受け渡すのかを定義する。各部門の役割範囲、引き渡し基準（例：どの条件を満たしたらマーケから営業に渡すか）、そしてSLA（部門間の合意）――「渡されたリードに何営業日以内に対応するか」といった約束事――を明文化する。サイロ化の多くは、この合意が存在しないことから始まる。
④KPI階層設計。 受注という最終成果から逆算し、商談化率・商談数・リード数・チャネル別流入と、階層的に指標を分解する。重要なのは、全部門が同じ定義の数字を見ることである。「商談」の定義が部門ごとに違えば、どれだけ計測しても意思決定には使えない。
⑤データモデル設計。 本書が最も強調したい設計図がこれである。上記①〜④のすべては、データの構造が正しく設計されていて初めて計測・運用可能になる。中核となる問いはシンプルだ――**「アカウント（企業）」と「ピープル（人）」という2つの基軸エンティティ（データ管理上の中心となる対象。あらゆる情報を紐づける「軸」となる箱と考えるとよい）を定め、あらゆるデータがそのどちらかに紐づくよう関係構造を描けているか。**企業と人の関係（所属・役職・購買関与）、活動データが誰に・どの企業に帰属するのか。この構造図こそが、次の実装層に引き渡す最重要の設計図となる。
3-4 ステップ③実装――設計図をデータとシステムに具現化する
実装層は、戦術層の設計図を実際に動くデータ基盤とシステムに具現化する工程である。冒頭の5階層モデルで言えば、多くの企業で最も深刻に欠落しているのがこの層であり、後章で述べるGTM Engineeringの主戦場でもある。実装の要諦は3つに集約される。
(1) 一意性の担保――SSOTの土台
すべての出発点は、同一の企業・同一の人物が、システム上で重複なく一意に管理されている状態を作ることである。具体的には、法人番号・企業ドメイン・メールアドレスといった一意キーを定め、名寄せ（重複データの統合）のルールを実装する。
なぜ一意性がそれほど重要なのか。「株式会社ABC」「ABC（株）」「ABC Corporation」が3件の別レコードとして存在した瞬間、その企業のリード数も、接触履歴も、商談状況も、3つに分裂する。集計は信頼を失い、スコアリングは誤作動し、自動化は誤った相手に誤ったメッセージを送る。一意性が崩れれば、その上に築かれるすべての計測と自動化が信頼を失う。
ここで**SSOT（Single Source of Truth：単一の真実）という言葉を改めて説明しておきたい。直訳すれば「唯一の信頼できる情報源」である。同じ顧客について、マーケが見るデータ、営業が見るデータ、経営が見るデータが、それぞれ別の場所にバラバラに存在し食い違っている状態——これがSSOTでない状態だ。対してSSOTとは、「この顧客のことは、ここを見れば全部わかる。そして全部門がその同じ一箇所を見ている」**という状態を指す。誰かがどこかで更新すれば、全員に反映される。営業が入力した商談メモも、マーケが計測したWeb行動も、同じ顧客の同じレコードに集約されている。この「一箇所に集約され、全員が同じものを見る」状態こそが、正しい意思決定と自動化の土台になる。
重要なのは、SSOTは崇高な理念やスローガンではなく、一意性の担保という地道な技術的実装の積み重ねによってのみ実現するという点である。名寄せルールを設計し、一意キーを定め、重複を継続的に統合する——その先にしか「単一の真実」は立ち上がらない。
(2) データが「集まる」仕組み――入力から集積へ
次の要諦は、発想の転換である。多くの企業はデータ整備を「現場に入力を徹底させること」と捉えるが、人手による入力は必ず漏れ、劣化する。目指すべきは、多様なデータが一意なアカウント/ピープルに自動的に紐づき、蓄積されていく構造である。
そして近年、この「自動的に集まる」ことの現実味は、AIの発展によって飛躍的に高まっている。かつては構造化された入力欄に手で打ち込むしかなかった情報が、いまや非構造の生データから自動で抽出・要約され、正しいレコードに紐づけられるようになった。具体的には——
- Webサイトの閲覧行動 → 匿名訪問からフォーム入力を経てピープルに紐づく
- メールの開封・クリック → ピープルの興味関心として蓄積される
- 商談・訪問の会話内容 → 録音・オンライン会議の記録をAIが文字起こし・要約し、商談メモとして自動記録される
- 顧客との電話・メールのやり取り → 通話内容やメール文面をAIが解析し、論点・温度感・次アクションを抽出してアカウント/ピープルに蓄積する
- 名刺交換・イベント参加 → ピープルとして取り込まれ、所属アカウントに接続される
- 契約・請求情報 → アカウントの取引実績として統合される
かつて「営業が議事録を書く時間がない」「電話の内容は担当者の頭の中にしかない」といった理由で失われていた情報が、AIによって自動的に資産化される時代に入った。「データは入力するものではなく、集まる仕組みを作るもの」——この転換ができた組織だけが、データを意思決定と自動化に使える資産に変えられる。
(3) MA/SFAへのシステム実装
最後に、上記のデータ構造と戦術層の設計図（ジャーニー、レベニューモデル、KPI）を、MA/SFAという実システムの上に構築する。リードのステージ定義、スコアリングルール、部門間ハンドオフの自動化、ナーチャリングシナリオの骨格、ダッシュボード――戦術がシステムの設定として具現化されて、初めて「実行できる状態」が完成する。
注意すべきは順序である。ツールを導入してから設計を考えるのではなく、設計図があってからツールに実装する。この順序が逆転した企業が、「MAを入れたが配信ツールにしかなっていない」「SFAが入力負担だけの箱になっている」という典型的な失敗に陥る。
そして、この工程で最も本質的なのは、ツールの機能比較よりも**「顧客管理の思想」を持っているかどうか**である。ここまで述べてきた一意なアカウント/ピープル構造、データが集まる仕組み、SSOT——これらはいずれも、ツールが自動的に与えてくれるものではなく、「顧客をどう捉え、どう管理するのか」という思想があって初めてシステムに宿るものだ。同じMA/SFAを導入しても、この思想の有無で結果は正反対になる。したがって、ツール選定においては「顧客管理の思想を、そのツールで体現・具現化できるか」という視点が欠かせない。
同じことは、導入を伴走するベンダーやパートナーの選定にも当てはまる。ツールの設定を代行するだけの相手ではなく、顧客管理の思想を強く持ち、それをデータモデルとして設計に落とし込める相手を選ぶことが、実装の成否を分ける。ツールは思想を実現する器にすぎず、器だけを立派にしても中身の設計思想がなければ機能しないのである。
3-5 ステップ④実行――実装済みの基盤の上で施策を走らせる
実行層は、ようやく多くの企業が「マーケティング施策」と呼ぶ実戦の層である。コンテンツ（ホワイトペーパー、事例、ウェビナー、調査レポート）の制作と配信、ナーチャリングシナリオの運転、キャンペーンの実施、アウトバウンドの実行。
ここまでの階層を経た実行と、いきなり施策から始めた実行は、外見が似ていても中身がまったく異なる。前者では、すべての施策がICPに向けられ、ジャーニー上の位置が明確で、成果が一意なデータとして蓄積され、受注まで追跡できる。後者では、施策は打ちっぱなしになり、「何が効いたのか」を誰も答えられない。実行の質は、実行層ではなくその上流で決まるのである。
3-6 ステップ⑤運用・PDCA――回し続け、正しい階層に戻る
最後の層は、この全体を継続的に回す仕組みである。運用面では、データ品質を維持するルール（入力規則、定期クレンジング）、リード管理と部門間ハンドオフの運用体制、そして担当者の異動・退職に耐える文書化と教育を設計する。属人化した仕組みは、作った人の離脱とともに崩壊する。
PDCAで最も重要なのは、Check（計測）の後、どの階層に戻って直すかの切り分けである。
- メールの開封率が低い → 施策の問題（実行層で改善）
- リードは取れるが商談化しない → 引き渡し基準やナーチャリング設計の問題（戦術層に戻る）
- 商談化しても受注率が著しく低い → そもそもICPやポジショニングの問題（戦略層に戻る）
この切り分けができない組織は、戦略の問題を施策のA/Bテストで解決しようとして消耗する。逆に切り分けができれば、PDCAは「施策の改善ループ」から「GTM全体を進化させるループ」に変わる。
ここまでが、GTM設計の5ステップの全体像である。そして、聡明な読者はすでにお気づきだろう――この5ステップ、とりわけ戦術と実装の層を、人力と気合だけで構築・維持し続けることは可能なのか？ データは日々劣化し、組織は変わり、市場は動き続ける。この問いへの答えとして登場したのが、次章で解説するGTM Engineeringである。
