pm-prioritization

優先順位付けスキル

このスキルの動作（最初にお読みください）

これは生成的なスキルであり、優先順位付けは、善意が機能工場へと変わってしまう領域です。Claude のデフォルトはまさに失敗モードです。すべてに RICE を適用し（まったく新しい製品には間違ったツールであり、そこではリーチのスコアがほぼゼロになります）、客観的に見えるが推測に支えられたスコアを算出し、戦略にたどれないまま順位付けし（その結果、最も声の大きいステークホルダーが勝ちます）、バックログをゴミ捨て場のように扱い、時間・スコープ・品質を同時に最適化できるふりをします。優れた優先順位付けはその逆です。戦略から導かれた基準、状況に合った正しいフレームワーク、偽の精度ではなくトレードオフを浮き彫りにするために使うスコアリング、フローを守るシーケンス、そして防御可能な「ノー」。したがって、このスキルは次をゲートします。

1. 戦略、ステージ／制約、そして意思決定の可逆性を確立する — これらが基準、フレームワーク、そしてどの程度の厳密さが正当化されるかを決定します。
2. 常に真である核を適用する — 戦略から基準を導き、バックログをファネルとして扱い、トレードオフを露呈させるためにスコアを付け、価値 × ビジネス × 実現可能性のバランスを取り、トレードオフを明示し、順位付けだけでなくシーケンスを組み、文脈とともにノーを言う。
3. 文脈依存の意思決定を浮き彫りにする（どのフレームワークか、スコアリングの厳密さ、ロードマップの時間軸、アペタイトか見積もりか、賭けか戦術か）をトレードオフとともに提示します。

その後、pm-prioritization-rigor-audit（主要なペアリング先）へ引き継ぎ、さらに pm-okr-metric-validity-audit、pm-assumption-rigor-audit、そして — 重要度が高く不可逆な判断については — pm-decision-quality-audit へ引き継ぎます。

スコープ: このスキルは優先順位付けの意思決定とそのシーケンスを担います。ロードマップの成果物とそのコミュニケーションは pm-roadmap に、戦略そのものは pm-vision-strategy に、問題の発見／検証は pm-discovery と pm-problem-statement に、仕様は pm-product-spec に委ねます。

---

Step 0 — 優先順位付けの前に文脈を確立する

不明な場合は尋ねてください。答えを得ずに進める場合は前提を明示してください:

• 戦略と望ましい成果は何ですか？ 優先順位付けの基準とは、あなたの戦略を明示化したものです。成果（リテンション、エンタープライズ拡大、アクティベーション）が名指しされていなければ、あなたは盲目的に順位付けしていることになり、機能工場へと流れていきます。まずビジョン → 戦略 → 成果 → 機会という階層を確立してください。
• どのステージにおり、どのような制約がありますか？ まったく新しい製品には推定すべきリーチがありません（RICE は誤作動します）。ローンチ日が固定されていれば、スコープが唯一の変数になります。満足度主導の賭けには Kano が適しています。キャパシティ、締め切り、依存関係、技術的リスクを最初に明示してください。
• その意思決定はどの程度可逆ですか？ 厳密さは賭け金に応じてスケールします。可逆的で安価な判断には素早い ICE の一巡がふさわしく、高コストで元に戻しにくい賭けにはより重いスコアリングとエビデンスが求められます。両方向のドアを過剰に分析すると、サイクルを無駄にします。

---

常に適用されるコア（あらゆる優先順位付けに当てはまる真実）

