買収プロセス

これは私たちの買収プロセスの詳細なビューです。買収アプローチについての詳細は買収ハンドブックをご覧ください。

買収プロセス

プロセスは5つの主要なステージで構成されています：

1. パイプライン構築
2. 探索
3. 初期デューデリジェンス
4. 確認的デューデリジェンス
5. 統合

パイプライン構築

1. ソーシング：コーポレート・デベロップメントチームは GitLab のプロダクトリーダーシップと緊密に連携し、M&A の潜在的な主要領域を特定します。私たちは買収機会（「ソースドパイプライン」）を以下から調達しています：
   1. Crunchbase などのサードパーティデータベースを活用したエコシステムスクリーン
   2. GitLab チームメンバーと業界コンタクトからのインバウンド紹介
   3. 私たちのビジョンと戦略的優先事項に沿った企業へのプロアクティブなアウトリーチ

探索

1. 私たちの製品と買収優先事項に適合する企業を優先し（「優先パイプライン」）、リーダーシップに連絡して紹介コールを設定します。

2. 紹介コール：この30分のコールの目的は、潜在的な対象企業についてより詳しく知り、さらなる買収議論が合理的かどうかを評価することです。コールのアジェンダは：

   1. チーム、製品、財務、資金調達を含む会社概要
   2. GitLab のロードマップを加速させる可能性のある機能の議論
   3. 適切な場合は取引条件を含む GitLab 買収プロセスのレビュー（買収ハンドブック）
   • 対象チームへ：このコールに先立って、私たちのロードマップを確認し、あなたの現在および将来の製品機能のうち GitLab の製品カテゴリに実装できるものをまとめてください。GitLab 参加後の最初の月に MVC リリース、その後毎月のリリースと迅速なイテレーションを考慮した、それらの機能のシンプルな統合タイムラインをまとめてください。

3. GitLab の買収戦略に沿った企業（「クオリファイドパイプライン」）の初期買収レビューテンプレート（Corp Dev 共有ドライブの買収テンプレート配下 - GitLab 内部のみ）のコールサマリーを関連するプロダクトリードと共有します。

   • 新しいプライベート Slack チャンネル（形式：#acq-company_name）を作成し、内部 GitLab ドキュメント（「メイン買収ドキュメント」）をトピックに追加します。Chief Product Officer（CPO）と関連するプロダクトおよびエンジニアリングリーダーを追加して、機会の初期評価を支援します。

4. プロダクトコール：プロダクトチャンピオンが適合の可能性を見て進めたい場合、製品とテクノロジーを詳しく調べるための初期90分のプロダクトコールを設定します。このコールにはプロダクトチャンピオンが必ず参加し、コールに関連するステージリーダーと特定のプロダクトマネージャーも参加できます。ステージリーダーとプロダクトマネージャーは、この評価の初期段階を念頭に置き、潜在的な買収が GitLab にどのように付加価値をもたらすかについて広い視野で考えるよう努めてください。コールのアジェンダは：

   1. 主要な機能とテクノロジーのハイライトを含む製品デモ
   2. 近期計画に焦点を当てた簡潔なロードマップ概要
   3. GitLab ロードマップとの適合性 - GitLab に組み込める機能とどの製品ステージに組み込めるかの議論
   4. GitLab のコードベースへの統合がどのようになるかの議論の開始

   相互 NDA は GitLab によって共有され、プロダクトコールの前に署名が必要です。MNDA と署名プロセスの詳細については、GitLab 法務ハンドブックをご覧ください。

   コーポレート・デベロップメント・ディールプロセスマネージャーは、プロダクトコール直後、または最初に利用可能な時間帯に GitLab 内部のみの同期プロダクトコールデブリーフのカレンダー招待をスケジュールして送信します。

