調達ガイド：GitLab Legalとの協力
ご覧いただきありがとうございます！このリソースの目的は、GitLabにおける製品とサービスの調達においてLegalがどのように支援・サポートするかについてGitLabチームメンバーに情報を提供することです。
GitLab調達チーム、ポリシー、プロセスについての情報は、調達ハンドブックページをご参照ください。
法的アドバイス、成果物、機密情報に関する議論を必要としない一般的な質問については、Slackの*#legal* でGitLab Legalチームに、またSlackの*#procurement* でGitLab調達チームにご連絡いただけます。
Legalへの連絡
GitLab Legalに直接連絡する必要はありません。GitLab Legalチームは、必要に応じて調達チームから直接エンゲージされます。
Legalが関与する場合
GitLab Legalは、GitLabのリスク基準への準拠を確保するために適切な法的条件が存在することを確認するため、すべての購入を審査します。購入の種類の例には以下が含まれますが、これに限りません。
- ソフトウェア契約；
- プロフェッショナルサービス契約；
- スポンサーシップ契約；
- イベント契約；
- ホテル契約；および
- 下請け契約（GitLabおよび/またはGitLab顧客へのスタッフ増強またはサービス/リソースの提供）*。
*注：一部の購入については追加のポリシーが適用される場合があります。購入がポリシーとプロセスに準拠していることを確認するためにGitLab調達チームと連携してください。詳細は調達ハンドブックページをご参照ください。
契約への署名
いかなる契約にも署名しないでください
- GitLabを代表して契約を締結できるのは授権された個人のみです。署名権限者については署名権限マトリクスをご参照ください。
- 締結されるためには、すべての契約にGitLab Legalスタンプが含まれている必要があります。このスタンプは契約がLegalチームメンバーによって審査・承認されたことを確認します。GitLab Legalスタンプが押された契約書を受け取らない場合は、調達チームメンバーにサポートをご依頼ください。
- 誤って契約書に署名した場合や権限のない誰かが署名した契約を知った場合は、GitLab Legalが関与できるよう直ちにGitLab調達チームに報告してください。
ベンダー要件
- すべてのベンダーは以下に準拠し従うことに同意する必要があります。
- GitLab行動規範倫理綱領
- GitLab現代奴隷法透明性声明
- GitLabの名前またはロゴを使用するためのGitLabブランドガイドラインページ
調達リクエストと追加情報
NDAリクエスト：NDAPプロセス
利用規約の交渉：条件の交渉
競合他社のサービスの使用：ガイドライン（内部限定）
NDAプロセス
- 機密情報を交換する前に、GitLabと潜在的なベンダーは相互秘密保持契約を締結する必要があります。これにより共有されるすべての情報の適切な保護が確保されます。
- DocuSign経由でNDAを送信するか、DocuSignへのアクセスがない場合はNDAをリクエストするために、秘密保持契約プロセスに従ってください。
- 注：GitLabは購入者として、ベンダーがGitLabのテンプレートを受け入れるか使用するよう促すべきです。GitLabテンプレートの使用を求めた後に潜在的なベンダーが自社のNDAテンプレートの使用を要求した場合は、法的審査プロセスを開始する調達ページにあるプロセスに従ってください。
条件の交渉
- GitLabが行うすべての購入について、購入前またはサービスが提供される前に締結された利用規約が必要です。
- 締結された利用規約なしに購入を行うか、サービスを受けることはGitLabの調達ポリシーによって禁止されており、GitLabに実質的かつ意図しないリスクをもたらす可能性があります。
- ベンダーがGitLabデータへのアクセス、処理、制御を含むサービスを提供する場合、GitLab Legalチームはベンダーに対してGitLabに提供されるサービスに関連するサブプロセッサーのリストを提供するよう要求することがあります。また、ベンダーが利用できるデータに基づいて、DPA（データ処理契約）が必要になる場合があり、これはプライバシーチームがエンゲージします。
- 購入リクエスト、GitLabテンプレート、および交渉の閾値についての詳細は、調達ハンドブックページをご参照ください。
GitLab Legalのエンゲージメントとベストプラクティス
調達プロセスを開始する方法についての詳細な手順は、調達ハンドブックページにあります。
リクエストが適切に送信されると、法的審査の準備が整う前にいくつかの異なる承認が必要になります。
リクエストがさまざまな調達ステークホルダーによって承認されると、Legal調達チームメンバーに割り当てられます（このメンバーの名前が「Legal review」ノードに添付され、このメンバーがその特定のリクエストの審査と承認を支援します）。Zipでリクエストを送信する際は以下の点に注意してください。
- リクエストはさまざまな調達ステークホルダーによって承認されると、法的審査ノード内で「Ready to Start」ステータスの下に表示されます；
- Legalチームメンバーがリクエストに割り当てられ、ステータスを「In Progress」に変更します。
- GitLab調達法務はキューを1日中監視し、リクエストは送信時間と緊急度によって自動的に割り当てられ優先順位が付けられます。キューは継続的に監視されているため、個人にタグを付けたり、契約が「Ready to Start」であるとSlackに投稿することは避けてください。
- リクエストには「Privacy」「Security」「Buyer Negotiation」などの追加の審査ノードがある場合があります。Legal調達チームはこれらの追加ノード内では制御権や承認権限を持ちません。別のチームメンバーとSMEがこれらの審査・承認ノードを所有しています。
- リクエスト者はすべての関連文書がリクエスト内のドキュメントタブに添付されていること、および関連情報がリクエスト内のコメントとして追加されていることを確認する必要があります。そうでなければ、リクエストのタイムリーな処理に遅延や問題が生じる可能性があります。
- Legal調達チームメンバーによってステータスが「In Progress」に設定された場合、リクエスト者はリクエストが積極的に審査中であることを把握します。
- リクエストに添付された文書へのレッドライン（Legal調達チームメンバーが適用する修正済み審査）（該当する場合）は、リクエスト内のリクエストによってLegal調達チームメンバーが提供した文書の元のバージョンの下に添付・保存されます。
- Legal調達チームメンバーは（i）審査が完了した場合または（ii）リクエストを作成したチームメンバーが潜在的な契約当事者に送信する準備ができたレッドラインがある場合にZIP内のタグとコメントを通じてリクエスト者に通知します。
- リクエストを作成したチームメンバーがLegal調達チームメンバーと潜在的な契約当事者との通信と関連文書を確立することが責任です。
- 合意可能な条件が達成されると、Legal調達チームメンバーはGitLab Legal承認スタンプを付けたクリーンなPDFバージョン（「Executable」という名前で開始）を添付します。
- 「Legal review」ノードが承認されると、Legal調達チームはそれ以上のアクションを持たず、リクエストは他の承認を通じて継続します。
GitLab調達ツールでリクエスト者をタグ付けして直接Legal調達チームメンバーに連絡してください。Legal調達チームメンバーはリクエストに関する通知を受け取るために直接タグ付けされる必要があります。
緊急の問題が発生した場合を除き、Legal調達チームメンバーをSlackでタグ付けすることは避けてください。チームは常に多数の大量リクエストに取り組んでおり、GitLab調達ツールを唯一の情報源として使用する必要があります。
保険証明書のリクエスト
- COIをリクエストするには、既存の調達リクエストを使用して割り当てられたLegalチームメンバーをタグ付けするか（該当する場合）、アクティブなリクエストが存在しない場合は一般的な法的テンプレートを使用してLegal and ComplianceプロジェクトでIssueを作成してください。
legal-procurement::to doラベルを適用し、リクエスト内で@dcolesjr、@chilling32、@ndjohnsonをタグ付けしてください。 - 顧客またはパートナーに関連するリクエストについては、SFDCで法的リクエストをオープンしてください。
