Feasibility Check

---
name: feasibility-check
description: 技術的な実現可能性を検証し、PoCの計画を立てる。ユースケース記述後、DDDモデリングや本格実装の前に技術リスクを洗い出す場合に使用。「技術的に実現できるか確認したい」「PoCを計画したい」「技術リスクを洗い出したい」「不確実性を検証したい」などのリクエストで起動。
---

# 技術検証（Feasibility Check）

## 概要

技術的な実現可能性を評価し、以下を生成する：
1. 技術リスク一覧
2. 検証項目と成功基準
3. PoC計画

## ワークフロー

### フェーズ1: コンテキストの確認

対象機能と既存ドキュメントを確認する。

#### 1.1 前提ドキュメントの読み込み

```javascript
Read({ file_path: "docs/USECASES.md" })
Read({ file_path: "docs/PRODUCT_SPEC.md" })
```

#### 1.2 コンテキストの活用

**ファイルが存在する場合**:
- USECASES.md: 検証が必要な機能のフローを把握
- PRODUCT_SPEC.md: プロダクトの技術的制約を把握

これらの情報を元に、技術リスクを効率的に洗い出す。

```javascript
AskUserQuestion({
  questions: [
    {
      question: "どの機能/ユースケースの技術検証を行いますか？",
      header: "対象機能",
      options: [
        { label: "機能を選択", description: "読み込んだユースケースから選択" }
      ],
      multiSelect: true
    }
  ]
})
```

**遷移条件**: フェーズ2へ

**ファイルが存在しない場合**:
AskUserQuestionで対象機能を確認。

```javascript
AskUserQuestion({
  questions: [
    {
      question: "どの機能の技術検証を行いますか？",
      header: "対象機能",
      options: [
        { label: "機能を入力", description: "技術検証が必要な機能や領域" }
      ],
      multiSelect: false
    }
  ]
})
```

**遷移条件**: 対象機能が明確になったらフェーズ2へ

### フェーズ2: 技術的不確実性の洗い出し

実現可能かどうか分からない技術要素を特定する。

**質問パターン**:
- 「この機能で技術的に不安な部分は？」
- 「やったことがない技術はありますか？」
- 「パフォーマンス的に問題になりそうな箇所は？」
- 「外部サービスとの連携で不明点は？」

```javascript
AskUserQuestion({
  questions: [
    {
      question: "この機能を実現する上で、技術的に不確実な点、不安な点は何ですか？",
      header: "不確実性",
      options: [
        { label: "不確実な点を入力", description: "例: 大量データの処理性能、API連携の可否" }
      ],
      multiSelect: false
    }
  ]
})
```

#### 不確実性の分類

| 種類 | 説明 | 例 |
|------|------|-----|
| **技術的実現性** | そもそもできるか | LLMでSQL改善が可能か |
| **パフォーマンス** | 速度・スケール | 1秒以内に応答できるか |
| **統合** | 外部サービス連携 | DBへの接続方法 |
| **セキュリティ** | 安全性の確保 | 認証情報の扱い |
| **コスト** | 費用対効果 | API利用料金 |

**遷移条件**: 不確実な点が3-5個特定できたらフェーズ3へ

### フェーズ3: リスク評価

各不確実性のリスクレベルを評価する。

```javascript
AskUserQuestion({
  questions: [
    {
      question: "[不確実性]について、実現できなかった場合の影響度は？",
      header: "影響度",
      options: [
        { label: "致命的", description: "プロダクトが成り立たない" },
        { label: "重大", description: "主要機能が使えない" },
        { label: "中程度", description: "代替手段がある" },
        { label: "軽微", description: "なくても問題ない" }
      ],
      multiSelect: false
    }
  ]
})
```

#### リスクマトリクス

| 影響度＼発生確率 | 高 | 中 | 低 |
|-----------------|-----|-----|-----|
| **致命的** | 🔴 最優先 | 🔴 最優先 | 🟡 優先 |
| **重大** | 🔴 最優先 | 🟡 優先 | 🟢 通常 |
| **中程度** | 🟡 優先 | 🟢 通常 | 🟢 通常 |
| **軽微** | 🟢 通常 | ⚪ 低 | ⚪ 低 |

**遷移条件**: リスク評価が完了したらフェーズ4へ

### フェーズ4: 検証項目の定義

各リスクに対する検証項目を定義する。

