日本のPMのための実践メディア ── AI時代の実務に効く、読む・使う・試すを一つに。
ソウ著者・編集長

PM Tool Practice Playbook

PM向けExperimentation導入前プレイブック

実験ツールを比較する前に、割付品質、metric、guardrail、停止条件、意思決定ログを固定するための実務runbook。

ExperimentationOwner: PM-CompassVendor handoff: SaaS Radar
vendor-neutral runbook:このページは製品名・ランキング・おすすめ・料金・口コミを扱いません。製品探索はSaaS Radar、検証・運用手順はPM Compassという責務分担です。

Decision question

最初に答える問い

実験結果を見た後に都合よく判断基準を変えず、割付事故や計測不備を除外して意思決定できるか

このカテゴリの100点評価基準・PoC設計を見る →PMツールPoC評価テンプレートへ進む →

Preflight

導入・検証前のチェック

  1. 1. 実験単位（user / account / session等）とrandomization unitを明文化する
  2. 2. 期待するvariant比率とSample Ratio Mismatch（SRM）確認方法を決める
  3. 3. Primary metricは1つに絞り、成功方向・最小意味差・観測windowを事前に固定する
  4. 4. Guardrail metricを2〜4個定義し、悪化時の停止条件を決める
  5. 5. Exposure eventがvariant割付と同じ単位・時点で記録されるか確認する

Runbook

運用手順

  1. Step 1. 開始前にexperiment briefへHypothesis / Primary metric / Guardrails / Stop rule / Ownerを記録する
  2. Step 2. 開始直後は効果量より先にSRM・欠損・重複・cross-overを確認する
  3. Step 3. 途中結果は事前定義したmonitoring cadenceでのみ確認し、都度の停止判断を避ける
  4. Step 4. 終了時はPrimary metricだけでなくGuardrailとsegment差分を同じdecision recordへ残す
  5. Step 5. 勝敗にかかわらず、次に再利用するlearningと計測上のfailureを記録する

Evidence

残す証拠

  • variant別の割付数・exposure数・SRM判定
  • Primary / Guardrail metricの定義・query version・観測期間
  • 途中で行った設定変更とその時刻
  • 最終判断、confidence、未解決risk、次のaction

Failure signals

運用失敗を疑うシグナル

  • SRMやexposure欠損があるのに結果を採用している
  • 実験開始後にPrimary metricや成功条件を追加・変更している
  • 短期conversionだけを見てguardrail悪化を無視している
  • 同じ実験の結果がdashboardや担当者ごとに一致しない

Sources

根拠にした一次情報

評価軸・運用ルールを設計するために参照した公式ドキュメントです。特定製品の推奨を意味しません。

Source 1

learn.microsoft.com

https://learn.microsoft.com/en-us/xbox/playfab/live-service-management/game-configuration/experiments/experimentation-keys

原文を確認する ↗
Source 3

microsoft.com

https://www.microsoft.com/en-us/research/articles/patterns-of-trustworthy-experimentation-pre-analysis/

原文を確認する ↗

次に使う

次のPM実務へ進む

横断検索で探す →
評価基準Experimentationの選定評価基準

100点評価基準とPoC項目へ戻る。

PoCPMツールPoC評価テンプレート

このrunbookを候補ツールの実データ検証へ落とし込む。

他カテゴリPM向けツール導入 実務プレイブック

他カテゴリのrunbookを確認する。