mcpField
R
Requirements Prioritization

Requirements Prioritization

github.com/danhvb開発93 回インストール
リポジトリ

Requirements Prioritization について

バックログやリリース計画、関係者間の意見調整で要件を優先順位付けするためのスキルです。MoSCoW、RICE、Kano、WSJFの手法に加え、ワークショップの進め方も扱います。

主な機能

  1. 01MoSCoW、RICE、Kano、WSJFの手法
  2. 02要件を順位付けするワークショップ
  3. 03優先度の対立と依存関係への対処
  4. 04優先順位付きバックログとリリース計画の作成

活用シーン

  1. 01スプリントやリリースの作業を選定
  2. 02関係者間で異なる要望の優先度を調整
  3. 03MVPの範囲を決定

インストール

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

$npx skills add https://github.com/danhvb/my-ba-skills --skill requirements-prioritization

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

詳細

要件の優先順位付けスキル

目的

最も価値の高い機能を最初に提供できるよう、要件の優先順位を体系的に決定し、スコープとステークホルダーの期待を効果的に管理します。

使用する場面

  • プロダクトバックログの管理
  • リリースやスプリントの計画
  • ステークホルダー間のニーズの対立を解消する
  • 限られたリソースを割り当てる
  • MVP（実用最小限の製品）の定義

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

1. MoSCoW メソッド

最適な場面：期限が決まっている場合、スコープの調整

  • Must Have（M）：成功に不可欠です。妥協できません。実現できなければ、ローンチは失敗です。
  • Should Have（S）：重要ですが、不可欠ではありません。対応が難しくなりますが、回避策はあります。
  • Could Have（C）：あると望ましい機能です。含まれなくても影響は小さいです。
  • Won't Have（W）：今回のリリースには含めないことで合意した項目です（後で対応する可能性はあります）。

例：Eコマースのチェックアウト

  • Must：ゲストチェックアウト、クレジットカード決済。
  • Should：PayPal 連携、住所の自動入力。
  • Could：ギフト包装オプション、暗号資産決済。
  • Won't：音声操作によるチェックアウト（現時点では）。
2. RICE スコアリング

最適な場面：データに基づく意思決定、異なる種類の機能の比較

$$ RICE Score = \frac{Reach \times Impact \times Confidence}{Effort} $$

  • リーチ：期間あたりの人数／イベント数（例：月間 1000 ユーザー）。
  • インパクト：
    • 3（非常に大きい）
    • 2（大きい）
    • 1（中程度）
    • 0.5（小さい）
    • 0.25（ごくわずか）
  • 確信度：
    • 100%（高：データがある）
    • 80%（中：ある程度のデータ／直感がある）
    • 50%（低：根拠の薄い推測）
  • 工数：人月（例：2 か月）。
3. Kano モデル

最適な場面：顧客満足度の向上と差別化

  • 基本（当たり前品質）：必須の機能です。あれば顧客は特に意識せず、なければ不満を感じます（例：車のブレーキ）。
  • 性能（線形品質）：多いほど良い機能です（例：車の燃費）。
  • 魅力（魅力品質）：驚きを与える機能です。あれば顧客満足度が大きく上がり、なくても不満はありません（例：無料のサンルーフ）。
4. WSJF（加重最短ジョブファースト）

最適な場面：アジャイル／SAFe 環境、経済的なフローの最大化

$$ WSJF = \frac{Cost of Delay (CoD)}{Job Size (Duration)} $$

遅延コストの構成要素：

  1. ユーザー／ビジネス価値（ユーザー／ビジネスにとっての価値）
  2. 時間的緊急性（期限や価値の低下があるか）
  3. リスク低減／機会の実現（リスクを低減するか、将来の価値を引き出すか）

優先順位付けワークショップの進行

準備
  1. 要件のリストアップ：すべての要件を収集し、明確にします。
  2. ステークホルダーの招集：意思決定者、技術リード、事業責任者を招集します。
  3. 基準の定義：使用するフレームワークについて合意します（例：「MoSCoW を使用します」）。
進め方（例：機能を買う）
  1. ステークホルダーに「模擬通貨」の予算を渡します（例：100 ドル）。
  2. 工数／コストに基づいて、要件に「価格」を設定します。
  3. ステークホルダーに、必要な機能を「購入」してもらいます。
  4. 結果を話し合います。何が購入され、何が見送られたでしょうか？
進め方（例：100 点テスト）
  • 各ステークホルダーに 100 点を渡します。
  • 重要度に応じて、要件に点数を配分してもらいます。
  • 点数を合計し、グループの総意を確認します。

よくある課題と解決策

課題解決策
すべてが「Must」になる順位を強制的に付けます（1 から N）。限られた予算で「機能を買う」方法を使います。
HIPPO（最も高給な人物の意見）データに基づく手法（RICE）を使います。トレードオフを可視化します。
優先順位の対立ビジネス目標／KPI に立ち返ります。交渉を促進します。
依存関係の見落とし技術チームが確認し、依存関係の連鎖を特定する必要があります（B の前に A を完了する必要がある、など）。

ビジネス価値と技術的な必要性

  • ビジネス上の優先度：顧客／ビジネスに提供する価値。
  • 技術上の優先度：アーキテクチャ上のニーズ、依存関係、技術的負債の削減。
  • 最終的な優先度：ビジネス価値が高く、技術的リスクが管理されている項目から着手します。

成果物

  • 優先順位付け済みバックログ：要件を順序付けたリスト。
  • リリース計画：リリース 1、2、3 に含める項目。
  • スコープ除外リスト：実施しない項目を明示したリスト。

参考資料

  • Wiegers, K. & Beatty, J. (2013). ソフトウェア要件。
  • Intercom のプロダクトマネジメント（RICE）。
  • SAFe フレームワーク（WSJF）。

コメント

Markdown 対応