結論：受け入れ基準（AC）は「Ahaに到達できたか」を数で判定する条文です。曖昧語を捨て、3クリック・3分・一意発火で締めます。
「ちゃんと動く」「迷わずできる」。耳ざわりは良くても、会議では解釈が割れ、レビューは長引きます。ACが甘いと、テストは通るのに価値は届かない。だからこそ、PRDのACは“ユーザーが価値を実感する＝Aha”を主語に、到達までの条件を数字で固定します。ここでは、ACをAha/TTV/D1へ接続し、QAと計測を同じ文脈で動かす作り方を、ストーリーとテンプレで落とし込みます。
ACの役割：仕様の合否ではなく“価値の合否”を決める
ACが担保するのは、実装の正当性ではありません。ユーザーがAhaへ到達できたかを判定する仕組みです。なぜなら、価値へ届かない最短経路は、どれだけ美しくても学習を生みません。ACを価値基準にすると、議論は仕様から体験へ、体験から数値へと自然に移動します。
- 主語は「Aha到達」：ユーザーの完了と価値の確認
- TTV（p50/p95）を閾値化：速さを客観化
- 観測の一意性：
achieve_aha発火をUIに紐づける - QAと計測の共同責任：同じ条文を読み上げて判定
【コピペ素材：ACの一句】
「Ahaに < 3分（p95 ≤ 7分）・3クリック以内で到達し、完了トースト時に 'achieve_aha' が一意に発火すること。」
まとめ：ACは「価値の到達・速さ・観測」の三点で決める。
具体例：初回の法人管理者が、招待リンク→“チーム作成”→完了トーストまで3クリック以内・3分以内で到達。
曖昧語を捨てる：数字で締めるACの基本構文
“スムーズ”“直感的”“迷わない”は解釈が割れます。数字へ落とすと、会議は短く、手戻りも小さくなります。ここでは、クリック・時間・観測・エラーの4系で条文化します。
- クリック：入口→Ahaまで最大3クリック（モバイルはタップ数2＋スクロール許容）
- 時間：TTV p50 ≤ 3分、p95 ≤ 7分（起点=view_entry、終点=achieve_aha）
- 観測：完了トースト表示と同時に
achieve_ahaが一意発火（重複禁止） - エラー：バリデーションは1画面内で自己解決（遷移戻り禁止）
【コピペ素材：AC基本構文 v1.2】
1) 入口→Aha：最大3クリック（モバイル：2タップ＋スクロール可）
2) 時間：TTV p50 ≤ 3分 / p95 ≤ 7分
3) 観測：完了トースト時に 'achieve_aha' 一意発火（1操作=1イベント）
4) エラー：同画面で解決（戻る遷移なし）
まとめ：主観を禁止し、測れる言葉だけで書く。
具体例：住所自動補完の有無はACに入れず、クリック数・時間・一意発火で評価。
摩擦別AC：入力／待ち／理解で条文化する
離脱は「入力・待ち・理解」の三類型に分けると、ACが設計しやすくなります。これは、対処レバーが異なるため、条文を分けるほうが運用が楽になるからです。
- 入力：必須項目 ≤ 2／選択肢は既定値あり／再入力は1回で完結
- 待ち：5秒超の処理は非同期化し、画面外で実行（プレースホルダ表示）
- 理解：画面冒頭に目的の一文／完了後は成果カードを即表示
【コピペ素材：摩擦別ACセット】
入力AC：必須≤2、選択は既定値、エラーは同画面解決（1回以内）
待ちAC：同期待ち≤5s。超過は非同期＋プレースホルダ（シャム差し替え≤60s）
理解AC：目的の一文を冒頭に表示。Aha到達時に成果カードを即描画
まとめ：摩擦を条文化してしまえば、議論は「満たしたか/満たしてないか」に還元できる。
具体例：p95遅延の原因が長文ガイド→「目的一文＋折りたたみ」をACに入れて是正。
QAと計測を一体化：同じACを読み上げて判定する
ACがQAだけの文書になっていると、ダッシュボードと会話が噛み合いません。テスト手順にイベント検証を内蔵し、QAが“数値の代弁者”になる構図を作ります。こうすると、ローンチ翌日の議論が速くなります。
- テストシナリオに「イベント一意性チェック」を必ず入れる
- p50/p95はログから回収（QCはUIストップウォッチでの補助のみ）
- 欠落時はPRDのAC条文に戻り、UI・ログどちらを直すかを即決
【コピペ素材：QA×計測 統合手順】
Step1：入口→Aha 3クリック以内で到達（動画保存）
Step2：完了トーストと 'achieve_aha' の同時発火をDevToolで確認（1回）
Step3：3本のテストを記録（p50暫定値・外れ値除外ルールあり）
Step4：エラーは同画面で解決できるかを再現
まとめ：QAは「通ったか」ではなく「価値に届いたか」を監査する。
具体例：Ahaイベントが二重発火→UI側の排他＋計測側のデデュープIDをAC違反として修正。
ワークショップ：60分でACを作り切る台本
ACは全員で決めると強くなります。時間を短く区切り、“一文→数値→観測”の順に固めましょう。短時間で骨が立つのは、最初にAhaを明文化するからです。
- 0–10分：Ahaの定義を音読（対象／行動／完了条件）
- 10–25分：3クリック・3分・一意発火の初期値を置く
- 25–40分：摩擦別AC（入力／待ち／理解）の条文化
- 40–55分：QA×計測の統合手順を合意
- 55–60分：PRDへ反映、v+0.1で保存通知
【コピペ素材：会議ひとこと】
「主観語は禁止。数字とイベント名で書く。満たさない案はWon’t、同等案は歓迎。」
まとめ：主観を排除するほど合意は速い。
具体例：営業の要望（自動補完）はACに含めず、結果として「3クリック・3分」を満たす方策かで評価。
具体例を丁寧に読む：条文化で“行間”を無くす
例1｜入力支援を入れたのにD1が伸びない
フォームのUI改善でp50は改善。しかしp95の尾が残る。セッション動画では、長文説明をじっくり読むユーザーが一定比率で存在。ACへ「目的は一文・詳細は折りたたみ」「完了時は成果カード即表示」を追記したところ、p95が2分短縮、D1は+6pt。
例2｜Ahaイベントが二重発火して数値が揺れる
完了トースト前後に別経路からachieve_ahaが発火。ACへ「1操作=1イベント」「UI排他＋計測側デデュープID」を明記。修正後、Aha率は±1%以内で安定。
例3｜SSOを入れるべきかで揉める
情シスは正しいが、初期コホートの価値は“すぐ使えること”。ACの「3分・3クリック」を満たせないため、SSOはWon’tへ退避。再審日は明記し、将来のD1・運用負荷の推定根拠を準備してもらう。
アンチパターン：ACが機能しか見ていない
ACが「ボタンが表示される」「APIが200を返す」で止まると、価値に届きません。価値基準を入れないACは、実装チェックリストに堕ちます。避けるべきは次の4つです。
- 主観語の多用（スムーズ・直感的・迷わない）
- 平均だけで判定（p95の山が見えない）
- イベント未定義（Ahaが観測不能）
- QAと計測の分断（片方だけが読める条文）
ダッシュボード：ACを数字で監視する
“見える化”の目的は意思決定の速度を上げること。ACに書いた数字は、そのままダッシュボードのタイルに写します。これで「満たしたか／満たしていないか」を毎朝5分で判定できます。
- タイル1：Aha到達率（前日／7日移動）
- タイル2：TTV p50/p95（警告：p95>目標+20%）
- タイル3：離脱トップ3（
input_error／wait_over_5s） - タイル4：入口別のAha率（招待リンク／アプリ内ボタン）
u-note：意思決定の順路を固定する
Aha→TTV→翌日活性の順で見ると意思決定が速くなります。詳しくはKPI設計と運用ガイドへ。
関連記事
FAQ
- Q. ACに“便利機能”を書いてよい？
- A. 原則NG。ACは価値の合否で書く。便利機能は「3クリック・3分・一意発火」を満たす手段として設計へ落とす。
- Q. p95が安定しません。
- A. 入口の混在とAhaの非一意を疑ってください。入口を1つに固定し、完了トーストでのみ発火に統一。
- Q. QAの負荷が高い。
- A. テストにイベント確認を組み込み、動画＋ログで一回の検証を兼ねます。AC条文を読み上げて判定する運用に切り替える。
▼有料note（直リンク）
コメント