prioritization-effort-impact

優先順位付け：労力と影響のマトリックス

目次

1. 目的
2. 使用する場面
3. これは何ですか？
4. ワークフロー
5. よくあるパターン
6. スコアリングのフレームワーク
7. ガードレール
8. クイックリファレンス

目的

労力（コスト／複雑さ）と影響（価値／メリット）の 2×2 マトリックス上に項目を配置することで、膨大なバックログや選択肢の一覧を、明確で実行可能な優先順位に変換します。クイックウィン（影響が大きく、労力が少ない項目）を特定し、大きな賭け（影響が大きく、労力も大きい項目）、時間の浪費（影響が小さく、労力が大きい項目）、隙間埋め（影響も労力も小さい項目）と区別します。

使用する場面

次のような場合にこのスキルを使用します：

• バックログの過多：機能、バグ、タスク、アイデアが 20 件以上あり、実行順を決める必要がある
• リソースの制約：時間、予算、人員が限られており、トレードオフの判断が必要である
• 戦略的な計画：四半期または年間ロードマップに向けて、施策、プロジェクト、投資のいずれかを選ぶ
• クイックウィンが必要：関係者が目に見える進捗を早く求めており、影響が大きく労力が少ない項目が必要である
• トレードオフの明確化：明示的に労力と影響を比較せずに、チームが「A と B のどちらをやるべきか」と議論している
• 認識のずれ：関係者（エンジニアリング、プロダクト、営業、経営陣）の優先順位が食い違っている
• コンテキストスイッチ：同時進行のプロジェクトが多すぎるため、最も重要なことに集中する必要がある
• 新任のプロダクトマネージャー／リーダー：バックログを引き継ぎ、体系的な優先順位付けのアプローチが必要である

よくあるきっかけ：

• 「機能リクエストが 50 件あります。どこから始めればよいですか？」
• 「クイックウィンは何ですか？」
• 「移行と新機能のどちらを先に進めるべきですか？」
• 「技術的負債と新機能の優先順位はどう付ければよいですか？」
• 「最小のコストで最大の効果が得られるのは何ですか？」

これは何ですか？

労力と影響のマトリックス（影響と労力のマトリックス、クイックウィンマトリックス、2×2 優先順位付けとも呼ばれます）では、各項目を次の 2 つの軸で評価します。

• X 軸：労力（時間、コスト、複雑さ、リスク、依存関係）
• Y 軸：影響（価値、収益、ユーザーへのメリット、戦略との整合性、リスクの低減）

4 つの象限：

High Impact │
            │  Big Bets       │  Quick Wins
            │  (do 2nd)       │  (do 1st!)
            │─────────────────┼─────────────
            │  Time Sinks     │  Fill-Ins
            │  (avoid)        │  (do last)
Low Impact  │
            └─────────────────┴─────────────
              High Effort       Low Effort

例： 12 項目の機能バックログ

項目	労力	影響	象限
「CSV にエクスポート」ボタンを追加	低（2 日）	高（多くのユーザー）	クイックウィン ✓
認証システム全体を再構築	高（3 か月）	高（セキュリティ）	大きな賭け
ロゴのピクセル単位の配置を完璧にする	高（1 週間）	低（見た目）	時間の浪費 ❌
フッターの誤字を修正	低（5 分）	低（些細）	隙間埋め

判断： まず「CSV にエクスポート」（クイックウィン）に取り組み、次に認証システムの再構築（大きな賭け）を予定し、ロゴの完璧化（時間の浪費）は見送り、誤字の修正（隙間埋め）はまとめて対応します。

ワークフロー

このチェックリストをコピーして、進捗を記録してください。

Prioritization Progress:
- [ ] Step 1: Gather items and clarify scoring
- [ ] Step 2: Score effort and impact
- [ ] Step 3: Plot matrix and identify quadrants
- [ ] Step 4: Create prioritized roadmap
- [ ] Step 5: Validate and communicate decisions

ステップ 1：項目を集め、スコアリングを明確にする

優先順位を付けるすべての項目（機能、バグ、取り組みなど）を集め、工数とインパクトのスコア尺度を定義します。工数とインパクトの定義については、スコアリングのフレームワークを参照してください。構成にはresources/template.mdを使用します。

ステップ 2：工数とインパクトを評価する

各項目の工数（1～5：ごくわずか～非常に大きい）とインパクト（1～5：無視できる～変革をもたらす）を評価します。正確さを高めるため、対象分野の専門家に協力してもらいます。フィボナッチ数列、Tシャツサイズ、RICE などの高度なスコアリング手法については、resources/methodology.mdを参照してください。

ステップ 3：マトリクスにプロットして象限を特定する

