mcpField
F
feature-prioritisation

feature-prioritisation

github.com/mohitagw15856生産性1.5k49 回インストール5 日前に更新
リポジトリ

feature-prioritisation について

feature-prioritisation は、明確な目標に照らしてプロダクト機能に優先順位を付けるスキルです。RICE、MoSCoW、ICE、Kano などに対応し、RICE と ICE の計算用 Python スクリプトや、判断理由と前提の記録も備えています。

主な機能

  1. 01状況に応じたフレームワーク選択
  2. 02共通目標に基づく機能評価
  3. 03RICE、MoSCoW、ICE、Kano に対応
  4. 04Python による RICE と ICE の計算
  5. 05判断理由と前提の記録

活用シーン

  1. 01スプリントやリリースのバックログを順位付け
  2. 02RICE や ICE で施策を比較
  3. 03機能分類による関係者間の合意形成
  4. 04保留項目と評価前提の記録

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mohitagw15856/pm-claude-skills --skill feature-prioritisation

インストール後、Claude Code で/feature-prioritisationを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
framework-selection.md
worked-example.md
scripts/
feature_prioritisation.py
templates/
prioritisation-session.md

詳細

機能の優先順位付けスキル

適切な優先順位付けフレームワークをバックログに適用し、単に並べ替えたリストではなく、根拠を明確に説明できる順位を作成します。

必要な入力

次の情報が提供されていない場合は、ユーザーに尋ねてください。

  • 優先順位を付ける機能または取り組みのリスト
  • 優先順位付けの基準となる目標または指標（OKR、リリース、スプリント）
  • 希望するフレームワーク（または、以下の状況に応じて提案）
  • チームのデータ：リーチの見積もり、工数の見積もり、ベロシティ（RICE の場合）

フレームワーク選択ガイド

ユーザーに希望するフレームワークを尋ねるか、状況に応じて提案してください。

状況推奨フレームワーク
手早く、データに基づくスコアが必要RICE
ステークホルダーとの合意形成ミーティングMoSCoW
顧客の満足度と期待の関係を理解したいKano
初期段階のスタートアップで、迅速な意思決定が必要ICE
満たされていない顧客ニーズを特定したいオポチュニティスコアリング
戦略的なポートフォリオの意思決定価値対工数マトリクス

RICE スコアリング

計算式：（リーチ × インパクト × 確信度）÷ 工数

要素定義尺度
リーチ四半期あたりの影響を受けるユーザー数実数
インパクトユーザーごとの目標への影響0.25 / 0.5 / 1 / 2 / 3
確信度どの程度確信があるか50% / 80% / 100%
工数必要な人月実数

出力テーブル：

機能リーチインパクト確信度工数RICE スコア優先度

MoSCoW メソッド

各機能を次のいずれかに分類します。

  • Must Have（必須） — リリース／スプリントに不可欠で、これがないとプロダクトが成り立たない
  • Should Have（必要） — 重要だが不可欠ではなく、回避策がある
  • Could Have（あるとよい） — あれば望ましいが、時間がある場合にのみ含める
  • Won't Have (this time)（今回は対象外） — 今回は明示的にスコープ外とし、後で再検討する可能性がある

必ず「何に対して必須なのか？」と確認してください。分類する前に、スコープ（リリース、スプリント、四半期）を定義します。

ICE スコアリング（スタートアップ／迅速モード）

計算式： インパクト + 確信度 + 容易さ（それぞれ 1～10）

迅速で主観的な評価です。データがまだない初期段階の意思決定に適しています。

Kano モデル

機能を次のように分類します。

  • 基本（必須品質）： 期待される機能で、欠けていると不満が生じる
  • 性能： 機能が充実するほど満足度が上がる。線形の関係
  • 魅力（感動品質）： 予想外の機能で、感動を生み出す。なくても中立
  • 無関心： ユーザーは、あってもなくても気にしない
  • 逆品質： 求めるユーザーもいれば、望まないユーザーもいる

次の順に開発することを推奨します。まず基本機能をすべて実装し、次に主要なユースケース向けの性能機能を実装し、各リリースで魅力機能を 1～2 個実装します。

プログラムによる補助ツール

このスキルには、数学的なフレームワーク（RICE、ICE）で順位を計算する、標準ライブラリのみを使った Python スクリプトが付属しています。これにより、セッション間で機能のスコアリングを統一できます。

# RICE from JSON
python3 scripts/feature_prioritisation.py initiatives.json --framework rice

# RICE from CSV
python3 scripts/feature_prioritisation.py initiatives.csv --framework rice --format csv

# ICE from JSON
python3 scripts/feature_prioritisation.py features.json --framework ice

# Pipe into it
printf '%s\n' '[{"name":"API refactor","impact":8,"confidence":80,"ease":5}]' \
  | python3 scripts/feature_prioritisation.py --framework ice -

