measure

Measure — 成功を定義し、追跡する

概要

成功を定義できなければ、成功に向けて設計することもできません。また、間違ったものを測定すると、間違った結果を最適化することになります。

UX 測定は、設計上の判断と観察可能な証拠を結び付けます。つまり、作ったものは実際に役立ったのかを明らかにします。このスキルでは、何をどのように測定し、得られた知見に基づいてどう判断するかを定義します。「リリースした」から「効果があった」への隔たりを埋めます。

ただし、測定は中立ではありません。選ぶ指標はどれも、最適化の方向を形作ります。サイト滞在時間を測れば無限スクロールが生まれ、クリック数を測ればクリックベイトが生まれます。コンバージョンを測ればダークパターンが生まれます。そうした指標がユーザーにもたらす代償も測定しない限りは。このスキルは、測定が操作の手段になることを防ぎ、指標が作為的なエンゲージメントではなく真の価値を促すようにします。

このスキルを有効にするタイミング： 新機能の成功基準を定義するとき、実験を設計するとき、測定フレームワークを構築するとき、ファネルのパフォーマンスを分析するとき、既存の指標が適切なものを測定しているか確認するとき、または「数字は良好に見える」のにユーザー体験に違和感があるとき。

---

スキルファミリー

Measure は、Intent スキルシステム全体と連携します。

• /strategize：その仮説には測定可能な成功基準が必要です。戦略上の賭けはすべて、その賭けが実を結んだかどうかを示す指標と結び付ける必要があります。/strategize は仮説を示し、/measure はそれが真となる条件を定義します。指標が戦略上の前提と矛盾するときは、ガードレールを設けたうえで、Measure が戦略を見直すためのループに戻ります（詳しくは、以下の「測定結果が戦略の見直しを促すとき」を参照してください）。
• /investigate：定性的な調査は、定量的な測定を補完します。数値からユーザーがステップ 3 で離脱していると分かったとき、Investigate はその理由を明らかにします。デザイン変更後に満足度スコアが下がったときは、Investigate がユーザーにインタビューし、数値の背後にある体験を理解します。指標だけを根拠に重大な設計上の判断を下してはいけません。
• /evaluate：UX 評価では、測定内容に役立つスコアと所見が得られます。評価でユーザビリティの問題を特定し、測定で修正が実際に問題を解決したかを追跡します。
• /specify：ビルドに向けてデザインをまとめます。プロジェクトで測定フレームワークが作成されている場合は、それもまとめた内容に含め、ビルダーが成功の指標を計測できるようにします。
• /philosopher：指標が目標になる前に疑問を投げかける、横断的な認知モードです。指標があまりにも簡単に操作できそうなとき、ダッシュボードは良好な数値を示しているのにユーザーから不満が出ているとき、測っているのがユーザーの成功なのかビジネスによる搾取なのか分からないとき、または「これを測定すると、測ろうとしている行動が変化してしまわないか？」という問いが必要なときに有効にします。

---

主な機能

1. 指標の選定：HEART フレームワーク

Google の HEART フレームワークは、UX 指標を選定するための体系的なアプローチを提供します。全体ではなく、機能ごとに適用してください。機能によって必要な指標は異なります。

Happiness — 主観的な満足度：

• NPS（Net Promoter Score）：他者にすすめる可能性を 0～10 で評価します。大まかですが、推移の把握には役立ちます。
• CSAT（Customer Satisfaction）：特定のやり取りに対する満足度で、通常は 1～5 で評価します。機能単位の判断には、NPS よりも具体的な改善につなげやすい指標です。
• SUS（System Usability Scale）：標準化された 10 問のユーザビリティアンケートです。リリース間の比較に適しています。
• 独自アンケート：特定の機能に結びついた具体的な質問です。「探していたものをどれくらい簡単に見つけられましたか？」は、「どれくらい満足しましたか？」よりも役立ちます。

Engagement — 行動の深さ：

• 頻度：ユーザーがどれくらいの頻度で戻ってくるか（日次、週次、月次のアクティブユーザー数）
• 強度：セッションごとの利用の深さ（利用した機能、閲覧したコンテンツ、実行したアクション）
• 幅：ユーザーが利用する機能の数（深さだけでなく、利用範囲の広さ）
• 最終利用時期：最後に利用したのはいつか（解約の早期警告）

Adoption — 新たな利用：

• 新規ユーザーのアクティベーション：主要なオンボーディングの達成段階を完了したユーザーの割合
• 機能の利用率：新機能を試した対象ユーザーの割合
• オンボーディングの完了率：初回利用の流れにおける完了率
• 価値実現までの時間：新規ユーザーが最初の有意義な成果に到達するまでの速さ

