Content last updated 2026-07-20

Growth セクションの仕組み

概要

Growth ステージは、GitLab のビジネス価値をスケールさせる責任を担います。これを達成するために、Growth は顧客の取得から複数の GitLab 機能にまたがるフロー、そして失われたユーザーの再アクティブ化まで、カスタマージャーニー全体を分析します。このミッションを支援するいくつかのグループがあります:

  • Activation、Conversion、Expansion、Adoption は、迅速な実験によって、GitLab がすでに提供している既存の価値にユーザーを接続します。
  • Analytics Instrumentation は、他のグループが成功するために必要なデータの基盤を構築し、GitLab でのデータインフォームドな製品文化を可能にします。

Growth の究極の目標は、Single DevOps Platform としての GitLab の価値を私たちの顧客と接続することです。そのために、ズームインとズームアウトのアプローチを取ります。GitLab の成長モデル全体を分解し、現時点で焦点を当てるべき最高 ROI のレバーを特定します。Growth direction ページでは、Growth セクションの長期的な方向性と短期的な焦点領域を概説しています。

Growth セクションの仕組み

Growth チームメンバー全員はこちらにリストされています 私たちはプロダクト開発フローに従います。

Growth のアイデア出しと優先順位付け

誰でも experiment idea テンプレートを使って、実験アイデアバックログにアイデアを提出することを歓迎します。

優先順位付けには、growth グループが ICE フレームワークを使用します。これは以下の要素から構成され、1 ～ 10 のスケールでスコアリングされます:

  • Impact - インパクトが高いほど高スコア
  • Confidence - 自信が高いほど高スコア
  • Ease - 容易さが高いほど高スコア

Weekly Growth Meeting

Growth Product Management Director は、実験のレビュー、優先順位付け、計画のための毎週の Growth Meeting を運営する必要があります。ミーティングは火曜日に 50 分で行われ、以下のアジェンダをカバーするべきです。

5 分: ソーシャルな質問

5 分: お知らせ

30 分: グループアップデート

  • KPI & OKR (Live)
  • Highlights & Learnings (Live)
  • Activities (Read only)
  • Next UP (Read only)

10 分: ディスカッション

ミーティングの準備のために、Growth PM と Growth Director は実験をチェックインし、結論を出せるものを特定し、レビューのためのデータを収集する必要があります。

その他の定例 Growth ミーティング

Weekly Growth Meeting に加え、Growth チームメンバーは以下の定例ミーティングに参加します:

  1. Weekly Growth Engineering
    1. 出席者: Growth チームメンバー
    2. 目標: Growth エンジニアリング関連のことを議論する。
    3. アジェンダ: リンク
  2. Weekly Analytics Instrumentation and Data Weekly Sync
    1. 出席者: Analytics Instrumentation and Data
    2. 目標: Analytics Instrumentation、Data Engineering、Data Analysis 全体の作業について状況を共有する。
    3. アジェンダ: リンク
  3. Weekly Growth & Threat Management EM
    1. 出席者: Growth & Threat Management EM
    2. 目標: Growth エンジニアリングの努力について状況を共有する。
    3. アジェンダ: リンク
  4. Weekly Growth PM sync
    1. 出席者: Growth PM
    2. 目標: PM チームとして同期し、PM 固有の課題やアイデアを議論する
    3. アジェンダ: リンク
  5. Analytics Instrumentation, Fulfillment, Data, Customer Success, and Sales Weekly Sync
    1. Analytics Instrumentation、Data、Customer Success、Sales
    2. 目標: Analytics Instrumentation、Data、Customer Success、Sales 全体の作業について状況を共有する
    3. アジェンダ: リンク
  6. Data チームとの月次同期ミーティング
    1. 出席者: Growth PM と Data チーム
    2. 目標: 影響する可能性のある今後の変更について Data チームに認識してもらい、データやトラッキングのニーズをセットアップする方法について事前にフィードバックを得る
    3. アジェンダ: リンク
  7. Growth Marketing との月次同期
    1. 出席者: Growth PM と Growth マーケター
    2. 目標: 同期し、一緒に可能な限り効率的に作業する
    3. アジェンダ: リンク
  8. Product、Legal、Compliance、Data、Privacy との月次同期
    1. 出席者: Product、Legal、Compliance、Data、Privacy
    2. 目標: 法務、コンプライアンス、プライバシーの懸念事項に答える
    3. アジェンダ: リンク
  9. Growth セクションと Application Security との月次同期
    1. 出席者: Product、Engineering、Application security
    2. 目標: Growth / Application Security の安定したカウンターパートの月次ディスカッション
    3. アジェンダ: リンク