下流のツールで処理できる形式の出力を生成するには、--json を使用してください。

出力形式

機能の優先順位付け — [プロダクト／チーム] — [日付]

使用したフレームワーク： [RICE / MoSCoW / ICE / Kano / カスタム] スコープ： [スプリント / 四半期 / リリース] 優先順位付けの基準となる目標： [指標または目標]

[選択したフレームワークを使用したスコア付きテーブル]

推奨する開発順序：

  1. [機能] — [根拠を 1 行で説明]
  2. [機能] — [根拠を 1 行で説明]
  3. ...

優先度を明示的に下げた項目：

  • [機能] — 理由：[簡潔に記載]

前提：

  • [スコアリングで使用した見積もりや判断]

ガイドライン

  • 優先順位付けは必ず具体的な目標または指標に基づいて行い、何も基準のない状態で優先順位を付けないでください
  • スコアが近い一方で、リスクの特性が大きく異なる機能があれば指摘してください
  • ステークホルダー間の政治的な駆け引きが優先順位に影響している場合は、それを明示し、フレームワークのスコアと最終的な判断を分けるよう提案してください
  • 少なくとも 2 週間ごとに優先順位を見直すことを推奨してください
  • 根拠なしに順位だけを 1 列で並べたリストを出さないでください。上位 3 件と下位 3 件の判断理由を説明してください

詳細資料

このスキルにはサポートファイルが付属しています。利用できる場合は、これらを使用してください。

  • references/framework-selection.md — 優先順位付けフレームワークの選択（デフォルトでRICEを使うのではなく）。出力を作成する際に適用してください。上記の手法の概要で簡略化されている、調整や判断上の考慮事項が記載されています。
  • templates/prioritisation-session.md — 品質ゲートがインラインで示された、成果物の記入用テンプレートです。文書を自分で作成したいユーザーには、生成した文書ではなくこちらを提示してください。

スコアリング基準（0～40）

このスキルの出力は、引き渡す前に採点してください。32点以上がリリース品質です。

項目0510
目標との整合性目標が示されていない、または項目ごとに異なる目標に対して暗黙に採点されている目標は挙げられているが、個々のスコアは目標に言及していない。目標外の項目も採点されている指標と対象範囲が明確に示され、すべてのスコアがその根拠を説明している。異なる目標に関わる項目は除外し、再提出の指示がある
スコアリングの整合性1回のセッションで複数のフレームワークが混在している、計算が誤っている、または表の途中で尺度が独自に設定されている1つのフレームワークが一貫して適用されているが、信頼度が根拠なく高く、尺度の基準が定義されていない一貫したフレームワークが使われ、計算を検証できる。影響度の基準が定義され、各推定の根拠に照らして信頼度が正直に示されている
除外項目と前提の透明性除外項目が消えており、推定やその情報源の記録がない優先度を下げた項目は記載されているが、理由がなく、前提も一部しか示されていないか、情報源が記載されていないすべての除外項目に理由と再検討のきっかけがある。前提の情報源（分析データ、エンジニアリングの見積もりなど）が示され、順位付けを再現できる
数値を超えた判断並べ替えられた表がそのまま意思決定として提示されている上位候補の根拠は示されているが、僅差の項目、リスク特性、政治的圧力には触れていない僅差はリスクを考慮し、その理由を示して判断されている。政治的圧力が明示され、フレームワークのスコアと最終判断が区別されている。リストの上位と下位の両方について説明がある

品質チェック

  • すべての項目が同じ目標または指標に対して採点されている（項目ごとに異なる目標を使っていない）
  • 優先度を下げた項目が、理由とともに明示されている（順位付けリストから単に抜けているだけではない）
  • スコアリングに使用した前提が記録されている
  • ステークホルダー間の政治的な事情や個人の好みが、フレームワークのスコアと区別されている
  • 優先順位付けの対象範囲が明確に定められている（スプリント／四半期／ローンチ）

アンチパターン

  • 項目ごとに異なる目標に対して採点しないでください。優先順位付けセッションのすべての項目は、同じ目標に対して採点する必要があります
  • 優先度を下げた項目を省略しないでください。除外した項目とその理由を明示することは、順位付けリストと同じくらい重要です
  • ステークホルダー間の政治的な事情によってフレームワークのスコアを覆す場合は、理由とともにその判断を記録してください
  • 1回の優先順位付けで、RICE、ICE、MoSCoWのスコアを混在させないでください。優先順位付けの演習ごとに1つのフレームワークを選んでください
  • スコアリングに使った前提を記録せずに、出力を最終版として扱わないでください。前提は変わるため、リストを再検討できる状態にしておく必要があります

コメント

Markdown 対応