セールスプレイ: パッケージによる拡張
このページには、Package による拡張セールスプレイに関するすべての情報が記載されています。
注: セールスプレイをレシピとして考えてください。レシピに従えば、より予測可能で一貫した結果を達成できます。そして、最も効果的な（または失敗する）アセットやアプローチを見つけた場合は、レシピを微調整して継続的に改善できます。**改善の提案がある場合は、この Issue にコメントを投稿して編集を提案し、他の人の提案にいいねを付けてください。
セールスプレイ クイックリファレンスガイド
セールスプレイ クイックリファレンスガイド (社内向け)
概要
目的 - JFrog の Artifactory および Sonatype の Nexus に対する競合排除。
このセールスプレイは誰のためのものか。
- 主要: 1 つ以上の既存の GitLab Premium/Ultimate 顧客にアプローチする SAE および AE
- 副次的: 1 つ以上の既存の GitLab Premium/Ultimate 顧客をサポートする SA および CSM
誰に会うべきか
理想的な顧客プロファイル - GitLab に統合し、JFrog の Artifactory または Sonatype の Nexus から移行することを検討している GitLab 顧客。
- ボーナスポイント:
- 成熟度レベルが低く、トランスフォーメーションを進行中または計画中の組織
- パッケージやコンテナイメージなどのアーティファクトを管理するためのバラバラなツールを持つサイロ化されたチーム
- 厳格な規制セキュリティまたはコンプライアンス要件を持つ組織
ターゲットバイヤーペルソナ
| ペルソナの役割 | 可能性のあるタイトル |
|---|---|
| エコノミックバイヤー | CISO、VP of IT または CTO、App/Dev Director |
| テクニカルインフルエンサー | Chief Architect、App Dev Manager |
| 検討すべきその他のペルソナ | Infrastructure Engineering Director |
はじめに
以下の質問を検討してください。
- 顧客が JFrog の Artifactory から離れる（または離れることを検討する）ことを妨げてきたものは何か。
- 顧客には GitLab に統合し、追加のツール/ライセンスを削除することにつながる戦略的なイニシアチブや優先事項があるか。
- 適切なペルソナ/チームと連携できているか（上記のターゲットバイヤーペルソナを参照）。
- 権限/権威者（ビジネス意思決定者）にアクセスできているか。
- アカウント内でチャンピオンは誰か。
- GitLab Package で実現されるケイパビリティは顧客にとって重要か。なぜそうなのか、またはそうでないのか。なぜそれがわかるのか。
価値の発見
共通の課題
GitLab Premium/Ultimate 顧客は、以下の課題のいずれかを経験している可能性があります。
| 課題（「Before シナリオ」） | だから何か？（「ネガティブな結果」） |
|---|---|
| 複雑なツールチェーン、プラグイン、脆弱な自動化スクリプトの管理 | 追加のコスト、メンテナンス、管理オーバーヘッド |
| アプリやコンテキストの切り替えによる開発者体験の悪化 | 希少な開発者リソースの非効率な使用 |
| 脆弱性のトリアージと追跡にコストがかかる | 希少なセキュリティリソースの非効率な使用、長期にわたる修復プロセス |
| DevSecOps がスケールするにつれてコストが予測不可能または懸念される | サポートするアプリケーション数が増えるにつれて、より多くの資金を見つけなければならない |
共通のベネフィット
パッケージ管理のために GitLab に統合することで、顧客は以下のメリットを 1 つ以上享受できる可能性があります。
| 望ましい将来の状態（「After シナリオ」） | だから何か？（「ポジティブなビジネス成果」） |
|---|---|
| 削減されたコスト、メンテナンス、管理オーバーヘッド | ライセンスコストの節約 |
| セキュリティ、管理、開発の効率向上 | リスクの低減と DevSecOps のスピード向上 |
| セキュリティ露出の削減、より多くのスキャンによってより多くの脆弱性を発見 | 財務的および評判上のリスクの低減 |
必要なケイパビリティ
| 市場要件 | 説明 |
|---|---|
| パッケージの公開、ダウンロード、検証 | 一般的なさまざまなパッケージマネージャー向けのプライベートまたはパブリックレジストリ。 |
| コンテナイメージの公開、ダウンロード、検証 | Docker イメージを保存して配布できる、高いスケーラビリティを備えたアプリケーション。 |
| クリーンアップポリシーによるコスト削減 | 依存関係はすぐに蓄積されます。ストレージコストを管理する方法が必要です。 |
| GitLab メタデータを使用したアーティファクトの検証 | 正しいものを使用していることを検証するために依存関係のメタデータが必要です。 |
| 包括的なアプリセキュリティスキャン手法。 | アプリケーションを開発・テストする際、依存関係のセキュリティ脆弱性を自動的に検出します。 |
| ダウンロード前にアップストリームの依存関係をフィルタリング。 | 外部依存関係からのセキュリティ脆弱性の混入を防ぎます。 |
| 複数のソースからアップストリームの依存関係をキャッシュ。 | 単一の論理 URL を通じてアクセスされる、ローカル、リモート、その他の仮想リポジトリのコレクション。 |
| パッケージ、イメージ、コンテナの署名と保護。 | 重要なアーティファクトが破損したり上書きされたりしないように保護します。 |
顧客との関わり
| 顧客のニーズをよりよく理解するための質問 | 発見質問 |
|---|---|
| 現状 | 1. Artifactory または Nexus から移行したいですか。それは順調ですか。 2. これらの追加のツールを管理することで、どのような課題がありますか。 3. 現在、コンテナイメージとパッケージをどのように保護していますか。 |
| 将来の状態 | 1. 総ライセンスコストとツールチェーンを削減できたらどうですか。 2. 既存のツールにはどのような課題があり、2 年先のコストを予測できますか。 3. 開発者体験を向上させ、より高いセキュリティコンプライアンスを保証したいですか。 |
| 必要なケイパビリティ | 1. GitLab はそこにたどり着くお手伝いをできるでしょうか。 2. ALL のアーティファクト管理を可能にする 1 つの既知のコストがあったらどうですか。 3. アップストリームのパッケージをキャッシュして信頼性を向上させ、ビルドを高速化できたらどうですか。 |
最終更新 July 30, 2026: Merge pull request #483 from kyama0/translation/batch-2026-07-29-1 (
c955a93f)