define-prioritization-framework

優先順位付けフレームワーク

候補となる作業項目の一覧に対して、適用可能なすべての優先順位付けフレームワークを実行します。役割は、（a）データの有無とコンテキストに基づいてフレームワークを絞り込むこと、（b）適用可能な各フレームワークに基づき、各項目を明示的にスコアリングすること、（c）順位が一致する箇所と異なる箇所を示す比較表を作成すること、（d）推奨事項を含むエグゼクティブサマリーをまとめること、（e）優先順位付けで問題になり得る点を指摘することです。

概要

• フェーズスキル（定義）；Triple Diamond との統合
• 単一ターンで完結し、1回の実行につき1つの順位付け済み成果物を生成
• 読み取り専用ツール（Read、Grep）を使用し、出力成果物以外には書き込みません
• フレームワークごとのスコアリング表、比較、推奨事項を含む Markdown ドキュメントを出力します

基本原則

複数のフレームワークによる分析は、単一のフレームワークでの選定では見えないものを明らかにします。 RICE と ICE の結果が一致すれば、確信度が高まります。結果が異なる場合、その違いから検討すべき隠れた前提が浮かび上がります。多くの場合、これが最も価値のある発見となります。

適用可能性に基づいてフレームワークを絞り込みます。RICE にはリーチ、インパクト、工数に関する定量的な入力が必要です。ICE は大まかな見積もりで使用できます。MoSCoW は二択のコミットメント判断に使用します。Weighted Scoring には複数基準の重み付けが必要です。Kano には顧客調査の入力が必要です（ゲート制）。適用可能性の確認を通過したフレームワークはすべて実行します。複数のフレームワークが適用可能な場合、1つのフレームワークに絞らないでください。

使用しない場合

• 成果や機会をまだ候補一覧として整理していない場合 → define-opportunity-tree を使用してください。このスキルは一覧の順位付けを行うものであり、何を一覧に含めるべきかを見つけるものではありません
• 複数の項目を順位付けするのではなく、特定の前提を1つ検証したい場合 → define-hypothesis を使用してから、measure-experiment-design を使用してください
• 機能一覧の順位付けではなく、市場機会の規模（TAM/SAM/SOM）を算出したい場合 → discover-market-sizing を使用してください
• 項目の順位付けがすでに完了しており、次にリリース準備状況を確認したい場合 → deliver-launch-checklist を使用してください
• 既存の候補一覧を順位付けするのではなく、ユーザー調査を定性的に統合して候補を生成したい場合 → discover-interview-synthesis を使用してください
• スコアリング対象となる項目の候補一覧ではなく、未整理の状況（メモ、文字起こし、経営陣からの依頼）がある場合 → 一般的な次のアクションの順位付け計画には foundation-prioritized-action-plan を使用してください。このスキルでは候補一覧が必要であり、正式なフレームワークに照らしてスコアリングします

入力

必須：

• 候補項目の一覧（機能、取り組み、作業項目）。各項目には、少なくとも名前と1文の説明が必要です。
• 判断のコンテキスト：「第3四半期ロードマップの候補」「MVP の対象範囲の縮小」「次のスプリントに向けた仮説のトリアージ」など

任意ですが、品質の向上に役立つ情報：

• 項目ごとに利用可能なデータ（インパクトの見積もり、工数の見積もり、顧客の反応、ビジネスケース）
• ステークホルダーの評価基準（エンジニアリングのキャパシティ、ビジネス上の優先度、顧客の緊急度）
• 入力データの確信度
• 期間（スプリント、四半期、半年、1年）
• 顧客調査データ（Kano を利用可能にする）

フレームワークの適用可否フィルター

実行前に、利用可能な入力に照らして各フレームワークの適用可否を評価します。適用条件を満たすすべてのフレームワークを実行してください。

フレームワーク	実行条件	除外条件
RICE（リーチ * インパクト * 確信度 / 工数）	定量的なリーチ、インパクト、工数の見積もりが得られている、またはユーザーが見積もりのひな形を受け入れる	入力がなく、ユーザーが見積もりのひな形を拒否する
ICE（インパクト * 確信度 * 容易さ）	常に適用可能。概算の見積もりを許容できる	除外されない。ICE は最も必要な入力が少ないフレームワークです
MoSCoW（必須 / すべき / できれば / 対象外）	意思決定に、項目ごとの二者択一のコミットメント、またはスコープの限定が伴う	スコープの制約がなく、純粋な順位付けのみを行う場合は適用不可
Weighted Scoring（重み付けによる複数基準評価）	複数のステークホルダーまたは評価基準が関係し、ユーザーが重みを提示するか、提案されたデフォルトの重みを受け入れる	単一の基準が支配的な場合、または評価基準が完全に個人の好みによる場合
Kano（必須 / 性能 / 魅力）	以下のいずれかの証拠レベルで、顧客調査の入力が提供されている	**条件付き：**顧客調査がまったく提供されていない場合に限り除外します。その理由を説明し、どのような調査があれば適用できるかを提案してください。証拠が裏付けるレベルで実行し、出力にレベルを明記してください