Growth が実験を開始する方法

Growth セクションは製品実験と A/B テストを開始する最初のグループの一つであるため、実験に興味のある他のチームがより早く始められるように、現在のツーリングとプロセスを以下のガイドとドキュメントのリストにまとめました。

Growth が他のグループと協力する方法

Growth が探求する仮説は、グループとステージにまたがります。他のグループはどのように Growth と相互作用するのでしょうか？

Growth は製品のエリアを所有しませんが、GitLab アプリケーション全体でユーザーが価値を発見し解放できるようにする方法を見つけます。彼らは自分たちで成果を出しやすい改善を出荷することと、専門知識や継続的な焦点を必要とするより大きなイニシアチブで他のステージと協業することを組み合わせて行います。

それぞれの製品エリアでコア価値を維持・拡大することは他のステージの責任です。Growth のミッションは、その価値をユーザーへ届けることを合理化することです。たとえば:

  • Manage はユーザー登録と管理に責任があります。このステージは、他のカテゴリと優先順位を含むロードマップを持って、GitLab でユーザーがどのように作成・維持されるかについて長期的なビジョンを維持します。
  • Growth は、グループの優先順位を進めるための機会としてユーザー登録を特定する可能性があります。Growth のエンジニアリングチームは、Manage の直接的な関与なしに小さな改善を出荷する場合があり (ソフトメール確認など)、しかし全く新しいオンボーディング体験のようなより大きな努力では Manage とパートナーする必要がある場合があります。
  • 変更を最終的に所有するグループ - この場合は Manage - は、Growth の貢献を彼らの製品エリアにレビューし、より広いコミュニティからの貢献のように、最終的に最終結果を所有します。

UX

UX がマイルストーン計画にどう参加するか

計画 Issue が作成されると、プロダクトデザイナーは以下のステップに従う必要があります:

  • Issue ボードと優先順位付けダッシュボードをレビュー (Issue は優先度順に並べる必要があります)
  • 優先順位付けされた Issue に同意するか、変更を提案するかを決定。たとえば、私たちが見落としていた SUS に影響する Issue はないか？
  • 計画 Issue にコメントして提案された変更を議論。
  • 優先度が決定したらボードを並べ替える。
  • Issue に重みがあることを確認。
キャパシティ管理についての注意

すべてのマイルストーンには、コミットできる以上の作業があります。プロダクトデザイナーは、高い基準で作業を行うために引き受けられる Issue 重みのおおよその数を知っています。引き受けられる以上の Issue 重みを引き受けず、専門能力開発や UX 部署のイニシアチブなどの他の重要なタスクを犠牲にしないでください。これはバーンアウトにつながります。エスカレーションの指示に従って、引き受けられない Issue について、より広いチームに認識を持ってもらうことで、追加のオプションやトレードオフを探求できるようにします。

UX の働き方

ハンドブックの Product Design セクションで説明されている プロダクトデザイナーのワークフローと UX リサーチャーのワークフローに従います。Growth デザイナーとして、実験ワークフローに従って、デザイン変更のインパクトを徹底的に測定します。さらに:

  • 全員が何をしているかを確認できるように Issue ボードがあります。計画 Issue で Issue ボードを参照してください。たとえば、これは Acquisition Planning Issue のテンプレートです。
  • Issue には UX、devops::growth、group:: でラベルを付けます。
  • UX Research Workflow の定義に従って、実験が達成する学習のタイプを示すために、実験に UX problem validation と UX solution validation のラベルを付けます。これらのラベルの目的は、研究速度に関連する この UX KPI を追跡することです。
  • 通常の Issue には ワークフローラベル を、実験 Issue には 実験ワークフローラベル を使用します。
  • Acquisition、Conversion、Expansion、Retention の 4 つの growth グループの計画と優先順位付けを支援するためにマイルストーンを使用します。
    • PM は 実験用 ICE スコアを提供し、他の Issue には 優先度ラベルを使用します。
    • プロダクトデザイナーは、作業を提供する予定のマイルストーン (1-2 マイルストーン前、または数ヶ月先のアイテムについてはバックログ) を適用します。たとえば、現在のマイルストーンでデザイナーが実行できない Issue の場合、Issue に次のマイルストーンを追加することができ、これは PM に作業がいつ提供されるかを伝えます。
    • PM が計画されたマイルストーンについて懸念を持つ場合、プロダクトデザイナーや他の Growth PM とトレードオフを議論します。
  • キャパシティをよりよく見積もり、現実的に作業を分割し、マイルストーンでどれだけの作業を引き受けられるかについて PM にいくらかの洞察を与えるために、UX Issue 重みを使用します。
    • UX 作業用の Issue に UX のラベルを付け、Issue の重みを評価します。8 より大きい Issue はさらに分割する必要があります。
    • UX 重みを Issue に追加するには、design weight で始まるスコープ付きラベルを使用します。
    • UX 作業がエンジニアリングに移行する準備ができたら、ワークフローラベル workflow::planning breakdown を適用します。
  • 実験の設計用に Figma テンプレートがあります。Figma デザインのタイトルは実験名と一致させ、実験 Issue を Figma ファイルにリンクする必要があります。バリアントの準備ができたら、「All the variants」ページに control とバリアントを追加し、必要に応じてコンテキストを提供します。同じエリアで複数の実験を実施している場合、同じ Figma ファイルを使用することを検討しますが、実験設計ごとに異なるページを含めます。

