pm-okr-metric-validity-audit

OKR & 指標妥当性監査スキル

このスキルがデフォルトの動作と比べて変えること

デフォルトでは、Claude は OKR をレビューするとき、文言を磨き上げ、構造にうなずくだけです。あるキーリザルトが反証可能かどうか、ある指標が虚栄の指標かどうか、ある「目的」が実質的には機能リリースを言い換えただけではないか、あるいは目標を達成することが実際にプロダクトを損なう可能性があるかどうかまで問いただすことはほとんどありません。この監査では、次の4点を強制します。すべての指摘が違反した原則を明示すること、すべての指標が意思決定に役立つかどうか（「この数値が変わったら、私たちは何を違えて行うか？」）を検証されること、すべての最適化目標がゲーム化の余地とガードレールについてチェックされること、そして指摘が具体的な書き直し案とともに重大度別に示されること — 一般的な励ましではなく。

これは評価型のスキルです。レビューまたは生成される作業の中に OKR、KPI、成功指標が存在するたびに自動的に実行されます。

スコープの規律。 直接呼び出された場合（ユーザーがこの監査を指名した場合）、この関心事のみをレビューします — 兄弟となる監査を引き込まないでください。他のレンズと並んで実行されるのは、pm-product-review オーケストレーターまたは生成系スキルが docs/orchestration-policy.md に基づいてこれを呼び出したときだけで、その場合これは**成果物に固有のレンズ — 提供（指標/OKR が定義されているとき）**に位置づけられます。明示的なスコープは常に優先されます。

---

フレームワーク — 何を確認し、違反がどのように見えるか

1. アウトカムであり、アウトプットではない

アウトプットとは、チームが出荷するもの（機能、リリース、ローンチ）です。アウトカムとは、ユーザー行動やビジネス成果の変化です。キーリザルトと指標はアウトカムを測定しなければなりません。出荷したものを数えることは、機能工場の兆候です。

指摘すべきとき： KR や指標が成果物、ローンチ、クローズしたチケット、実施した活動を数えている場合。目的が解決策を規定している場合（「Q3 までにモバイルアプリをローンチする」）。

• ❌ KR：「今四半期に12個の機能を出荷する」 · 目的：「紹介プログラムをローンチする」
• ✅ KR：「週次4週目のリテンションを22%から30%に引き上げる」 · 目的：「サインアップを業界で最もシンプルにする」

2. 反証可能性（SMART テスト）

各キーリザルトは、達成したかどうかが明白でなければなりません — 数値、単位、ベースライン、目標値、期間。分別ある人々が達成したかどうかで意見を異にする可能性があるなら、それは願望であり、キーリザルトではありません。

指摘すべきとき： ベースラインまたは目標値がない。単位がない。期間がない。「改善する」「最適化する」「強化する」といった動詞に、測定可能なものが何も付いていない。

• ❌ 「ユーザー満足度を改善する」 / 「離脱率を大幅に削減する」
• ✅ 「Q3 末までに NPS を42から50に引き上げる」 / 「12月までに月次離脱率を4.1%から3.0%に削減する」

3. 虚栄の指標への露出

虚栄の指標とは、いかなる意思決定にも役立たないまま、時間やマーケティング支出とともに増大するものです。ページビュー、インプレッション、ダウンロード数、フォロワー数、登録総数など。テストはこれです：この数値が動いたとき、どの意思決定が変わるか？ 答えがなければ → 虚栄の指標。

指摘すべきとき： 累積値や注意力の量の指標が成功として提示されている場合。活動の条件づけがない「アクティブユーザー」。価値への転換とのつながりがない成長数値（訪問者8万人、それでも売上は8件）。

• ❌ 「20万ダウンロードを達成する」（その下に隠れたアクティブユーザー3,000人）
• ✅ 「ダウンロードの12%を2週目アクティブユーザーに転換する」

4. 目的の質

目的は方向性を鼓舞し、キーリザルトは進捗を測定します。目的は簡潔で、定性的で、野心的で、記憶に残るものであるべきです — 企業的なもやもやでも、タスクリストでもありません。

指摘すべきとき： 目的がタスクや解決策として読める場合。曖昧な企業的言葉（「顧客獲得効率を最適化する」）。四半期サイクルごとにチームあたりおよそ1つを超えるフォーカス目的。目的を実際には裏付けていない KR。

• ❌ 「シナジーを活用してファネルを最適化する」 + 1チームに9つの目的
• ✅ 四半期に1つ、焦点を絞った目的 + それを証明する3〜5個の KR

5. 価値への因果関係

すべての指標は、ユーザー価値とビジネス成功への検証可能な因果関係によって、その存在意義を得ます。階層は次のとおりです: ノーススター（ユーザー価値と企業の成功を1つの数値に表したもの）→ KPI/L1 ドライバー → チームのインプット指標。その上位にある何にもつながっていない孤立した指標は、ノイズです。

指摘すべきケース: ユーザー価値のメカニズムを欠いた、純粋にビジネスだけ（売上）または純粋に活動だけ（サイト滞在時間）のノーススター。上位レベルにたどれない指標。階層のない「すべてを測定する」ダッシュボード（30以上の指標）。

• ❌ ノーススター:「総登録ユーザー数」 — 永遠に増え続け、提供された価値について何も語らない
• ✅ ノーススター:「リスニングに費やした時間」（Spotify）/「配達され高評価を得た注文数」 — 価値と成功を1つの数値に表す

6. ゲーミングへの脆弱性とガードレール（グッドハートの法則）

ある測定値が目標になると、それは良い測定値ではなくなります。すべての最適化目標に対して問いかけてください: 冷笑的なチームなら、プロダクトを悪化させながらこの数値をどうやって達成するだろうか? 簡単な答えがあり、ガードレール指標がなければ、それが指摘事項です。