少なくとも1つのフレームワークは必ず実行されます（ICE は常に適用可能です）。実行したフレームワークと除外したフレームワーク、および簡潔な理由を示してください。

作成する内容

1. 適用可否フィルターの概要（3～5文）

実行したフレームワーク、除外したフレームワーク、およびその理由を示してください。入力不足により除外したフレームワークがあれば、適用するために必要な入力も記載してください。

2. 入力の概要

提供された情報を記載してください。入力が不足している、または仮定を置いた場合は、次のように記載してください：「リーチは提供されていません。仮定：特に明記がない限り、リーチは大きいものとします。」

3. フレームワークごとのスコアリング表

適用可能な各フレームワークを実行し、スコアリング表を作成してください。

RICE：

項目	リーチ（ユーザー数 / 四半期）	インパクト（0.25～3）	確信度（%）	工数（キャパシティ週）	RICE スコア	メモ
項目 A	1000	2	80%	3	533	リーチの確信度が高い

ICE：

項目	インパクト（1～10）	確信度（1～10）	容易さ（1～10）	ICE スコア	メモ

MoSCoW：

項目	区分	理由	対象外にした場合のリスク
項目 A	必須	リリースに不可欠	これがないとリリースできない

Weighted Scoring：

項目	評価基準 1（重み）	評価基準 2（重み）	...	加重合計スコア

Kano：

項目	カテゴリー（必須 / 性能 / 魅力 / 逆 / 無関心 / あいまい）	回答分布（調査済みの場合。not available (inferred)はそれ以外）	証拠レベルと主張の強さ	顧客の証拠	示唆

4. フレームワークごとの順位付け結果

スコアリングを行った各フレームワークについて、スコア順に項目を並べるか、区分ごとにまとめてください。スコアリングを行ったフレームワークでは、上位 5 件と下位 5 件を強調し、その差を示してください。バックログの項目数が 10 件以下の場合、上位 5 件と下位 5 件が重複するか、一覧全体を使い切ってしまうため、このルールをそのまま適用できません。その場合は、項目をすべて順位順に示し、5 件ずつに無理に分けるのではなく、明確な層の間の差を説明してください。

5. フレームワーク横断の比較

実行したすべてのフレームワークにおける項目ごとの順位を示す比較表を作成してください。順位の乖離を明確に示してください。

項目	RICE 順位	ICE 順位	MoSCoW 区分	一致度
項目 A	1	1	必須	高い
項目 B	2	8	すべき	乖離あり

乖離している各項目について、その要因を説明してください。通常、乖離は特定のスコアリング要素が大きく影響していることを意味します（例：ICE では容易さが非常に低いため項目 B が 8 位ですが、RICE ではリーチが非常に大きいため 2 位です）。これが重要な発見です。

6. 推奨事項を含むエグゼクティブサマリー

比較を 3～5 文の推奨事項にまとめます。どの項目を優先すべきか、どの項目を延期すべきか、そして最も重要な相違点がチームの意思決定にとって何を意味するのかを述べます。異なるフレームワークや前提の下で推奨事項が大きく変わる場合は、その旨を明示します。

7. 感度分析 / 順位を変える要因

Confidence が誤っている場合はどうなるか。Effort が 2 倍になった場合はどうなるか。順位が変わる 2～3 のケースを示し、カットライン付近の項目に注目します。

8. 推奨事項(順序付け)

資金を投入すべき上位項目、延期または中止すべき下位項目、どのような追加データがあれば推奨事項が変わるか。単なる順位だけでなく、次のステップを推奨します。

9. 限界とバイアス

これらのフレームワークが測定していないものは何か。フレームワークが誤った方向に導く可能性があるのはどこか。特定の項目タイプを他のタイプよりも体系的に優遇してしまうのはどこか。

拒否プロトコル