5. 初期内部レビュー：

   1. 潜在的な機会の製品・テクノロジー適合性の予備的評価、および GitLab の製品ロードマップへの適合性と統合オプションの評価。
   2. 特定のケースでは、プロダクトコール後にハンズオンの製品検証が必要になる場合があり、買収プロセスと次のステップを決定するのに役立ちます。プロダクトチャンピオンはハンズオン製品検証を行う DRI を選択します。プロダクトコール後にハンズオン製品検証が行われない場合、初期デューデリジェンスの段階で後ほど実施されます。
      1. ハンズオン製品検証に続いて、プロダクトチャンピオン、検証のために選択された DRI、コーポレート・デベロップメントチャンピオン＆ディールプロセスマネージャーは、ハンズオン製品検証の調査結果についてデブリーフし、次のステップを調整するために同期で会議します。
         1. コーポレート・デベロップメント・ディールプロセスマネージャーは、ハンズオン製品検証後にエンゲージメントを終了する決定がされた場合、評価中の会社とデブリーフするための時間を提供します。
   3. 初期技術デューデリジェンスに進む前に、プロダクトチャンピオンは Chief Product Officer と財務チームで年間財政予算を確認する必要があります。
      1. 対象企業の従業員のオンボーディングが、プロダクトチャンピオンのセクション内、R&D 予算全体、またはその他の運営費再配分を通じて既存または予定されたポジションから資金調達できるかどうかを理解する必要があります。できない場合は、財務の支援を受けながら製品チームが予算を確保する必要があります。
      2. このステップは、最終承認の段階で対象企業の従業員をオンボーディングするための予算が存在しないと判断されて取引の結果が危ぶまれるケースを防ぐために、クロスファンクショナルなコラボレーションを最適化することを目的としています。

初期デューデリジェンス

1. 対象企業名の代わりに使用するコードネームを選択します。Slack チャンネルを更新：#project-code_name。
   1. コーポレート・デベロップメント・ディールプロセスマネージャーは、クロスファンクショナルなコラボレーションとIssueトラッキングのための専用プロジェクトを作成します。新規プロジェクトデューデリジェンステンプレートのコピーを作成してリネームして開始します。
2. 買収チームを組織し、チーム全員をチャンネルとドキュメントに追加します。 +1. 内部買収チャンピオンを確認します - すべての買収には、買収を推進し、買収の根拠と成功した統合プロセスを促進する先頭に立つチャンピオンが必要です。アプローチに適合するほとんどの買収では、チャンピオンはディレクター以上のレベルの製品セクションリードであり、GitLab のエンジニアリングチームからのエンジニアリングチャンピオン（同じくディレクター以上）が伴います。その他の買収では、チャンピオンは他の内部機能から来る場合があります。
3. 専用の技術デューデリジェンス Slack チャンネル #p-code_name-technical-diligence を作成します。このチャンネルは GitLab の開発チームとの技術的なトピックに関するコミュニケーションのメインチャンネルになります。
4. 予備デューデリジェンス - 以下は GitLab と共有するドキュメントのリストです：
   1. 財務：
      1. キャップテーブル
      2. バランスシート
      3. 損益計算書
      4. キャッシュフロー計算書
      5. 税務申告書
   2. 従業員：
      1. 以下を含む名簿：従業員名、役職、役割、在職期間、経験年数、勤務地、給与、LinkedIn プロフィール、プログラミング言語習熟度、コードベースの各コンポーネントとサービスへの貢献
      2. 従業員の履歴書
      3. 従業員契約と PIAA
   3. 顧客リスト（名前、月次収益、契約終了日、その他関連フィールド）。
   4. ベンダーリスト（月次支出付き）
   5. 資産リスト：
      • 事業に必要で買収に含まれる資産
      • 買収から除外される資産
   6. 技術部品表（BOM）- 以下を完全にリストした文書：
      1. リポジトリ
      2. Issueトラッカー / バグ管理システム
      3. 追加（非コード）資産
      4. ドメイン名
      5. サーバー
      6. 依存関係
      7. データベーススキーマ
      8. データ
      9. 商標
      10. ソーシャルメディアアカウント
   7. セキュリティレポート/ドキュメント
      1. 外部セキュリティレポート
         • SOC 2
         • ISO 27001 認証
         • CAIQ
         • 外部ペネトレーションテストレポート
      2. 内部セキュリティドキュメント
         • リスク管理プログラムドキュメント
         • リスク登録簿とリスクのステータス
         • 企業が現在のベンダーに対して実施したセキュリティレビューの結果