Retention — 継続的な利用：

• 再訪率：D1、D7、D30 の継続率（1 日後、7 日後、30 日後に再訪したユーザーの割合）
• 解約率：一定期間内に製品の利用をやめたユーザーの割合
• 再利用：離脱後に戻ってきたユーザー（何が再訪のきっかけになったか？）
• コホート別継続率：登録コホートごとの継続率曲線（新しいユーザーほど継続率が高くなっているか？）

Task success — 有効性：

• 完了率：開始したタスクを最後まで完了したユーザーの割合
• エラー率：エラーが発生した試行の割合
• タスク所要時間：タスクの完了にかかる時間（通常は短いほどよいものの、常にそうとは限りません）
• 効率性：最適な手順の長さに対するタスク完了の効率

すべての機能で 5 つすべてが必要なわけではありません。 機能の目的にとって最も重要な 2～3 つの観点を選んでください。チェックアウトフローでは、タスクの成功と満足度が特に重要です。コンテンツフィードでは、エンゲージメントと継続率が特に重要です。新機能のリリースでは、利用率が特に重要です。

カウンター指標： 最適化する指標ごとに、悪化する可能性のある指標を挙げてください。エンゲージメントが上昇しても満足度が低下しているなら、危険信号です。コンバージョン率が改善してもサポートチケットが増えているなら、何か問題があります。カウンター指標は、炭鉱のカナリアのように問題を早期に知らせてくれます。

2. 目標・シグナル・指標の対応付け

GSM フレームワークを使うと、何を明らかにしたいのかを理解せずに、いきなり指標に飛びつくことを防げます。

目標： 達成しようとしているユーザーまたはビジネス上の成果は何ですか？具体的にしましょう。「ユーザー体験を向上させる」は目標ではありません。「ユーザーが過度に閲覧することなく、関連性の高いコンテンツをすばやく見つけられる」は目標です。

シグナル： 目標に向けた進捗を示す、観測可能なユーザー行動は何ですか？これは意図とデータを結び付けるものです。「ユーザーが関連性の高いコンテンツへ直接移動する」はシグナルです。「ユーザーがサイトで過ごす時間が増える」は、必ずしも成功のシグナルではありません。ユーザーが迷っている可能性もあります。

指標： そのシグナルをどのように定量化しますか？具体的な計算式、データソース、測定頻度、成功基準を定めます。「分析データを使って毎週測定し、セッションの80パーセンタイルでコンテンツ到達までのクリック数の中央値が3未満」は指標です。

GSM の連鎖の例：

• 目標：ユーザーが煩わしさを感じずにチェックアウトを完了できる
• シグナル：ユーザーが離脱したり戻ったりすることなく、チェックアウトの各ステップを進む
• 指標：カートに商品を追加したユーザーのチェックアウト完了率が75％超、チェックアウト時間の中央値が90秒未満、チェックアウト中の戻る操作率が10％未満

リリース前に、主要な機能ごとに GSM の連鎖を構築しましょう。 目標を明確に説明できなければ、成功がどのようなものかを理解していません。シグナルを特定できなければ、何を測定すべきかを推測しているにすぎません。指標を定義できなければ、リリースしたものから学ぶことはできません。

3. A/B テストの設計

実験は、デザインの変更が実際に効果をもたらすかどうかを学ぶための方法です。しかし、設計が不十分な実験は誤った確信につながります。

仮説の構成： 「[具体的な変更]を行うと、[因果関係の説明]により、[具体的な指標]が[変化の方向]に[推定規模]だけ変化する。」

例：「検索バーをヘッダーからヒーローセクションに移動すると、ユーザーが閲覧時により早く検索バーを目にし、上にスクロールして検索する手間が減るため、検索の利用率が15％増加する。」

最小検出可能効果（MDE）： 検出する価値がある最小の変化はどれくらいでしょうか。コンバージョン率の0.1％の改善は、エンジニアリングの労力に見合わないかもしれません。5％の改善なら見合うでしょう。MDEはテスト後ではなく、テスト前に設定してください。これによって必要なサンプルサイズが決まります。

サンプルサイズの計算： ベースラインのコンバージョン率、MDE、統計的検出力（通常80％）、有意水準（通常95％／alpha = 0.05）によって決まります。推測せず、数式または計算ツールを使ってください。

一般的なシナリオの早見表（両側検定、検出力80％、有意水準95％、2つのバリアント）：

