prioritization-effort-impact

優先順位付け：労力とインパクトのマトリクス

ワークフロー

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

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：マトリクスに配置し、象限を特定する

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

ステップ 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 よりシンプルな手法（インパクト × 確信度 × 容易さ）
• 価値対複雑さ：工数対インパクトと同じ手法で、ラベルが異なるだけ
• 遅延コスト：タイミングが重要な場合（延期によって失われる収益）