5. 初期技術デューデリジェンス：
   1. 対象企業にオープンソースコンポーネントがある場合、（GitLab ステージによる）担当の Dir. Engineering は早期コードレビューを開始し、コード品質、開発実践、貢献、ライセンス準拠などを判断します。これは2〜3営業日以内に完了する必要があります。
      1. コーポレート・デベロップメント・ディールプロセスマネージャーは、技術コールの会議メモのための新しいドキュメント（Project [code-name] - Technical Diligence）を作成します。これはメイン買収ドキュメントとは別のものです。今後のデューデリジェンスの調査結果と、エンジニアリング中心のすべての技術デューデリジェンス関連の会議（外部および内部）のメモは、この技術デューデリジェンスドキュメントに記録されます。技術デューデリジェンスドキュメントは #p-code_name-technical-diligence の Slack チャンネルトピックにブックマークされます。
   2. 技術コール：技術リード（担当エンジニアリングチャンピオンによって割り当てられた）と担当プロダクトチャンピオンが共同でリードする、製品機能のハンズオン検証とアプリケーションの概要のためのハンズオン製品・コードスクリーンシェアセッション（2時間）です。コールの目的とアジェンダは：
      1. 目的：
         1. プロセスを通じてこれまでに提示された製品の機能とコンピテンシーを技術的に検証する
         2. 買収が GitLab に潜在的に付加できる価値を判断する
         3. ソリューションの複雑さと品質の高レベル評価を結論付ける
         4. 統合のブロッカーと課題を特定する
      2. アジェンダ：
         1. 製品のより技術的なデモをカバーし、プロダクトコール後に浮上したさらなる質問/領域をカバーする
         2. 製品のアーキテクチャとメカニズムのウォークスルー
         3. コアコンポーネント/サービス/アプリケーションと開発実践のレビュー
         4. 統合の潜在的なパスの技術的な側面の議論を開始する
      3. コールの内部メモは技術評価 Google Doc に記録する必要があります
      4. 専有コードへのアクセスはこの段階では求めません。コードレビューは確認的デューデリジェンスフェーズで行われます。
6. 統合 - 取引後統合の重要なコンポーネントは製品統合戦略です：取引のクロージング前に、GitLab プロダクトとエンジニアリングの買収チャンピオンは機能セット/機能に焦点を当てた統合戦略を正式化します：
   1. そのまま維持するもの、書き直すもの、廃棄/EOL するもの
   2. ユーザー移行に重要なもの
   3. GitLab での対象製品ティア
   4. 実装の障壁
   5. ディールマイルストーン：
      1. GitLab 参加から2、4、6ヶ月後に3つのマイルストーンを設定し、取引で特定された製品への関心の大部分をカバーする簡潔な目標セットを提供することを目指しています
      2. マイルストーンは特定のタスクではなく目標として明確にする必要があります。マイルストーンを定義する構造は OKR に似ており、各マイルストーンには目標があり、その目標を達成するために必要ないくつかの主要な結果があります。これにより、対象企業は目標の達成に集中でき、統合作業が開始されると変化が生じる可能性があるため、特定のタスクに縛られることがなくなります。マイルストーンは、取引が提供すると特定されたロードマップの進化を達成するために必要な作業を促進するための目標を概説します。各マイルストーンは、そのマイルストーンの目標を達成するために完了する必要がある鍵に分解される必要があります。
         1. マイルストーン言語が GitLab 法務の具体性と明確さのレベルを満たすよう確実にするために、マイルストーン策定の議論スレッドと同期コールに GitLab 法務を含めてください。
      3. GitLab 参加から60日以内に最初のマイルストーンを出荷：
         1. 3週間のオンボーディングを考慮すると、対象企業はオンボーディング期間終了後5週間で最初のマイルストーンを出荷します
         2. カルチャーの採用と対象企業のエンジニアリングチームの GitLab への統合成功に重要です
         3. イテレーションの価値観に沿って、買収の初期成果を早期に示せます
      4. 製品は6〜9ヶ月以内に統合される：
         1. 6〜9ヶ月は、最善で全体を、少なくとも基本部分を対象の機能の段階的な統合を可能にしながら、過度に長くならない最適なタイムフレームです。ロードマップの優先事項が変わり、特定のマイルストーンを放棄することになり、取引の根拠の一部または全部が否定される可能性があるため、より長いタイムフレームの使用は避けたいです。
         2. 買収対象と製品チームの両方に集中力をもたらすのに役立ちます
         3. 取引ドキュメントの条件に従い、できる限り早く対象企業へのクロージング後の支払い（もし発生し期日が来た場合）を完了し、対象企業をシャットダウンできます
      5. 少なくとも1つのマイルストーンは、以前のマイルストーンで提供された統合に基づいて構築される新しい機能の開発に焦点を当てます
