サクセスプラン

サクセスプランは、顧客の望むビジネス成果と GitLab ソリューションを結びつけるロードマップです。CSM が作成・管理する生きたドキュメントです。

CSM 関連のハンドブックページについては、CSM ハンドブックのホームページを参照してください。


サクセスプランが初めての方はここからスタート

サクセスプランとは、GitLab を使って顧客のビジネス目標を達成するためのロードマップです。すべての CSM エンゲージメントの基盤となるもので、顧客と共に構築し、関係を通じて継続的に維持していきます。

作成を始める前に理解しておくべき概念が 3 つあります:

概念内容
目標(Objective)顧客のビジネス成果 — 明確なゴール、測定可能な成功基準、担当者、タイムラインを持つ。
イニシアチブ(Initiative)目標を支える行動計画。「どのように」に焦点を当てる。
Verifiable Outcome(VO)正式に追跡され、顧客が検証し、四半期ごとに報告される目標。SMART である必要がある。

準備ができたら サクセスプランの作成へ進んでください。

Verifiable Outcomes の概念的な紹介を先に見たい場合は、以下の動画をご覧ください(GitLab Unfiltered アカウントが必要です):


サクセスプランの作成

サクセスプランは、顧客と共有する GitLab 顧客コラボレーショングループに保存されます。目標はエピックで、イニシアチブは Issue で管理します。Success Plan Viewer はこのグループから直接データを読み取ります — 追加のツールやパイプラインのセットアップは不要です。

グループの作成場所: 顧客コラボレーショングループは、account-management グループ下の各リージョン(Western North AmericaEastern North AmericaEMEAAPAC)に作成します。不明な場合は CSM マネージャーにお問い合わせください。


ステップ 1 — 目標エピックを作成する

各顧客目標は、顧客コラボレーショングループ内の GitLab エピックとして作成します。目標エピックテンプレートを使うと素早く開始できます。

新しい目標をゼロから作成する場合は、顧客コラボレーショングループに直接新しいエピックを作成してください。

すでに VO として追跡すべき既存の Issue がある場合は、以下の 2 つの方法のいずれかを使用してエピックに昇格させます:

方法 A — UI:

  1. Issue を開く
  2. 右上の More actions (…)Change type をクリック
  3. TypeEpic を選択
  4. Change type をクリック

方法 B — クイックアクション:

Issue のコメントに以下を入力して送信:

/promote_to Epic

どちらの方法でも、Issue の親グループにエピックが作成され、タイトル、説明、コメント、参加者、関連するグループラベルが引き継がれます。

注意: 昇格後、必要な 3 つのラベルがすべて存在することを確認してください — 元の Issue に適用されていなかった場合、ラベルが引き継がれないことがあります。

すべての目標エピックに必要なもの:

3 つのラベル — すべて存在しないとレポートに表示されません:

ラベル設定内容
~SP Objective常に必須 — 値は不要
~SP Objective::Status::Not Started · On Track · Watchpoint · Concern · Closed Success
~Verifiable Outcome::Proposed · Accepted · Delivered · Verified

1 つのユースケースラベル: ~UseCase:: — 以下から 1 つ選択: AI · CD · CI · Dedicated · Developer Experience · Infrastructure · Other · Plan · SCM · Security

オプションラベル: ~Priority:: (Low · Medium · High) · ~Success Accelerator(Success Tier 導入促進者向け)

期日 — レポートにおけるターゲット完了日として扱われます。

2 つの必須説明セクション — Success Plan Viewer が解析するため、以下の正確なヘッダーを使用してください:

  • ## Summary — 顧客が達成しようとしていることと、それがビジネスにとって重要な理由。ステークホルダー向けに記述します。オプションで ### Successes### Risks サブセクションを追加できます。
  • ## Success Criteria — 完了を定義する測定可能な箇条書き。

目標エピックテンプレート

以下をエピックの説明にコピーして、正しい構造から始めてください:

## Summary

[顧客が達成しようとしていることは何か、それはビジネスにとってなぜ重要か?
経営幹部のステークホルダー向けに記述してください — GitLab の機能ではなく、ビジネスへの影響に焦点を当てます。]

## Success Criteria

