買収統合

これは私たちの買収統合プロセスの詳細な説明です。買収アプローチの詳細については買収プロセスをご覧ください。

概要

統合計画はトランザクションのクロージングよりもかなり前から始まります。ディールプロセスの適切な時期に、統合ステージの DRI である Sr. Dir. Corporate Development が、関係する部門と機能間の統合を促進します。そのために、GitLab 全体の部門（Finance、Legal、Product、Engineering、People など）の代表者で構成される統合ワーキンググループ（IWG）が設立されます。

重要なことは、各統合には E-Group からのエグゼクティブスポンサーと、以下の 2 人の追加 DRI が置かれることです：

  1. ロードマップ DRI - 買収の Product Champion として、統合の方向性、影響、範囲、および整合性に責任を負います
  2. エンゲージメント DRI - 買収の Engineering Champion として、技術統合マイルストーンの実施と GitLab 内での買収チームメンバーの定着に責任を負います

私たちはディール文書、デューデリジェンスの調査結果、その他のデータと情報を使用して、書面による Day 1 プランと長期プランを策定します。前者はトランザクションのクロージング直後の Day 1 に何が必要か、または何が整っている必要があるかを正確に文書化します。長期プランには、買収プロセスの一環として策定された主要なマイルストーンが含まれます。IWG の各分野の専門家は、Day 1 の前後および長期プランが有効な期間（統合が完了するまで）に何をすべきかを特定します。

IWG は定期的に会合（頻度はディールごとに決定）を行い、IWG メンバーはその時間を利用して統合に影響を与える可能性のある Issue やその他の事項を議論します。統合はイテレーティブであり、そのため IWG は必要に応じて統合計画を改訂しながら、すべてのステークホルダーが改訂と更新を把握していることを確認します。

ディール構造とディール文書によって一部が決定される、クロージング後の統合プロセスに含まれる可能性のある領域とタスクの例を以下に示します：

コミュニケーション

  1. 新しいチームメンバーが質問先を把握することが重要であり、また新しいチームメンバーとのコミュニケーションには「一つの声」を持つことも重要です。クロージング前は「一つの声」はディールリードであり、クロージング後は関連する分野の専門家またはリードであるチームメンバーで構成されたチームとなります。「一つの声」アプローチを使用することで、すべてのコミュニケーションが調整され、メッセージが一貫してタイムリーであることを確保できます。クロージング前およびクロージング事項の場合、ディールリードはディールアナウンスの一部として買収対象企業の従業員とのコミュニケーションに関して、適切かつ許可される範囲で、買収対象企業の CEO やその他の上級管理職と連携します。
  2. ディールリードは、買収対象企業の顧客とのコミュニケーションの調整（適切かつ許可される範囲で）に関して買収対象企業と連携する責任があります。コミュニケーションのタイミングと性質は、トランザクションの構造とディール文書に定められた顧客コミュニケーションに関する条件によって異なります。
  3. さらなる指示については買収プロセスコミュニケーションハンドブックページをご覧ください。

戦略目標とパフォーマンストラッキング

  1. 目標とゴールの整合：
    1. 統合計画を GitLab のロードマップに組み込む
    2. ディールマイルストーンを各部門の OKR に導入する
    3. GitLab に新しいプロダクト領域が追加される場合、プロダクトビジョンを作成または更新する
  2. パフォーマンストラッキング：
    1. ディールの付加価値と ROI を時間をかけて追跡するためのビジネスパフォーマンス指標を特定し、継続的に見直す
    2. プロダクト計画と OKR に対する実績

Finance、Accounting & Tax

  1. 必要に応じて銀行口座を開設、閉鎖または移管し、適切であれば署名権限を更新する。
  2. 必要であれば、インボイスの送金先を変更/更新する。
  3. 買掛金と売掛金を照合し、適切であれば GitLab のシステムに移管する。
  4. 必要に応じて、また必要な期限までに、買収対象企業のベンダーに通知する。
  5. People Team と連携して新しいチームメンバーを GitLab の給与システムにオンボードする。
  6. ディール固有の給与計算やその他の考慮事項をシステムに記録する
  1. クロージング後のすべての期限、成果物、エスクロー解放、顧客および/またはベンダーが必要とするクロージング後の通知などを追跡・管理する。
  2. デューデリジェンスおよびディールプロセス中に特定された Issue と事項に対処するために適切なチームメンバーと連携する。
  3. 適切または買収文書に規定されている場合に応じて、買収対象企業の業務を停止する。
  4. 買収に関連するクロージングバインダーを整理・取得し、ContractWorks にアップロードする。
  5. 適切かつ許可される範囲で、買収対象企業の法律顧問から GitLab Legal への法律事項の円滑な移管のために買収対象企業の顧問と連携する。