ベースライン率	MDE（相対値）	バリアントごとのサンプルサイズ
5％	20％（5％ → 6％）	約25,000
10％	10％（10％ → 11％）	約14,500
10％	20％（10％ → 12％）	約3,800
25％	10％（25％ → 27.5％）	約4,800
50％	5％（50％ → 52.5％）	約6,000

ベースライン率が低いほど、またMDEが小さいほど、必要なトラフィックは大幅に増加します。必要なサンプルサイズが月間トラフィックを超える場合は、MDEを大きくする（より大きな効果だけを検出する）、テスト期間を延長する、またはA/Bテストが適切な方法ではないと判断して、代わりに定性的な調査を行ってください。検出力が不十分なテストでは、結論が出ず、時間が無駄になります。

期間： 曜日による影響を考慮するため、少なくとも週単位のサイクルを1～2回通して実施してください。季節性のあるビジネスでは、さらに長く実施します。早期にサンプルサイズに達したとしても、1週間未満で終了しないでください。行動パターンは曜日によって異なります。

セグメンテーション： ユーザーセグメントごとに効果に差があるか確認します。新規ユーザーとリピーター、モバイルとデスクトップ、地域、プランの種類などです。全体では中立的な結果でも、あるセグメントには強いプラスの効果があり、別のセグメントには強いマイナスの効果がある可能性があります。

ガードレール指標： 悪化してはならない指標を定義します。新しいチェックアウトフローをテストする場合、ガードレール指標にはユーザーあたりの収益、サポートチケット数、返品率などが含まれます。テストのバリアントによってコンバージョン率が改善しても返品が増えた場合、そのテストは失敗です。

よくある間違い：

• テストが統計的有意性に達する前に結果を確認する（偽陽性率が上昇します）
• 多重比較への補正を行わずに、多数のバリアントを実行する
• 新奇性効果を無視する（新しいものは、それだけの理由でクリックされやすくなります。効果が安定するまで待ってください）
• 初期結果が「決定的」に見えるため、テストを早く終了する
• 複数のテストを同時に実施する際、交互作用効果を考慮しない
• 本当の問題が構造にあるのに、見た目の変更をテストする

4. ファネル分析

ファネル分析により、ユーザーが望ましいフローのどこで離脱しているかがわかります。しかし、価値があるのは数値そのものではなく、その理由を理解することです。

ステップを正確に定義する： 「カートに追加」はボタンのクリックですか、それとも追加の確定ですか？「チェックアウト」は支払いフォームの開始ですか、それとも送信ですか？ステップの定義が曖昧だと、コンバージョン率を誤って解釈する原因になります。各ステップを、具体的で観測可能かつ曖昧さのないイベントとして定義してください。

各ステップ間のコンバージョンを測定する： ステップ 1 → ステップ 2：何パーセントが次に進みますか？何パーセントが前のステップに戻りますか？何パーセントが完全に離脱しますか？各遷移から、それぞれ異なる状況がわかります。

最も大きな離脱を特定する： コンバージョン率が最も低いステップ間の遷移に注目します。「商品を見る」から「カートに追加」の間で 40％が離脱する問題と、「支払い情報を入力」から「注文を確定」の間で 40％が離脱する問題は異なります。

あらゆる条件でセグメント化する： ユーザーの種類（新規かリピーターか）、デバイス、トラフィックソース、地域、時間帯、曜日。全体をまとめたファネルでは傾向が見えなくなります。全体では 30％のコンバージョン率のファネルでも、デスクトップを使うリピーターでは 50％、モバイルを使う新規ユーザーでは 10％かもしれません。これはまったく別の問題です。

定性的な調査と組み合わせる： 離脱が見つかると、ユーザーがどこで苦労しているかがわかります。理由を理解するには、/investigate と組み合わせて、セッション録画、ユーザビリティテスト、摩擦が生じている箇所でのアンケートを実施します。文脈のない数値からは、誤った対策が生まれます。

ベンチマーク： 期間ごとに（直近のリリースで改善したか、悪化したか）、セグメントごとに（最も苦労しているのは誰か）、そして業界ベンチマークと慎重に比較します（桁違いの差を確認するには有用ですが、具体的な目標設定に使うのは危険です）。

5. 定性データと定量データの三角測量

数値からは何が起きたかがわかります。定性的な調査からはその理由がわかります。デザイン上の意思決定には、どちらか一方だけでは不十分です。

三角測量を行うタイミング：

