Content last updated 2025-01-07

セールスプレイ: GitOps によるインフラストラクチャ自動化

概要

なぜ GitOps を気にする必要があるのか

GitOps マーケティングキャンペーンは、2020 年 4 月のローンチ以来、すべてのセグメントで最も多くの線形 SAO を生み出しています
Kubecon EU の調査回答者の 45% 以上が、GitOps は短期的に自分たちの組織の優先事項であると強調しています。
GitOps トピックへの関心が非常に高かったため、CD カンファレンス（CNCF 主催）は別のGitOps カンファレンスを立ち上げる必要がありました
GitOps はまったく新しいペルソナとユースケースをターゲットにでき、あなたのために新しい Land and Expand の機会を開きます

GitOps とは何か

上記が興味をそそった場合は、こちらで、GitOps、それが顧客にとって重要である理由、そして私たちがどう違うかについてさらに詳しく学んでください。

簡単に言えば、GitOps は、バージョン管理、コラボレーション、コンプライアンス、CI/CD などのアプリケーション開発に使用される DevOps のベストプラクティスを取り入れ、インフラストラクチャ自動化に適用するものです。

セールスプレイの目的

新しいペルソナとユースケースで新規案件を Land する
既存顧客を新しいチームとユースケースに拡張する

このセールスプレイのナビゲーション

ヒント: ボックスをクリックすると関連セクションに直接移動します

graph TB Z1[Getting Started] -.- A1[Who to meet] A1 -.- B1[Keywords to listen for] B1 -.- C1[How to identify interest] click Z1 “./#getting-started” click A1 “./#who-to-meet” click B1 “./#keywords” click C1 “./#identify-interest”

Z2[Value Discovery] -.- A2[Common pain] A2 -.- B2[Common benefits] B2 -.- C2[Required capabilities] C2 -.- D2[Positioning value] click Z2 “./value-discovery” click A2 “./#common-pains” click B2 “./#common-benefits” click C2 “./#required-capabilities” click D2 “./#positioning-value”

Z3[Sales Tactics] -.- A3[SAEs / AEs] A3 -.- B3[SAs / CSMs] B3 -.- C3[SDRs] click Z3 “./#sales-tactics” click A3 “./#sals-aes” click B3 “./#sas-tams” click C3 “./#sdrs”

Z4[Resources] -.- A4[Email Templates] A4 -.- B4[Customer Stories] B4 -.- C4[Identifying lead interest] C4 -.- D4[All collaterals] D4 -.- E4[Services] click Z4 “./#resources” click A4 “./#email-templates” click B4 “./#customer-stories” click C4 “./#lim-anchor” click D4 “./#resources-list” click E4 “./#services”

classDef orange fill:#fca121,stroke:#333,stroke-width:1px; class Z1 orange class Z2 orange class Z3 orange class Z4 orange

はじめに

誰に会うべきか

GitOps に関心を持つペルソナは、一般的に開発組織やエンジニアリング組織のものとは異なります。彼らは多くの場合、組織の運用、システム、インフラ、プラットフォーム、クラウド側の人たちです。

	典型的な役割	典型的な肩書き
エコノミックバイヤー	Director/VP/CIO of IT、Head of IT Infrastructure / Platform Engineering / Operations	SVP of Technology Operations、Sr. Manager Systems Engineering、Cloud Architect、Information Systems Architect
ユーザー	SRE、Infra Engineer、Sys Admin、Platform Engineer - 動的に変化する弾力的な環境をサポートするために、頻繁な繰り返しタスクを実行する必要がある	DevOps エンジニア、Architect、Team Lead、DevOps Ninja

詳細はこちら

注意すべきキーワード

アクティビティに基づく関心の見極め方

顧客は、ウェブサイト、コラテラル、動画、キャンペーンからのコンテンツに関与します。彼らの最新のアクティビティに基づいて顧客の関心レベルを特定でき、それを SFDC で確認できます。

これらの両方に GitOps のキーワードや GitOps のトピックが含まれている場合は、GitOps の会話を必ず行ってください。

