配置を変えた、経路を追加した、目印を置いた。良くなった気がするでは判断できません。
この回は、空間の変更を比較で検証する方法を扱います。指標設計の教科書 EP.18 で扱った一般的な話に対して、この領域に固有の難しさを中心に書きます。
1. 空間ならではの難しさ
通常の比較検証と違う点があります。設計を誤りやすい箇所でもあります。
| 難しさ | 内容 |
|---|---|
| 同じ人が両方を体験できない | 一度覚えた空間は忘れられない |
| 影響が局所に留まらない | 1か所を変えると、周辺の流れも変わる |
| 他のプレイヤーの影響を受ける | 混雑は他人次第 |
| 慣れの効果が混ざる | 新しい配置は最初だけ迷う |
| 変更の粒度が大きい | 文言の変更とは違い、影響が広い |
1行目が最大の制約です。同じ人に両方を試してもらえません。一度その空間を覚えた人は、別の配置を初見として体験できない。だから人を分けて比べるしかありません。
4行目も重要です。変更した直後は、慣れていないせいで指標が悪化します。それを「変更が悪かった」と判断すると、良い変更を戻してしまいます。
慣れの効果は数日から数週間続きます。初期の数字だけで判断すると、変更は常に悪く見えます。既存のプレイヤーが慣れる期間を見込んで、評価の対象期間を決めてください。
2. 何を測るかを先に決める
変更の意図から指標を決めます。先に決めないと、後から都合の良い指標を選べてしまいます。
| 変更の意図 | 主要な指標 | 見張る指標 |
|---|---|---|
| 混雑を緩和したい | 1人あたりの滞留時間 | 通過人数が減っていないか |
| 寄り道を促したい | 訪問した区画数 | 目的地への到達率 |
| 迷いを減らしたい | 目的地までの経路の長さ | 探索の楽しさに関わる指標 |
| 特定の場所へ誘導したい | その区画の訪問率 | 他の区画が過疎化していないか |
見張る指標の列が重要です。指標設計の教科書 EP.24 で扱った と同じで、主要な指標を良くする過程で、犠牲にしてはいけないものを決めておきます。
2行目が分かりやすい例です。寄り道を増やそうとして、目的地に着けなくするのは改善ではありません。両方を見て初めて判断できます。
3. 分け方
同じ人が両方を体験できない以上、人を分けて比べます。分け方には選択肢があります。
| 分け方 | 利点 | 難点 |
|---|---|---|
| 新規のプレイヤーで分ける | 慣れの影響がない | 件数が集まりにくい |
| 既存も含めて分ける | 件数が多い | 慣れの影響が混ざる |
| サーバや地域で分ける | 実装が簡単 | 元々の性質が違う |
| 時期で分ける（前後比較） | 分ける必要がない | 他の変更や季節が混ざる |
1行目が最も清潔です。新規のプレイヤーはどちらの配置も初見なので、慣れの影響がありません。ただし件数が集まるまで時間がかかります。
3行目と4行目には注意が必要です。元々違うものを比べている可能性があります。統計入門 EP.06 で扱った「くじ引きで分ける」の原則が守れていません。
4行目は実装が最も簡単なので選ばれがちですが、他の変更や季節の影響と区別できません。同時期に別の変更を入れていれば、どちらの効果か分かりません。使うなら、その期間に他の変更を入れないことが条件です。
4. 必要な件数を見積もる
始める前に、どれくらいの件数が必要かを見積もってください。足りないまま始めると、結論が出ないまま期間だけ過ぎます。
import math
def required_n(baseline_mean, baseline_sd, detect_ratio, alpha=0.05, power=0.8): """平均の差を検出するのに必要な、片群あたりの件数の目安。
detect_ratio: 検出したい変化の割合（0.1 なら 10% の変化） """ delta = baseline_mean * detect_ratio if delta <= 0: raise ValueError("検出したい差が0以下です")
# 標準的な近似（両側検定） z_alpha = 1.96 if abs(alpha - 0.05) < 1e-9 else 2.576 z_power = 0.84 if abs(power - 0.8) < 1e-9 else 1.28
n = 2 * ((z_alpha + z_power) * baseline_sd / delta) ** 2 return math.ceil(n)
# 例: 現在の滞留時間が平均120秒、標準偏差60秒for ratio in [0.20, 0.10, 0.05]: n = required_n(120, 60, ratio) print(f" {ratio:.0%} の変化を検出: 片群 {n:,} 件（合計 {n * 2:,} 件）")実行すると、小さい変化を検出するには、桁違いに多くの件数が必要だと分かります。5%の変化を検出するには、20%の場合の16倍の件数が要ります。
この見積もりが、そもそも検証できるかの判断になります。必要な件数が現実的でないなら、A/B以外の方法を考えるか、もっと大きな変更で試すことになります。
5. 影響が漏れる問題
空間に固有の問題として、片方の変更が、もう片方に影響することがあります。
- 同じ空間を共有している — 混雑の影響が両群に及ぶ
- プレイヤー同士が情報を交換する — 変更内容が伝わる
- 経済や資源を共有している — 片方の行動が全体に影響
- 周辺の区画への流れが変わる — 変更していない場所も変わる
1番目が起きると、比較が成立しません。A群の混雑が B群にも影響するなら、「変更の効果」と「相手の群の影響」が混ざります。
対処としては、空間ごと分ける（別のインスタンスで比べる）方法があります。ただし今度は「元々の性質が違う」という問題が出ます。完全な解決はないので、限界を認識したうえで結論を出してください。
6. 判断の整理
最後に、進め方をまとめます。準備が結果の質を決める領域です。
- 1変更の意図を言葉にする — 何を良くしたいのか
- 2主要な指標と、見張る指標を決める — 始める前に
- 3必要な件数を見積もる — 検証できるかの判断
- 4分け方を決める — できれば新規のプレイヤーで
- 5慣れの期間を除いて評価する — 初日で判断しない
- 6影響が漏れていないか確認する — 群の間で混ざっていないか
- 7結論と、その限界を記録する — 何が言えて、何が言えないか
7番目を必ずやってください。「この検証で言えるのはここまで」を書いておくと、後から結果が独り歩きするのを防げます。件数が足りなかった、影響が漏れていた可能性がある ── 限界を書くことは、結果の価値を下げません。
そして、検証できないなら、できないと判断するのも正当です。必要な件数が集まらない、影響を分離できない。その場合は、A/Bではなく、EP.13 で扱った観察と、プレイヤーの声で判断するほうが誠実です。
空間の検証は、同じ人が両方を体験できないという制約がある。慣れの効果で初期は必ず悪く見えるので、初日で判断しない。指標は始める前に決める（見張る指標も）。必要な件数を見積もって、検証できるかを先に判断する。群の間で影響が漏れる問題は完全には解決できないので、限界を記録してください。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。