7. コーポレート・デベロップメント・ディールプロセスマネージャーは、プロジェクトの情報にアクセスできる人を記録し、GitLab 法務と協力して署名・返送のためのリードイン確認書を回覧します。
   1. プロジェクトリードイン確認テンプレート（Google Forms）
   2. リードインした個人のリストはコーポレート・デベロップメント・ディールプロセスマネージャーが管理し、参照用にディールチームへのIssueとして利用可能にします。
8. 取引の ROI を決定するために、買収チームは適用可能なモデルと買収 NPV 計算機（GitLab 内部ドキュメント）を使用して分析を行います。
   1. Build vs. Buy & 統合タイムライン見積もりデルタは、取引モデルへの主要な入力値です。初期デューデリジェンスの一部として、後に確認的デューデリジェンスで改良されながら、プロダクトとエンジニアリングのチャンピオンとそのサポートチームは、タイムラインと人員を含むパリティ構築見積もり、および GitLab の顧客に価値を提供するための統合見積もり予測を詳細化・予測します。
      1. Build vs. Buy & 統合見積もり演習のためのガイダンスはこちら（GitLab 内部ドキュメント）にあります。Build vs. Buy & 統合テンプレートはこちら（GitLab 内部ドキュメント）にあります。
9. 初期ピープルオプスレビュー
   1. コーポレート・デベロップメント・ディールプロセスマネージャーは新しい Slack チャンネルトピック #p-code_name-people を作成し、ピープルオプスチャンピオン（VP of People-Ops）とタレントアクイジションリードを含めます。ピープルオプスチャンピオンは、必要に応じてコーポレート・デベロップメントチャンピオンとプロセスマネージャーが指定されたピープルオプスチームメンバーを参加させるよう要請することがあります。
      1. 従業員名簿のレビュー
         1. 対象の従業員プロフィールをレビューする際は、LinkedIn プロフィールをプライベートモード閲覧に設定してください。プライベートモード閲覧により、対象の従業員が GitLab による自分の LinkedIn プロフィールの閲覧に気づくことを防ぎます。
      2. 報酬レビュー - HR ビジネスパートナーが主導するギャップと問題フラグの特定
      3. 創業者技術面接 - 創業者は技術的・文化的整合性を評価するための2ラウンドの面接を行います。
         1. 創業者面接は、従来の新規採用面接とはスタイルと目的が異なります。面接官は創業者との面会前に面接準備ガイダンスを確認するよう求められます。
10. GitLab のアプリケーションセキュリティチームが実施するアプリケーションセキュリティレビュー
    1. 脅威モデリングアプローチを適用してレビューを実施し、GitLab が考慮する必要があるアプリケーションの脆弱性を特定します