項目を 2x2 マトリクスに配置し、クイックウィン（インパクト大、工数小）、ビッグベット（インパクト大、工数大）、フィルイン（インパクト小、工数小）、タイムシンク（インパクト小、工数大）に分類します。一般的な象限の分布については、よくあるパターンを参照してください。

ステップ 4：優先順位を付けたロードマップを作成する

項目に順序を付けます。まずクイックウィン、次にビッグベット（クイックウィンで勢いをつけた後）、空き時間にフィルインを進め、必須でない限りタイムシンクは避けます。ロードマップの構成については、resources/template.mdを参照してください。

ステップ 5：判断を検証し、共有する

resources/evaluators/rubric_prioritization_effort_impact.jsonを使って自己チェックします。スコアリングに根拠があり、ステークホルダーの視点が含まれ、判断が理由とともに明確に説明されていることを確認します。

よくあるパターン

領域別：

• プロダクトバックログ：クイックウィン＝小規模な UX 改善、ビッグベット＝新しいワークフロー、タイムシンク＝エッジケースの完全な対応
• 技術的負債：クイックウィン＝設定の修正、ビッグベット＝アーキテクチャの刷新、タイムシンク＝時期尚早な最適化
• バグのトリアージ：クイックウィン＝インパクトが大きく簡単に修正できるバグ、ビッグベット＝複雑で重大なバグ、タイムシンク＝見た目上の問題
• 戦略的な取り組み：クイックウィン＝プロセスの調整、ビッグベット＝市場の拡大、タイムシンク＝見栄えだけの指標
• マーケティングキャンペーン：クイックウィン＝メールによる顧客育成、ビッグベット＝ブランドの刷新、タイムシンク＝小規模な A/B テスト

ステークホルダーの優先事項別：

• 経営幹部が求めるもの：クイックウィン（目に見える進展）＋ビッグベット（戦略的なインパクト）
• エンジニアリングチームが求めるもの：技術的負債のクイックウィン＋ビッグベット（プラットフォーム関連の作業）
• 営業チームが求めるもの：商談の障害を取り除くクイックウィン＋ビッグベット（主要な機能）
• 顧客が求めるもの：クイックウィン（課題の解消）＋ビッグベット（大きな変革をもたらす価値）

一般的な象限の分布：

• クイックウィン：10～20％（まれな、高価値の機会）
• ビッグベット：20～30％（戦略的で、リソースを多く必要とする項目）
• フィルイン：40～50％（ほとんどのバックログには、価値の低い項目が多数含まれます）
• タイムシンク：10～20％（意外によく見られ、「磨き込み」として紛れ込んでいることがよくあります）

注意すべき兆候：

• ❌ クイックウィンがない：工数を過大評価しているか、インパクトを過小評価している可能性があります
• ❌ すべてがクイックウィン：スコアが適切に調整されていない可能性があります
• ❌ タイムシンクが多い：範囲を縮小するか、これらの項目を却下してください
• ❌ 工数／インパクトのスコアがすべて 3：もっと差を付ける必要があります（1～2 と 4～5 を使ってください）

スコアリングのフレームワーク

労力の評価軸（関連するものを選択してください）：

• 時間：エンジニアリング／実行にかかる時間（1＝数時間、2＝数日、3＝数週間、4＝数か月、5＝四半期単位）
• 複雑さ：技術的な難易度（1＝ごく簡単、5＝前例のない新規性）
• リスク：失敗の可能性（1＝安全、5＝高リスク）
• 依存関係：外部要因による阻害（1＝なし、5＝複数のチーム／承認が必要）
• コスト：金銭的な投資（1＝$0-1K、2＝$1-10K、3＝$10-100K、4＝$100K-1M、5＝$1M+）

インパクトの評価軸（関連するものを選択してください）：

• 影響を受けるユーザー：対象範囲（1＝<1%、2＝1-10%、3＝10-50%、4＝50-90%、5＝>90%）
• ビジネス価値：収益／コスト削減（1＝$0-10K、2＝$10-100K、3＝$100K-1M、4＝$1-10M、5＝$10M+）
• 戦略との整合性：OKRへの貢献（1＝間接的、5＝戦略上、極めて重要）
• ユーザーの課題：問題の深刻度（1＝あると便利、5＝阻害要因／危機）
• リスク軽減：リスク対策の価値（1＝小さい、5＝存続に関わるリスク）

総合スコアの算出方法：

• シンプル：評価軸の平均（労力＝平均（時間、複雑さ）、インパクト＝平均（ユーザー、価値））
• 重み付け：重要度を乗じる（労力＝0.6×時間 + 0.4×複雑さ）
• フィボナッチ数列：1〜5の代わりに1、2、3、5、8を使い、差を指数的に表します
• Tシャツサイズ：S/M/L/XLを1/2/3/5に対応させます

