Requirements Triage

概要

このスキルは、カール・ウィーガーズの要求工学理論に基づく要求トリアージ手法を提供します。 複数の要望を体系的に評価し、実装順序を決定するためのフレームワークです。

トリアージの評価軸

1. ビジネス価値（Business Value）

評価基準 (1-5点):

• 5点: プロジェクトの中核、これなしでは成立しない
• 4点: 大きな価値、ユーザー満足度に直結
• 3点: 中程度の価値、あると便利
• 2点: 限定的な価値、一部のユーザーのみ
• 1点: ほとんど価値がない

具体的な評価指標:

• ROI（投資対効果）: 開発コストに対する期待収益
• 顧客満足度への影響: ユーザーエクスペリエンスの向上度
• 競争優位性: 競合に対する差別化要素
• ビジネス目標への貢献度: 戦略目標との整合性

評価質問:

• この要件がなかった場合、プロジェクトの成功に影響するか？
• ユーザーがこの機能を使う頻度は？
• この機能により、どの程度の収益/コスト削減が期待できるか？

2. 実現可能性（Feasibility）

評価基準 (1-5点):

• 5点: 既存技術で容易に実装可能
• 4点: 一部調査が必要だが実装可能
• 3点: 技術的チャレンジあり、リスク中程度
• 2点: 高度な技術、大規模な調査が必要
• 1点: 現時点では実現困難、新技術の開発が必要

具体的な評価指標:

• 技術的難易度: 使用技術の習熟度、新規性
• リソース要件: 必要な人員、時間、予算
• 既存システムとの親和性: 統合の容易さ、影響範囲
• 外部依存: サードパーティAPI、外部サービスへの依存度

評価質問:

• チームはこの技術に精通しているか？
• 実装に必要な工数はどの程度か？
• 外部システムへの依存はあるか？
• 既存アーキテクチャに適合するか？

3. リスク（Risk）

評価基準 (1-5点):

• 5点: 重大リスク、失敗時の影響が極めて大きい
• 4点: 高リスク、失敗時の影響が大きい
• 3点: 中程度のリスク、対応可能
• 2点: 低リスク、影響は限定的
• 1点: リスクなし、安全に実装可能

具体的な評価指標:

• 技術的不確実性: 未知の要素、検証が必要な仮説
• 失敗時の影響: システム全体への影響、ビジネスへの影響
• 複雑性: 依存関係の数、コンポーネント間の結合度
• 変更の頻度: 要件が変わる可能性

評価質問:

• この要件の実装に不確実性はあるか？
• 失敗した場合、どのような影響があるか？
• この要件は他の要件に依存しているか？
• 将来的に変更される可能性は高いか？

4. コスト（Cost）

評価基準 (1-5点):

• 5点: 極めて高コスト（6ヶ月以上）
• 4点: 高コスト（3-6ヶ月）
• 3点: 中コスト（1-3ヶ月）
• 2点: 低コスト（1-4週間）
• 1点: 極めて低コスト（1週間未満）

具体的な評価指標:

• 開発工数: 設計、実装、テストの合計時間
• 保守コスト: 運用後のメンテナンス負荷
• 技術的負債: 将来的なリファクタリングコスト
• インフラコスト: サーバー、外部サービスの利用料

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

MoSCoW分類

Must have（必須）:

• システムの核心機能
• これがなければプロジェクトは成立しない
• ビジネス価値が極めて高い
• 法的要件、コンプライアンス要件

判断基準:

• ビジネス価値が4点以上
• この機能なしではシステムが機能しない
• 法的義務、契約上の義務がある
• 顧客との合意事項である

Should have（重要）:

• ビジネス価値は高いが、必須ではない
• 短期的には回避策がある
• ユーザーエクスペリエンスを大きく向上させる

判断基準:

• ビジネス価値が3点以上
• 一時的な回避策が存在する
• ユーザー満足度に大きく貢献する

Could have（望ましい）:

• あれば便利だが、なくても問題ない
• リソースに余裕があれば実装
• 将来のバージョンで実装を検討