• 基準は戦略から導き出し、すべての項目を戦略にたどれるようにする。 戦略的な選択を、重み付けされた採点可能な3〜5個の基準に翻訳します（エンタープライズ戦略 → 取引規模への影響、セキュリティ、管理機能の深さ）。実際のユーザー課題を解決する機能であっても、現在の戦略を前進させないのであれば、それは依然として誤りです。項目を戦略目標にたどれないなら、それが本当に属するのかを疑いましょう。これがフィーチャーファクトリーに対する防御策です。
• バックログは保管箱ではなくファネルとして扱う。 選択的に保ちましょう — 次のスプリントと、そのすぐ先の優先事項の小さな第2層のみとし、それ以外はすべて別の長期リストへ移します。項目をバケット分け（バグ / 技術的負債 / 顧客からの要望 / 戦略的取り組み）して、緊急のノイズがインパクトの大きい作業を埋もれさせないようにします。すべてを詰め込んだリストは、重要なものを隠してしまうブラックホールです。
• 採点はトレードオフを明らかにするために行い、精度を捏造するためではない。 フレームワークの価値は透明性にあります — 前提を明るみに出し、共通の言語を生み出すこと — それが生み出す数値ではありません。スコアがその土台にある推測よりも信頼できるように見えるときは注意しましょう。スコアが引き起こす議論（「なぜここは確信度が低いのか？」）は、数字よりも重要です。
• 3つの力のバランスを取る。 ユーザー価値 × ビジネス成果 × 実現可能性をまとめて秤にかけます。ユーザーの要望に偏りすぎる → 目標を前進させない小さな成果ばかりになる。収益に偏りすぎる → 実際のニーズから乖離する。実現可能性に偏りすぎる → 簡単なものだけを出荷することになる。単一の声に支配されないようにしましょう。
• トレードオフを明示する。時間・スコープ・品質の3つすべてを最適化することはできない（アイアントライアングル）。 どれか2つを固定すれば、3つ目が変動します。固定した期日 + 固定した予算は、暗黙のうちに品質を削ることを意味します — バグが出荷された後ではなく、作業が始まる前にそれを明言しましょう。Aに「はい」と言うことは、Bに「今はしない」と言うことです。そう伝えましょう。
• 順位付けだけでなく、順序を組み立てる。 採点されたリストは計画ではありません。作業をテーマごとにまとめて、ユーザーが一貫した変化を感じられるようにし（チェックアウトの改善3つをまとめたほうが、無関係な3項目より良い）、依存関係で並べて上流の決定が先に固まるようにし、「完了」をコードのデプロイにとどまらず定義します — アナリティクスの発火、サポート/営業のトレーニング、リリースノートの作成まで。実現を可能にする作業を伴わない順序の計画は、測定可能な価値を生まないコードを出荷することになります。
• 戦略的な文脈とともに「いいえ」と言う。 そっけない拒否は不満を生みます。「それは、ミッドマーケットを狙うという現在の戦略には沿いません」と言えば、意見から基準へと再構成されます。整合しないが有望なアイデアのためのパーキングロットのバックログを保ちましょう。非戦略的な機能への「はい」は、より重要な何かへの「いいえ」です。
• 意思決定を伝える。 フレームワークと根拠を共有し、相手に合わせて調整し（経営層は戦略的整合性を、エンジニアは文脈を、営業/サポートは顧客への影響を求める）、戦略テーマごとにまとめたロードマップを示します。優先順位に対する驚きは、たいてい意思決定ではなくコミュニケーションが失敗したことを意味します。

---

文脈に依存する判断（表面化させ、自動適用しない）

それぞれをトレードオフと Step 0 に紐づけた推奨事項とともに提示し、ユーザーに選ばせます。あらゆる判断を一つのフレームワークにデフォルト設定することが失敗パターンです — 問いに対してツールを合わせてください。

判断	適用すべきとき	避ける／適応すべきとき	デフォルトの推奨
どのフレームワークか	RICE: リーチを見積もれ、賭け金がより大きい既存プロダクトの機能を比較するとき。ICE: 迅速で初期段階の、時間に追われた判断。MoSCoW: 固定された締め切りの下でスコープを交渉するとき（Must は容量の約 60% 以下）。Kano: サーベイで測れる満足度主導の賭け。Impact×Effort: 初期の素早い合意形成。Eisenhower: ステークホルダーの雑音をふるいにかけるためのもので、バックログのツールではありません	まったく新しいプロダクトへの RICE（リーチが 0 になり優れたアイデアが罰せられます）、どこでも一つのフレームワークを使うこと、すべてが「Must」になる MoSCoW	文脈に合わせます: スピードには ICE / Impact×Effort、賭け金とデータが労力を正当化するときは RICE、締め切りの下では MoSCoW、満足度には Kano。その後は一貫してそれにコミットします
スコアリングの厳密さ	賭け金が高く不可逆な賭けには、より重いデータに裏打ちされたスコアリング	小さく可逆な判断のために精密なスコアをでっち上げること	厳密さは可逆性に合わせて調整します。数値は結論ではなく会話のきっかけとして保ちます
確信度と予測価値	不確実性が高いときは、予測価値だけでなくうまくいくという確信度で順位づけし、まず検証します	高価値・低確信度のアイデアに大きなリソースをコミットすること	大きな賭けに対する低い確信度 → 列に割り込む前に安価な実験を行います
ロードマップの期間フォーマット	通常の作業では、日付ではなく確実性を伝えるために Now-Next-Later	偽りの確実性を生み、遅延したときに信頼を損なう日付コミット型のロードマップ	デフォルトは Now-Next-Later。締め切りが本当に動かせないときのみ 固定日付・変動スコープ（パレート/MVP カットライン）
アペタイトと見積もり	投資をコントロールするための アペタイト（時間を設定し、それに合うようソリューションを形作る）	作業が長引くと締め切りを延ばすことが既定になる、終わりのない見積もり	アペタイトを設定します。超過したら、時間を延ばすのではなくスコープを削ります
戦略的賭けと戦術的ニーズ（およびセグメント）	プロダクトの成熟度に応じて容量を明示的に配分します（例: 70/20/10）。セグメントは戦略的重要性で重みづけします	戦術的な火消しや一人の大口顧客に戦略的作業を押しのけられること	目標配分を設定し、四半期ごとに見直します。セグメント間の対立はその場の取引ではなく戦略にエスカレーションします