スコアリングの例（機能：「ダークモードを追加」）：

• 労力：時間=3（2週間）、複雑さ=2（CSS）、リスク=2（軽微なバグ）、依存関係=1（阻害要因なし）→ 平均 = 2.0（低）
• インパクト：ユーザー=4（80%が希望）、価値=2（収益ではなく、継続率の向上）、戦略=3（デザインシステムの目標）、課題=3（眼精疲労）→ 平均 = 3.0（中〜高）
• 結果：インパクトは中〜高、労力は低 → すぐに取り組むべき成果！

ガードレール

品質を確保する：

1. 多様な視点を取り入れる：1人だけでスコアを付けないでください（エンジニアは労力を過大評価し、営業はインパクトを過大評価する傾向があります）

   • ✓ エンジニアリング、プロダクト、営業、カスタマーサクセスの意見を取り入れる
   • ❌ PMがすべてを1人で採点する

2. スコアに差をつける：すべてが3なら、優先順位を付けられていません

   • ✓ 順位を強制的に付けるか、幅広い尺度（1〜10）を使う
   • ✓ 分布の目安：1と5は少数、2と4はそれより多く、3は多数
   • ❌ すべての項目が2.5〜3.5

3. 極端なスコアを問い直す：インパクトが大きく労力が小さい項目はまれです（10個もあるなら、何かがおかしいです）

   • ✓ すぐに取り組むべき成果について、「なぜ今まで実施していないのか？」と問いかける
   • ❌ 希望的観測（労力を過小評価し、インパクトを過大評価する）

4. スコアリングを透明化する：各スコアを付けた理由を記録する

   • ✓ 「労力=4。3チームが必要で、新しいインフラが必要なうえ、期間が6週間かかるため」
   • ❌ 根拠を示さず「労力=4」とだけ記載する

5. スコアを定期的に見直す：状況の変化に応じて、労力やインパクトも変化します

   • ✓ 四半期ごと、または大きな変化（新技術の導入、チーム規模の変更）の後に再評価する
   • ❌ 2年前のスコアをそのまま使う

6. 依存関係を無視しない：労力の大きい前提条件によって阻まれている項目は、労力が小さくてもすぐに取り組める成果ではありません

   • ✓ 「タスクの労力=2。ただし、労力=5の移行作業に依存する」
   • ❌ タスクを単独で採点する

7. 「戦略的」という理由での上書きに注意する：幹部がすべてを「インパクト大」と呼ぶと、優先順位付けが機能しなくなります

   • ✓ 「戦略」は評価軸の1つであり、他の評価を覆すものではありません
   • ❌ 「CEOが望んでいる」→自動的に5と採点する

クイックリファレンス

リソース：

• クイックスタート：resources/template.md - 2×2 マトリックスのテンプレートとスコアリング表
• 高度な手法：resources/methodology.md - RICE、MoSCoW、Kano、重み付けスコアリング
• 品質チェック：resources/evaluators/rubric_prioritization_effort_impact.json - 評価基準

成功基準：

• ✓ すぐに実行するクイックウィンを1～3件特定している
• ✓ ビッグベットを現実的なロードマップに沿って順序付けている（過剰な約束をしない）
• ✓ 時間を浪費する項目（ROI の低い項目）を削除または延期している
• ✓ スコアリングの根拠が透明で、納得できる
• ✓ 関係者間で優先順位について合意している
• ✓ ロードマップに余力を確保している（時間の100％を予定で埋めない）

よくある間違い：

• ❌ 個別にスコアリングする（関係者の意見を取り入れない）
• ❌ 工数を無視する（楽観バイアス：「どれも簡単」）
• ❌ インパクトを無視する（価値のあるものではなく、簡単なものを作る）
• ❌ 分析麻痺（十分な優先順位付けではなく、完璧なスコアを求める）
• ❌ 時間を浪費する項目に「ノー」と言わない
• ❌ ロードマップに詰め込みすぎる（毎週をビッグベットで埋める）
• ❌ メンテナンスやサポートの時間を忘れる（プロジェクトに使える時間が100％だと想定する）

代替手法を使う場面：

• 重み付けスコアリング（RICE）：2×2よりも細かな評価が必要な場合（リーチ × インパクト × 確信度 ÷ 工数）
• MoSCoW：スコープや期限が固定されている場合に優先順位を付けるとき（Must／Should／Could／Won't）
• Kano モデル：顧客満足度を評価するとき（基本機能／性能機能／魅力的機能）
• ICE スコア：RICE よりシンプルな手法（インパクト × 確信度 × 容易さ）
• 価値対複雑さ：工数対インパクトと同じ手法で、ラベルが異なるだけ
• 遅延コスト：タイミングが重要な場合（延期によって失われる収益）