判断基準:

• ビジネス価値が2点以下
• 一部のユーザーのみが利用
• 実装コストが高い

Won't have（対象外）:

• 今回のスコープには含めない
• 将来のバージョンで再検討
• 技術的制約、リソース制約により実装不可

判断基準:

• ビジネス価値が1点以下
• 実現可能性が低い（2点以下）
• リスクが高い（4点以上）
• プロジェクトのスコープ外

スコアリング手法

計算式:

優先度スコア = (ビジネス価値 × 3) + (実現可能性 × 2) - (リスク × 2) - (コスト × 1)

最大スコア: (5 × 3) + (5 × 2) - (1 × 2) - (1 × 1) = 22点
最小スコア: (1 × 3) + (1 × 2) - (5 × 2) - (5 × 1) = -10点

スコアに基づく分類:

スコア範囲         → MoSCoW分類
├─ 15-22点         → Must have（最優先、早期実装）
├─ 8-14点          → Should have（重要、計画的に実装）
├─ 1-7点           → Could have（余裕があれば実装）
└─ 0点以下         → Won't have（今回は対象外）

依存関係の考慮

依存関係の種類:

1. 必須依存（Mandatory Dependency）:

   • 要件Bを実装するには、要件Aが完了している必要がある
   • 例: ユーザー認証 → ユーザープロファイル編集

2. オプション依存（Optional Dependency）:

   • 要件Aがあると要件Bの実装が容易になる
   • 例: 基本検索 → 高度なフィルタリング

3. 相互排他（Mutually Exclusive）:

   • 要件Aと要件Bは同時に実装できない
   • 例: シングルテナント設計 vs マルチテナント設計

依存関係の記録方法:

| 要件ID | 優先度      | 依存   | 依存理由                   |
| ------ | ----------- | ------ | -------------------------- |
| FR-002 | Must have   | FR-001 | FR-001の認証機能が前提     |
| FR-005 | Should have | FR-003 | FR-003のデータがあれば容易 |

実装順序の決定:

1. 依存関係グラフを作成
2. トポロジカルソートで実装順序を決定
3. 循環依存がある場合は設計を見直す

トリアージのワークフロー

ステップ1: 要求の収集と記録

実行内容:

1. すべての要望を一覧化
2. 各要望に仮のIDを付与
3. 要望の出所を記録（ステークホルダー、優先度の初期値）

成果物:

| 仮ID    | 要望             | 提案者 | 初期優先度 |
| ------- | ---------------- | ------ | ---------- |
| REQ-001 | ユーザー登録機能 | PM     | 高         |
| REQ-002 | ダッシュボード   | CTO    | 中         |

ステップ2: 評価軸での採点

実行内容:

1. 各要求を4つの評価軸で採点（1-5点）
2. 採点理由を簡潔に記録
3. 不明点はステークホルダーに確認

成果物:

| ID      | ビジネス価値 | 実現可能性 | リスク | コスト | 採点理由                     |
| ------- | ------------ | ---------- | ------ | ------ | ---------------------------- |
| REQ-001 | 5            | 4          | 2      | 3      | 核心機能、技術的には標準的   |
| REQ-002 | 3            | 3          | 3      | 4      | 便利だが必須ではない、工数大 |

ステップ3: スコア計算とMoSCoW分類

実行内容:

1. スコアリング計算式で優先度スコアを算出
2. スコア範囲に基づきMoSCoW分類を決定
3. 依存関係を考慮して調整

成果物:

| ID      | 優先度スコア | MoSCoW分類 | 依存    |
| ------- | ------------ | ---------- | ------- |
| REQ-001 | 18           | Must have  | -       |
| REQ-002 | 7            | Could have | REQ-001 |

ステップ4: レビューと調整

実行内容:

1. ステークホルダーとスコアをレビュー
2. ビジネス判断による調整を反映
3. Must haveの数が適切か確認（全体の30-40%推奨）

判断基準:

• Must haveが多すぎないか（>50%は要注意）
• 依存関係が考慮されているか
• ステークホルダー間で合意されているか