• 指標に離脱が現れているが、理由がわからない → 摩擦が生じている箇所でユーザビリティテストを実施する
• リデザイン後に満足度スコアが低下した → 体験に何が変化したのかを理解するため、ユーザーにインタビューする
• A/B テストで統計的な差が見られない → 定性的な調査により、どちらの案にも根本的に同じユーザビリティの問題があったことがわかる
• 機能の利用率が低い → 発見しにくいのか、有用性の問題なのか、使いやすさの問題なのか？区別できるのは定性的な調査だけです。

三角測量の方法：

• 定量データから始めて、何がどこで起きているかを特定する
• 定性的な調査で理由を理解する
• 定量データに戻り、実施した対策がその理由に対処できたかを検証する
• 繰り返す

主要なデザイン上の意思決定を、単一のデータタイプだけに基づいて行わないでください。「コンバージョンが 5％改善した」という指標だけでは、真の価値を生み出したことで改善したのか、別の経路に摩擦を加えたことで改善したのかはわかりません。5 人が苦労したというユーザビリティテストだけでは、その問題がどれほど広く見られるかはわかりません。両方を組み合わせることで、実態が見えてきます。

6. 倫理的な測定

指標は、チーム、製品、ユーザーの行動を形作ります。慎重に測定しましょう。

グッドハートの法則： 「測定指標が目標になると、良い測定指標ではなくなる。」これは理論上の懸念ではありません。チームがサイト滞在時間で評価されると、無限スクロールや自動再生を実装します。登録数で評価されると、ユーザーを欺く登録画面を作ります。エンゲージメントで評価されると、通知を大量に送ります。指標が失敗したのではありません。目標の代わりに使う代理指標が、目標そのものになってしまったのです。

エンゲージメントは価値と同じではありません： エンゲージメントの高さは、満足ではなく依存を示している場合があります。1日に200回スマートフォンを確認するユーザーは、エンゲージメントが高いと言えます。不安や注意散漫を感じ、不満を抱えている可能性もあります。エンゲージメント指標と並べて、満足度指標も取り入れましょう。エンゲージメントが上がっても満足度が下がるなら、役に立つ製品ではなく、スロットマシンを作っていることになります。

注意すべきダークパターンの指標：

• あらかじめチェックされたボックスによる「成功した」ニュースレター登録を数える
• ユーザーが閉じるためにクリックする、しつこい通知から「エンゲージメント」を測定する
• 実際には解約を困難にしているだけの「継続率」を祝う
• 誤解を招くボタンラベルや緊急性をあおるタイマーによる「コンバージョン」を報告する
• 分かりにくいナビゲーションによって増えた「サイト滞在時間」を追跡する

Intent のアンチパターンカタログとの関連： ダークパターンを実装することで改善する指標は、誤ったものを測定しています。指標の改善を祝う前に、こう問いかけてください。この改善はダークパターンを使って達成できたでしょうか。答えが「はい」なら、実際にそうした方法が使われていないことを確認してください。

倫理的な代替フレームワーク： あらゆるビジネス指標と並べて、ユーザー満足度、タスクの完了度、作業負荷を測定しましょう。2つの列を設けた測定ダッシュボードを作成します。ビジネス成果とユーザー成果です。ビジネス指標が改善してもユーザー体験指標が低下しているなら、たとえ誰にもその意図がなくても、それはダークパターンの兆候です。

• ビジネス指標：コンバージョン率 → 対応するユーザー指標：購入後の満足度
• ビジネス指標：エンゲージメント（DAU） → 対応するユーザー指標：ユーザーが報告する価値
• ビジネス指標：継続率 → 対応するユーザー指標：解約のしやすさ
• ビジネス指標：ユーザーあたりの収益 → 対応するユーザー指標：価格に見合う価値の認識

---

測定結果が戦略を再検討させるとき

測定は戦略の下流にあるだけではありません。証拠が戦略上の前提と食い違うとき、測定によって戦略を再検討することもできます。以下のトリガーは測定に特化したものです。人間によるチェックポイント、ループの予算、文書化された終了条件といった一般的なループバックのルールは、/intent の「ループバックと終了条件」に記載されています。

指標をもとに /strategize を再検討するトリガー

• 対象ユーザーとの食い違い。 セグメント分析により、製品を利用している主要ユーザー層が、戦略で想定していたユーザー層と異なることが判明した。
• 機能検証の失敗。 中核機能とされていた機能が使われていない一方、周辺機能とされていた機能が広く使われていることを、採用指標が示している。
• ソリューション適合性の失敗。 離脱が起きているのは最適化したフロー内ではなく、その手前です。戦略で想定していた方法では、ユーザーが製品にたどり着いていません。
• グッドハートの法則が発動した。 主要指標は改善したものの、対抗指標は悪化し、定性的な調査によってユーザーの状況が悪化していることが確認された。
• 機会の過大評価。 測定した支払い意欲、利用頻度、またはリーチが、戦略上の見積もりを一桁以上下回っている。

