営業ガイド | GitLab 法務部門との連携
このハンドブックリソースの目的は、すべての GitLab チームメンバーに、あらゆるタイプの市場開拓に関する法務コマーシャルリクエストやプロセスを管理するための明確な道筋を提供することです。以下の情報は、自分自身で特定の情報を見つけてアクセスし、GitLab コマーシャル法務チームへの最良の連絡方法と支援の調整方法を明確に確立するのに役立てることを目的としています。
注意: このハンドブックページ内の「GitLab 法務」または「法務」への言及はすべて、コマーシャル法務チームを指します。
(1) 業務的 - ディールをクローズするための要件、法務運営に関する一般的な FAQ（財務やディールデスクに関する並行点を含む）を含む、GitLab 法務との連携および関与方法。
(2) 教育的 - 法務について学び、顧客が法務に関連する質問を持っている場合により自信を持って対応できるよう積極的なアドバイスや教育を含む、販売サイクル中の営業をより良くサポートするための契約の仕組み。
このページに含まれる情報は、次のように業務的と教育的の2つの区分に整理されています：
業務的
法務コマーシャルチームへの連絡方法
状況によってアプローチが異なります。収益関連リクエストの圧倒的多数の場合、法務チームと関与する適切な方法は、以下のプロセスに従って法務ケースを作成することで Salesforce（SFDC）を通じて行います。
- 法務ケースを作成するには、SFDC の顧客オポチュニティの右上隅にあるドロップダウンメニューで「サポートリクエスト」ボタンを選択し、次のドロップダウンメニューから「法務」を選択します。オポチュニティが存在しない場合は、$0 のオポチュニティを開いてこのセクションの手順に従ってください。
- 法務ケースが正しく作成されると、そのリクエストは適切な法務チームメンバーが自分自身をケースに割り当て、必要に応じてリクエスト担当者とコミュニケーションをとるキューに記録されます。
- 法務ケース開設のステップバイステップの手順：
- SFDC のオポチュニティ上部にある「サポートリクエスト」を選択します。
- 「サポートリクエスト」を選択した後に表示されるドロップダウンメニューで「法務」を選択します。
- 各フィールド（つまり「法務リクエストの種類」と「アクションの概要」）に最も適切な回答を選択し、「次のステップ」セクションに関連するすべての詳細を追加し、関連する文書をアップロードして「送信」をクリックします。できるだけ多くの詳細を追加し、リクエストの緊急性または期限を含めてください。これにより、法務チームメンバーは適切に計画し優先順位を付けることができます。
- 適切に提出されると、新しい法務ケースが法務チームのキューに追加され、適切なチームメンバーが自分自身に法務ケースを割り当てて支援します。
- また、新しく作成した法務ケースのメールとチャッターセクションの両方で自動メッセージを受け取ります。法務リクエストの種類によっては、法務チームが支援するために必要な書類および/または情報が概説されます。あるいは、クエリに直接回答するリソースが案内される場合があります。このメッセージを確認し、すべての必要な情報が提供され、書類が添付されていることを確認してください。
- 法務ケースは審査され、回答され、リクエスト担当者がメンションされます。
- リクエストが対応されると、法務ケースは法務チームメンバーによって閉じられます。
- 法務ケースの開設に問題が生じた場合は、Slack の #legal でサポートを求めてください。
- SFDC で @Legal にタグ付けしないでください。チーム全体に不必要に通知が送信されます。
- 特定の顧客のオポチュニティに関するすべての契約または文書は、同じ法務ケースに添付する必要があります。例えば、顧客がサブスクリプション契約とその注文書の両方に修正を返送した場合、両方を同じ法務ケースにアップロードする必要があります。
注意: 各オポチュニティにつき1つの SFDC 法務ケースのみ開設する必要があります。
契約に署名してもらう方法
営業組織の誰も契約に署名する権限がありません。GitLab を代表して署名できるのは特定の個人のみです。こちら（随時更新）の承認マトリックスをご覧ください。ご質問がある場合は、該当するリクエストを支援している法務チームメンバーにお問い合わせください。
すべての契約は署名前に法務承認スタンプが必要です。このスタンプは、実行可能なバージョンに達した際に法務チームメンバーによって契約に押印されます。
注意 - 法務スタンプは署名ではありません
法務によって契約にスタンプが押されたら、SFDC 内で署名のために顧客に契約を送付する DocuSign プロセスに従ってください。
すべての営業チームメンバーは DocuSign にアクセスできます。使用方法についての質問は営業オペレーションに相談してください。すべての完全に実行された契約については、該当する法務チームメンバーをコピーしてください。
NDA への署名が必要ですか？DocuSign アクセス権を持つチームメンバーのプロセスに従ってください。
データ処理補遺（DPA）への署名方法
GitLab は利用規約ウェブサイトに DPA の署名済みバージョンを掲載しています。サブスクリプション契約に記載されているように、この DPA はすべての顧客に適用され、別途署名を必要としません。また、DPA のヘッダーに記載されているように、顧客のサブスクリプション契約への同意は DPA への同意として扱われます。
承認書（LOA）
パートナーが承認書をリクエストする方法については、パートナーオペレーションページをご覧ください。
LOA レビュー手順:
- パートナーが GitLab パートナー契約を実行またはクリックして同意した後、パートナーポータルへのアクセス認証情報とアクセス権が提供され、パートナーが LOA をリクエストできるようになります。パートナーが LOA のリクエストを開始すると、エコシステムオペレーションズが
[email protected]で DocuSign 経由でリクエストを受け取り、パートナーが有効で承認されたパートナーであることを確認します。確認されると、エコシステムオペレーションズ、法務が[email protected]で DocuSign 経由でメールを受け取ります。 - DocuSign プロセスがパートナーによって開始され、エコシステムオペレーションズがリクエストするパートナーが有効で承認されたパートナーであることを確認したら、LOA は法務チームに転送されて法務スタンプが追加され、次に実行のために GitLab の承認された署名者に転送されます。完了すると、完全に実行された LOA が DocuSign を通じて GitLab 法務とパートナーに配布されます。
- パートナーがカスタム条件を含む非標準の LOA をリクエストする場合は、上記のように SFDC で法務リクエストを開いてください。
SFDC での輸出レビュー
- 輸出コンプライアンスツールによってフラグが立てられたアカウントをクリアできるのは法務のみです。これらのリクエストについては他のグループにタグ付けしないでください。
- 詳細と手順については、貿易コンプライアンスハンドブックページをご覧ください。
RFP プロセス
提案依頼書（RFP）（RFI、RFQ、または RFX とも呼ばれる場合があります）の完成に関して、営業チームメンバーが既存の回答ベースを活用し、クロスファンクショナルなステークホルダーから関連情報を収集する DRI として機能する方法については、RFP プロセスハンドブックページをご覧ください。
ベンダーリクエストフォームの完成
ベンダーリクエストフォームを完成させるのは営業チームメンバーの責任です。
これらの文書は通常、(i) 適切な GitLab ステークホルダーによるレビューが必要なさまざまな非法的要素を含んでいます。また (ii) 会社情報ページ、GitLab 投資家向け広報ページ、GitLab ハンドブック、または GitLab.com で既に公開されている情報が含まれていることがよくあります。営業チームメンバーは、法務チームに連絡する前にまずこれらの公開リソースを確認することで、法務レビュー時間を大幅に削減できます。
会社情報ページに掲載されている情報:
- 各 GitLab エンティティに関する住所/情報
- すべての銀行情報
- ECCN 番号
- NAICS コード
- ダン・アンド・ブラッドストリート番号
- その他の関連する企業情報
会社情報ページに見つからない情報については、営業チームメンバーは残りの事項について適切な GitLab 部門の担当者を特定する必要があります。財務リクエストを調整するために営業注文プロセスページで Deal Desk に連絡するか、財務 Slack チャネル内で財務チームに連絡することができます。適切な部門が不明な場合は、法務が適切なルーティングについてガイダンスを提供できます。
GitLab の W9 は財務のフォームページにあります。
GitLab のトラストセンターに見つからないセキュリティ関連の質問については、営業チームメンバーは顧客保証活動ページを通じてフィールドセキュリティチームと連携する必要があります。
税務に関する特定の質問については、営業チームメンバーは税務 Slack チャネル内または既存の SFDC ケースがある場合は SFDC チャッターで税務チームと連携する必要があります。税務証明書のリクエストについては、財務チームに ’[email protected]’ でメールを送ってください。
法務リクエストは以下の場合にのみ開くこと： (i) 明示的に特定された法律上の質問がある場合；および/または (ii) 文書への GitLab 署名のために法務スタンプが必要な場合。
GitLab の財務情報と保険証明書のリクエスト
- 保険証明書のリクエストには、SFDC で法務ケースを開いてください。注意: 私たちの保険証明書は GitLab の機密情報であり、配布前に NDA または合意されたサブスクリプション条件が必要です。
- GitLab の財務情報については、GitLab は上場企業であり、その公開申告は SEC.gov またはGitLab 投資家向け広報ウェブサイトで確認できます。
エスカレーションプロセス
顧客またはパートナーが重要な非標準条件を要求し、その取引が GitLab のリーダーシップによる追加の検討に値する場合は、GitLab エスカレーションプロセス（「プロセス」）に従ってください。このプロセスは、重要な非標準リクエストをリーダーシップにエスカレーションする前に考慮すべき要素（最初の閾値考慮事項、適切なレベルのレビューを確保すること、エスカレーションの適切な文書化の手順など）を定めています。 注意: このドキュメントは GitLab チームメンバーのみが利用できます。
名称変更または支配権変更のリクエスト
GitLab は顧客またはパートナーから、会社の法的名称の変更または会社の支配権の変更のいずれかを概説した通知を受け取ることがあります。以下の手順は、SFDC で顧客またはパートナーのアカウントを更新するプロセスの概要を示しています。
顧客が名称変更通知を営業/エコシステムに提供します。
営業/エコシステムが SFDC で法務リクエストを開きます。
法務が名称変更または支配権変更であるかを確認します：
a. 名称変更のみの場合、顧客は財務書類、W9 または W8BEN を営業/チャネルに提供します。
- 営業/エコシステムが文書を SFDC にアップロードします。
- 法務は提供された文書を審査し、必要に応じて名称変更を文書化するための修正案を起草します。
- 法務は顧客/パートナーの審査および実行のために営業/エコシステムに提供します。
- 営業/エコシステムオペレーションズが SFDC の該当情報を更新します。
- 法務は、営業/エコシステムオペレーションズの作業が完了したことを確認した上で、法務ケースを閉じます。
支配権変更の場合、法務は取引カテゴリ（買収、売却、資産売却、合併、倒産）を確認します。
- 法務は顧客/パートナーの文書と既存の契約を審査します。
- 法務は適切な譲渡文書を起草し、顧客/パートナーに送付するために営業に提供します。
- 顧客/パートナーが署名された同意文書を営業/エコシステムに提供します。
- 営業/エコシステムオペレーションズが SFDC の該当情報を更新します。
- 法務は、営業/エコシステムオペレーションズの作業が完了したことを確認した上で、法務ケースを閉じます。
法務コマーシャルカバレッジモデル
- 地域とセグメント別の GitLab 法務カバレッジモデルの概要を提供する法務カバレッジモデルを確認してください。注意: これは GitLab チームメンバーのみが利用できます。
- このリソースは個人の連絡先情報を提供していますが、顧客に関連する必要がある場合は該当する手順に従って法務リクエストを開いてください。
- このモデルは、割り当てられる特定のチームメンバーが現在のワークフローと専門知識を考慮に入れることから、ガイドであることに注意してください。
GitLab Issues を使ったクロスファンクショナルな協力
SFDC の外部で処理する必要がある事項（プロジェクトベースの作業、または SFDC アクセスのないチームメンバーからの入力が必要なトピックなど）で、法務チームの注意が必要な場合は、(i) 法務・コンプライアンスプロジェクトで Issue を開き；(ii) 適切な Issue テンプレートを選択し；(iii) legal-commercial::to-do ラベルを適用し；(iv) どの法務チームメンバーと連携するかわかっている場合は、その人物を担当者として含めてください。これにより法務チームの利益のためにコマーシャル法務 Issue ボードが更新され、チームが適切に引き継いだり割り当てたりできるようになります。また、ステータスを指定するために次のラベルを使用します：
- legal-commercial:in progress はコマーシャル法務チームが Issue に積極的に取り組んでいることを意味します。
- legal-commercial:pending requester はコマーシャル法務チームが Issue を進める前に、リクエスト担当者が満たさなければならない要件またはタスクがあることを意味します。
- legal-commercial:done はコマーシャル法務チームが Issue の担当部分を完了したことを意味します。
法務通話のベストプラクティス
法務と顧客またはパートナーの法務担当者との間の通話を検討する際のベストプラクティスを概説した GitLab 法務ベストプラクティスリソースを確認してください。 注意: これは GitLab チームメンバーのみが利用できます。
トレーニング（LevelUp）認定購入のリクエスト
トレーニング認定バウチャーは注文書で購入でき、LevelUp で使用します。
営業のための注文書プロセス：
- 顧客が注文している認定資格と数量を確認する；
- Salesforce で完全かつ正確な見積もりを生成する；
- 修正された認定注文書の作成のために Salesforce で法務ケースを開く；
- 注文書のワード文書をリクエストして法務ケースのチャッターで Deal Desk に連絡する；
- 法務は購入されている認定資格に基づく書面による手順に従って注文書を修正します。
無料試用版または評価契約のリクエスト
GitLab ソフトウェアへの無料アクセスを希望するすべての顧客は、GitLab のサブスクリプション契約の対象となって管理される GitLab ソフトウェアへのアクセスのための無料試用版を開始するよう誘導する必要があります。無料試用版は通常、顧客が社内評価のために使用し、必要に応じて GitLab による価値証明というより関与した形でサポートする場合もあります。
顧客が試用版プロセスを拒否し、別の評価契約を締結することを主張する場合、営業チームメンバーまたはソリューションアーキテクトは以下を行う必要があります：
- リクエストフォームとともに評価契約をリクエストするために法務リクエストを開く。
- 法務リクエストには (i) エリア営業マネージャー以上の承認リクエストを含め；(ii) 顧客連絡先情報、評価期間、ユーザー数などのリクエストフォームを完成させるための該当する詳細を記載する必要があります。
必要な承認を取得した後、該当する法務チームメンバーはリクエストフォームを提供し、顧客と GitLab による実行のための評価の詳細を設定します。リクエストフォームと GitLab ソフトウェアへの無料アクセスは、リクエストフォームに添付されている評価契約の条件に従います。
リクエストフォームが実行されると、営業チームメンバーまたはソリューションアーキテクトは、SFDC の顧客アカウントに文書を保存する必要があります。次に、営業チームメンバーは SFDC で営業サポートにタグ付けして、該当する期間とユーザー数で顧客の GitLab ソフトウェアへの無料アクセスを有効化する支援を求めてください。
法務からの非標準市場開拓および価格のリクエスト
OEM などの価格とパッケージのバリエーションを含む非標準の GTM 構造に関するすべての販売関連リクエストは、法務支援が必要になる可能性がありますが、適切なクロスファンクショナルステークホルダーとの収益化リクエストを適切に精査するために、リクエスト担当者が製品ボードこちらで Issue を開くことから始める必要があります。monetization-intake テンプレートまたは monetization-intake-simple テンプレートのいずれかを選択してください。作成されると、Issue は内部レビュー、コメント、および承認のために適切なステークホルダーに通知します。法務は Issue の進捗状況をフォローし、適切なステークホルダーが承認された構造について明確なガイダンスを提供した後、関連する契約または非標準言語の起草を開始します。
教育的
GitLab 契約の概要
- GitLab は GitLab サブスクリプション契約に従ってソフトウェア（オンプレミスと SaaS の両方）を提供し、GitLab プロフェッショナルサービス契約に従ってプロフェッショナルサービスを提供しています。オンラインバージョンはこちらで見つけることができます。
- GitLab はサブスクリプション条件の過去のバージョンを含めることで完全な透明性を提供しています。これらは契約履歴セクション内で見つけることができます。
- サブスクリプション契約は次のいずれかによって合意されます：(i) 顧客が GitLab ウェブサイト経由でソフトウェアを購入（またはダウンロード）する際にクリックスルー、(ii) 顧客によって署名された注文書で参照される、(iii) 交渉されたサブスクリプション契約に署名する、または (iv) 顧客が承認されたパートナーを通じて購入する場合はパートナー経由でパススルーされる。
- 交渉の閾値を満たす新規顧客については、サブスクリプションとプロフェッショナルサービス条件の両方をカバーする単一の契約をリクエストするために法務リクエストを開くことができます。
- GitLab にはパートナーが次のことを行えるように複数の展示物を含めることができるマスターパートナー契約があります：(i) 転売する、(ii) 紹介する、または (iii) GitLab ソフトウェアおよびプロフェッショナルサービスを配布する。
GitLab はいつ交渉しますか？
GitLab には、いつ、どの程度、標準条件を交渉するかを決定する際の特定の閾値があります。GitLab がこちらで詳細に説明されているように交渉に参加することを検討します。 注意: これは GitLab チームメンバーのみが利用できます。
正味 ARR 閾値要件が満たされる場合、営業チームメンバーは最新の契約テンプレートを要求するために法務リクエストを開く必要があります。最新バージョンでない可能性があるため、契約テンプレートをローカルドライブに保存しないでください。営業チームメンバーは裁量を持って使用し、顧客との適切な期待を設定するために割り当てられた法務チームメンバーとアプローチについて話し合うことを強く推奨します。以下のサブスクリプション契約の基本を参照してください。交渉は避けられないかもしれませんが、潜在的な交渉のトーンをどのように最もうまく確立するかについて、以下の意味合いを常に考慮する価値があります：
GitLab の標準契約での交渉: GitLab の逸脱への対応の柔軟性は、オポチュニティ額、正味 ARR（NARR）、戦略的重要性、取り込み可能な全体市場（LAM）などのいくつかの要因に大きく結びついています。例えば、将来の LAM が重要でない $30K のオポチュニティ/NARR では最小限の変更が期待されます。
- チャネルパートナーに関する注意: パートナーに関しては、交渉資格はパートナーの分類（オープンパートナーまたはセレクトパートナー）から生じます。セレクトパートナーのみが条件を交渉できます。
顧客の契約テンプレートでの交渉: NARR にかかわらず、顧客の契約は私たちが販売するソフトウェアの種類、ソフトウェアのライセンス方法、プロフェッショナルサービスの場合はソフトウェアの実装方法と無関係な、場合によっては完全に相反する条件を持つことがほぼ常にあります。
顧客の契約を利用することが決定された場合は、顧客との信頼と透明性のレベルを確立するのに役立てるために、大幅な修正と条件を最終化するための増加した時間枠があることを事前に顧客にメッセージして期待を設定するように、割り当てられた法務チームメンバーと協力することがベストプラクティスです。
- エコシステムパートナーに関する注意: GitLab のパートナープログラムとパートナーをどのように有効化するかにより、パートナーのフォーム契約を利用することははるかに困難になります。複数のクロスファンクショナルなステークホルダーとの整合と、前進する前の追加の精査が必要になります。そのようなプロセスを通じてガイドするために法務チームメンバーと協力してください。
オープンソースとは何ですか？
- GitLab はオープンコアビジネスモデルの一部としてオープンソースソフトウェアを使用しています。GitLab のオープンコアビジネスモデルについてさらに学んでください。
- GitLab で使用できるオープンソースライセンスと使用できないライセンスのリストを含む、オープンソースの一般的な紹介については、GitLab のオープンソースを参照してください。
- オープンソースソフトウェアに関する有用な外部リソースは Opensource.com と Open Source Initiative で見つけることができます。
- GitLab のオープンソースプロジェクトは gitlab.com/gitlab-org/gitlab にあります。
GitLab サブスクリプション契約の基本
🎥 「サブスクリプション契約の基本」ビデオを視聴してください。
注意: 上のビデオは GitLab チームメンバーのみが利用できます。
ビジネスアソシエート契約（BAA）
ビジネスアソシエート契約（BAA）またはビジネスアソシエートコントラクトは、保護医療情報（PHI）の取り扱いと保護の方法を概説する、HIPAA（医療保険の携行性と責任に関する法律）の下での対象事業体とそのビジネスアソシエート間の法的拘束力のある契約です。
GitLab が BAA に署名しない理由：
- GitLab は、製品とサービスを提供するために必要または不必要な情報について透明です。
- GitLab は、保護医療情報（PHI）を格納するために使用するよう設計されておらず、必要としていません。また、GitLab は組織として、製品とサービスを提供するために PHI を受け取り、処理し、保存し、取引し、またはその他の形で保持することを望まず、必要としていません。GitLab が PHI を受け取るべきでないことを具体的に強調するサブスクリプション契約のセクション 14.3を参照してください。そのため、GitLab は HIPAA の下で定義された「ビジネスアソシエート」の定義を満たさず、満たすことを意図していません。
- 顧客が「偶発的な開示」について質問する場合は、HIPAA の定義自体を強調してください。それは次のように述べています：「対象事業体を代表するビジネスアソシエートの機能または活動には、クレーム処理、データ分析、利用レビュー、および請求が含まれます。対象事業体へのビジネスアソシエートサービスは、法的、保険数理的、会計、コンサルティング、データ集約、管理、行政、認定、または財務サービスに限定されます。ただし、機能またはサービスが保護医療情報の使用または開示を含まない場合、そのような人物または組織はビジネスアソシエートとは見なされず、そのような人物による保護医療情報へのアクセスは偶発的であるか、まったくない場合があります。」
データプライバシー、セキュリティ、および GitLab データ処理補遺
- GitLab プライバシーポリシーでは、GitLab が顧客の個人情報を収集、使用、共有する方法と、顧客がその個人情報に関する権利を行使する方法について説明しています。GDPR に関するよくある質問への回答を含む GitLab でのプライバシーコンプライアンスの詳細は、GitLab のプライバシーコンプライアンスハンドブックページで見つけることができます。
- 通常「DPA」と呼ばれる GitLab データ処理補遺は、GitLab の利用規約ページからアクセスできます。GitLab サブスクリプション契約に記載されているように、DPA の条件は企業顧客に自動的に適用されます。
- データプライバシーについて質問する場合、顧客はセキュリティに関する質問をすることもあります。一般的に、そのような質問はフィールドセキュリティチームに向けるのが最善です。ただし、フィールドセキュリティチームに連絡する前に以下のリソースが役立つ場合があります：
- セキュリティプラクティスハンドブックページでは、GitLab の組織的セキュリティについて詳しく説明しています。
- GitLab のトラストセンターでは、GitLab の現在のセキュリティとコンプライアンスポリシーの詳細と文書を提供しています。
- アプリケーションのセキュリティ保護方法、インストールのセキュリティ保護、および GitLab の権限ガイドについて説明する GitLab ドキュメントは、顧客が GitLab によって処理される個人データをセキュリティ保護するために取ることができる手順を理解するのに役立ちます。
契約ライフサイクル管理（CLM）プロセス
契約ライフサイクル管理（CLM）は、法務チームがサブスクリプション契約における法的およびビジネス条件に関連するデータを取得して報告できるツールです。CLM の最終目標は、CPQ / 見積もりから現金化プロセス中に法的プロセスをより効率的にし、内部リクエストプロセスへの可視性を高めることです。このプロセスを促進するために、すべての完全に実行された契約は法務リクエストに割り当てられた法務チームメンバーに送付またはコピーされていることを確認してください。
契約が完全に実行された後に法務チームが従う手順は以下のとおりです：
- 完全に実行された契約をアップロードする（営業チームメンバーによって SFDC アカウントに既に保存されているはずです）；
- アップロードされる契約に関連する情報を記載したインテークフォームを完成させる；および
- 「保存」をクリックする
CLM で契約をアップロードすることで、インテークフォームで提供された情報が CLM に保存されます。完全に実行されたバージョンは SFDC の場所に加えて CLM リポジトリに保存されます。 注意: これは GitLab チームメンバーのみが利用できます。
コンテンツリクエスト
- あなたとチームを助ける将来のコンテンツのリクエストを常に歓迎しています。こちらのフォームを記入するだけです。
