requirements-feasibility-check

star 86

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

skanehira By skanehira schedule Updated 2/21/2026
play_arrow Run Skill in Manus View GitHub

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

技術検証（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: 技術設計に進む場合
Install via CLI
npx skills add https://github.com/skanehira/dotfiles --skill requirements-feasibility-check
Repository Details
star Stars 86
call_split Forks 4
navigation Branch main
article Path SKILL.md
More from Creator
skanehira
skanehira Explore all skills →