ステップ5: 実装計画への落とし込み

実行内容:

1. Must haveをMVP（Minimum Viable Product）として定義
2. Should haveを次期リリース候補として計画
3. Could haveをバックログに追加

成果物:

## MVP（フェーズ1）

- REQ-001: ユーザー登録機能
- REQ-003: 基本的なダッシュボード

## 次期リリース（フェーズ2）

- REQ-002: 高度なダッシュボード
- REQ-004: レポート機能

## バックログ

- REQ-005: 多言語対応
- REQ-006: ダークモード

実践例

例1: ECサイトの要件トリアージ

要求一覧:

1. 商品検索機能
2. カート機能
3. 決済機能
4. レコメンデーション機能
5. レビュー機能
6. ウィッシュリスト機能

評価とスコアリング:

要求	ビジネス価値	実現可能性	リスク	コスト	スコア	分類
商品検索	5	5	1	2	19	Must have
カート	5	5	1	2	19	Must have
決済	5	3	4	4	8	Should have
レコメンド	3	2	3	5	3	Could have
レビュー	3	4	2	3	10	Should have
ウィッシュリスト	2	5	1	2	10	Should have

実装計画:

• MVP: 商品検索、カート（決済は外部サービスで簡易実装）
• フェーズ2: 決済機能の本格実装、レビュー機能
• フェーズ3: ウィッシュリスト、レコメンデーション

例2: SaaSダッシュボードの要件トリアージ

要求一覧:

1. ユーザー認証
2. ダッシュボード表示
3. データエクスポート
4. リアルタイム通知
5. カスタムレポート
6. マルチテナント対応

依存関係:

• ダッシュボード表示 → ユーザー認証（必須）
• データエクスポート → ダッシュボード表示（必須）
• カスタムレポート → データエクスポート（オプション）

評価とスコアリング:

要求	ビジネス価値	実現可能性	リスク	コスト	スコア	分類	依存
ユーザー認証	5	4	2	3	17	Must have	-
ダッシュボード	5	4	2	3	17	Must have	認証
データエクスポート	4	5	1	2	17	Must have	ダッシュボード
リアルタイム通知	3	3	3	4	7	Could have	-
カスタムレポート	3	2	3	5	3	Could have	エクスポート
マルチテナント	4	2	5	5	1	Won't have	-

実装順序（依存関係考慮）:

1. ユーザー認証（依存なし、Must have）
2. ダッシュボード表示（認証に依存、Must have）
3. データエクスポート（ダッシュボードに依存、Must have）
4. リアルタイム通知（依存なし、Could have）
5. カスタムレポート（エクスポートに依存、Could have）
6. マルチテナント（大規模な設計変更、Won't have）

品質チェックリスト

トリアージ完了前に以下を確認:

評価の妥当性:

• すべての要求が4つの評価軸で採点されているか？
• 採点理由が記録されているか？
• 不明点がすべて解決されているか？

分類の適切性:

• Must haveの数は適切か（全体の30-40%推奨）？
• Must haveはすべてシステムの核心機能か？
• Won't haveの理由が明確か？

依存関係の明確性:

• 依存関係がすべて特定されているか？
• 循環依存はないか？
• 実装順序が依存関係を考慮しているか？

ステークホルダーの合意:

• 優先順位付けがレビューされているか？
• ステークホルダー間で合意されているか？
• ビジネス判断による調整が反映されているか？

関連スキル

このスキルは以下のスキルと連携します:

• .claude/skills/ambiguity-elimination/SKILL.md: トリアージ前に要求を明確化
• .claude/skills/functional-non-functional-requirements/SKILL.md: 要求の分類後にトリアージ
• .claude/skills/acceptance-criteria-writing/SKILL.md: 優先度決定後に受け入れ基準を定義

参考文献

• Karl Wiegers『Software Requirements』: 要求の優先順位付け手法
• Alistair Cockburn『Writing Effective Use Cases』: MoSCoW分類の実践
• Dean Leffingwell『Agile Software Requirements』: アジャイル環境でのトリアージ