実験（Experimentation）
実験（Experimentation）
このページでは、実験を実施するための Growth エンジニアリングプロセスについて説明します。以下も参照してください:
- Growth による実験の開始方法（プロダクト）
- 実験ガイド（GitLab 開発者ドキュメント）
- 実験のデザインと分析（プロダクト分析）
実験の実施
Andrew Chen の How to build a growth team で概説されている 4 ステップのプロセスに従って実験を実施します。
- 仮説の形成: チームがテストしたいアイデアを定義します。
- アイデアの優先順位付け: 最初にテストするアイデアを決定します。
- 実験の実施: 実験を実行するためのプロダクト、デザイン、エンジニアリング、データ、マーケティングの業務を行います。
- 結果の分析: 結果データを詳細に分析し、仮説を証明または反証します。
毎週、Growth 週次ミーティングで進捗の更新を提供し、学習内容についてディスカッションします。
各実験の期間は、実験結果が統計的有意性に達するまでの時間によって異なります。期間が様々であるため、週によっては複数の実験が並行して実施されることがあります。
実験プロセス
概要
- 実験のスコープを定義するための実験アイデア Issue を作成します（追加ラベル:
~"experiment idea"、任意で追加:~"growth experiment"）
- 実験として試みるアイデアを持つ人は誰でもこの Issue を作成できます
- 実験したいプロダクトの部分、実験のアイデア（つまり仮説）、成功した結果がどのようなものかについての情報を提供します
- この非常に初期の段階で最も重要なことは、チームの他のメンバーが理解でき、プロジェクトマネージャーが引き継げるだけの十分なコンテキストと詳細でアイデアをメモしておくことです
- プロジェクトマネージャー（PM）は実験バックログを定期的にレビューして、明確に定義された実験の必要な基準を満たしているかを確認します
- PM は実験セットアップで概説されているプロセスに従ってエピックと関連 Issue を作成します
- PM、UX、エンジニアリングはプロダクト開発フローに従い、実験の完了に必要な業務を追跡するためにエピックにリンクされた
workflow::Issue を作成します - さらに、PM はデータチームと協力して、定義された成功指標を達成するために必要なデータを定義します
- 注意: データチームが新しいテーブルまたはカラムからのデータの取り込みを開始するためには、それらのテーブルまたはカラムがまず本番データベースに存在している必要があります。
- エンジニアリングチームはプロダクト開発フローに従って変更を提供し、他の GitLab チームに影響する変更に注意を払います。
- 私たちのプロセス、計画、現在の優先事項は他のグループに対して透明です
- 現在または近い将来に他のグループによって開発中の機能に対して実験を実施することを避けるようにします
- 私たちが導入する変更に対して、異なるグループが親しみを持てるよう、可能な限り関連するグループからレビュアーとドメインエキスパートを選びます
- プロダクトマネージャーが判断を下した時点で、実験とフィーチャーフラグのクリーンアップを開始し、実験機能をプロダクトに追加するか元に戻します
- エンジニアリングと PM は定義されたロールアウト計画に従って実験を有効化するために協業します
- PM は Sisense に送信されたデータを通じて実験をモニタリングし、必要に応じて実験ロールアウト Issue のロールアウト戦略を調整します
- PM は記録されたデータと実験の成功測定基準を比較します
- 実験（バリアント）が成功した場合、PM/エンジニアリングは成功したフローをプロダクトに完全に統合するための実験クリーンアップ Issueを作成します
- 実験（すべてのバリアント）が失敗した場合、PM/エンジニアリングは実験コードを削除して「コントロール」フローに戻すための実験クリーンアップ Issueを作成します
- 実験クリーンアップ Issue が解決されたら、実験ロールアウト Issue と実験エピックがクローズされ、実験プロセスが完了します
各ステージでの DRI の決定については、Growth RADCIE と DRI も参照してください。
実験 Issue ボード
実験のバックログは実験バックログボードで追跡されます。
実験のステータスを追跡するために、~"experiment-rollout" とスコープされた experiment:: ラベルを使用した実験トラッキング Issue が以下のグループの実験ロールアウトボードで追跡されます:
| gitlab-org | gitlab-com | すべてのグループ |
|---|---|---|
| 実験ロールアウト | 実験ロールアウト | Issue リスト |
実験セットアップ
- 実験の仮説と測定基準が明確に定義されたら、実験業務に最も適した最上位グループ（通常は
gitlab-orgグループ）に実験エピックが作成されます- エピックは実験の唯一の情報源（SSoT）になります
- 元の実験定義 Issueはクローズされてエピックに添付されます
- 実験定義 Issueからの最終的な定義、仮説、測定基準が新しいエピックの説明にコピーされます
- 実験に関連する新しい Issue（実験ロールアウト Issue、実験クリーンアップ Issue、UX 仕様 Issue、またはエンジニアリング業務 Issue など）がエピックに添付されます
実験定義 Issue
この Issue は、実験の概要、仮説、および成功の測定方法についての考えを含む実験を定義するための起点として機能します。[実験アイデア] Issue テンプレートをこれに使用できます（追加ラベル: ~"experiment idea"、任意で追加: ~"growth experiment"）。
実験定義標準
- 実験は定性的に測定できる（つまり、誤ったデータを与える可能性のある他の要因がない）
- 実験は可能な限りアトミックである（つまり、一連またはグループの変更ではなく、一つの特定の個別の変更を測定する方が最も容易）
- 実験には明確に定義された信頼性のある測定可能な成功指標がある
- 選択された成功指標についてのコンセンサスがある
- 成功指標は、実験のアクティブフェーズ中に収集・測定されるデータに明確に結びついている（実験ロールアウト Issue）
- 実験には統計的有意性への推定時間が含まれている: 母集団サイズと期待される転換率を考慮して実験が実施される必要がある期間
- この推定を計算するのに役立つA/B テスト計算機（外部）などの便利なツールを使用できます
実験エピック
このエピックは、実験が実験定義標準に従って適切に定義され、実施する価値があると判断された後、実験の唯一の情報源（SSoT）として機能します。実験定義 Issueがこのエピックに追加されたら、期待されるロールアウト計画などのさらなる詳細を記入します。また、実験をマイルストーンに割り当て、UX とエンジニアリング業務のためのプロダクト開発フローに従います。実験のデザインとロールアウトが進むにつれて、このエピックまたは親 Issue には、実験が成功かどうかを判断するために使用されるトラッキングイベントとデータポイント、および関連するメトリクス報告ダッシュボード（Sisense など）へのリンクを含む詳細や情報へのリンクが含まれるべきです。
実験ロールアウト Issue
この Issue は、デプロイ後の実験の進捗を追跡するために使用されます。実験のステータスを追跡するための追加の experiment:: スコープラベルを持つフィーチャーフラグロールアウト Issue に類似しています。[実験トラッキング] Issue テンプレートには、実験の概要、連絡先、ロールアウトステップ、および全体的な実験 Issue またはエピックへのリンクが含まれています。
experiment:: スコープラベルは:
~"experiment::pending"- 実験はデプロイ待ちです~"experiment::active"- 実験はアクティブ（ライブ）です~"experiment::blocked"- 実験は現在ブロックされています~"experiment::validated"- 実験は検証されました（成功基準が明確に達成された）~"experiment::invalidated"- 実験は無効化されました（成功基準が明確に達成されなかった）~"experiment::inconclusive"- 実験は結論が出ませんでした（成功基準が明確に達成されたとも達成されなかったとも言えなかった）
実験クリーンアップ Issue
この Issue は、実験が完了した後に実験をクリーンアップするために使用されます。クリーンアップ業務が行われるプロジェクト内（例: gitlab-org/gitlab プロジェクト）で作成されます。
クリーンアップ業務には、実験を完全に削除すること（~"experiment::invalidated" と ~"experiment::inconclusive" の場合）または長期間のために実験機能をリファクタリングすること（~"experiment::validated" の場合）が含まれます。
クリーンアップ Issue は、クリーンアップ前に実験が完了していることを確認するために、実験ロールアウト Issue の参照としてリンクされるべきです。
実験成功クリーンアップ Issue テンプレートは gitlab-org/gitlab プロジェクトに使用できます。
実験 Issue テンプレート
- GitLab
gitlab-org/gitlabプロジェクト- 実験アイデア Issue テンプレート
- エンジニアリング用実験実施 Issue テンプレート
- 実験ロールアウト
- 成功した実験を機能に転換するための実験成功クリーンアップ Issue テンプレート
- Growth
team-tasksプロジェクト
最小実行可能実験（MVE）
GitLab のすべてのことと同様に、実験はGitLab CREDIT 価値観、特にイテレーション、効率性、結果の価値観を念頭に置いてアプローチすべきです。
実験が大きくなるほど、デザインの作成、コード変更の実施、コード変更のレビュー、必要なデータの定義と収集、データを意味のあるテーブル・グラフ・ダッシュボードに整理するなどに時間がかかります。 実験プラットフォームを構築・改善し、実験を素早く作成・実施する能力を高めるにつれて、すべての実験の大部分が仮説の証明に失敗することを予期すべきです。 これらの無効化または結論の出なかった実験はロールバックされるため、実験を可能な限り小さくイテレーティブに保つことに利点があります。
これを念頭に置いて、最小実行可能実験（MVE）の開発を検討することに利点があります。 最小価値変更（MVC）の概念と同様に、MVE の目標は、テストする最小の仮説、その仮説をテストするための最もシンプルなデザイン、デザインの最速の実装、仮説を検証するために収集する最小限のデータなどを見つけることです。
では、MVE は実際にはどのようなものでしょうか？ Matej Latin は彼のブログ記事「Small experiments, significant results and learnings」で、いわゆる「painted door」テストの例を共有しています。 「painted door」テストのシンプルな例は、実際にはどこにも行かない CTA（行動喚起）ボタンかもしれません。「申し訳ありません！その機能はまだ準備できていません」という簡単なモーダルを表示したり、ドキュメントの既存のページにユーザーを連れて行ったりするかもしれません。 このタイプの MVE のデザインが意図的にシンプルなため、開発、デプロイ、データ収集の開始がより簡単で速くなります。 このタイプの MVE のデザインが意図的にシンプルなため、開発とデプロイがより簡単で速くなります。少量のインストルメンテーションで、そのボタンへの初期エンゲージメントを測定する機会として使用できます。
- CTA をクリックするのは誰ですか？
- どのくらいの頻度でクリックされていますか？
これは、次のステップ（例えばロールバック、より大きな実験の開発、またはフォローアップとしての機能の実装）を通知するための比較的低コストな方法になります。
「painted door」テストが常に最初のアプローチとして最良であるとは限らないことに注意してください。 主なアイデアは、実験に対してイテレーティブなアプローチを目指すことです。 「デプロイする価値があり、進め方を知るのに十分なデータをまだ提供するこの実験のよりシンプルなバージョンはありますか？」と自問してください。
実験ステータス
リアルタイムの実験ロールアウトステータスについて、GitLab チームメンバーは実験 API（ドキュメント）を表示できます（ブラウザ用の JSON ビューアを推奨）。
「current_status」はオン、オフ、または条件付きになります。条件付きの場合は、percentage_of_time または percentage_of_actors のいずれかが存在します。実験ガイドのフィーチャーフラグに関する注記を参照してください。
実験フラグがまだ存在するかどうかを示す Sisense のダッシュボードがありますが、現在のステータスは示しません。これらも GitLab チームメンバーのみが利用できます。
実験ロールアウトボードには、開発および SaaS で使用される実験フィーチャーフラグにリンクされたロールアウト Issue が一覧表示されます。