11. 承認のためのビジネスケースの提示（発生順）：
    1. チャンピオンの承認：買収チームはビジネスケースを一緒にレビューし、提案された取引を承認します。これには以下のすべての承認が含まれます：
       1. 予算と人員配分を含む完全なエグゼクティブサマリー（タームシートドラフトへのリンク付き）
       2. ディールマイルストーンを含む完全なビジネスケーステンプレート（Corp Dev 共有ドライブに両方あります - GitLab 内部のみ）
       3. 提案された詳細（資産支払、留保ボーナス、ディールマイルストーン、クロージングスケジュール、顧客終了とクロージング条件）が記入された完全なタームシートドラフト。
    2. 機能承認：コーポレート・デベロップメント、プロダクト、エンジニアリングのチャンピオンは、CPO、CTO、CRO に買収のビジネスケースを提示します。チャンピオンの承認でリストされた項目（完全な：エグゼクティブサマリー、ビジネスケース、タームシート）を承認するためにレビューします。
    3. CEO、CFO、CLO の承認：コーポレート・デベロップメント、プロダクト、エンジニアリングのチャンピオンは、CEO、CFO、CLO に買収のビジネスケースを提示します。この会議では、交渉を開始するためのタームシートの明示的な承認も取得します。
       1. 交渉を開始するためのタームシートの承認はタームシート承認Issueで追跡されます。機密性の理由から、承認追跡Issueには財務・マイルストーン情報を含めません。
12. タームシート：
    1. 交渉を開始する条件が承認されたら、コーポレート・デベロップメント・ディールチャンピオンは対象企業に連絡してオファーとタームシートを共有します。
    2. 対象企業との条件合意が得られたら、（変更があれば）タームシートを CLO、CFO、CEO（この順序で）の承認のために提出します。これらの承認はタームシート承認Issueに記録されます。
    3. すべての承認が得られたら、コーポレート・デベロップメントチャンピオンは DocuSign で対象企業の CEO と GitLab CEO（この順序で）の署名のためにタームシートをステージングします。契約書の CC に CLO、CFO、CPO を追加します。
       1. 承認追跡は前述のタームシート承認Issueで追跡されます。以前に承認された条件への変更は、次のメンバーによって再度レビューおよび承認される必要があります：プロダクトチャンピオン、エンジニアリングチャンピオン、CPO、CTO、CLO、CFO、CEO。変更は承認を求める前にタームシート承認追跡Issueに参照される必要があります。

確認的デューデリジェンス

1. デューデリジェンスステージを開始するために、コーポレート・デベロップメント・ディールプロセスマネージャーは以下の説明と情報要求を対象企業の CEO にメールします：
   1. すべての従業員とそのプロフィールが GitLab チームによってレビューされます
   2. 面接に招待される従業員は GitLab の標準面接プロセスを経ます
   3. 初期デューデリジェンスステージで面接された重要な従業員は、GitLab でのポジションの資格を得るために、GitLab チームによって決定されたさらなる面接ラウンドを受ける可能性があります
   4. すべての従業員は、自分のプロフィールに最も合うと思う GitLab の空きポジションを特定する必要があります。これは対象企業の CEO が収集したスプレッドシートで共有されます
