顧客テレインマッピングエンゲージメント

顧客テレインマッピングエンゲージメントは、DevOps の方法論、Git、GitLab、CI、CD、モニタリングに関する GitLab の経験の恩恵を顧客に提供します。スコープされた DevOps 領域(テライン)で成功するために対処する必要のある特定の課題の高レベルなファーストドラフトディスカバリーをブレインストーミングすることによって行います。この必要性は一般に、顧客が馴染みの薄いテクノロジーや方法論を活用する準備をしているときに生じます。

テレインマッピングの設計目標

  • GitLab ソリューションを地上の特定の課題に適用するために、スコープされた領域(テライン)での顧客の懸念事項の発見に焦点を当てる。
  • テレインマップのファーストドラフトを共同作成することで、重要な成功要因の明確化において顧客とのコラボレーションを促進する。
  • プロフェッショナルサービスが、顧客が GitLab の実装と価値獲得においてより成功するための重要かつ直接的な役割を果たすシナリオを顧客と GitLab チームメンバーが理解できるように支援する。これは GitLab プロフェッショナルサービスの公式に述べられたミッションをカスタマーサクセスの延長として直接支援します。
  • 60 分のセッション 1 回という短時間で、考慮事項とスコープを概説した共同作業ドキュメントを通じて結果を迅速かつ効率的に生み出す。
  • 再利用と拡張を可能にするために、簡潔な埋め込みトレーニングと手順を含む単一のテンプレートを活用する。
  • 成果物を構築するためのオープンなコラボレーションイベントを使用することで、多様で包括的なインプットを可能にする。
  • 顧客に反復的に改善できるテレインマップのファーストドラフトを提供する。
  • GitLab がそれらの項目に対してサービスを提供できるかどうかに関わらず、成功に必要なすべての事項を明確にすることで透明性を示す。
  • 上記のすべての目標が組み合わさって、ファシリテートできる人の範囲を広げます。ファシリテーションは一般的に技術的なバックグラウンドが必要ですが、GitLab 内の特定の技術的役割に限定されません。

いくつかの条件

  • 顧客がプロフェッショナルサービスを使用しないことを選択した場合でも、そのドキュメントはさらに発展させられる価値の高い成果物です。
  • 顧客テレインマッピングアクティビティは、詳細な設計の議論や、特定された項目の進捗を実際に実施することを含みません。
  • 一般的に、SA の顧客エンゲージメントごとに 1 つの顧客テレインマップが提供されます。
  • 顧客が該当するプロフェッショナルサービスを使用することを選択した場合、エンゲージメントドキュメントはエンゲージメントのスコープと価格設定を迅速に理解するのに役立ちます(効率的な再利用)。

顧客テレインマップのさらなるイテレーション

ハンドブックのすべてのことと同様に、修正と強化を通じてこれらの資料を改善することは誰の責任であり特権でもあります。同時に、テレインマッピングは顧客テレインマッピング設計目標に文書化された項目を提供するために特定の設計原則への準拠を反映しています。大幅な変更を加えたい方や全く新しいテレインマップを作成したい方向けに、これらの設計原則は以下に文書化されています: テレインマッピングの概要と設計原則(GitLab チームメンバー限定)

GitLab 内部イネーブルメントと準備リソース

各テレインマッピングエンゲージメントテンプレートには、できるだけ早く最新の状態になれるよう支援する手順と準備セクションが含まれています。

背景として、元の CS イネーブルメントセッションも視聴してください — リンクと手順は テレインマッピングの概要と設計原則(GitLab チームメンバー限定)の上部近くに記載されています。

顧客テレインマッピングエンゲージメントのカタログ

準備手順は以下の各項目に含まれています。一部の項目は GitLab チームメンバーのみがアクセスできます。

更新またはエンゲージメントを追加する際には、すべてのセクションを必ず含めてください。

  1. セルフマネージド実装レビューのテレインマッピング
  2. GitLab CI と CD への開発者スキルランプアップのテレインマッピング
  3. GitLab セルフマネージドのベストプラクティステレインマッピング
  4. GitLab 移行レビューのテレインマッピング
  5. SCM、CI、CD の Gitflow、ワークフロー、ロール、コントロールのテレインマッピング
  6. GitLab Secure 実装のテレインマッピング
  7. GitLab CI の顧客内部開発者イネーブルメントのテレインマッピング
  8. 特殊または高度にスケールされた GitLab Runner 実装のテレインマッピング
  9. GitLab と他のシステムの統合のテレインマッピング

セルフマネージド実装レビューのテレインマッピング

ステータス: 準備完了

よくある顧客の課題

セルフマネージド GitLab の実装