UX Definition of Done (DoD)

プロダクトマネージャーと一緒に、プロダクトデザイナーはデザイン作業をより良く分解し、MVC が開発フェーズに移行する前にデザインワークフローのどのステップが完了する必要があるかについて、カウンターパートにより良い洞察を与えるために、epic に DoD を適用します。

プロダクト開発フローにリストされている 検証フェーズの成果に加えて、以下も確認します:

  • 実験の場合、仮説と実験計画を伴う実験 Issue が作成され、実験ラベルが適用されている
  • クロスチームの依存関係が特定され、それらのチームに通知され、彼らのフィードバックが受領されている
  • 選択された解決策のプロトタイプまたはモックが完了し、Issue のドキュメントとコンテンツを通じて、それらが開発の準備ができていることが明らかである
  • 解決策の以前のバージョンとディスカッションは「Draft」とラベル付けされ、Epic の説明には表示されない
  • 変更がコピーを含む場合、~“Technical Writing” と ~“UI text” ラベルが追加されている
  • デザインスペックがデザインに追加されている。gitlab-ui の関連コンポーネントへのリンクを試みる
  • Pajamas にないデザインパターンの場合 (まれに使用)、詳細な実装注釈が含まれ、エンジニアリングがレビューしている
  • 新しいデザインパターンやドキュメント更新のためのフォローアップ Issue がデザインシステムプロジェクトに作成されている
  • UX Issue がクローズされ、SSOT (epic) が完成したデザインへのリンクとともに更新され、主要な決定のためのデザインの理由も含まれる
  • MVC エンジニアリング Issue が更新され、~“workflow::planning breakdown” のラベルが付けられている

MR のビジュアルレビュー

エンジニアリングチームは、視覚的、相互作用的、またはフローの変更を導入する任意の MR に UX ラベルを適用します。これらの MR は、新しい Issue、バグ、フォローアップ、または任意のタイプの MR に関連する可能性があります。エンジニアが MR に UX が必要かどうか確信が持てない場合、関連 Issue で作業したデザイナー、および/またはそのステージグループに割り当てられたデザイナー、または Product Design Manager に相談する必要があります。

UX ラベルが付いた MR にはビジュアルレビューが必要です。MR が workflow::In review のとき、エンジニアはサイドバーの レビュアー機能を使用して、デザイナーにビジュアルレビューを割り当てます。これはメンテナーレビューと並行して行うことができますが、デザイナーはこれらのレビューを可能な限り早く完了することを優先する必要があります。

デザイナーが Review Apps や GDK を通じてビジュアルレビューを完了することが不可能または非現実的な場合があります。そのような場合、デザイナーとエンジニアはデモを調整するか、エンジニアが新機能を通じて自分自身の動画を録画して MR に追加することができます。ビデオの作成はレビュープロセスをスピードアップする方法ですが、これはオプションであり、完全なレビューの代用として常に適切とは限りません。

UX スコアカード

Growth のすべての計画中、進行中、完了した UX スコアカードは、この epic で見つけることができます。 詳細については、UX スコアカードについて読んでください。

UX スコアカードはオンボーディング体験を評価するために使用でき、私たちの UX ヒューリスティックにもオンボーディング基準を含めています。

UX テーマとラベル

UX 改善をいくつかのテーマで追跡するためにラベルを使用します。これにより、UX 改善のために特定した大きな領域に対して、より全体的に作業を追跡することができます。

現時点では、これらのテーマ/ラベルは次のとおりです:

他の Product チームとのコラボレーションプロセス

このプロセスを使用して、growth と product チームがビジネスインパクトを最大化しながら、緊密なコラボレーションを確保するようにします。

