Content last updated 2026-05-08

商談の推進

商談を推進するための GitLab セールスプロセス

リードを認定し、それをセールスに変える必要があります。このフェーズは 商談の推進 (Facilitate the Opportunity) と呼ばれます。このフェーズの目的は、顧客から テクニカルコミット、続いて エコノミックコミット を獲得することです。コミットとは、買い手がディールを進めたいという口頭での承認です。このフェーズでは、テクニカルコミットとエコノミックコミットを獲得するために完了させる必要のある 4 つのハイレベルなタスクがあります。

  • ディスカバリー
  • スコーピング
  • テクニカルバイヤーからのテクニカル評価/テクニカルコミット
  • エコノミックバイヤーからのエコノミックコミット

繰り返しになりますが、上記の 4 つのタスクは、各タスク内で MEDDPPICC と Command of the Message (CoM) を正しく適用したことを示す実証可能なアウトプットです。これは、皆さんが一般的なソフトウェアセールスパーソンとして見られる存在から、複数の請求書と笑顔の代わりにビジネスソリューションをもたらす信頼されたコンサルタントへと変わっていく移行も支えます。

ステップ 1: ディスカバリーの質問

伝統的なセールスは、通常、顧客を理解することを飛ばしてしまいます。伝統的なセールスは、バズワードや何らかのランダムな製品機能が顧客の注意を引き、顧客に緊急性を構築することを期待して、顧客を製品情報で圧倒することにより、顧客に足がかりを得る ことに大きく依存しています。GitLab はそのような形では運営しません。GitLab はディスカバリーの質問を使います。

ディスカバリーの質問 は、既存の顧客のニーズ、問題、ペインポイント、ゴールなどを明らかにするのに役立ちます。商談が SDR から引き継がれたものであろうと、皆さん自身が認定したものであろうと、以下のリサーチプロセスと基準に基づいて常にディスカバリーの質問を作成すべきです。

1.1 リサーチ

1.1.1 バイヤーペルソナを判断する

バイヤーペルソナは、主要な買い手を架空表現したものです。これにより、買い手にとって重要な障害、反対、イニシアチブ、メトリクスを事前に特定できます。このステップは、競合よりも顧客をよりよく理解する優位性を与えてくれます。一般的に出会う可能性のあるバイヤーペルソナは 5 つあります。

  • テクノロジーリーダー
  • ビジネスアプリケーションリーダー
  • セキュリティリーダー
  • CXO リーダー
  • ファイナンシャルリーダー

1.1.2 バイヤープロセスマップを参照する

バイヤープロセスマップ (BPM) は、買い手が意思決定をするためにたどる思考の経路を浮き彫りにし説明するもので、買い手がプロセスのどこにいるかに基づいてセールス活動をガイドするのに役立ちます。このステップでのゴールには、差別化、抵抗の軽減、サイクルの無駄遣いの回避、より良いミーティングの推進と作成が含まれます。バイヤープロセスマップの内訳と、見込み客がバイヤープロセスのどの段階にいるかを示す一般的な買い手のアクションをご覧ください。

1.1.3 買い手をリサーチする

このステップには、追加の買い手のインサイトを得るために必要な多数のサブタスクが含まれます。

  1. SFDC を参照して、リードが現在の顧客または見込み客であるかどうかを確認します。最近の活動や過去の連絡などのデジタルなボディランゲージをレビューします。
  2. LinkedIn を参照し、コンタクトのプロフィールを関連するバイヤーペルソナと相互参照して、重なりを探します。
  3. 会社のウェブサイト を参照し、戦略的目標、業界、ビジネスモデル、買い手などに関する基本を吸収します。

1.1.4 ディスカバリーの質問を作成する

商談を認定するために必要な情報を収集するには、MEDDPPICC を活用します。

  • ディスカバリーの質問 は、既存の顧客のニーズ、問題、ペインポイント、ゴールなどを特定するように設計されています。
  • MEDDPPICC は、商談に時間、労力、会社のリソースを費やす価値があるかどうかを判断するのに役立つ認定フレームワークです。これは プレコール計画 の一面です。プレコール計画の質問は、セラーとしての皆さんに、エンゲージするバイヤーペルソナをさらに検証して参照させます。バイヤーがセールスプロセスのどの段階にいるかをより迅速に判断するのに役立ちます。このフレームワークは、問題を浮き彫りにし、次のステップを明確にもします。良いディールとノーディール、迅速なディールと長期的なディールを仕分けやすくすることで、皆さんをより効率的でフォーカスされたセールス担当者にするのに役立ちます。