顧客適用性の手がかり

  • ボリュームの手がかり: 「セルフマネージド GitLab インスタンスを使用する 3000 人以上のユーザーがおり、スケールを確保する必要があります」
  • ベロシティの手がかり: 「今四半期末までに GitLab を本番環境にインストールして設定したいと思っています」
  • 複雑さの手がかり: 「私たちの組織では、GitLab が高可用性と災害復旧機能を持ってデプロイされることが必要です」
  • プロフェッショナルサービス利用経験の手がかり: 「GitLab は多くのコンポーネントで構成されており、私たちの専門家にセットアップしてもらい、堅固な基盤から始めたいと思っています」

この必要性を示す顧客の移行

  • セルフマネージドの初期購入

支援できる既存のプロフェッショナルサービス

準備資料

準備資料(GitLab チームメンバー限定)

アウトライン: セルフマネージド実装レビューのテレインマッピング

  1. プロジェクト概要
  2. アーキテクチャのアプローチと根拠
  3. 実装の適切なサイジング
  4. アーキテクチャのトレードオフ
  5. リスク・Issue と軽減策
  6. ソリューションの代替案
  7. 主要な意思決定ポイント
  8. 懸念事項
  9. 主要な前提条件

GitLab CI と CD への開発者スキルランプアップのテレインマッピング

ステータス: 準備完了

よくある顧客の課題

チームを GitLab で生産的にする(学習)

顧客適用性の手がかり

  • ボリュームの手がかり: 「この新しいシステムで生産的になる方法を学ぶ必要がある約 300 人がいます」
  • ベロシティの手がかり: 「4 四半期が始まる前に全員が最新の状態になれなければ、来年まで待たなければなりません」
  • 複雑さの手がかり: 「GitLab には多くの動く部分があり、このプラットフォームを最適に管理・運用する方法を理解することは難しいでしょう」
  • プロフェッショナルサービス利用経験の手がかり: 「トレーニングは組織内でソリューションを採用する際の成功に不可欠であり、GitLab が教育サービスを提供できることを期待しています」

この必要性を示す顧客の移行

  • 初期購入
  • 更新
  • CI ステージ採用

支援できる既存のプロフェッショナルサービス

準備資料

準備資料(GitLab チームメンバー限定)

アウトライン: GitLab CI と CD への開発者スキルランプアップのテレインマッピング

  1. チームとユーザー

  2. 開発者フォーカス

  3. プロジェクトマネージャー・スクラムマスターフォーカス

  4. CI / CD スコープ

  5. セキュリティの左シフト

  6. CI コーディングスキル

  7. 同時変更

  8. ワークフロー・チェンジゲートのリファクタリング

  9. 統合と Webhook

  10. エンゲージメントと完了の促進

  11. タイムライン

GitLab セルフマネージドのベストプラクティステレインマッピング

ステータス: 準備完了

よくある顧客の課題

セルフマネージドの場合に GitLab を本番グレードの内部サービスとして実行する方法。

顧客適用性の手がかり

  • 複雑さの手がかり: 「新しいインスタンスのバックアップを取り、災害復旧能力をテストするにはどうすればいいですか?」
    「多くの Runner に権限を割り当てるにはどうすればいいですか?」
  • プロフェッショナルサービス利用経験の手がかり: 「GitLab.com を運用する方法と同様に、セルフマネージドインスタンスを管理するために行う必要があるすべての活動のドキュメントはありますか?」

この必要性を示す顧客の移行

  • セルフマネージドの初期購入
  • 既存の GitLab インストールの再プラットフォーム化
  • GitLab SaaS からセルフマネージドへの移行
  • 既存のセルフマネージド GitLab インスタンスの安定性の問題・バージョン停滞

支援できる既存のプロフェッショナルサービス

準備資料

準備資料(GitLab チームメンバー限定)

アウトライン: テレインマッピングのベストプラクティス

本番グレードの内部サービスとしてセルフマネージド GitLab を運用するために

  1. チームとユーザー
  2. 既存のパイプラインコード分析
  3. 既存のパイプラインサードパーティ統合
  4. 開発者イネーブルメント(迅速なオンボーディングのためのテンプレート化)
  5. セキュリティの左シフト
  6. CI / CD スケーリング要件
  7. 新しい統合と Webhook
  8. テンプレート化すべき特定の既存パイプライン機能
  9. ツールの廃止・統合
  10. サポートする必要があるデプロイ環境
  11. タイムライン

GitLab 移行レビューのテレインマッピング

ステータス: 準備完了

よくある顧客の課題

GitLab へのデータおよび/または統合システムのカットオーバー(一括移行)