指摘すべきケース: 摩擦や依存メカニズムによって達成可能なエンゲージメント/継続時間の目標。情報を隠すことで達成可能なコンバージョン目標（→ ダークパターンの領域）。積極的な成長目標と対になっていないガードレールのしきい値（品質、サポートチケット、使いやすさ、オプトアウト）の欠如。

• ❌「平均セッション時間を20%増加させる」 — 品質のガードレールなし
• ✅ 同じ目標＋ガードレール:「タスク完了時間が増加しない。サポートへの問い合わせは横ばい」

7. 先行指標/遅行指標のバランス

遅行指標（売上、チャーン）はすでに起きたことを確認します。先行指標（アクティベーション、初期エンゲージメント、オンボーディング完了）は軌道修正を可能にします。すべてが遅行指標のセットは、事後にしか失敗を報告できません。

指摘すべきケース: すべての KR が先行ドライバーを伴わない遅行のビジネス成果である場合。または、すべてが先行指標で、遅行指標による確認と結びついていない場合。

• ❌ MRR とチャーンだけで測定される四半期 OKR
• ✅ MRR 目標＋先行ドライバー: トライアルから有料へのコンバージョン、最初の2週間のエンゲージメント

緊張関係の注記: 野心と反証可能性 — OKR はストレッチすべきです（約70%の達成が健全）。したがって、野心的であるという理由だけで目標を指摘してはいけません。測定不能、無関係、またはゲーミング可能であるという理由で指摘してください。そして、厳密さと集中 — 指標の乱立をより多くの指標を要求することで修正してはいけません。修正策は通常、より少なく、よりよく結びついた指標です。

---

重大度の評価

各指摘事項を意思決定への損害によって評価してください — その指標をそのままにしておくと、チームに何をさせることになるか:

重大度	意味
Critical	書かれているとおりにこの指標を最適化すると、ユーザーまたはビジネスに害を及ぼす（ガードレールのないゲーミング可能な目標、虚栄のノーススター、フィーチャーファクトリーを誘導するアウトプットのみの OKR）
Major	進捗を正直に評価できない（反証不可能な KR、ベースラインの欠如、孤立した指標、すべて遅行指標のセット）
Minor	システムを劣化させる衛生上の問題（期間の欠如、目標あたり5つを超える KR、軽度の指標の乱立、あいまいな目標の文言）
Cosmetic	表現の磨き込み。これらでレポートを水増ししないこと

重複について: 指標を達成するために作られた操作的なUI は ux-dark-patterns-audit に属します — この監査は指標とガードレールのギャップを指摘し、あちらはインターフェースを指摘します。スペックレベルの要件品質は pm-spec-quality-audit に属します。

---

出力形式

## OKR & Metric Validity Audit — [Target]
Context: [team/product · cycle · business model, if known]

### Critical
- [Issue] — what's wrong → concrete rewrite. (Principle)
### Major
- …
### Minor
- …
### Working well ✓
- …

**Top 3 priorities:** the highest decision-damage fixes, with suggested rewrites.

常に優先順位付けされた上位の課題で終えてください — 平坦なリストは誰の行動にも役立ちません。

---

優れた監査の実行方法

1. まずコンテキストを確立する — ビジネスモデル（SaaS と e コマースでは指標が異なります）、プロダクトの段階（初期：アクティベーション／エンゲージメント、成熟期：リテンション／収益）、そしてどのレベルを監査するのか（会社の NSM か、チームの OKR か）。
2. 実際のコストのみを指摘する — 完璧ではなくても正直な指標のほうが、誰も収集できない紙の上だけの完璧な指標よりも優れています。実際にどのようなデータが存在するのかを尋ねてください。
3. 野心の緊張関係を尊重する — ストレッチ目標は OKR の欠陥ではなく特徴です。
4. 列挙ではなく優先順位づけを行う — 意思決定を損なう 3 件の指摘は、15 件の些末な指摘よりも優れています。
5. 修正案は具体的に — KR を書き直し、ガードレール指标に名前を付け、ノーススター指標の候補を提案してください。決して「もっと測定可能にする」だけで済ませてはいけません。

---

よくあるやるべき／やるべきでないパターン

❌ やるべきでない	✅ やるべき
OKR の文言を磨き上げて、それをレビューと呼ぶ	各指標について反証可能性、虚栄、ゲーミング、価値とのつながりを検証する
「20 万ダウンロード」をトラクションとして称賛する	その数字がどの意思決定に役立つのかを問い、アクティブユーザーの真実を明らかにする
「X をローンチする」をキーリザルトとして受け入れる	ローンチが引き起こすべき行動／ビジネスの変化として書き直す
すべての意欲的な目標に精度を求める	目標は鼓舞し、KR は測定する — それぞれの役割に応じて監査する
ストレッチ目標を「非現実的」と指摘する	非現実的ではなく、測定不能、孤立、ゲーミング可能なものを指摘する
さらに 10 個の指標を追加するよう勧める	より少なく、階層的につながった指標＋ガードレール
操作的な UI に関するダークパターン監査を重複して行う	指標／ガードレールのギャップを指摘し、インターフェースは ux-dark-patterns-audit に委ねる
順位づけされていない課題の山を提出する	意思決定への損害による重大度＋書き直しを伴う上位 3 件の優先事項

---

出典のレッスン（Uxcel）

• OKR、KPI、ノーススター指標
• 優れた（そして悪い）指標の解剖学
• 虚栄指標 vs. 実行可能指標
• 機能ではなく成果で考える
• 効果的なプロダクト指標の選択
• ダークパターンとガードレール指標の重要性