最低限の入力品質がない場合、順位付けの作成を拒否します。具体的には以下のとおりです。

1. 空の / 単一項目のリスト。 ユーザーが候補項目を 0 個または 1 個しか提供しない場合:「優先順位付けが意味を持つには、少なくとも 3 項目が必要です。それ未満の場合は、直接決めてください。」

2. コンテキストの欠如。 ユーザーがどのような意思決定を行うのか述べずに項目を提供した場合:「この優先順位付けがどのような意思決定を支えるのかを知る必要があります。スプリントのスコープですか?四半期のスコープですか?仮説のトリアージですか?コンテキストが異なれば、適用すべきフレームワークも変わります。」

3. RICE に必要な数値入力の欠如。 ユーザーが入力データを提供せずに RICE スコアを求めた場合:「reach、impact、confidence、effort の推定値がなければ、防御可能な RICE スコアを作成することはできません。選択肢:(a) 項目ごとにおおよその数値を提供する、(b) 推定の足場を作成する — 各項目の reach、impact、confidence、effort をどのように推定するかを示す構造化ワークシート、(c) 代わりに ICE を実行する — これは粗い 1～10 の判断で機能し、定量的な入力を必要としません。どちらを希望しますか?」(ICE 自体はデータ欠如を理由に拒否されることはありません — 常に適用可能な粗いフォールバックです。)

4. 誤ったフレームワークへの固執。 ユーザーが初期段階の仮説トリアージに RICE を主張した場合:「RICE は測定可能な impact と effort を前提としていますが、この段階ではそれらはありません。RICE の表を作成することはできますが、スコアは推測になります。ICE または MoSCoW のほうが誠実です。それでも RICE で進めますか、それとも切り替えますか?」

5. 単一ステークホルダーの重み付きスコアリング。 ユーザーが 1 人のステークホルダーしか関心を持たない基準で重み付きスコアリングを求めた場合:「重み付きスコアリングは複数のステークホルダー間のトレードオフのためのものです。1 人のステークホルダーの基準しか当てはまらないのであれば、RICE または ICE のほうが簡単です。進めますか、それとも切り替えますか?」

6. 顧客調査なしの Kano。 ユーザーが Kano を要求したが顧客調査の入力も提供しない場合:「Kano のカテゴリは顧客調査があって初めて防御可能です。それがなければ、ある機能が Must-Have なのか Delighter なのかを推測することになり、本来の目的が損なわれます。今回の実行では Kano を除外しました。他の適用可能なフレームワークは上記で実行済みです。Kano を利用可能にするには、顧客アンケートまたはインタビューのデータを提供してください(スキル: discover-interview-synthesis または measure-survey-analysis)。」どちらのスキルも環境で利用できない場合は、その参照先を裸のままにしないでください。代わりに調査を平易な言葉で名指ししてください。それは、機能ごとに、それが存在する場合にユーザーがどう感じるか、それが存在しない場合にどう感じるかを尋ねることです。それが実際にもたらす以上に多くを暗示する数値を挙げるのではなく、小規模な実行で何が得られるかに正直になってください。階層はどのように収集するかによって決まり(下記のエビデンス階層を参照)、何を主張できるかは回答した人数によって別途決まります。小規模な正式な計器であっても、それは調査に基づく実行であり、測定ではありません。階層と主張の強さは、2 つの別個の記述として報告してください。

フレームワークの詳細

RICE（リーチ、インパクト、確信度、工数）

Score = (Reach * Impact * Confidence) / Effort

• リーチ：一定期間（四半期単位が一般的）に影響を受けるユーザー／顧客／イベントの数です。割合（％）ではなく、実数を使います。
• インパクト：影響を受けるユーザー一人ひとりがどの程度のメリットを得るかです。Intercom の尺度を使います：0.25（最小）、0.5（低）、1（中）、2（高）、3（非常に高）。
• 確信度：ほかの見積もりがどの程度確かかです。0～100％で表します。
• 工数：キャパシティ週単位で、どれだけの作業が必要かです。値が大きいほどスコアは低くなります。**実際に実行するチームの週あたりのキャパシティに合わせて単位を調整し、換算方法を出力に明記してください。**名目上のエンジニアリング週（40時間）は、スタッフのいるチームには適切ですが、週に5時間しか作業できない一人のメンテナーには適切ではありません。そのキャパシティでは、どんな小さな項目も「1週未満」に丸められ、工数の軸では項目間の違いをまったく区別できなくなります。実際にそのチームが1週間でこなせる作業量を単位とし、その単位を一度明記したうえで、すべての項目で一貫して使用してください。

