| name | feasibility-check |
| description | 技術的な実現可能性を検証し、PoCの計画を立てる。ユースケース記述後、DDDモデリングや本格実装の前に技術リスクを洗い出す場合に使用。「技術的に実現できるか確認したい」「PoCを計画したい」「技術リスクを洗い出したい」「不確実性を検証したい」などのリクエストで起動。 |
技術検証（Feasibility Check）
概要
技術的な実現可能性を評価し、以下を生成する：
- 技術リスク一覧
- 検証項目と成功基準
- 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ツールで修正）
問題がなくなるまでレビューと修正を繰り返すこと。
`
})
完了条件
関連スキル
- usecase-description: 技術検証の前にユースケースを整理する場合
- ddd-modeling: 技術検証後、ドメインモデリングに進む場合
- analyzing-requirements: 技術設計に進む場合
