# 出力例：A/Bテスト計画書

> 架空のB2Bタスク管理SaaSを題材にした例です。数値は説明用の仮置きです。

## 仮説

案件横断の「今日の対応」ビューを提供すると、複数案件を担当するユーザーが必要タスクへ到達するまでの時間が短縮し、当日中のタスク処理率が上がる。

## 対象と割付

- 対象: 過去14日で3件以上の案件を閲覧したアクティブユーザー。
- Randomization unit: user_id。
- Control: 現行の案件別ホーム。
- Treatment: 案件横断「今日の対応」ビューへの導線を追加。
- Exposure: Treatment画面を実際に表示できた時点で記録する。

## Primary metric

**当日対応タスク到達時間の中央値**

- 開始: セッション開始後、最初にホームを表示した時刻。
- 終了: 当日対応対象タスクを最初に開いた時刻。
- 対象外: 対応対象タスクが存在しないセッション。

## Secondary metrics

- 当日中に完了した対象タスク数。
- 案件横断ビューから元タスクへの遷移率。
- 対象タスクがあるセッションでの離脱率。

## Guardrail

- ページ表示失敗率。
- 権限エラー率。
- タスク更新操作の失敗率。
- 主要ページのp95表示時間。

## Data Quality checks

1. Sample Ratio Mismatchを確認する。
2. Control / Treatmentでexposure欠損率を比較する。
3. 同一userが複数variantへ入っていないことを確認する。
4. bot / internal traffic除外条件を事前固定する。
5. timezoneによる「当日」の境界を固定する。

Data Quality異常がある場合、効果判定より先に計測・割付を修正する。

## 事前Go / No-Go条件

### Go

- SRMなし。
- Guardrailに重大悪化なし。
- Primary metricが事前に定義した実務上意味のある幅で改善。

### No-Go / 継続検証

- 計測異常がある。
- Primary metricは改善してもタスク更新失敗率が悪化。
- 特定segmentだけに効果が集中し、対象戦略と整合しない。

## 期間・sample

必要sample sizeはbaseline分布、検出したい最小効果、許容する誤検出・見逃しリスクを使って事前計算する。固定の「2週間」で十分とは仮定しない。

## 停止条件

- セキュリティ・権限関連の重大問題。
- Guardrailが事前閾値を超えて悪化。
- 割付・exposureの重大なdata quality異常。

途中の好結果だけを理由に早期終了しない。

## 結果記録

- 実験開始前の仮説・metric定義・対象・除外条件を保存。
- 実験中の仕様変更を記録。
- 結果と意思決定を分けて記録する。
- 再評価条件をDecision Logへ残す。

## 重要な前提

ユーザー単位での割付が他ユーザーへ強く干渉しないと仮定しています。

## 不足情報

baseline分布、必要sample、実際のnetwork effect、季節性が不足しています。

## 次に人間が確認すべきこと

実験開始前に分析担当・実装担当とmetric SQL / event definition / exposure条件を相互確認します。