- [具体的で測定可能な条件 #1 — ベースライン、ターゲット、日付を含める]
- [具体的で測定可能な条件 #2]

## Updates

- [ステータス更新、目標クローズの理由]

ステップ 2 — イニシアチブ Issue を追加する

各イニシアチブは、目標のエピック内の GitLab Issue として作成します。すべてのイニシアチブ Issue には以下が必要です:

  • ## Update セクション — 現在のステータス、成功基準に対する進捗、次のステップ
  • 期日
  • 少なくとも 1 人のアサイニー(GitLab DRI;該当する場合は顧客側 DRI も追加)
  • ステータスラベル: ~SP Initiative::Status:: Not Started · On Track · Watchpoint · Concern

Enablement Plan のイニシアチブには、~EP Initiative::Status:: On Track · Watchpoint · Concern · Proposal も追加してください。


ステップ 3 — VO ライフサイクルを進める

作業の進捗に合わせて ~Verifiable Outcome:: ラベルを更新します。SPV ダッシュボードはライブデータです — 四半期末にまとめて更新しないでください。

ステージラベル適用タイミング
Proposed~Verifiable Outcome::ProposedVO を特定し、顧客への提示前に社内でドラフト中
Accepted~Verifiable Outcome::Accepted顧客が目標、ベースライン、成功基準、タイムラインに同意した
Delivered~Verifiable Outcome::DeliveredGitLab 側の作業が完了した
Verified~Verifiable Outcome::Verified顧客が完了を明示的に確認した (推奨)

ステップ 4 — 完了した VO をクローズする

以下の 3 つのステップを順序どおりに実行する必要があります。いずれかをスキップするとレポートエラーが発生します。

  1. ~SP Objective::Status::Closed Success を設定する
  2. ~Verifiable Outcome::Verified(または顧客確認が得られない場合は ::Delivered)を設定する
  3. エピックをクローズする

四半期ごとの VO トラッキング

VO の完了は、顧客コラボレーショングループからライブで読み取る Success Plan Viewer を通じて四半期ごとに報告されます。

各四半期、担当者の責任事項:

  • アクティブなすべての VO エピックに 3 つの必須ラベルが適用されていること
  • イニシアチブの ## Update セクションが最新の状態に保たれていること — ダッシュボードはライブであり、スナップショットではありません
  • 作業の進捗に合わせてライフサイクルラベルがリアルタイムで更新されていること
  • 完了した VO が四半期レポートの締め切り前に完全にクローズされていること

ステークホルダーが簡単にアクセスできるよう、以下の 3 か所に SPV リンクを追加してください:

  • Gainsight のサクセスプランリンクフィールド(プラン情報タブ)
  • 社内の顧客 Slack チャンネルのトピック
  • 顧客コラボレーションプロジェクトの README(顧客向けビュー版)

良い VO とは何か?

VO は SMART である必要があります: Specific(具体的)、Measurable(測定可能)、Attainable(達成可能)、Relevant(関連性がある)、Time-bound(期限付き)。

すべての VO には: ベースライン(現状)、成功基準(完了の判断方法)、ビジネスインパクト(顧客の言葉で)、タイムラインが必要です。

四半期内 VO の例:

VOベースライン成功基準期間ビジネスインパクト
セキュリティリードとエンジニアリングリードがパイプライン内でコンプライアンスポリシーを適用する準備が整うチームはコンプライアンスパイプラインを使用していない;ポリシーフレームワークが強制されていないセキュリティリードとエンジニアリングリードがコンプライアンスポリシーワークショップに参加し、ポリシー適用モデルを理解し、実装するポリシーを少なくとも 1 つ特定することを確認する四半期内標準の適用を開始するための具体的な出発点をチームに提供し、コンプライアンスに対する個々の開発者の行動への依存を減らす
プラットフォームチームがすでに所有している DAP 機能を積極的に活用するDAP 機能が使用されていない;利用可能なプロモーションクレジットが未使用上位 5 つの DAP ユースケースをプラットフォームチームとレビュー;プロモーションクレジットが適用されるか、デプロイメント計画が確認される四半期内活用されていない購入を積極的な価値に変換し、最初の意味ある DAP 導入までの時間を短縮する
新しい開発チームが GitLab で最初のパイプラインを実行する12 人の開発者からなる新チームが GitLab に CI/CD パイプラインを持っていない全 12 人の開発者が自分のプロジェクトで少なくとも 1 つのパイプラインを実行し、CSM のサポートなしに基本的なパイプラインを構築・トラブルシューティングできる四半期内チームを手動デプロイメントのステップから解放し、より広範な CI/CD 導入の基盤を確立する
パイロットグループが GitLab Duo を実際に体験し、明確な次のステップを持つアカウント内に Duo の使用実績がない;パイロットグループは特定されているが有効化されていないパイロットグループが有効化され、少なくとも 1 つのユースケースウォークスルーを完了し;顧客がフィードバックを提供し、展開、停止、またはロールアウトの調整を確認する四半期内不確実な状態を意思決定に変換し、次の Duo 投資の選択肢に対する具体的な根拠を顧客に提供する
顧客のメインブランチのパイプライン失敗率がリリースをブロックしなくなるメインブランチで約 30% の失敗率がリリース遅延を引き起こしているパイプライン失敗率が 5% 未満に低下し、根本原因が文書化されて顧客エンジニアリングリードと共有される四半期内リリース速度を回復し、開発者の不満と時間の損失という継続的な原因を排除する

ディスカバリーのヒント:

  • オープンエンドな TED 質問をしてください: 「チームの優先事項について教えてください… どのように… どのような…を説明してください」
  • 投資家報告書、プレスリリース、GitLab のケーススタディを参照してビジネスへのインパクトを組み立てる
  • GitLab Duo を使って成功基準が真に SMART かどうかテストする
  • continuous triage bot が毎週オープンな目標をレビューし、ドラフト成功基準がある場合に SMART な基準を提案する

追加のディスカバリー質問とテクニックについては、サクセスプランディスカバリーのための質問とテクニックを参照してください。


トラブルシューティング

VO がレポートに表示されない場合

症状対処方法
ワークアイテムがエピックではなく Issue になっているエピックに昇格させる
~SP Objective ラベルが欠落しているエピックに追加する
~SP Objective::Status:: ラベルが欠落している適切なステータス値を追加する
~Verifiable Outcome:: ラベルが欠落している適切なステージ値を追加する
エピックがクローズされていない3 つのクローズアウトステップをすべて完了する
ラベルは更新されているがエピックがまだオープン、またはエピックはクローズされているがラベルが更新されていない3 つのクローズアウトステップがすべて順序どおりに完了していることを確認する

サクセスプランのライフサイクル

サクセスプランは顧客のジャーニー全体にわたります。CSM の役割がどこに当てはまるかを以下に示します:

フェーズリード内容
プリセールスSA + AE顧客の目標が文書化され、GitLab の価値実証に使用されます。相互顧客サクセスプランプロセスを参照してください。
ポストセールス / オンボーディングCSMCSM が目標をレビューし、正確性を検証し、有効化と実装のためのイニシアチブを追加します。次に何をするか、誰が担当するかについての完全な合意。
継続的なエンゲージメントCSMサクセスプランはすべてのケーデンスコールビジネスレビューの基軸となります。ケーデンスコールが週次の進捗を促し、ビジネスレビューが戦略を評価し新しい目標を発掘します。

Gainsight

GitLab.com はサクセスプランの唯一の情報源です。Gainsight はそれを反映し、ビジネス全体のパターン分析を可能にします。

顧客との主要なインタラクション — 通話、ミーティング、マイルストーンの更新 — は Gainsight タイムラインに記録されます。GitLab で作成された目標は Gainsight に反映され、クローズされると両方で更新されます。

Gainsight ワークフローの詳細なガイダンスについては、CSM としての Gainsight の使用を参照してください。

フェーズ 1 — Success Plan Viewer(現在): 四半期ごとの VO トラッキングは Success Plan Viewer を通じて現在利用可能です。VO トラッキングに Gainsight への手動データ入力は不要です。

フェーズ 2 — Gainsight 統合(計画中): Gainsight 内での完全な VO レポートが開発中です。利用可能になり次第、このページを更新します。


サクセスプランディスカバリーのための質問とテクニック
CSM 関連のハンドブックページについては、CSM ハンドブックのホームページを参照してください。 このページで説明する質問とテクニックは、顧客との戦略的な会話を推進し、効果的なサクセスプランを構築す …
継続的プランニング(Continuous Planning)
継続的プランニングは、顧客コラボレーショングループで管理されている情報をもとに、GitLab アカウントチームが顧客向けサクセスプランを構築する際の時間を削減するために設計されたツールです。誰でもこのツールを使って、GitLab プロジェクト内で進行中のイニシアチブの更新を提示できます。