ICE（インパクト、確信度、容易さ）

Score = Impact * Confidence * Ease

3つすべてを1～10の尺度で評価します。大まかですが、迅速に使えます。30件以上のアイデアを素早くトリアージする必要があるときに使用してください。多額の投資を決定する際には使用しないでください。

MoSCoW（必須／推奨／可能なら対応／今回は対象外）

• Must have：リリース／公開／コミットメントに必須
• Should have：重要だが、必須ではない
• Could have：時間や予算に余裕があれば含めるとよい
• Won't have (this time)：今回は明確に対象外

コミットメントの伝達には強い一方、各分類内での相対的な順位付けには向いていません。

加重スコアリング

各基準に明示的な重みを設定する、多基準の評価方法です。

Score = Sum over criteria (Weight_i * Score_i)

何を重視すべきかについて関係者の意見が一致しない場合に使用します。重みを通じて、意見の相違を明確にしてください。

**ユーザーから指定がない場合のデフォルト基準：**ビジネス価値、顧客価値、工数、リスク、戦略との適合性を、それぞれ同じ重み（各20％）にします。重みを等しくすることも一つの選択です。「この初期設定の重みはすべて同じです。組織が実際に重視するものを反映するよう調整してください」と明示してください。重みを黙って適用してはいけません。

Kano

機能の有無が顧客満足度にどのように影響するかに基づいて、機能を分類します。

• Must-Have：ないと不満が生じ、あっても当然と受け止められる
• Performance：線形に、増えるほどよい
• Delighter：あると満足度が高まるが、なくても不満にはならない
• Reverse：あると不満が生じる（まれ）
• Indifferent：顧客は、あってもなくても気にしない

妥当な分類には、顧客調査からの情報が必要です。実行条件あり — 調査情報が提供されていない場合は、実行対象から除外します（拒否理由 #6 を参照）。

**「顧客調査」には幅があり、分類の信頼性も調査方法によって異なるため、エビデンスの階層を設けます。**実行に使用した階層を、出力内で各分類のそばに明記してください。

階層	意味	実行方法とラベル
調査済み	機能ごとに、機能的・非機能的な質問を組み合わせた正式なKano質問を実施	通常どおり分類します。**Kano（調査済み）**とラベル付けします。分類が測定済みかどうかは、データの収集方法とは別の問題です。以下の十分性に関する注記を参照し、条件が満たされるまでは「直接測定」と書かないでください
推定	インタビューのテーマ、アンケートの平均値、サポートチケットの傾向、満足度を示す分析データなど、Kano形式の質問として収集されていない調査の要約	分類し、**Kano（推定）**とラベル付けします。明白でない分類ごとに、どのシグナルが判断の根拠になったかを示します。また、Delighter または Must-Have の判断は、確定した知見ではなく、検証すべき仮説として扱います

エビデンスが調査済みではなく推定であることを理由に、実行を拒否しないでください。顧客調査がまったくない場合に限り、拒否してください。推定の階層に下げてその旨を明示するほうが、フレームワークを除外するより有用であり、確信度に関する主張も誠実に保てます。 ティアは方法に関するもので、妥当性はサンプルに関するものであり、両者は独立しています。 少人数を対象に正式なKano調査票を実施した場合でも、データの収集方法に基づけば調査に分類されますが、測定ではありません。measure-survey-analysis では、nが100未満の場合は方向性を示すにとどまり、nが30未満の場合はセグメントに関する主張には小さすぎると定めています。また、Kanoカテゴリは機能ごとの主張です。そのため、方法に基づいてティアを分類し、サンプルが裏付ける内容は別途明記してください。これらのしきい値を下回る場合は、カテゴリを方向性を示すものとして報告し、「直接測定した」「検証済み」といった表現や、カテゴリ別の回答者の割合は使用しないでください。小規模な正式調査と大規模な正式調査では、ティアは同じでも、裏付けられる主張は異なります。

基準数を満たすことは必要条件ですが、十分条件ではありません。 nに達しても「検証済み」と言えるわけではありません。それは、その表現を避けるべき理由が一つなくなるだけです。妥当性は、機能ごとの有効なペア回答数（ペアのうち機能不満側を回答しなかった回答者は、その機能の集計に含めません）、募集した回答者の属性と、その回答者が意思決定の対象となる母集団を代表しているかどうか、そして調査票の品質にも左右されます。measure-survey-analysis では、サンプル数にかかわらず、募集バイアスがあると一般化できないことが明記されています。そのため、規模が大きくても自己選択によるサンプルから得た結果は方向性を示すにとどまり、測定に基づく主張も実際に回答した人に限られます。回答者がロードマップの対象ユーザーを代表している理由を説明できない場合は、nがいくつでも「検証済み」と書かないでください。

