Collection

---
name: .claude/skills/requirements-triage/SKILL.md
description: |
  要求のトリアージと優先順位付けスキル。MoSCoW分類、リスク評価、実現可能性評価により、
  実装すべき要件を決定します。

  📚 リソース参照:
  このスキルには以下のリソースが含まれています。
  必要に応じて該当するリソースを参照してください:

  - `.claude/skills/requirements-triage/resources/moscow-framework.md`: MoSCoW分類の詳細ガイド（Must/Should/Could/Won't）とバランスガイドライン
  - `.claude/skills/requirements-triage/templates/triage-matrix.md`: 要件評価マトリクステンプレート（ビジネス価値、実現可能性、リスク、コスト）
  - `.claude/skills/requirements-triage/scripts/calculate-priority.mjs`: 優先度スコアを自動計算しMoSCoW分類を行うNode.jsスクリプト

  使用タイミング:
  - プロジェクト開始時の要求整理
  - 複数の要望がある場合の優先順位決定
  - リソース制約下での実装範囲の確定
  - 要件のリスク評価が必要な時

  Apply when: requirements prioritization, MoSCoW, risk assessment, feasibility evaluation
version: 1.0.0
---

# 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 マルチテナント設計

**依存関係の記録方法**:

```markdown
| 要件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. 要望の出所を記録（ステークホルダー、優先度の初期値）

**成果物**:

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

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

**実行内容**:

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

**成果物**:

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

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

**実行内容**:

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

**成果物**:

```markdown
| 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をバックログに追加

**成果物**:

```markdown
## 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』: アジャイル環境でのトリアージ