技術統合

  1. 買収契約または付随するディール文書に定義された各デリバリーマイルストーンは、買収アナウンスが公開された後、統合努力をリードする PM によって機密 Issue に変換されます。これらの Issue はデリバリーマイルストーンの進捗を追跡する SSOT となります。Issue が完了すると、そのマイルストーンの成功したデリバリーの確認として機能します。マイルストーンの完了承認は以下の者による署名が必要です：
    1. Product Champion
    2. Engineering Champion
    3. Corp. Dev. Champion
  2. マイルストーンが承認されると、Corp. Dev. Champion は処理が必要な対価の支払いがある場合に経理チームに通知します
  3. チェックインコール（頻度（例：毎週、隔週、毎月など）はディールごとに決定）は、統合努力をリードする PM によって以下のチームメンバーとスケジュールされます：
    1. Product および Engineering Champion
    2. Corp. Dev. Champion
    3. 買収対象企業側で統合努力をリードするメインエンジニア
    4. Legal
  4. マイルストーンへの変更 - 統合マイルストーンは、それらの達成に向けて作業する中で変更の対象となります。これらのマイルストーンには契約上の義務が伴い、より広いプロダクトビジョンの目標に影響を与える可能性があるため、マイルストーンの内容へのいかなる変更も Corp Dev、Product、Engineering の 3 つのディール Champion による承認が必要です。マイルストーンへの変更によって買収契約の修正が必要になる場合は、買収対象企業の適切なチームメンバーと連絡先が必要に応じてそのような議論に含まれます。承認や買収契約の修正を必要としない変更は非同期で対処することもできますが、一般的には上記の定期的なチェックインコール中に変更を議論することが望ましいです。

ファストブート

チームの効果的、効率的かつポジティブなオンボーディングを促進するために、チームが GitLab にオンボードしてから最初の 1 か月以内にファストブートを計画する必要があります：

  • 目的：
    • 両チーム間の社会的なつながりを構築する
    • GitLab および買収対象企業の両方の技術について、それぞれのチームを整合させる
    • 統合のための作業計画を完全に策定する
  • 予算：ディールのクロージング前に買収プロセスの一部として構成する必要があります
  • ファストブートの形式はこちら（GitLab 内部アクセスのみ）で確認できます

People Integration

  1. GitLab のオンボーディング Issue を使用して、買収対象チームメンバーのオンボーディングを行います（ディール文書に規定されている通り）。
  2. Day 1 時点で、すべての新しいチームメンバーが GitLab の給与システムに登録されていることを確認します。これには Day 1 のかなり前に給与プロバイダーへの連絡が必要です。
  3. 買収対象企業の従業員福利厚生ベンダーがクロージング予定を認識していることを買収対象企業に確認し、すべての買収対象チームメンバー（ディール文書に規定されている通り）がタイムリーに福利厚生に関する情報を受け取ることを確保します。クロージング後に提供されるすべての福利厚生は、買収契約に規定された関連する条件に準拠する必要があります。
  4. 新しいチームメンバーに必要な特定のトレーニングコース（GitLab オンボーディング Issue に含まれるもの以外）を特定する。
  5. 雇用契約に存在するコントロール変更の問題でクロージング後に影響を与えるものに対処する。買収契約に別途規定されていない限り、そのような問題に対しては一般的に買収対象企業が責任を負い、適用される雇用契約の条件に従います。
  6. チームメンバーが GitLab に参加してから最初の 12 か月間、People Ops チームは統合を評価するために 2 つのパルスサーベイを実施します。最初の買収統合サーベイはクロージングから約 3 か月後に実施され、2 回目のパルス買収統合サーベイはクロージングから約 9 か月後に実施されます。
  7. 内部異動 - 買収チームのロールに異動/応募したい既存のチームメンバーについては、採用マネージャーは買収の詳細、憲章、マイルストーン、目標などに関するコンテキストと情報のレビューに特に注意を払うべきです。買収チームは、特に初期段階において、典型的な GitLab チームとは異なる運営が行われることがあります。これは、最初の 6〜12 か月（またはそれ以上）の作業において、マイルストーンと方向性が買収契約の一部として事前に定義されているためです。異動するチームメンバーが成功するよう、完全な透明性が維持されることを私たちは確保したいと考えています。

フィールドイネーブルメント

セールスとマーケティングのメッセージング

買収対象企業の製品のセールスとマーケティングは、以下の 3 つの異なる領域をカバーします：