推定に基づく実施では分布が得られないため、分布を捏造してはいけません。 インタビューのテーマ、サポートの傾向、分析データからは、Kanoカテゴリ別の回答者数は得られません。その列には not available (inferred) と記載し、代わりに定性的なシグナルと、その根拠となる情報源を示してください。推定に基づく判断を調査結果のように見せてしまうため、分布を捏造するのは、分布がないままにするよりも問題です。

このスキルでは「明確に優勢」を数値で定義していません。それは意図的です。 消費者向けの項目が5つあるバックログに適したしきい値が、エンタープライズ向けの項目が2つある場合にも適切とは限りません。ここで独自の基準値を設けることは、サンプルサイズを捏造するのと同じで、根拠のない数値に、置き換えた判断以上の権威を持たせることになります。分布を報告し、読者が差を確認できるようにしてください。分布を見てもどのカテゴリが優勢か判断できない場合に使うのが、Ambiguousです。

そして、良好なサンプルでも満たせないことがある条件、それがシグナルの強さです。 measure-survey-analysis では、確信度のラベルはサンプル、方法論、シグナルの強さに基づいて決められており、妥当性のチェックリストでは3つ目の条件が見落とされがちです。ある機能について、Must-Have、Performance、Delighterにほぼ均等に分かれた、代表性のある400件の回答を得たとしても、上記の条件をすべて満たしながら、結論は出せないままです。勝者となるカテゴリだけでなく、機能ごとの分布を報告してください。明確に優勢なカテゴリがない場合は、その機能をAmbiguousに分類し、何があれば判断できるかを記載してください。安定しない最多カテゴリはロードマップの判断材料にならず、サンプルサイズにかかわらず、それを「検証済み」と呼ぶのは適切ではありません。

スキル間の連携

• このスキルの出力の用途：今後のロードマップの優先順位付けスキル（未提供。順位付け後に順序を決定）、deliver-launch-checklist（Must-Have項目をリリース基準にする）、スプリント計画ワークフロー
• このスキルへの入力元となることが多いもの：develop-solution-brief、define-opportunity-tree、define-hypothesis、discover-interview-synthesis
• 敵対的レビュー：utility-pm-critic（前提とした入力、フレームワークの適用可能性、乖離の説明に異議を唱える）

出力形式

出力の構成には references/TEMPLATE.md のテンプレートを使用してください。複数のフレームワークを使った完全な実行例については、references/EXAMPLE.md を参照してください。

品質チェックリスト

最終決定の前に、以下を確認してください。

• 3 つ以上の候補項目と、明示された意思決定の背景がある
• 適用性フィルターの概要に、実施したフレームワークと、除外したフレームワークおよびその理由が記載されている
• 適用可能なフレームワークをすべて実施している（複数が該当する場合に、1 つだけに絞っていない）
• すべてのスコアが、提示された入力情報または明示された仮定に基づいている（根拠のない捏造がない）
• フレームワーク間の比較で、異なる項目それぞれについて、差を生んだ要因となる評価軸を明示している
• 加重スコアリングを実施した場合、重み付けは任意の選択であることを明確に示している
• 顧客調査が提供されていない場合は、Kano を除外し、その理由を説明している
• Kano を調査ベースで実施した場合、各項目に根拠のレベルと主張の強さを示し、最有力のカテゴリだけでなく、機能ごとの回答分布を報告している
• Kano を推論ベースで実施した場合、分布の列は捏造した内訳ではなく not available (inferred) とし、各項目について、その判断を導いた定性的なシグナルと、そのシグナルを示した情報源の数を記載している
• Kano を実施した場合、分布に明確な最多カテゴリがない機能は、弱い過半数を根拠に分類するのではなく、解決に必要な情報とともに曖昧として記録している
• エグゼクティブサマリーに、推奨事項と次のステップが含まれている（単なる順位付けにとどまっていない）

相互参照

• テンプレート：references/TEMPLATE.md
• 例：references/EXAMPLE.md ＋ library/skill-output-samples/define-prioritization-framework/ 内のサンプル