1.1.5 ペルソナベースのコールプランを開発する

このステップは、買い手からより適切な情報を収集するのに役立ちます。より具体的には、情報のギャップを特定し、特定の目標を設定し、最終的に皆さんに対する買い手の信頼を高めるのに役立ちます。以下の 2 つのジョブエイドを使ってディスカバリーコールに備えてください。

1.1.6 ディスカバリーコールミーティングを実施する

ディスカバリーは 1 回のコールでは行われません。一連のミーティングを通じて行われます。可能な限り最善のプロダクトソリューションを提案するために、顧客の組織を深く理解する時間を取ることが重要です。以下は、成功するディスカバリーコールミーティングを推進するために必要なタスクとアセットです。

  1. ミーティングアジェンダを準備する - 買い手が何を求めているかと皆さんがカバーする内容がマッチするかを特定します。これを買い手に事前に送って、整合を確認することができます。各アジェンダ項目について、BPM からのいくつかの質問を含めたり、ステートメントを準備したり、業界のケーススタディを準備します。ペルソナの目標と障害セクションの 1〜3 項目をリサーチします。買い手に対して準備ができていて、聞いていて、共感的であることを示すために、ミーティングの目標を確定します。見込み客がリラックスして、自分の問題やニーズについて深く話すことが快適になるようにミーティングを構成します。
  2. カスタマー要件ドキュメント を使う - ミーティング中に、ディスカバリーの質問からのフィードバックを捕捉します。
  3. コマンドプランを使う - ディールの進捗を追跡します。これは Salesforce 内のイテレーティブなドキュメントで、皆さんとチームに商談へのマクロおよびミクロレベルの可視性を提供します。商談を適切に認定するために必要な情報を迅速に捕捉するため、必要な MEDDPPICC プロセスを通して整合とガイドを行うように設計されています。サンプルコマンドプランはこちらです。
  4. 顧客向けデックを作成する - 顧客向けデックは商談固有のものとし、可能な限り顧客のブランディングを活用すべきです。さらに、顧客向けデックは、主要なコンタクトポイントまたは特定されたチャンピオンからのインプットを得て作成すべきです。

1.2 顧客向けデックの作成 (フェーズ 1)

良いピッチを開発し提示する目的は、顧客から 口頭でのコミット を獲得することです。再度言いますが、伝統的なセールス担当者は、機能の 1 つが顧客に響き、購入する緊急感が生まれることを期待して、会社と製品機能の長い概要で顧客を圧倒する傾向があります。

ピッチを顧客のことよりも私たちのことに重きを置かないようにしましょう。 GitLab ではアプローチがよりコンサルティング的です。これが、個別のリサーチとディスカバリーコールに基づいた顧客への洞察が非常に重要である理由です。それは、顧客の問題が何で、長期的なゴールは何かについての深い理解を皆さんに与えてくれます。GitLab セールスピッチを開発し提示する皆さんの責任は、顧客の問題を特定の GitLab プロダクトベースのソリューションに整合させることです。皆さんはここまで顧客と協力して、重い荷物を持ち上げて、彼らに必要なものを理解してきました。今、コンサルタントとして、彼らの即時のニーズに対応する確固たるソリューションを提示すると同時に、彼らの長期的なゴールとニーズに対するソリューションロードマップも提供します。

ルールとして、GitLab セールスピッチデックは 10〜15 スライド以下であるべきです。GitLab カスタマーテンプレートを使用して、推奨スライド数に減らすことができます。

エンタープライズストラテジックアカウントリーダーの場合、この GitLab ENT SAE 提案テンプレートを使用して、顧客向けのカスタム提案にスタートダッシュを切ることもできます。

また、テキストが多いよりもビジュアルなプレゼンテーションが推奨されます。GitLab 顧客向けデックには以下のコンポーネントを含めるべきです。

  1. バリュードライバー
  2. GitLab がどのように役立つか

1.2.1 顧客の問題をバリュードライバーと整合させる

GitLab セールス担当者として、ディスカバリーコールとリサーチから、すべてではないにしても 1 つの GitLab バリュードライバーに合わせるのに十分なほど顧客のペインポイントを知っているべきです。GitLab には以下の 3 つのバリュードライバーがあります。

  • 業務効率の向上
  • より良い製品をより速く提供する
  • セキュリティとコンプライアンスのリスクを低減する

皆さんの仕事は、特定の主要なペインポイントを呼び出して、顧客に彼らのペインが GitLab のバリュードライバーとどのように整合しているかを示すことです。