提案された Growth と Feature Product Owner のコラボレーションプロセス

  1. Growth は、別の product チームが所有するエリアに潜在的に触れる可能性のあるフォーカス領域を特定します。たとえば、growth は FY21 Q4 から Create と Verify 機能の新規ユーザー採用に焦点を当てる予定です。

  2. Growth は product チーム (理想的には PM、EM、UX を含む) と同期または非同期のキックオフ会話を持つために連絡を取ります。キックオフの目標は:

    • growth がこのエリアで実験を計画していることを Product feature オーナーに伝える
    • 衝突するロードマップや重複した努力を避けるために、growth の高レベルの計画とアイデアを共有する
    • 2 つのチームが互いに非同期で更新し合う方法 (関連する Issue または非同期/同期ミーティングで PM に ping するなど) のための計画を立てる
    • 理想的には、両チームの KPI と目的についての理解を確立する

  3. Growth は、私たちが取り組んでいること、出荷したもの、進行中で次に来るもの、分析された実験の結果と学びを、Key Reviews、GC などのチャネル、および潜在的に月次サマリービデオに定期的にアップデートを投稿します。

  4. ほとんどの growth 実験は最初は UX/copy フローの変更に焦点を当てており、これらは典型的な GitLab のコードレビュープロセスに従います。

  5. growth 実験から多くの新しい「機能」が開発されることは予想していませんが、これが発生した稀なケース、または私たちが開発した UX フローに永続的なオーナーが必要だと感じる場合、Growth チームは適切な product オーナーを特定する作業を行い、典型的なコミュニティ貢献プロセスに従ってオーナーに引き渡します。

  6. UX コラボレーションのために、プロダクトデザイナーは以下のことを行います

    • Growth プロダクトデザイナーは、デザイン Issue の作業を始めるときに、ステージグループのプロダクトデザイナーに認識と背景情報 (既存の制約、ユーザビリティの問題、既存の研究など) を収集するためにメンションします (Growth PM もステージ PM と同様の方法でコミュニケーションを取ります)
    • Growth プロダクトデザイナーは、フィードバックを得て一貫性を確保するために、ステージグループのプロダクトデザイナーをデザインレビューに追加します。デザインレビューは同期または非同期で行えます。例:
      • 定期的な月次の同期通話のスケジューリング。
      • 非同期キャッチアップ用のドキュメントの作成 (テンプレート) と、関係者全員に取り組んでいる内容を共有するように促すカレンダーイベント。
    • UX リサーチャーは、その研究がクロスステージで関連する場合、ステージグループと研究結果を共有する必要があります。

Learn GitLab プロジェクトへの貢献

Learn GitLab プロジェクトは、新規ユーザーを GitLab にオンボードするために利用され、GitLab プラットフォーム内でユーザーとそのチームを成功に導くのに役立つセルフペースの Issue を含んでいます。現在、Learn GitLab プロジェクトには、新しい無料 SaaS サインアップ用と新しい SaaS トライアルサインアップ用の 2 つの別個のプロジェクトがあります。growth チームはこの体験への改善を引き続き積極的に実験しています。Learn GitLab プロジェクトのいずれかへの改善を貢献したい場合は、この Issue で概説されている手順に従って行うことができます。

Growth RADCIE と DRI

GitLab の DACI アプローチに合わせて、以下のタスクの DRI は次のようになります:

タスクDRI
仮説の生成Growth Product/Engineering
実験設計Growth Product/Engineering
実験実装Growth Product/Engineering
貢献のレビューStage Product/Engineering
実験のランプGrowth Product/Engineering
実験後分析Data Team
実験後決定Growth Product/Stage Product/Engineering
メンテナンスStage Product/Engineering
アラート作成Growth Product/Engineering

Growth チームの権限内で、アプリケーションの任意のエリアで任意の実験を実行することができます。Growth がこのように実験できる能力は、より大きな GitLab チームの学習可能性を促進し、ビジネス優先事項をサポートするように設計されています。実験が別の product オーナー/チームのエリアに影響する場合、Growth は上記のコラボレーションモデルに従って彼らに通知します。Product オーナー/チームは、懸念を提起し、さらなるコンテキストを提供することが奨励されます。最終的に、Growth はデータと関連チームからの入力を使用して、実験が成功とみなされるかどうかを判断します。Product オーナー/チームには結果と次のステップが通知されます。

最終更新 July 30, 2026: Merge pull request #483 from kyama0/translation/batch-2026-07-29-1 (c955a93f)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License