ターゲットされたリードが注意を待っている

マーケティングは関連するデマンドジェネレーションキャンペーンを実行しています。

異なるチャネル（LinkedIn、Facebook、Google 検索など）でデマンドジェネレーションキャンペーンが実行されており、Focus Account Lists、ICP Total Addressable Market、Volume アカウントから新しいリードを浮かび上がらせています。マーケティングキャンペーンのフローはこちらの Figjam で確認できます
FY22 を通じて、新規および既存の Inquiries をターゲットにした一連のバーチャルイベントが予定されています。今後の Infrastructure Automation/GitOps GTM 関連のバーチャルイベントのスケジュールは、FY22 All-Marketing Calendar SSoT で確認できます

価値の発見

共通の課題

課題「before シナリオ」	だから何か？「ネガティブな結果」
- インフラチームは、構成、ポリシー、変数などをインフラ全体で一貫して管理する方法をどうしていますか。	一貫性なし、知識共有なし、バージョン管理なし、クリックオプス
- 適切な担当者によって変更がレビュー・承認され、ステージング/本番環境への混乱を最小限に抑えられるようにできていますか。	不正な変更が本番環境にリリースされ、パフォーマンスの問題やダウンタイムが発生する可能性が高くなる、ハイスキル/高給なリソースが雑用をしている可能性がある
- インフラチームは、毎回環境をセットアップする手順を一貫して再現できますか。	標準化なし、手作業のプロセス - よりエラーが起きやすい

その他の質問はこちら

共通のベネフィット

望ましい将来の状態（「After シナリオ」）	だから何か？（「ポジティブなビジネス成果」）
より多くの自動化	手作業の繰り返しタスクはエラーが起きやすいため、リスクが低減
修復までの平均時間が短縮	ロールバック前にトラブルシューティングするのではなく、動作するインフラの定義に迅速にロールバックでき、結果として修復までの時間が短縮
価値実現までの時間が短縮	手動のクリックオプスから GitOps に移行し、より頻繁にデプロイ
コンプライアント	すべての変更が追跡されるため、コンプライアンスが自動化
セキュリティ露出の削減	すべての変更をレビュー・承認でき、インフラコードのセキュリティをパイプラインに組み込める

必要なケイパビリティ

「GitOps = Infrastructure as Code + Merge Request + CI/CD」

必要なケイパビリティ	顧客指標
インフラコードのバージョン管理	価値実現までの時間の改善 - より少ない手作業、より少ないエラー、より多くの自動化
インフラの変更管理とコラボレーション	変更失敗率の低下 - より多くのコントロール、より多くのレビューと承認
コンプライアンスと監査	監査にかかる時間の短縮、コンプライアンス問題の減少
CI/CD - テスト自動化、パイプライン構成管理	デプロイ頻度の向上 - より多くの自動化
ロールバック	修復までの平均時間の短縮 - トラブルシューティングの前にインフラの動作する定義にロールバックできる

価値のポジショニング

エレベーターピッチ

インフラのダウンタイムに直面したとき、誰が変更したのか、何が変更されたのか、誰が承認したのかをたどれない経験はありますか？GitLab を使ったインフラ自動化により、コラボレーション、バージョン管理、CI/CD、コンプライアンスというアプリケーション DevOps のベストプラクティスをインフラに持ち込むことができます。

バリュープロポジション（GitLab はどうやってそれを実現するのか）

他のベンダーとは異なり、GitLab による GitOps は、物理、仮想、クラウドネイティブのインフラを管理するのに役立ちます。Terraform、AWS Cloud Formation などの業界をリードするインフラ自動化ツールとの緊密な統合を活用し、あなたの状況に合わせて対応します。これらすべてが 1 つのアプリケーションで実現します。

GitLab が市場要件をどのように満たしているかの詳細セクションはこちら

差別化要因（GitLab はどうやってそれをよりうまく実現するのか）