顧客適用性の手がかり

  • ボリュームの手がかり: 「GitLab に移行する必要がある以前の SCM からの 300 以上のプロジェクト・リポジトリ(GIT)を移行します」
  • ベロシティの手がかり: 「GitLab の使用を開始する前に、以前の CI/CD ツールから 500 以上のパイプラインを移行・変換する必要があります」
  • 複雑さの手がかり: 「私たちは GIT に不慣れで、GitLab を使用するためにコードベースを SVN/TFS/CVS から GIT に変換する必要があります」
  • プロフェッショナルサービス利用経験の手がかり: 「移行または GIT への変換が必要なリポジトリが多数あり、自分たちで行う時間もリソースもないため、あなたのサービスが必要です」

この必要性を示す顧客の移行

  • 初期購入

支援できる既存のプロフェッショナルサービス

準備資料

準備資料(GitLab チームメンバー限定)

アウトライン: GitLab 移行レビュー

  1. ビジネスの背景

  2. スコープとアプローチ

  3. 移行の複雑さに関する質問

  4. リスク・Issue と軽減策

  5. チームアプリ機能デリバリーベロシティの配分

  6. タイムライン

SCM、CI、CD の Gitflow、ワークフロー、ロール、コントロールのテレインマッピング

ステータス: 準備完了

よくある顧客の課題

コードおよび可能であればデプロイのワークフローコントロールを含む GitFlow / GitLab Flow の作成

顧客適用性の手がかり

  • ボリュームの手がかり: 「83 の開発チーム全員が同じ GitFlow プロセスを使用する必要があり、一度に 1 チームずつ再教育することは難しいようです。」
  • ベロシティの手がかり: 「開発者が定義している新しい GitLab ベースの DevOps サービスにオンボーディングする際に、ワークフローコントロールをアップグレードしてほしいと思っています。」
  • 複雑さの手がかり: 「GitLab ワークフローには非常に多くの設定と可能性があり、開発者は GitLab に移行する際に現在のプロセスを適応させ改善するために何を設定すべきかを理解するのに苦労しています。」
  • プロフェッショナルサービス利用経験の手がかり: 「コード品質とデプロイワークフローの新しいモデルを考案するためにプロフェッショナルサービスを提供してもらえますか?」

この必要性を示す顧客の移行

  • 初期購入
  • CI ステージ採用
  • CD ステージ採用

支援できる既存のプロフェッショナルサービス

準備資料

準備資料(GitLab チームメンバー限定)

アウトライン: SCM、CI、CD の Gitflow、ワークフロー、ロール、コントロールのテレインマッピング

  1. チームとユーザー

  2. コードインテグリティ

  3. コードレビューに誰が参加すべきか

  4. マージ承認はどのような形であるべきか

  5. ブランチ保護はどのような形であるべきか

  6. 保護すべき重要なファイル・ディレクトリ

  7. 職務分離

  8. 保護されたブランチ、タグ、環境、Runner

  9. コンプライアンス要件

  10. マイクロサービスワークフロー

  11. デプロイ承認に誰が参加すべきか

  12. デプロイの複雑さ

  13. ユーザー固有のグループ階層

  14. リポジトリグループ階層

  15. 監査アクティビティとロール

  16. タイムライン

GitLab Secure 実装のテレインマッピング

ステータス: 準備完了

よくある顧客の課題

顧客が GitLab Secure の実装を成功させるための計画を支援する

顧客適用性の手がかり

  • ボリュームの手がかり: 「52 の開発チーム全員ができるだけ早く DevSecOps ゲームを向上させる必要があります。」
  • ベロシティの手がかり: 「購入から 2 四半期以内に、すべての開発者が GitLab Secure の機能を活用できるようにしたいと思っています。」
  • 複雑さの手がかり: 「デモは気に入りましたが、フル Secure 機能セットを活用するためにどのような設定を実装すべきかについて、少し圧倒されています。」
  • プロフェッショナルサービス利用経験の手がかり: 「必要な GitLab Secure の機能をすべて活用するサンプルプロジェクトの定義と構築を支援してもらえますか?」

この必要性を示す顧客の移行

  • 初期購入
  • CI ステージ採用
  • GitLab Secure 採用

支援できる既存のプロフェッショナルサービス

準備資料

準備資料(GitLab チームメンバー限定)

アウトライン: GitLab Secure 実装のテレインマッピング

  1. GitLab Secure 実装のテレインマッピング

  2. チームとユーザー

  3. 開発ビルドとテストワークフロー(開発修復)

    1. コードインテグリティ
    2. コード品質
    3. セキュリティスキャン
    4. セキュリティ発見事項の実践
    5. マージ承認
    6. Issue 作成
  4. スプリント計画修復

    1. Issue の作成
  5. 防御ワークフロー

    1. Kubernetes
    2. スケジュールされたスキャン / DAST
  6. セキュリティ監査

  7. ライセンス監査

  8. タイムライン

GitLab CI の顧客内部開発者イネーブルメントのテレインマッピング