1.2.2 GitLab がどのように役立つかを示す

ピッチデックの次のコンポーネントは、GitLab がどのように役立つかを示すことです。これには、顧客の特定のユースケースを理解する必要があります。ディスカバリーコールから問題を定義するためのデータの多くが提供されたはずですが、さらに進むには以下を行う必要があります。

  • カスタマーユースケースをリサーチする
  • 顧客のペインポイントを典型的なカスタマーユースケースに整合させる
  • 関連するカスタマーユースケースに関連して GitLab が何をするかを説明する

顧客向けデックのこの部分は、顧客に GitLab とは何で、どのように彼らを助けることができるかを方向づけるのに役立ちます。

1.2.3 AE/SAE からソリューションアーキテクトへの移行

ディスカバリーコールから収集されたデータは、AE/SAE によって分析され、彼らの組織にとっての GitLab の価値という観点でリードを認定するかどうかが判断されます。認定の判断後、AE/SAE は ソリューションアーキテクト をエンゲージして、セールスプロセスのスコーピングフェーズへの移行を開始すべきです。

  1. AE/SAE は、ディスカバリーの質問から捕捉されたデータのギャップ分析を実行し、それはカスタマー要件ドキュメントに保持されます。スプレッドシートの顧客要件を特定の GitLab 製品ラインに整合させ、GitLab がその要件を満たすかどうかを示します。この分析は、顧客の要件とゴールが異なるため、可能な DevOps サイクルのエントリポイントも提供します。
  2. AE/SAE はソリューションアーキテクトを紹介し、エンゲージ して技術的な会話を行い、ソリューションアーキテクトと一緒にカスタマー要件ドキュメントをレビューします。
  3. AE/SAE は関連する SFDC フィールドを新しい情報で更新し、スコーピング のためにソリューションアーキテクトへの正式な引き継ぎを行います。コマンドプラン を活用して、ディールの進捗を追跡します。これは Salesforce 内のイテレーティブなドキュメントで、皆さんとチームに商談へのマクロおよびミクロレベルの可視性を提供します。

ステップ 2: スコーピング

スコーピングは、顧客要件をより詳細に議論する機会を表します。このステップは、ソリューションアーキテクト (SA) の主な責任です。SA は、AE/SAE が提供したドキュメントに基づいて、技術要件の詳細レビューを行います。スコーピングにおける SA の主なゴールは、プロジェクトスコープに含める必要のあるすべての必要な要素を理解し、すべてのステークホルダーにとって成功する成果を生み出すために結集する必要のある部分を特定することです。適切なスコーピングを達成するために必要なタスクは以下のとおりです。

  1. カスタマー要件 ドキュメントと関連するミーティングノートをレビューして、ギャップを特定し、技術機能に関連するより深いディスカバリーの質問を作成します。
  2. ハイレベルな技術ディスカバリーコール を顧客と実施し、一緒にカスタマー要件ドキュメントをレビューし、顧客の要件についてのコンテキストとインサイトをさらに収集します。
  3. 更新された要件を GitLab 製品に対して 分析 し、フィット評価を判断します。フィットが判断されたら、技術評価を開始します。
  4. プロフェッショナルサービスを販売する機会を特定する。SAE/ISR は、PS チームが提供する一般的なサービスをサービスページで、または特定の SKU 提供の詳細についてはフルカタログで見つけることができます。SAE/ISR は、顧客要件に基づいて必要なサービスの選択を支援するために SA を引き入れることができます。

ステップ 3: 技術評価

技術評価 は、見込み客が GitLab の彼らの組織と特定のビジネス成果へのフィットを評価する場です。これは、Lite POV、無料トライアル、リアルタイムまたは非同期の Q&A、ワークショップ、および/または SA の技術ガイダンスを必要とするその他のアプローチによって駆動される可能性があります。ディスカバリーに SA が含まれていなかった場合、AE はトリアージプロセスに従って商談に SA をエンゲージし、Issue テンプレートに記入し、Salesforce で MEDDPPICC 情報と既知の必要な能力を提供する必要があります。以下は、技術評価中に SA がレビューおよび管理する必要があるタスクです。

  1. カスタマー要件ドキュメントを更新 し、Google Docs と Salesforce で顧客環境と技術仕様に関する進行中のミーティングノートをレビューします。
  2. 以下の技術評価基準に基づいて、GitLab の無料トライアルをセットアップ します。
  3. 要件収集、技術ディスカバリー、顧客のメタレコードから ソリューション設計のブループリントを作成 します。
  4. 必要に応じて、他の技術的および/またはビジネス的なやり取りを通じて達成できない特定の顧客のビジネス成果に焦点を当てた Proof of Value を作成します。
  5. Proof of Value (PoV/PoC) プランを提出 し、ステークホルダーの承認を得ます。