2. コーポレート・デベロップメント・ディールプロセスマネージャーはエンゲージメントデブリーフと学習ドキュメントを作成し、洞察のオンデマンドキャプチャのためにチームと共有します。
3. 技術デューデリジェンスの完了
4. 財務デューデリジェンスの完了
5. 法務デューデリジェンス - 技術と財務の両方のデューデリジェンスがそれぞれエンジニアリングチャンピオンと財務買収チームメンバーによって完了・承認されたら、コーポレート・デベロップメント・ディールプロセスマネージャーは法務に連絡して法務デューデリジェンスを開始します。法務はメイン買収ドキュメントの（テンプレートデューデリジェンス表 - Corp Dev 共有ドライブ - GitLab 内部のみ）に各デューデリジェンスタスクの関連オーナーをタグ付けします。
6. デューデリジェンスの進捗は買収チームとの定期的なスタンドアップコールで同期されます
7. コーポレート・デベロップメントチャンピオンと法務リードが対象企業の CEO および法務チームと確定的取引書類の交渉を行います
8. 重要な従業員の引き留め会話 - 取引と統合計画の成功率を高めるために、特定された重要な技術従業員の引き留め会話を行うよう要請する場合があります。重要な技術従業員は、買収の成功、提案された統合計画、および統合後の GitLab でのチームの将来に不可欠と特定された人々です。
9. 最終レビューと承認：
   1. 結論コール - 買収全体を振り返り、買収契約書をレビューし、最終的な推薦を提示するための、買収チームとの最終内部レビューコール。この会議では、CLO、CFO、CEO からの買収契約書の明示的な承認も取得します。コールからの承認と追加で必要な承認は、確定的契約承認Issueテンプレートを使用して追跡されます。
   2. BoD 承認：
      1. 法務は GitLab の取締役会（BoD）からの最終取引承認を促進します
      2. BoD メンバーは承認を要求される前にボードパッケージを共有されます。以下を含む必要があります：
         1. エグゼクティブサマリーメール：
            1. CEO によって BoD メンバーに送信されます
            2. コーポレート・デベロップメントチャンピオンとディールプロセスマネージャーが1〜2ページのエグゼクティブサマリーメールメッセージを作成します。以下のトピックの高レベルのカバレッジを含める必要があります：
               1. 取引の詳細と根拠（ロードマップ加速、予測収益ゲインを含む）
               2. 参加するチームの専門知識
               3. APA の主要条件と追加コスト
               4. 実施されたデューデリジェンス：法務、税務、財務、技術、人材
               5. 既知のリスク、補償条件、および表明保証
         2. APA の最終バージョンへのリンク
10. コーポレート・デベロップメントチャンピオンが取引の署名とクロージングを調整します

統合

コーポレート・デベロップメントチームは、法務、プロダクト、エンジニアリング、ピープル、財務、その他の適切な GitLab 部門と緊密に連携しながら、クロージング後の統合の監督と促進を担当します。DRI はシニアディレクター・コーポレート・デベロップメントです。

統合プロセスは買収統合ページに概説されています。

終了した買収エンゲージメント

1. 買収が技術コールを超えて進んでいた場合、振り返りを実施します：
   1. 振り返りIssueを作成する（GitLab 内部のみの例）
   2. 任意のライブ同期の時間を設定する
   3. 関連するすべての買収チャンネルでフィードバックを募集する
   4. 同期が完了したら、以下のステップを続ける。
2. コーポレート・デベロップメント・ディールプロセスマネージャーは、買収に関連するすべての Slack チャンネルをアーカイブします。
3. 署名された NDA に従い、GitLab コーポレート・デベロップメントチャンピオンとディールプロセスマネージャー、および予備・確認的取引デューデリジェンス資料を保有するすべての取引参加者は、GitLab の内部ドライブとリポジトリから資料を削除するための最善の努力をします。

買収チーム

主要な買収チームはコンパクトなユニットとして設計されており、以下の GitLab 機能チームメンバーで構成されます：

1. コーポレート・デベロップメントチャンピオン - VP of Corporate Development
   1. コーポレート・デベロップメント・ディールプロセスマネージャー - コーポレート・デベロップメントマネージャー
2. プロダクトチャンピオン - プロダクトセクションリーダー（Chief Product Officer への直属）
   1. プロダクトマネージャー
3. エンジニアリングチャンピオン - Dir. Engineering
   1. エンジニアリングチームメンバー
4. VP、ピープルオペレーション
5. 法務、コーポレートリード

主要買収チームは必要に応じて他の機能と役割とも連携します：

1. VP Finance and Business Technology
2. VP Tax
3. Principal Accounting Officer
4. People Business Partner
5. VP Talent Acquisition
6. VP of Security

プロダクトマネージャーを割り当てるには、プロダクトコール後、または機能がどの製品カテゴリに実装されるかが明確になったら、割り当てのためにカテゴリのプロダクトディレクターに連絡します。

エンジニアリングチームメンバーを割り当てるには、割り当てのために関連カテゴリのエンジニアリングマネージャーに連絡します。

買収チームの責任

買収は機密です

GitLab では、すべての買収議論を機密として扱い、内部でのいかなる情報共有もニードトゥノーに基づいて行います。機密性を維持し不必要な露出を減らすために、買収プロセス中に発生するさまざまなトピックにコンパートメント化を適用します。

