pm-prioritization-rigor-audit

優先順位付けの厳密性監査スキル

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

デフォルトでは、Claude は自信を持って優先順位付けを実行します — でっち上げた数値で RICE テーブルを埋め、もっともらしく聞こえるインパクトで機能をランク付けし、根拠のない精度でその結果を提示します。他人の優先順位付けをレビューするときは、スコアを額面通りに受け入れる傾向があります。この監査は次の4つを強制します。すべてのスコアをその根拠までたどる（または装飾としてフラグを立てる）、すべてのランキングを戦略的成果までたどる（または根拠不明としてフラグを立てる）、すべての「必須」に異議を唱える、そしてすべての意思決定について明示的でストレステスト済みのトレードオフが検討されているか確認する。発見事項は重要度が評価され、具体的な修正案とともに提示されます。

これは評価型のスキルです。優先順位付けされたリスト、スコアリングテーブル、バックログの順序、または次に何を作るかの意思決定が、レビュー中または生成中の作業に現れるたびに自動実行されます。

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

---

フレームワーク — 何をチェックし、違反がどのようなものか

1. スコアの背後にある根拠（偽の精度のチェック）

RICE/ICE スコアは、その入力と同じだけしか良くありません。リーチは実際の利用データから、インパクトは誰かが擁護できる仮説から、コンフィデンスは根拠の質から導かれるべきであり、楽観論からではありません。小数点以下2桁まででっち上げられたスコアは、白衣を着た直感です。

フラグを立てる条件： スコアが出典なしで現れる。コンフィデンスが一律に高い。工数の見積もりにエンジニアリングの入力がない。出力の精度（例：「RICE 847.5」）がどの入力の精度も超えている。スコアリングが意思決定の後に、それを正当化するために適用された。

• ❌ 「リーチ: 9、インパクト: 8、コンフィデンス: 90% — RICE が作れと言っている」（どこにもデータが挙げられていない）
• ✅ 「リーチ: 約5,000新規ユーザー/月（サインアップ分析）。インパクト: 中（2）— 収益ではなくアクティベーション。コンフィデンス: 80%（問題についてはインタビュー根拠があるが、解決策についてはまだない）」

2. 戦略との連携（根拠不明な優先順位のチェック）

すべてのランキングは基準を含意し、その基準はプロダクト戦略から来ていなければなりません — 明示的で、重み付けされ、書き留められていること。各上位項目がどの戦略的成果を前進させるのかを挙げられない優先順位リストは、声の大きさ、直近性、またはステークホルダーの力によって並べられています。

フラグを立てる条件： 基準が明記されていない。戦略目標にたどれない基準。単一の案件や最も声の大きい人のために機能する上位項目。誰も意図的に選んでいない重みによる「重み付きスコアリング」演習。明言された戦略変更の後も変わらない優先順位。

• ❌ バックログの最上位: ある企業見込み客向けのカスタムレポートダッシュボード、根拠は「営業が必要としているから」
• ✅ 「戦略（ミッドマーケット拡大）からの基準: 案件規模への影響 40%、セキュリティ網羅性 30%、管理機能の深さ 30% — 1〜5で採点、重みの合計は100%」

3. 成果志向（機能工場のチェック）

アウトプットをランク付けする優先順位付けは、機能工場を生み出します。多くのリリース、進歩なし。項目は、影響を受けるユーザー数と痛みの深刻度が判明している問題/成果として枠組みを与えられるべきであり、それぞれがそれが奉仕する仮説にマッピングし直せるべきです。

フラグを立てる条件： リストが問題記述のない純粋な機能名である。何人のユーザーが影響を受け、どの程度深刻かが何も述べられていない。項目が元の仮説（「私たちは[セグメント]が[理由]により[行動]すると信じる」）にたどれない。ランク付けされた作業の成功が「出荷した」と定義されている。

• ❌ 「1. AI アシスタント 2. ダークモード 3. 新しいダッシュボード」— 問題も成果もない
• ✅ 「1. ステップ3でのアクティベーション離脱（サインアップの60%に影響、ノーススター指標を妨げる）— 候補となる解決策はその下に列挙」

4. 正直なカテゴリ（must-have インフレのチェック）

MoSCoW やクイックウィン／メジャープロジェクトのポートフォリオは、カテゴリに実効性がある場合にのみ機能します。すべてが must-have なら、何も must-have ではありません。「Won't have」が空なら、スコープクリープは事前に承認されているようなものです。

警告すべきケース: 項目の約 60% 超が Must Have に位置している。「Won't have」が空または存在しない。クイックウィンがどこにもない（勢いが枯渇する）、またはクイックウィンだけしかない（変革が決して起きない）。Kano のロジックが逆転している — 基本が壊れているのに delighters が優先されている。

• ❌ 18 項目中 14 項目が「Must Have」、Won't-have リストは不在
• ✅ Must はそれがなければ製品が失敗するもの。理由を伴う明示的な Won't-have。クイックウィンとメジャープロジェクトのバランスの取れた混合

5. 明示的なトレードオフ（隠れたコストのチェック）

すべての yes は、何かに対する no です。厳密さとは、却下された代替案、選択した道のコスト、そしてその理由が可視化されていること — そしてステークホルダーの「なぜこれか、なぜ今か」に耐えられることです。

警告すべきケース: 何が優先度を下げられたか、その理由の記録がない。意思決定が問題から選択へと飛躍し、緊張が覆い隠されている。ユーザー価値とビジネス実現性の対立が、自然に整合しているかのように提示されている。「この決定を変えるような証拠は何か」への答えがない。