ほとんどの競合ソリューションは、GitOps ワークフローを実現するために 5 〜 6 つの統合が必要です。GitLab はバージョン管理、CI/CD、コンテナレジストリを提供し、構成管理、オーケストレーション、インフラのプロビジョニングについても標準で統合できます。
ワークフロー全体でのより優れたトレーサビリティ - GitLab はインフラのデプロイを変更まで遡って結びつけることができ、これは複数のソリューションで結びつけられたワークフローでは困難です。
ほとんどの競合は主にクラウドネイティブをサポート - GitLab はオンプレミスとクラウド、物理、仮想、クラウドネイティブのインフラをサポートしながら顧客に対応します
エージェントベースとエージェントレスのアプローチ - 顧客が自分の環境に合った正しいアプローチを選択できます

詳細はこちら

競合

主要競合: Flux (Weaveworks)、Argo CD、Terraform Cloud 副次的競合: Codefresh、Transposit、Red Hat/IBM

主要競合に対する詳細な競合比較はこちら

反論への対処

典型的な質問:

Kubernetes を使用していないので、GitOps は自分には関係ない
私たちの環境は GitOps には複雑すぎる
GitOps は開発者にデプロイをいじる機会をより多く与えてしまい、インフラチームはそれに不安を感じる
(Infra / DevOps Engineer) 自分の仕事と環境のコントロールを失ってしまう

詳細な Q&A 一覧はこちら

セールスプレイの戦術

SAE と AE

GitOps の会話で先導する必要があるかをどう判断するか。

発見の前

上記の GitOps セールスプレイに慣れ親しんでください - 最低限イネーブルメント動画を視聴してください。
適切なペルソナと話していることを確認 - 通常これは開発者ではなく、チームリード、システムアーキテクト、クラウドアーキテクトなど、インフラ/運用側の人たちです。
SFDC の「Pathfactory for Sales」での Last Interesting Moment が GitOps に関連しているかを特定（キーワードを使って判断）
SFDC の「Pathfactory for Sales」で顧客が閲覧した上位コンテンツが GitOps のトピックに関連しているかを特定

発見中

上記のキーワードリストを使って、リードが GitOps の会話に関心があるかを特定
GitOps の上位の発見質問、反論への対処、差別化要因に慣れ親しんでください。注意: 私たちが話すペルソナが異なるため、これは他の会話とは大きく異なります
発見中に必ずビジネスの目的と優先事項を特定できるようにしてください。これらは以下のいずれか 1 つ以上である可能性があります:
- インフラ自動化
- クラウドネイティブ環境の管理
- マルチクラウド / Kubernetes 採用
- インフラに関連するコンプライアンス
通話後、GitOps の会話のためにカスタマイズされたこれらのメールテンプレートのいずれかを使って顧客にメールを送信することを検討してください。コールトゥアクションをGitOps の Pathfactory トラックの任意のアーティファクトに自由に更新してください

評価中

GitOps 関連の顧客リファレンスを共有
GitOps の Pathfactory トラックの一部であるテクニカルデモやウェビナーを共有
Gartner Peer Insights を共有
SA と協力して GitOps のテクニカルデモを披露
通話後、GitOps の会話のためにカスタマイズされたGitOps デモメールテンプレートを顧客にメールで送信することを検討してください。

交渉 / 意思決定中

私たちがどう違うかを示す
GitOps の Pathfactory トラックから Forrester TEI レポートを共有
ROI 計算ツールを使って、他のソリューションよりも単一のアプリケーションとして GitLab を使用する価値を披露

SA

GitOps の会話で先導する必要があるかをどう判断するか。

発見の前

上記の GitOps セールスプレイに慣れ親しんでください - 最低限イネーブルメント動画を視聴してください。
正しいユーザーペルソナの 1 人とミーティングすることを確認。
GitOps の上位の発見質問、反論への対処、差別化要因に慣れ親しんでください。

発見中

