ワークショップとイネーブルメントセッション
CSM 関連のハンドブックページについては、CSM ハンドブックのホームページを参照してください。
概要
CSM チームの主な焦点は、顧客が望むビジネス成果に合致すること、現在のユースケースで顧客をイネーブルすること、そしてプラットフォームの採用を拡大することです。
GitLab で追加の DevOps ユースケースを採用した顧客は、投資対効果（ROI）の向上を実感します。運用効率の向上、より良い製品のより迅速な提供、セキュリティとコンプライアンスリスクの低減によってこの ROI を得ることができます。
顧客のオンボーディングを加速し、ユーザーの採用を増やし、ステージの採用を促進するために CSM が持つツールの一つは、顧客にワークショップやランチアンドラーン（まとめてイネーブルメントセッションと呼びます）を提供することです。
CSM 主導のイネーブルメントと拡大
ユースケースイネーブルメント: 顧客が希望するビジネス成果の一環として採用の準備ができていると表明したユースケースのイネーブルメント。CSM は価値実現までの時間を短縮し、技術的な障壁を克服し、定着性を確保することで顧客をイネーブルします。CSM は価値の帰属を最大化し、採用を顧客の望むポジティブなビジネス成果に合わせるために、ユースケースの採用に関するガイダンスを顧客に提供します。CSM 主導のイネーブルメントは以下に示すワークショップを通じて行われ、CSM 主導の顧客サクセスプランの一部です。
ユースケース拡大: SAE または AE と連携したアカウント計画の動きの一環として、新しいユースケースへの拡大を推進し、顧客が ROI を増やし続けて満足し成長する顧客を確保します。このモーションは、より深いディスカバリー、デモ、そして顧客が「イエス」と言い、そのユースケースを採用することに同意することにつながる価値提案に焦点を当てたワークショップへの扉を開くディスカバリープロセスから始まります。CSM はこの拡大を既存のサクセスプランの目標内で追跡するか、この拡大イニシアチブを追跡するための別の目標を作成できます。
ユースケースのイネーブルメントと拡大はどこで追跡しますか？ ユースケースを拡大またはイネーブルするための手順はサクセスプランの一部であり、顧客の望むビジネス成果に向けた大きなモーションの一部です(製品採用マイルストーンの実現につながります)。
イネーブルメントセッションの頻度
必要に応じて実施します。PR1 の顧客については、最低でも 6 ヶ月ごとにイネーブルメントセッションが実施されることを目指します。PR2 については 12 ヶ月ごとです。 CSM はまずオンボーディング中にイネーブルメントセッションを提供し、顧客がそれらが利用可能であること、および実施可能な典型的なセッションのリストを認識するようにします。また、CSM はユースケースのイネーブルメントに関して顧客と取り組む際には特定のセッションを提案するべきです。顧客コラボレーションプロジェクトには現在、現在の提供内容とその簡単な説明を含むデフォルトの Issue があります。
セッションは Gainsight に記録される必要があり、これはエンゲージメントスコアカードメトリクスを動かします。セッションの日付とタイプ、および参加者の概算人数を記録してください。
セッションの種類
提供できるセッションには主に 2 種類があります。ワークショップは一般的に 1.5〜2 時間で、プレゼンテーション、デモ、Q&A が含まれます。これらはより多くの準備と計画が必要であり、通常は CSM が他の CSM や SA と協力して組織します。
イネーブルメントセッションは一般的に 1 時間で、プレゼンテーション、デモ、Q&A が含まれ、通常は CSM 自身が実施します。
現在利用可能なセッション
以下はすでに開発済みで、複数の顧客に提供され、こちらで利用可能です:
- GitLab 入門 （GitLab を始めたばかりのチーム向け） - GitLab の高レベルな概要を提供する一般的な入門セッション
- 開発者ジャーニー - アイデアから本番まで （開発者、運用、セキュリティ向け） - 開発者が Issue の割り当てからマージリクエストの作成、変更とパイプライン結果の確認、コードレビューへの参加まで、典型的なワークフローをカバー
- WebIDE と Markdown （コードやページに変更を加えたい方向け） - GitLab WebIDE を使用してコード、ファイル、Pages を GitLab Web UI から直接変更できることと、Issue、マージリクエスト、エピック、Pages などで GitLab Markdown でできるヒントとコツをカバー
- Git 基礎 （ローカルマシンから貢献したい方向け） - 開発者がコードを GitLab サーバーに pull/push するために必要なコマンドラインインターフェースに焦点を当てる
- CI/CD 基礎 （自動化されたビルド・テスト・デプロイパイプラインについて学びたい方向け） - コードをビルド、テスト、デプロイするパイプラインの設定の基礎をカバー
- 高度な CI/CD （CI/CD についてさらに学びたい方向け） - 基本的な CI/CD 知識が必要で、includes/extends、rules、子パイプラインなどの高度なトピックをカバー（具体的なコンテンツはカスタマイズされます）
- GitLab セキュリティとコンプライアンス （セキュリティ、開発者、マネージャー、PM 向け） - 開発者がマージリクエスト内でスキャン結果を確認する方法、セキュリティチームがセキュリティダッシュボードで結果を確認する方法を含むセキュリティ機能の概要をカバー
- DevSecOps 採用パス （セキュリティと開発者向け） - GitLab Secure のスキャナーを採用して Secure で可能な限り迅速に ROI を最大化するための、規範的でキュレートされたルート。Secure の採用に苦労している顧客や、Ultimate を使い始めて GitLab Secure を使い始めたばかりの顧客に最適なワークショップ
- PM ツールとしての GitLab （PM、スクラムマスター、チームリード、開発者向け） - エピック、サブエピック、ロードマップ、Issue、ラベル、マイルストーン、ボードの組織と使用に焦点を当てる
- Issue、ラベル、ボード （GitLab PM についてさらに学びたい方向け） - Issue、ラベル、ボードに関するさらなるヒントとコツをカバーし、PM セッションの続きとして最適
- GitLab による DevOps メトリクス （マネージャー、PM、チームリード向け） - DORA4 メトリクスとは何か、なぜ追跡することが有用か、GitLab で利用可能なものは何かを概説
- GitLab によるインナーソーシング （社内でコード共有イニシアチブを開始したいチーム向け） - インナーソーシングとは何か、なぜ有用か、成功に必要な主要事項を概説し、GitLab での始め方をカバー
- GitLab による GitOps （Infrastructure as Code に GitLab を使用したいチーム向け） - GitOps とは何か、Infrastructure as Code 以上のものである点、メリット、GitLab での始め方を概説
- GitLab 管理 （セルフマネージドインスタンスの GitLab 管理者向け） - GitLab コンポーネントとアーキテクチャ、インストール、アップグレード、UI の管理エリア、一般的な CLI コマンド、バックアップを概説
- GitLab の権限とアクセス （セルフマネージドインスタンスの GitLab 管理者向け） - グループ、サブグループ、プロジェクト、メンバーレベルでの権限アクセスを概説し、オンボーディングとオフボーディングのためにサポートされている認証プロトコルとアクセスを効果的に結び付ける方法を説明
- GitLab SaaS の管理 （GitLab.com の GitLab 管理者向け） - 権限、アクセス、可視性、ライセンス、SaaS とセルフホスト、監査イベントとストリーミング、サポート、ユーザーアクティビティ、GitLab Workspace の将来、SaaS を使用する管理者ロールの業務に役立つすべてのことを概説
- GitLab によるリリース、環境、デプロイメント （GitLab でリリースを行い、環境を使用し、デプロイメントを作成したい方向け） - GitLab でのリリース作成の基礎をカバー。デプロイメントと GitLab 内での環境の使用を含む。動的・静的環境とデプロイメントを含む。
追加のセッションに貢献したい場合は、以下の手順に従ってください:
- テンプレートデッキを ランチアンドラーンの Google Drive フォルダに保存してください（最終的にはシングルソースオブトゥルースとして Highspot に移行されます）
- セッション名、対象オーディエンス、コンテンツ・目標の概要を含めてこのハンドブックページを更新してください
- 同じ内容を含めてコラボレーションプロジェクトテンプレートの Issue を更新してください
まだ存在しないセッションに興味があるが、作成する能力や自信がない場合は、見たいものについて #tim-tams にメッセージを投稿してください！
セッションの提供
CSM はオンボーディングの早い段階でセッションを提供し、ステージのイネーブルメントに取り組むときにも提供するべきです。顧客がまだスライドが用意されていないトピックのセッションを希望する場合は、準備のためにより多くの時間を要求し、その後 Customer Success チームと協力してセッションのスライドをまとめてください。その後、新しく作成されたセッションを他の CSM が利用できるセッションのリストに追加できます。
メモの取り方、オーディエンス管理（参加者のスクリーンショット取得を含む）、Q&A の補助のために別の GitLab チームメンバーをセッションに招待することを推奨します。この補助役は、アカウントのソリューションアーキテクトやアカウントエグゼクティブ、または同僚の CSM でも構いません。
スケジュールを調整する際には、セッションの典型的な長さを考慮してください。チャンピオンと以下の情報を調整することをお勧めします:
- セッションのホストは誰か
- 録画するか
- 誰がキックオフするか
セッション中に尋ねられる質問の中には、インスタンス設定に特有のものがある可能性があり、それらの質問に答えられる人が必要なため、通常のケーデンスコールの誰かをセッションに参加させることを強くお勧めします。
セッションの準備
CSM はリクエストされたトピックのワークショップとランチアンドラーンの利用可能なコンテンツを確認するべきです。CSM はコンテンツをそのまま使用してもよいし、スライドのコピーを作成して顧客のニーズに合わせてカスタマイズすることもできます。
CSM はスピーカーノートを確認して各スライドを理解し、必要に応じて明確化事項やメモを追加するべきです。各スライドで伝えたいことを計画しておきますが、言うことを暗記しようとしないでください。
CSM が以前に実施したセッションの録画はこちらで確認でき、準備プロセスの一部としてレビューするのに役立つかもしれません。
セッションの実施
可能であればチャンピオンに紹介してもらいましょう。Google スライドのプレゼンタービューを使用して、スピーカーノートを別のウィンドウで利用できるようにしてください。参加者の画面解像度の問題が起きないよう、小さなモニターまたは MacBook 画面でスライドを実行してください。
自己紹介をして、チャンピオンが設定しなかった場合はグラウンドルールを設定してください。
小グループ（40 人以下）では、質問を口頭で尋ねることができます。
大グループでは、適切なタイミングで対応できるよう、チャットに質問を入れてもらうことをお勧めします。定期的に一時停止して質問を受け付け、セッション中に水分補給することをお勧めします。
迷子になったり言うことを忘れた場合は、スピーカーノートを参照してください。軌道に戻るまでそのまま読み上げても問題ありません。あるトピックをより詳しくカバーする他のセッションを参照することを気軽にしてください。たとえそのセッションを予定していなくても、それがそれらのセッションへの需要を生み出し、さらなるユーザー採用とステージのイネーブルメントにつながる可能性があります。また、顧客が Premium を利用している場合でも、プレゼンテーション中に Ultimate の機能について言及することを躊躇わないでください。
質問のために一時停止するときは、答えようとしますが、分からない場合は調べてチャンピオンに回答することを伝えても問題ありません。質問が別のセッションでより詳しくカバーされている場合は、現在のセッションで時間をとりすぎずに単純にそのセッションを参照しても問題ありません。セッション中に直接の連絡先情報を参加者に渡すことはお勧めしません。代わりに、将来の質問はチャンピオンに向けてもらうようにしてください。
セッション後
使用したスライドのコピーと録画のリンクをチャンピオンに送り、参加者や ライブセッションに参加できなかった方々と共有できるようにしてください。回答できなかった質問についてフォローアップしてください。次のケーデンスコールのアジェンダにフォローアップ項目を追加して、うまくいったことと将来のセッションで改善できることについて確認してください。需要に基づいて他のセッションのスケジュールを調整してください。ウェビナーに参加していた見覚えのない参加者がいる場合は、日常的な連絡先に追加チームが GitLab をどのように使用しているか、また何らかのトレーニングが必要かどうかについてフォローアップしてください。
セッションノート
ケーデンスコールでのメモ取りと同様に、顧客向けに実施した各イネーブルメントセッションで実行中のメモドキュメントに追加することが有用です。参加者リスト、最大参加者数、質問と提供された回答の記録、およびセッション中に対処されなかったフォローアップ項目を含めてください。
メモ取りと計画のベストプラクティス
- アジェンダ（聞きたい質問を含む）を書き留めてください。こうすることで、特定のコンテキストに対するメモをすばやく追加できます。
- Markdown 形式での記述に慣れている場合は、リアルタイムでメモを素早く構造化するために使用してください。
- 通話直後にメモをクリーンアップする時間を確保してください。連続したミーティングを入れないようにしてください。
- 通話の会話を遅らせる練習をしてください。「それを書き留めさせてください」と言って数秒止まることで、顧客に彼らが言ったことが重要だと伝わります。
- SAE/AE/SA にメモを一緒に取ってもらいましょう。ミーティング後に統合して詳細を追加してください。
- Gong を使用して通話を録音し、すべてを記録するプレッシャーを減らしてください。
- アカウントチームの誰かが Chorus で通話を振り返って書き起こすことが理にかなっている場合があります。
- 最も簡単な方法でメモを取り、常に最善の情報源にコピーしてください。最初から情報源にメモを書ければ、より効率的で一貫性があります
- 顧客との計画通話のために ワークショップ計画チェックリストを活用してください