トリガーではないもの — よくある誤検知

• 結果が予測をわずかに下回る。 規模よりも方向性が重要です。
• 目新しさや季節的な影響による初期指標。 安定するまで、週単位のサイクルを2回以上待ちましょう。
• 1つのセグメントのパフォーマンスが低い。 戦略全体の再検討ではなく、そのセグメントに特化した取り組みが必要な場合があります。

責任を持って戦略を見直す方法

1. 指標が否定する戦略上の前提を明示します。「ユーザーがコンバージョンしていない」ではなく、「[XのオーディエンスとYの動機]が主要な対象だと想定していましたが、データは[Z]を示しています」とします。
2. **結論ではなく、証拠を提示します。**指標、反対指標、定性的な兆候、当初の前提を示します。/strategize に再構成を任せ、先回りして枠組みを決めないでください。
3. **見直しの許可をユーザーに求めます。**測定によって戦略が誤っている可能性が明らかになることはありますが、戦略を変更する必要があるかどうかを決めるのは、ビジネスの背景を把握している人間だけです。

中止条件

プロジェクトの各イテレーションで、ローンチ後の指標に基づく戦略の見直しは最大1回までです。2回目の見直しが必要になった場合は、ユーザーが解決すべきフレーミング上の問題があることを示しています。分析を中止し、矛盾点をそのまま提示してください。

---

出力形式

成果物は、作業ディレクトリ、またはユーザーが指定した場所に、種類と対象を名前にしたファイル（metrics-larkspur-refills.md）として書き出します。成果物はファイルに、説明は会話に記載します。ファイルは最初のセクションから始め、自身についての説明行は含めません。

測定フレームワーク（GSM マップ）

主要な各機能または取り組みについて、カウンター指標と倫理的配慮を含むGoal-Signal-Metricの連鎖を作成します。

A/B テスト計画テンプレート

仮説、バリエーション、主要指標、ガードレール指標、サンプルサイズの計算、期間、セグメンテーション計画、判断基準（結果ごとにどのような対応を取るか）。

ファネル分析テンプレート

各ステップの定義、コンバージョン率、セグメンテーションの軸、離脱分析、主な摩擦点に対する定性調査計画。

指標ダッシュボードの仕様

表示する指標、表示方法、更新頻度、アラートのしきい値、対象者（誰が閲覧し、そこからどのような意思決定をするか）。

学習計画

ローンチ後の測定スケジュール：1日目、1週目、1か月目、1四半期目に測定する内容。確認するタイミング、注目する点、成功または方向転換を判断するタイミング。

---

口調とアプローチ

データが証明することと証明しないことを正確に述べます。区間を示し、曖昧な表現は避けます。「コンバージョン率は1～3ポイント上昇（95％ CI）、n=4,100」のように記載します。統計的有意性は、実務上の重要性を意味するものではありません。p値が0.05未満であれば、その結果が偶然による可能性は低いという意味ですが、結果が重要であることを意味するわけではありません。

成果物における制約は、数値で示します。n、区間、セグメントを記載します。選択バイアス、生存者バイアス、交絡変数については、会話で明示し、記録に残します。偽りの確信より、率直な不確実性のほうが役に立ちます。

根拠のない確実性に抗います。会話では、データから判断できないことと、どのような調査で判断できるのかを述べます。成果物では、区間とnでそれを示します。最も危険な指標とは、決定的に見えて、実際にはそうではない指標です。

追跡しやすいものだけでなく、ユーザーにとって重要なものの測定を推奨します。クリック数は簡単に数えられます。満足度の測定はより困難です。タスクの完了は意味のある指標です。滞在時間は解釈が曖昧です。計測の実装が難しくても、ユーザーの成功を反映する指標を推奨します。

---

対象範囲

このスキルが担当する内容：

• 指標の選定と測定フレームワークの設計
• A/B テストの設計と実験手法
• ファネル分析の手法とテンプレート
• 倫理的な測定に関する指針とカウンター指標の定義
• GSM マッピングと学習計画の作成

このスキルが担当しない内容：

• アナリティクスの実装と計測の仕組みづくり（エンジニアリング）
• 定性調査の実施（/investigate）
• 戦略のフレーミングと仮説の生成（/strategize）
• UX 評価とヒューリスティック評価（/evaluate）
• ダッシュボードのビジュアルデザイン（ビジュアルデザイン）
• 統計分析の実行（データサイエンス）