発見質問を尋ねます。顧客の話を聞いて、彼らの課題や苦労を理解してください。
彼らの課題、苦労、ビジネスの目的、優先事項を聞きながら、彼ら自身の用語を使って、GitLab を使った GitOps が彼らをどう助けられるかを説明し始めてください。
彼らの技術的要件を理解してください。たとえば、以下の技術的発見質問の回答を得るように努めてください:
- 彼らのアプリケーションはハイブリッドクラウドインフラまたはマルチクラウドを必要としますか。
- 彼らは Terraform や Ansible などの Infrastructure-as-Code ツールへの強い依存性がありますか。
- 彼らは K8s、K8s 以外、またはその両方の GitOps を必要としますか。
- K8s の場合、彼らのクラスターはファイアウォール外で利用可能ですか。
競合への反論への対処の準備をしておいてください

評価中

SA CD ワークショップのGitOps ラボの手順に従って、デモ目的の自分自身の GitOps 環境を準備してください。このラボはクラウドプロバイダーとして AWS をカバーします。Google および/または Azure を追加したい場合は、公開向けの GitOps デモを活用して環境を拡張できます。
GitOps の Pathfactory トラックの一部であるテクニカルデモやウェビナーを共有
顧客から PoV への参加を求められた場合、PoV の要件を収集し、PoV を実行する準備をしてください。準備に役立つリソース:
- #gitops Slack チャネル
- #s_configure Slack チャネル
- GitOps Engineering
- GitOps TMM
- GitOps PM

SDR

リードと GitOps の会話を行う必要があるかをどう判断するか。

アウトリーチ / 会話の前

リードがどこから来たかを特定 -> リードが GitOps 向けのターゲットリードを生成している GitOps キャンペーンから来ているかを確認
SFDC の「Pathfactory for Sales」での Last Interesting Moment が GitOps に関連しているかを特定（キーワードを使って判断）
SFDC の「Pathfactory for Sales」で顧客が閲覧した上位コンテンツが GitOps のトピックに関連しているかを特定
上記のキーワードリストを使って、リードが GitOps の会話に関心があるかを特定
正しいペルソナと話していることを確認 - 通常これは開発者ではなく、チームリード、システムアーキテクト、クラウドアーキテクトなど、インフラ/運用側の人たちです。
GitOps の上位の発見質問、反論への対処、差別化要因に慣れ親しんでください。注意: 私たちが話すペルソナが異なるため、これは他の会話とは大きく異なります

顧客アウトリーチ / 会話

多くのハイパフォーマンスなアウトリーチシーケンスが利用できます - すでに利用可能なものを使用し、必要に応じてカスタマイズしてください
Land / Expand用の SDR Call Script を使用
GitOps Pathfactory トラックのコンテンツを使用してリードと共有してください。SFDC を通じて Pathfactory for Sales から直接コンテンツリンク（トラッキングを含む）を取得できます。顧客のジャーニーの段階別に分類されています。

リソース

推奨メールテンプレート

顧客のジャーニーの段階に基づいて使用できる推奨メールテンプレートをいくつか紹介します。

サービス

GitLab プロフェッショナルサービスは、顧客が GitLab を素早く効率的に活用できるよう支援します。GitLab（または GitLab パートナー）は、顧客をサポートするためのさまざまなサービス提供を行っています。

GitOps セールスプレイでは、顧客の従業員の git、GitLab、GitLab CI への習熟度について尋ねることを検討してください。これらは GitOps の基礎要素です。これらのトピックすべてに強くない場合は、GitLab with git Basics トレーニングおよび/または GitLab CI/CD トレーニングを提案することを検討してください。

GitOps のロールアウトを支援するアドバイザリー/コンサルティングサービスは、今年後半にロールアウトされる予定です。GitOps アドバイザリーオファリングへの関心をこちらに登録して、PS が効果的に優先順位付けできるよう支援してください！

サービスをポジショニングする際には、Services Pitch Deck を使用して PS と関わる価値を確立するのに役立てることができます。その他のサービスは、プロフェッショナルサービス提供の完全一覧で確認できます。

詳細は、professional services Slack チャネルで @em と話してください。