```javascript
AskUserQuestion({
  questions: [
    {
      question: "[リスク]を検証するために、何を確認すればよいですか？",
      header: "検証項目",
      options: [
        { label: "検証項目を入力", description: "例: レスポンス時間を計測する" }
      ],
      multiSelect: false
    },
    {
      question: "成功と判断する基準は何ですか？",
      header: "成功基準",
      options: [
        { label: "基準を入力", description: "例: 95%タイルで1秒以内" }
      ],
      multiSelect: false
    }
  ]
})
```

#### 検証項目テンプレート

```
## 検証項目: [項目名]

**対象リスク**: [リスクの説明]

**検証内容**:
- 何を検証するか
- どのように検証するか

**成功基準**:
- 定量的な基準（数値）
- 定性的な基準（状態）

**失敗した場合の代替案**:
- プランB
- スコープ縮小案
```

**遷移条件**: 主要リスクの検証項目が定義できたらフェーズ5へ

### フェーズ5: PoC計画

検証のための実装計画を立てる。

```javascript
AskUserQuestion({
  questions: [
    {
      question: "PoCの優先順位をつけてください。最もリスクが高いものから検証すべきです。",
      header: "優先順位",
      options: [
        { label: "優先順位を入力", description: "1. xxx 2. xxx" }
      ],
      multiSelect: false
    }
  ]
})
```

#### PoC計画テンプレート

```
## PoC: [名前]

**目的**: 何を検証するか

**スコープ**:
- 含むもの
- 含まないもの

**実装内容**:
1. ステップ1
2. ステップ2
3. ステップ3

**必要なリソース**:
- 技術: xxx
- 環境: xxx
- データ: xxx

**成功基準**:
- 基準1
- 基準2

**判断**:
- 成功 → 本実装へ
- 失敗 → 代替案を検討
```

**遷移条件**: PoC計画が完成したらフェーズ6へ

### フェーズ6: 技術選定の整理（オプション）

採用する技術スタックを整理する。

```javascript
AskUserQuestion({
  questions: [
    {
      question: "この機能の実装に使用する技術（言語、フレームワーク、サービス）は決まっていますか？",
      header: "技術スタック",
      options: [
        { label: "決まっている", description: "技術スタックを入力" },
        { label: "検討中", description: "候補を入力" },
        { label: "未定", description: "PoCで決める" }
      ],
      multiSelect: false
    }
  ]
})
```

#### 技術選定の観点

| 観点 | 質問 |
|------|------|
| **実績** | チームに経験はあるか |
| **成熟度** | 安定しているか |
| **コミュニティ** | サポートは得られるか |
| **コスト** | ライセンス、運用コストは |
| **将来性** | 長期的にメンテできるか |

**遷移条件**: 技術選定が整理できたらフェーズ7へ

### フェーズ7: ドキュメント生成

テンプレートは [references/feasibility-template.md](references/feasibility-template.md) を参照。

### 出力ファイル

```javascript
Write({
  file_path: "docs/FEASIBILITY.md",
  content: feasibilityContent
})
```

### フェーズ8: セルフレビュー（サブエージェント）

生成したドキュメントのレビューをサブエージェントに委譲する。

```javascript
Task({
  description: "技術検証レビュー",
  subagent_type: "general-purpose",
  prompt: `
以下の技術検証ドキュメントをレビューし、問題があれば修正してください。

## レビュー対象ファイル
- docs/FEASIBILITY.md

## レビュー観点

1. **不確実性の網羅性**: 技術的な不確実性が十分に洗い出されているか
2. **リスク評価の妥当性**: 影響度と発生確率の評価が適切か
3. **検証項目の具体性**: 何をどう検証するかが明確か
4. **成功基準の測定可能性**: 定量的で測定可能な基準か
5. **代替案の実現可能性**: 失敗時の代替案が現実的か
6. **PoC計画の実行可能性**: 必要なリソースと手順が明確か

## 出力形式

1. 発見した問題のリスト（問題がない場合は「問題なし」）
2. 各問題の修正内容
3. 修正後のファイル更新（Editツールで修正）

問題がなくなるまでレビューと修正を繰り返すこと。
`
})
```

## 完了条件

- [ ] 技術的不確実性が洗い出されている
- [ ] リスク評価が完了している
- [ ] 検証項目と成功基準が定義されている
- [ ] PoC計画が作成されている
- [ ] FEASIBILITY.mdが生成されている
- [ ] セルフレビューが完了し、問題が解消されている

## 関連スキル

- **usecase-description**: 技術検証の前にユースケースを整理する場合
- **ddd-modeling**: 技術検証後、ドメインモデリングに進む場合
- **analyzing-requirements**: 技術設計に進む場合