1. メッセージング

GitLab のフィールドおよびマーケティング組織は、標準的かつ一貫した顧客価値ベースのメッセージングフレームワークに基づいたゴーツーマーケットアプローチで整合しています。そのため、買収統合チームは Product Marketing と連携し、以下を文書化する必要があります：

  1. この買収はどの顧客価値ドライバーを強化し、どのように強化するのか？
  2. この買収はGitLab の差別化要因をどのように強化し、また新しい差別化要因を導入するのか？
  3. この買収は既存の顧客ユースケースをどのように強化するのか？
2. ロールベースの学習目標

価値ベースのメッセージングが完了した後、Field Enablement チームと連携してロールベースの学習目標を定義します。始めるにあたって、チームは Sales Development Rep および各フィールドロール（例：Account Executive / Strategic Account Executive、Channel Sales Manager、Solution Architect、Customer Success Manager、Professional Services Engineer）に対して、買収に関連した以下の質問に回答する必要があります：

  1. 知識のギャップ：そのロールが今日は知らないかもしれないが、知る必要があることは何か？
  2. 行動のギャップ：そのロールが今日はできないかもしれないが、できるようになる、明確に伝える、または示す必要があることは何か？
3. イネーブルメント開発

上記が完了したら、チームはイネーブルメントの開発と実行に進みます。以下は買収のための標準的なイネーブルメント資産です。買収チームは以下のリストを評価し、当該買収に特有の変更や追加を行う必要があります。

  1. スナップショット動画 - アナウンスに先立ち、Product Champion は短い動画（最大 10 分）を録画します。これは買収の PR の一部として、また GitLab チームのイネーブルメントのリソースとして含まれます。動画は以下の点をカバーする必要があります：
    1. 買収が関連するカテゴリの概要
    2. これらのカテゴリが GitLab のユーザーにとって重要な理由と適合性
    3. 買収の統合完了がユーザーにもたらす価値
    4. 統合がユーザーに与え得る影響
  2. 見込み客 FAQ - 顧客から来そうな質問に回答した見込み客 FAQ 文書を作成する
  3. 概要ウェビナー - アナウンスから 1〜2 か月後に、買収の概要とプロダクト、顧客、見込み客への影響についての、より詳細な概要を提供するウェビナーがフィールドチーム向けにスケジュールされます。
  4. 技術ウェビナー - 統合努力の MVC のデリバリー前後にスケジュールされ、新機能と新しいプロダクトワークフローのデモを提供するためにフィールドチーム向けの技術ウェビナーがスケジュールされます。
  5. フィールドコミュニケーションプラン - Field Communications は Product DRI と連携し、Field Communication Playbookを使用したコミュニケーションプランを作成して、フィールドチームメンバーに主要なリソースと情報を配信します。
4. 買収対象企業ウェブサイトの Digital Experience（DEX）所有

Digital Experience チームは、コミュニケーションプランが買収を公開アナウンスする予定の場合、買収を告知する買収対象企業の更新されたウェブサイトバナーに責任を持ちます。追加の詳細についてはコミュニケーション買収プロセスをご覧ください。ディールクロージング時に、DEX は GitLab Communications および Corporate Development と調整して、買収対象企業のウェブサイトの引き継ぎと所有権を整合させます。買収対象企業のウェブサイトの DEX による引き継ぎと所有権に対処・調整するために、Corporate Development Deal Process Manager によって Issue がオープンされ管理されます。DEX が買収対象企業から必要なウェブサイト認証情報を確保することを確認することに加えて、検討・追跡すべき事項の例として以下が含まれます：

  1. 買収対象企業のウェブサイトを廃止したいか？
    1. 廃止する場合、いつ廃止するか？
  2. 買収対象企業のウェブサイトの特定のページをリダイレクトしたいか？
    1. リダイレクトする場合、どこへ？また、いつか？

文書管理プロセス

  • クロージング前の文書は Google Drive に保存され、潜在的な買収プロセスに関与する人々がアクセスできます。
  • クロージング時に、Legal & Corporate Affairs チームのメンバーが買収に関連するクロージングバインダーを整理・取得する責任を負います。
  • 受領後、Legal Operations チームはバインダーおよび元の Google Drive フォルダ内の残りの文書を ContractWorks の新しいフォルダにアップロードします。
  • 毎月、前月の調整 Issue が作成されます。この Issue には Corporate Counsel からの義務が含まれ、(i) 前月に契約がなかったこと、または (ii) 締結されたすべての契約が Legal Operations チームメンバーにアップロード用に提供されたことを確認します。
最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License