戦略ミーティングを開催する: SA がソリューション設計のブループリントおよび/または Proof of Value を完了したら、セールス担当者は、顧客にピッチデックを準備して提示するためにソリューションのハイポイントを議論する戦略ミーティングを SA と開催する必要があります。セールス担当者が深い技術製品の知識を持っていない場合、SA とソリューションブループリントを振り返ることがさらに重要になります。

Command of the Message は、「お客様の問題に対するソリューションを、競合と差別化し、製品とサービスにプレミアム価格を請求できるような形で定義する準備ができていること」と定義されています。これは、多くの面で顧客のペインポイントとゴールを彼ら自身よりもよく理解し、本物のソリューションを語る必要があることを意味します。ソリューションは、ピッチデックを通じて顧客に提示されます。

この時点で、セキュリティアシュランスのサポートを提供するために、リスク&フィールドセキュリティチームをエンゲージすることも有益かもしれません。財務的なコミットを行う前に、多くの顧客がセキュリティのデューデリジェンスを必要とします。AE、SAE、または SA は、セルフサービスのリソースとしてカスタマーアシュランスパッケージを活用したり、カスタマーアシュランスアクティビティ手順を通じて支援を要求することができます。

3.1 GitLab デモンストレーションをいつ提示するか

セールスピッチと同じミーティングにデモンストレーションを含めるべきでしょうか? 通常、50% の確率でデモンストレーションは、ピッチデックが先に提供される同じミーティングで提示されます。

しかし、これは AE/SAE と SA がチームとして集まり議論する 必要のあるオーディブル・レディの瞬間です。これは、定期的なアカウント管理ミーティングのアジェンダ項目であるべきで、各チームは、顧客ごとにピッチデックミーティングとデモンストレーションを組み合わせるかどうかの基準を設定する必要があります。デモンストレーションは、顧客の特定のペインポイントとビジネスゴールに合わせて調整するべきです。再度言いますが、伝統的なセールス担当者は、機能の 1 つが顧客に響き、購入する緊急感が生まれることを期待して、会社と製品機能の長い概要で顧客を圧倒する傾向があります。

  • (SAE/AE) 30 日トライアル POV を実施する。このトライアル中、セールス担当者とテクニカルバイヤーは成功のためのメトリクスを確立しているべきです。これらのメトリクスは、GitLab がトライアルにどの程度関与するかを測定するのに役立ちます。セールス担当者は、POV トライアル内のメトリクスに対して GitLab がどのように機能しているかを確認するために、毎週のタッチポイントを持つべきです。
  • (SAE/AE) ペーパープロセスディスカバリーを実行する - エンドトライアル POV 中。テクニカルバイヤーから誰がサインオフする必要があるかについての情報を取得します。ペーパープロセスをドキュメント化し、エコノミックバイヤーを判断し、テクニカルチャンピオンを通じてエコノミックバイヤーへのアクセスを得るように努めます。ゴールは、この時点でエコノミックバイヤーをプロセスに統合することです。

3.1.1 テクニカルコミットの獲得

テクニカルコミットは、GitLab の機能が カスタマー要件ドキュメント 内のビジネスおよび技術要件にマッピングされる一連のワーキングセッションを通じて、技術評価 POV 内で行われます。テクニカルチャンピオンが組織内で社内化し、GitLab の機能が彼らのビジネスドライバーへの対応における技術的ニーズを満たす、または上回ることを社内化し、前進したいと考えている場合、これは口頭での テクニカルコミット です。

3.1.2 チャンピオンを見つける

チャンピオン とは、皆さんがいないときにあなたに代わって売り込んでくれる、クライアント組織内の人物です。彼らは意思決定プロセスを通じて皆さんをガイドし、主要なプレーヤーや意思決定者を紹介し、物事がうまくいかないときに皆さんに知らせます。 中規模から高エンゲージメントのディールでは、最低限 テクニカルチャンピオン と ビジネスチャンピオン の両方を獲得するように努めましょう。テクニカルチャンピオンは、技術評価のステップを通じて皆さんをガイドし、できればテクニカルコミットを獲得するのに役立ちます。ビジネスチャンピオンは、テクニカルチャンピオンと同一人物でない場合、ペーパープロセス、意思決定者、商談を前進させるかどうかに影響を与える内部組織についての洞察を提供します。チャンピオンの基準は以下のとおりです。

  • 影響力があり、少なくともマネージャー/ディレクターレベル以上である
  • 意思決定プロセスへの影響力があることを示す
  • ディールへの障壁を取り除くことができる
  • イニシアチブを推進するために自身の価値の通貨を投じる