---

結果を検証する（オーケストレーション）

ハンドオフでは、各レンズをインストール可能なスキルの name で指定します。呼び出すのは、そのスキルがインストールされている場合のみにしてください。インストールされていない場合、このスキル自体の中核がすでにこれらのルールを備えているため、ブロックせずにそのまま進めてください。

成果物を作成または改訂した後は、完了と宣言するのではなく、監査レンズに引き渡してください。これらは候補のレンズです。姿勢は docs/orchestration-policy.md に従うか、成果物全体を pm-product-review にルーティングしてください。ここでは assumption-rigor が常に関連するレンズ（自動実行） であり、その他は提案されるもので、成果物が実際に含む内容に紐づきます。ユーザーが特定の目的のためにこのスキルを呼び出した場合は、そのスコープを尊重してください。

• pm-assumption-rigor-audit (自動実行) — リーチ/インパクト/確信度の見積もりは前提です。「確信度」は証拠（パターン、テスト）に基づいているのか、それとも単なる楽観なのでしょうか？
• pm-prioritization-rigor-audit (提案 — 優先順位を設定する場合) — その主要なペアリング：偽の精密さ（確実性に見せかけたスコア）、戦略との連動（ランク付けされた各項目は目標にたどれるか？）、フィーチャーファクトリーの罠、must-have の水増し、そして可逆性に応じて調整された厳格さ。
• pm-okr-metric-validity-audit (提案 — インパクト/バリューの指標に依存する場合) — スコアリングが依拠する「インパクト/バリュー」基準：それは実際の成果であり、虚栄やゲーム可能な数値ではないでしょうか？
• pm-decision-quality-audit (提案 — 高リスクで後戻りしにくい判断を下す場合) — 結果よりもプロセス、可逆性に合わせた熟慮、サンクコストとバイアスの防止策、文書化された根拠とトレードオフ。

構成（docs/orchestration-policy.md §9 に準拠）： これを伝えるロードマップ（pm-roadmap）は下流にあります（次に作成することを提案し、自動生成はしないでください）。監査によって矛盾が表面化した場合（例：最高スコアの項目が実際には戦略を前進させない、または「確信度」が根拠のないもの）、目的に向けて解決してください：優先順位付けは、限られたリソースを戦略を最も前進させる作業に振り向けるために存在します — トレーサブルに保ち、不確実性について正直であり、何を断っているかを明示してください。 アイデアから計画までの完全な構築には、pm-idea-to-plan が、このステップをラダーの残りと順序付け、仕様の前に証拠を強制する、構成上のフロントドアです。

---

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

❌ しない	✅ する
何にでも RICE（または単一のツール）を頼りにする	フレームワークを状況に合わせる。RICE はリーチのない新製品では失敗する
直感でランク付けし、最も声の大きいステークホルダーに勝たせる	戦略から重み付き基準を導き、すべての項目をたどれるようにする
スコアを客観的な真実として扱う	前提を明らかにし、議論を促すために使う。偽の精密さのためではなく
すべてを一つのバックログに積み上げる	絞り込む：次のスプリント＋小さめの第二層。残りはバケット化して保留する
固定日付と全スコープと品質を約束する	アイアントライアングルを明示する。二つを固定し、三つ目を明示的に柔軟にする
エンジニアリングに締め切りを渡して見積もりを求める	アペタイトを設定する。超過したら時間ではなくスコープを削る
スコア付きリストを計画として出荷する	テーマと依存関係で順序付ける。コードデプロイ後も含めて「完了」を定義する
日付入りロードマップがずれて信頼を損なう	確実性を伝える Now-Next-Later。固定日付は本当に必要なときだけ
ステークホルダーをいら立たせる一律の「ノー」	「私たちの X という戦略に合わない」＋後日のためのパーキングロット
優先順位付けを未チェックのまま出荷する	prioritization-rigor（＋ okr-metric-validity、assumption-rigor、decision-quality）に引き渡す

---

参考レッスン (Uxcel)

• 容赦ない優先順位付け
• あなたを導くフレームワーク
• 優先順位付けの技術
• プロダクト戦略を活用した優先順位付け
• 優先順位付け、順序立て、そしてフロー
• 優先順位付けとトレードオフ