買収プロセス中の機密性を確保するために、初期デューデリジェンスステージに入ったら各潜在的取引にコードネームを割り当てます。プロジェクト名のテーマは GitLab 法務によって定義され、コーポレート・デベロップメントのテーマは映画/TVキャラクターです。

機密性を維持するために、以下のガイドラインに従います：

1. 新しい買収 Slack チャンネルを作成する際：
   1. チャンネルトピックを次のように設定します：「このチャンネルは機密です。チャンネルまたは関連ドキュメントに人を招待する前に、コーポレート・デベロップメントチャンピオンまたはディールプロセスマネージャーの 名前をここに に確認してください。」
   2. チャンネルの説明を次のように設定します：「買収に対する私たちのアプローチを理解するために買収ハンドブックとプロセスを確認してください。プロセスの機密性セクションとガイドラインをご覧ください。」
2. 法的露出を減らし、取引情報の開示リスクを最小化するために、買収に関与する人数をできる限り少なくします。特定のトピックに限定した議論のために追加メンバーが必要であり、より広いエンゲージメントに関与する必要がない場合は、専用の単一トピックチャンネルを作成し、関連する当事者を追加します。
3. 買収の Slack チャンネル、Google Doc、またはその他の GitLab 内部議論のメンバーであり、別の GitLab チームメンバーをそのいずれかに招待したい場合は、そうする前にコーポレート・デベロップメントチャンピオンまたはディールプロセスマネージャーに確認してください。
4. すべての買収に関するメモは、買収の Slack チャンネルのトピックで共有されるメイン買収ドキュメントに収集します。新しいドキュメントを作成する必要がある場合は、招待のみに設定して関連する人を手動で追加してください。そのドキュメントはコーポレート・デベロップメント共有ドライブの買収 G-Drive フォルダ内に保管する必要があります。
5. プロジェクトに関与するすべての人は、公式発表まで、取引に関するすべてのコミュニケーションで実際の企業名の代わりにコードネームを使用する必要があります。

対象企業との共有 Slack チャンネル

私たちのチームと対象企業が効率的なコミュニケーションのために共有 Slack チャンネルを開きたい場合は、持続的なプロセスの可視性を確保するためにコーポレート・デベロップメントに連絡してください。

ソーシャルメディア

運営原則として、すべてのチームメンバーは、買収議論に積極的に関与している企業の個人からのソーシャルメディア招待またはフォローリクエスト（LinkedIn、Facebook）を受け入れないことが推奨されます。サードパーティはこれらのつながりを閲覧し、GitLab が M&A や投資に関連する議論を行っている、または行ったことを推測できます。

既存のつながりがある場合、または M&A 議論に関与するようになった企業との定期的なやり取りがある場合は、関係を切る必要はありません。このガイダンスの趣旨は、現状を維持し、GitLab と評価されている企業との関係の変化の認識を作り出さないことを意図しています。

買収機会の優先順位付け

四半期ごとに、コーポレート・デベロップメントチームはアウトバウンド活動のためにその四半期に優先される3つのカテゴリを定義します。私たちはこれらを四半期フォーカスエリアと呼びます。これは特にアウトバウンドの取り組みに当てはまりますが、これらのカテゴリはインバウンドの見込み客も考慮しながら、その四半期の全体的な取り組みと焦点の中心になります。

四半期のフォーカスエリアがあるとはいえ、そのエリア以外の機会の議論・追求にもオープンです。四半期のフォーカスエリア以外の機会を検討するためには、以下の基準の1つ以上を満たす必要があります：

1. 突出した収益ポテンシャルを提示する
2. 戦略的な動きとして機能する（市場のダイナミクスなど）

私たちが探索するすべての機会は、私たちの優先順位付けと帯域幅（アクティブなエンゲージメントを含む）に対して常に評価されます。

四半期のフォーカスエリア以外の機会で追求すべきと考えるものを提案したい場合は、その特定の機会の根拠とともにコーポレートデベロップメントチームに連絡してください。

ページのソースコードを見る - ページの編集 - please contribute.