その人が上記の基準を満たさない場合は、アドボケイトと見なすべきです。アドボケイトは皆さんに代わってよく話してくれて、皆さんのソリューションを社内化し、組織内のランドスケープを理解するのを助けます。しかし、彼らはディールの障壁を取り除くことはできません。

ディールを推進するにあたって、コンタクトポイントを可能なチャンピオンまたはアドボケイトとして常にテストする必要があります。このため、ポジションの変化やイニシアチブの変化に備えて、コンタクトポイントのセーフティネットを作るために、複数のアドボケイトと複数のチャンピオンを持つことが最善です。

ステップ 4: エコノミックバイヤーからのコミット獲得

エコノミックコミットを得るには、顧客組織が共通のペインポイントとゴールを理解するのを助け、意思決定プロセスに過度に関与せずに、それらのペインポイントとゴールに対処する計画を立てることを支援する必要があります。GitLab とパートナーを組まないことに関連するペインが、前進することに関連するどんなペインよりも大きいことを顧客に示すことで、緊急性を生み出します (3 つのなぜ: なぜ GitLab か、なぜ今か、なぜ何かをするのか)。

これを適切に行うことができれば、顧客が購入する決断をするように強いるコンサルティングベースのケースを作ることができます。これは、特定したチャンピオン/アドボケイトと同じテーブルの同じ側で行われます。以下は、エコノミックバイヤーをエンゲージしてコミットメントを得るために取る必要のあるステップです。

4.1 顧客向けデックの更新 (フェーズ 2)

エコノミックバイヤーをエンゲージするには、ハイレベルなビジネスニーズを GitLab のバリュードライバーに整合させる、顧客にフォーカスしたデックが必要です。顧客向けデックは、皆さんのチャンピオンがエコノミックバイヤーに提示できるという考えで作成すべきです。これを行うには、以前に作成した顧客向けデックを更新するために、皆さんのアドボケイトとチャンピオンと一緒に取り組み、エコノミックバイヤーに以下のコンポーネントを提供する必要があります。

  1. 顧客に整合するケーススタディ
  2. 正当性
  3. 暫定的な価格提案
  4. コミット/次のステップを依頼する

4.1.1 顧客の問題をバリュードライバーと整合させる

顧客のニーズを既存の GitLab ケーススタディに整合させます。良いケーススタディを見つけるには、カスタマーリファレンスドキュメントに行きます。ケーススタディの主要なポイントを蒸留して、ピッチしている顧客に整合させるために、いくつかのスライドを作成する必要があります。

4.1.2 ビジネスの正当化

正当化とは、何かを正しいまたは合理的であることを示す行動として定義されます。チャンピオンと協力して、以下のポイントの 1 つまたはすべてのグラフィック表現を作成することで、GitLab を選択するビジネスの正当性を明確に示す必要があります。

  1. 現在のツールセットと比較して得られる効率を強調する
  2. 投資収益率
  3. 次善の代替案と比較して GitLab でどれだけ生産性が向上するかのメトリクス

4.1.3 暫定的な価格提案

暫定的な価格設定は、通常、ソリューションアーキテクトが設計した Proof of Value に基づきます。チャンピオンと協力して、暫定的な価格設定を、すでに顧客向けデックで作成しているはずの正当性と ROI とさらに整合させます。

さらに、技術評価プロセスの後期段階でチャンピオンをテストして、現れる可能性のある価格と予算の影響について把握し、その情報を暫定的な価格提案に組み込みます。

4.1.4 ビジネスと次のステップを依頼する

  1. 次のステップと日付を設定 して、顧客と一緒にディールクロージャーフェーズに移ります。チャンピオンとエコノミックバイヤーをエンゲージして、デプロイメントへの相互に合意したアクションプランを作成します。これは相互クローズプランと呼ばれ、コマンドプランにドキュメント化すべきです。
  2. Salesforce で 商談のステージとステータスを更新 し、Proposal から Negotiating に変更します。
  3. 最近のセールスモーションに基づいた最新の予測予想で Clari を更新 します。

この時点で商談は、GitLab セールスサイクルのフェーズ 3 である ディールクロージャー フェーズに移ります。

最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License