• ❌ 「オンボーディングの改善を優先しました。」（そして沈黙）
• ✅ 「高度なレポートではなくオンボーディングを選択。アクティベーションは基盤全体を引き上げるが、レポートはアカウントの 8% にしか資さない — エンタープライズのパイプラインが倍増すれば再検討。コスト: レポートを求める顧客は四半期待つことになる。」

6. フレームワークの適合性と一貫性

フレームワークは既知の失敗モードを持つツールです。RICE はデータと時間を要します。MoSCoW は工数を無視します。Kano は（推測された「delighters」ではなく）実際の調査入力を必要とします。そして、選択的に適用されるフレームワーク — 結果が都合が悪くなるたびに放棄されるもの — は、何もないより悪いです。

警告すべきケース: 状況にミスマッチなフレームワーク（データゼロでの RICE、勘で割り当てられた Kano カテゴリ）。意思決定間でのフレームワークの乗り換え。理由を記録せずに直感でスコアが上書きされている。工数見積もりで制約（時間／スコープ／複雑さのトライアングル）が無視されている。

• ❌ 会議で Kano の「delighter」ラベルが割り当てられ、その背後にユーザー調査がない
• ✅ 「今回のリリースには MoSCoW（固定期限、データ乏しい）。RICE はアナリティクスが成熟するまで保留」

緊張に関する注記: 厳密さ対スピード — すべての意思決定が完全なスコアリング演習に値するわけではありません。可逆的で低リスクの選択を素早く行うことは良い優先順位付けです。厳密さの欠如は、元に戻すのにコストがかかる意思決定で警告し、どこでも警告するわけではありません。また、戦略的賭けがスコアを正当に上書きすることもあります — 要件は、その上書きが明示的で理由づけられていることであり、数学が常に勝つことではありません。

---

重大度評価

各所見を意思決定への損害 — その優先順位付けを放置した場合に、チームが何を構築し、何をスキップすることになるか — によって評価します:

重大度	意味
Critical	その順序付けがチームを誤った方向へ導く（戦略よりも一件の取引に資する優先順位、高コストで不可逆な賭けを駆動する捏造されたスコア、成果のないフィーチャーファクトリー的なリスト）
Major	その理由づけが擁護も監査もできない（基準がない、証拠の記録がない、隠れたトレードオフ、must-have インフレ）
Minor	プロセスの衛生状態（低リスク項目でのフレームワークのミスマッチ、Won't-have リストの欠落、戦略転換後の陳腐化した優先順位）
Cosmetic	フォーマット／ラベリングの磨き込み。これらでレポートを水増ししないこと

重複: 基準として用いられる指標自体が妥当かどうかは pm-okr-metric-validity-audit に属します — この監査は基準を前提とし、ランキングの規律をチェックします。より広範な意思決定プロセスの質（バイアス、可逆性、プロセス対成果）は pm-decision-quality-audit に属します。

---

出力形式

## Prioritization Rigor Audit — [Target]
Context: [team/product · decision stakes · framework used · data available, if known]

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

**Top 3 priorities:** the highest decision-damage fixes, each with the specific question the team must answer.

常に優先順位付けされた上位課題で締めくくってください — フラットなリストは誰の行動にも役立ちません。

---

優れた監査を実行する方法

1. まずコンテキストを確立する — 意思決定の重要性と可逆性、どのようなデータが存在するか、納期のプレッシャー、そしてどのフレームワーク（もしあれば）が使用されたか。これらが厳格さの基準を設定します。
2. 本当のコストのみを指摘する — 方向性を示す証拠は正当です。不完全な証拠ではなく、欠如しているまたは捏造された証拠を指摘してください。
3. スピードとの緊張関係を尊重する — 可逆的な項目に対する迅速な判断は健全です。儀式を押し付けないでください。
4. 列挙ではなく優先順位付けを行う — 来四半期に構築されるものを変える 3 つの所見は、10 の衛生上のメモよりも優れています。
5. 修正は具体的に — 不足しているデータソースを明示し、基準の重みを提案し、Won't-have エントリを起草してください。決して「もっと厳格さを加える」だけで済ませないでください。

---

よくある do/don't パターン

❌ Don't	✅ Do
RICE テーブルを額面通りに受け入れる	各スコアをその証拠まで追跡する。装飾を指摘する
ギャップを監査するときに、もっともらしいスコアを埋める	ギャップを明示する:「Reach は測定されていない — サインアップ分析を取得せよ」
ランク付けされた機能リストを優先順位付けとして扱う	影響を受けるユーザー数を含む問題/成果を要求する
「すべてが重要」をそのまま通す	Must-have に実効性を持たせ、明示的な Won't-have リストを強制する
フレームワークの選択を称賛して先に進む	フレームワークがデータと重要性に適合するか確認する
すべての小さな判断に完全なスコアリングを要求する	厳格さを可逆性とコストに応じて調整する
指標の妥当性を再監査する	指標の品質は pm-okr-metric-validity-audit に委ねる
順位付けされていない問題のダンプを納品する	意思決定への損害による重大度 + 回答すべき問いを含むトップ 3

---

ソースの教訓 (Uxcel)

• Ruthless Prioritization
• The Frameworks that Guide You
• Using the Product Strategy to Prioritize
• Prioritization and Trade-Offs
• The Art of Prioritization