サクセスプラン
CSM 関連のハンドブックページについては、CSM ハンドブックのホームページを参照してください。
サクセスプランが初めての方はここからスタート
サクセスプランとは、GitLab を使って顧客のビジネス目標を達成するためのロードマップです。すべての CSM エンゲージメントの基盤となるもので、顧客と共に構築し、関係を通じて継続的に維持していきます。
作成を始める前に理解しておくべき概念が 3 つあります:
| 概念 | 内容 |
|---|---|
| 目標(Objective) | 顧客のビジネス成果 — 明確なゴール、測定可能な成功基準、担当者、タイムラインを持つ。 |
| イニシアチブ(Initiative) | 目標を支える行動計画。「どのように」に焦点を当てる。 |
| Verifiable Outcome(VO) | 正式に追跡され、顧客が検証し、四半期ごとに報告される目標。SMART である必要がある。 |
準備ができたら サクセスプランの作成へ進んでください。
Verifiable Outcomes の概念的な紹介を先に見たい場合は、以下の動画をご覧ください(GitLab Unfiltered アカウントが必要です):
サクセスプランの作成
サクセスプランは、顧客と共有する GitLab 顧客コラボレーショングループに保存されます。目標はエピックで、イニシアチブは Issue で管理します。Success Plan Viewer はこのグループから直接データを読み取ります — 追加のツールやパイプラインのセットアップは不要です。
グループの作成場所: 顧客コラボレーショングループは、account-management グループ下の各リージョン(Western North America、Eastern North America、EMEA、APAC)に作成します。不明な場合は CSM マネージャーにお問い合わせください。
ステップ 1 — 目標エピックを作成する
各顧客目標は、顧客コラボレーショングループ内の GitLab エピックとして作成します。目標エピックテンプレートを使うと素早く開始できます。
新しい目標をゼロから作成する場合は、顧客コラボレーショングループに直接新しいエピックを作成してください。
すでに VO として追跡すべき既存の Issue がある場合は、以下の 2 つの方法のいずれかを使用してエピックに昇格させます:
方法 A — UI:
- Issue を開く
- 右上の More actions (…) → Change type をクリック
- Type で Epic を選択
- 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::Proposed | VO を特定し、顧客への提示前に社内でドラフト中 |
| Accepted | ~Verifiable Outcome::Accepted | 顧客が目標、ベースライン、成功基準、タイムラインに同意した |
| Delivered | ~Verifiable Outcome::Delivered | GitLab 側の作業が完了した |
| Verified | ~Verifiable Outcome::Verified | 顧客が完了を明示的に確認した (推奨) |
ステップ 4 — 完了した VO をクローズする
以下の 3 つのステップを順序どおりに実行する必要があります。いずれかをスキップするとレポートエラーが発生します。
~SP Objective::Status::Closed Successを設定する~Verifiable Outcome::Verified(または顧客確認が得られない場合は::Delivered)を設定する- エピックをクローズする
四半期ごとの 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 の価値実証に使用されます。相互顧客サクセスプランプロセスを参照してください。 |
| ポストセールス / オンボーディング | CSM | CSM が目標をレビューし、正確性を検証し、有効化と実装のためのイニシアチブを追加します。次に何をするか、誰が担当するかについての完全な合意。 |
| 継続的なエンゲージメント | 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 レポートが開発中です。利用可能になり次第、このページを更新します。
