skanehira/requirements-feasibility-check

技術検証（Feasibility Check）

概要

技術的な実現可能性を評価し、以下を生成する：

1. 技術リスク一覧
2. 検証項目と成功基準
3. PoC計画

ワークフロー

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

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

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

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

1.2 コンテキストの活用

ファイルが存在する場合:

• USECASES.md: 検証が必要な機能のフローを把握
• PRODUCT_SPEC.md: プロダクトの技術的制約を把握

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

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

遷移条件: フェーズ2へ

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

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

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

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

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

質問パターン:

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

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

不確実性の分類

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

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

フェーズ3: リスク評価

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

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

リスクマトリクス

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

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

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

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

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

検証項目テンプレート

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

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

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

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

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

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

フェーズ5: PoC計画

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

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: 技術選定の整理（オプション）

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

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

技術選定の観点

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

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

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

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

出力ファイル

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

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

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

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: 技術設計に進む場合