ステータス: 準備完了

よくある顧客の課題

顧客が開発チームの内部イネーブルメントを作成する GitLab の部分を理解・設定するのを支援する

顧客適用性の手がかり

  • イネーブルメントチームと話しているという手がかり: 「私たちは一般的に他の開発者向けのテンプレートを作成します。」「私たちのチームはすべての組織全体で共有される開発ツールに責任があります」「私たちの新しい取り組みは、すべての開発者に対してより多くの共有・構造化されたサービスを提供することです。」
  • ベロシティの手がかり: 「購入から 2 四半期以内に、すべての開発者が GitLab Secure の機能を活用できるようにしたいと思っています。」
  • 複雑さの手がかり: 「GitLab で行う方法を開発者が容易に理解できる方法で、既存の強固に意見を持つ開発・DevOps ワークフローをセットアップする必要があります。」
  • プロフェッショナルサービス利用経験の手がかり: 「必要な GitLab Secure の機能をすべて活用するサンプルプロジェクトの定義と構築を支援してもらえますか?」

この必要性を示す顧客の移行

  • 初期購入
  • CI ステージ採用

支援できる既存のプロフェッショナルサービス

準備資料

準備資料(GitLab チームメンバー限定)

アウトライン: GitLab CI の顧客内部開発者イネーブルメントのテレインマッピング

  1. チームとユーザー

  2. 既存のパイプラインコード分析

  3. 既存のパイプラインサードパーティ統合

  4. 開発者イネーブルメント(迅速なオンボーディングのためのテンプレート化)

  5. セキュリティの左シフト

  6. CI / CD スケーリング要件

  7. 新しい統合と Webhook

  8. テンプレート化すべき特定の既存パイプライン機能

  9. ツールの廃止・統合

  10. サポートする必要があるデプロイ環境

  11. タイムライン

特殊または高度にスケールされた GitLab Runner 実装のテレインマッピング

ステータス: 提案中

よくある顧客の課題

ML Ops と Data Ops を含む、特殊で複雑かつ高度にスケールされたセルフマネージド GitLab Runner 実装計画について顧客を支援する

顧客適用性の手がかり

  • ボリュームの手がかり: 「各チームは 3 つのクラウドアカウントそれぞれに Runner を持つ予定で、初期デプロイと長期メンテナンスを管理するのは多いように見えます。」
    • 「AI プロジェクトのために大規模な弾力的スケーリングが必要な ML Ops データセットをプッシュする予定です。」
  • ベロシティの手がかり: 「GitLab の立ち上げ時にチームごとの Runner を稼働させる必要があります。」
  • 複雑さの手がかり: 「本番環境のクラウドアカウントはゼロタッチです — GitLab Runner はそのクラウドアカウントにデプロイするためにどのように設定できますか?」
  • プロフェッショナルサービス利用経験の手がかり: 「セルフマネージド Runner への適切なアプローチを設計するのにプロフェッショナルサービスが支援してもらえますか?」

この必要性を示す顧客の移行

  • 初期購入
  • CI ステージ採用
  • ML Ops または Data Ops

支援できる既存のプロフェッショナルサービス

準備資料

準備資料(GitLab チームメンバー限定)

アウトライン: 特殊または高度にスケールされた GitLab Runner 実装のテレインマッピング

  1. チームとユーザー
  2. 既存のパイプラインコード分析
  3. 既存のパイプラインサードパーティ統合
  4. 開発者イネーブルメント(迅速なオンボーディングのためのテンプレート化)
  5. セキュリティの左シフト
  6. CI / CD スケーリング要件
  7. ML Ops / Data Ops
  8. 新しい統合と Webhook
  9. テンプレート化すべき特定の既存パイプライン機能
  10. ツールの廃止・統合
  11. サポートする必要があるデプロイ環境
  12. タイムライン

GitLab と他のシステムの統合のテレインマッピング

ステータス: 提案中

よくある顧客の課題

既存システムへのプラットフォームの接続(統合)

顧客適用性の手がかり

  • ボリュームの手がかり: 「現時点では置き換えられない多くの他のサービスに依存/頼っています(Slack、Jira、Jenkins など)」
  • ベロシティの手がかり: 「GitLab を使い始める前に、初日からこれらの統合が必要です」
  • 複雑さの手がかり: 「必要なすべての統合を接続することは開発者の生産性に影響し、顧客価値・製品デリバリーに影響することができません」
  • プロフェッショナルサービス利用経験の手がかり: 「必要なコンポーネントの統合を支援するサービスを提供してもらえますか?」

この必要性を示す顧客の移行

  • 初期購入
  • GitLab 使用のエンタープライズ全体への拡大

支援できる既存のプロフェッショナルサービス

準備資料

まだありません

アウトライン: まだありません