| name | analyzing-requirements |
| description | ユーザー要件を分析し、システム設計ドキュメント(DESIGN.md)を生成します。ユーザー要件が曖昧または不明確な場合、システムアーキテクチャの設計が必要な場合、大規模な機能開発の設計仕様が必要な場合、技術的実現可能性の検証が必要な場合に使用します。不明点はAskUserQuestionツールで確認します。 |
要件分析
概要
曖昧なユーザーリクエストを具体的で実行可能な設計仕様に変換する。要件を深く理解し、技術的実現可能性を検証し、アーキテクチャを設計し、開発者が従える詳細な設計ドキュメント(DESIGN.md)を生成する。
注: タスク分解とTODO.md生成は planning-tasks スキルで行う
コアワークフロー
ステップ0: MUSTルールの確認（必須）
分析を開始する前に、../shared/references/must-rules.mdのすべてのMUSTルールを確認する：
- テスト駆動開発（TDD）は必須
- Tidy Firstアプローチは必須
- 不確実性への対処は必須
- バックグラウンドプロセス管理は必須
- ドキュメント検索は必須
- コミット規律は必須
すべてのタスク分解はこれらのルールに準拠する必要がある。
ステップ1: 要件の理解と分析
ユーザーリクエストを複数の観点から分析する：
何を構築するか（What）
- コア機能の特定
- 機能スコープの定義
- ユーザーインターフェース要件
目的と価値（Why）
使用パターン（How）
- ユーザーインタラクションフロー
- 統合ポイント
- パフォーマンス要件
タイムライン（When）
- 納品期待値
- マイルストーン計画
- 依存関係のタイミング
対象ユーザー（Who）
- ユーザーペルソナ
- アクセスパターン
- スキルレベルの考慮
ステップ2: 不確実性の解消
必須: 決して仮定を立てない
利用可能なツールを使用して既存の実装を調査する：
Grep(pattern="relevant-keyword")
Read(file_path="related-file")
Glob(pattern="**/*.{js,ts,py}")
情報が不足している場合、AskUserQuestionツールを使用してユーザーに確認する：
AskUserQuestion({
questions: [
{
question: "この機能の認証方式はどれを使用しますか？",
header: "認証方式",
options: [
{
label: "JWT",
description: "JSON Web Tokenを使用したステートレス認証"
},
{
label: "Session",
description: "サーバーサイドセッション管理"
},
{
label: "OAuth 2.0",
description: "外部認証プロバイダーとの連携"
}
],
multiSelect: false
}
]
})
不明点が複数ある場合は、一度に複数の質問（最大4つ）を行うことができる
質問がなくなるまで繰り返して確認する
ステップ3: 要件定義の作成
要件を明確に構造化する：
機能要件
- 必須機能（MUST have）
- オプション機能（NICE to have）
- 将来の拡張性の考慮
非機能要件
- パフォーマンス目標
- セキュリティ要件
- 保守性基準
- スケーラビリティニーズ
制約
- 技術的制約（言語、フレームワーク、依存関係）
- 時間的制約（締め切り、マイルストーン）
- リソース制約（チームサイズ、インフラ）
ステップ4: アーキテクチャ設計
システム全体の構成と技術選定を行う：
システム構成
- コンポーネント構成と責務分担
- レイヤーアーキテクチャ（プレゼンテーション層、ビジネスロジック層、データアクセス層）
- モジュール間の依存関係
- 通信プロトコルとインターフェース
技術選定
- プログラミング言語とフレームワーク
- データベース選定（RDBMS、NoSQL、キャッシュ）
- 外部サービス連携（認証、決済、通知など）
- インフラストラクチャ（クラウド、コンテナ、CI/CD）
データ設計
- データモデル定義
- エンティティ関係図（ER図）
- データフロー図
- API設計（エンドポイント、リクエスト/レスポンス仕様）
非機能要件の設計
- セキュリティ対策（認証、認可、暗号化、脆弱性対策）
- パフォーマンス最適化（キャッシング、クエリ最適化、非同期処理）
- スケーラビリティ（負荷分散、水平スケール、垂直スケール）
- 可用性と信頼性（冗長化、バックアップ、障害復旧）
エラー戦略
- エラー分類（回復可能/不可能、ユーザー起因/システム起因）
- エラーハンドリング方針（例外処理、Result型、エラーコード）
- リトライポリシー（回数、間隔、バックオフ戦略）
- フォールバック処理（代替動作、グレースフルデグラデーション）
- エラーログ・通知（ログレベル、アラート条件）
テスト戦略
- テストピラミッド（単体/統合/E2Eの比率と範囲）
- カバレッジ目標（ライン、ブランチ、重要パスの基準）
- テストデータ戦略（フィクスチャ、ファクトリ、シード）
- モック/スタブ方針（外部依存の扱い）
- CI統合（テスト実行タイミング、失敗時の動作）
ステップ5: ドキュメント生成
設計ドキュメント(DESIGN.md)を生成する：
docs/DESIGN.md
# [プロジェクト名] 設計ドキュメント
生成日: [日付]
ジェネレーター: analyzing-requirements
## システム概要
[システムの目的、解決する問題、ビジネス価値、対象ユーザー]
## 機能要件
### 必須機能（MUST have）
- [機能1の説明]
- [機能2の説明]
### オプション機能（NICE to have）
- [機能3の説明]
## 非機能要件
### パフォーマンス要件
- レスポンスタイム: [具体的な数値]
- スループット: [具体的な数値]
- 同時接続数: [具体的な数値]
### セキュリティ要件
- 認証方式: [JWT、Session、OAuth等]
- 認可方式: [RBAC、ABAC等]
- データ暗号化: [保存時、転送時]
- 脆弱性対策: [XSS、CSRF、SQLインジェクション等]
### 可用性・信頼性
- 稼働率目標: [99.9%等]
- バックアップ戦略: [方式と頻度]
- 障害復旧時間: [RTO、RPO]
## アーキテクチャ設計
### システム構成
[コンポーネント図、レイヤーアーキテクチャの説明]
### 技術スタック
- **フロントエンド**: [React、Vue.js等]
- **バックエンド**: [Node.js、Go、Python等]
- **データベース**: [PostgreSQL、MongoDB等]
- **インフラ**: [AWS、GCP、Azure等]
- **その他**: [Redis、RabbitMQ等]
### モジュール構成
[各モジュールの責務と依存関係]
## データ設計
### エンティティ定義
User
- id: UUID (PK)
- email: String (unique)
- name: String
- created_at: Timestamp
[他のエンティティ...]
### データフロー
[データの流れを図で示す、または文章で説明]
## API設計
### エンドポイント一覧
POST /api/auth/login - ログイン
GET /api/users/:id - ユーザー情報取得
PUT /api/users/:id - ユーザー情報更新
[他のエンドポイント...]
### リクエスト/レスポンス例
```json
// POST /api/auth/login
Request:
{
"email": "user@example.com",
"password": "secret"
}
Response:
{
"token": "jwt-token",
"user": { ... }
}
セキュリティ設計
認証・認可フロー
[認証プロセスの詳細]
セキュリティ対策
- 入力検証: [方式と実装方法]
- XSS対策: [エスケープ処理等]
- CSRF対策: [トークン方式等]
- SQLインジェクション対策: [パラメータ化クエリ等]
パフォーマンス設計
最適化戦略
- キャッシング: [Redis、CDN等の利用]
- 非同期処理: [メッセージキュー等の利用]
- データベース最適化: [インデックス、クエリ最適化]
スケーラビリティ
- 水平スケール: [ロードバランサー、レプリケーション]
- 垂直スケール: [リソース増強の計画]
開発・運用
開発環境
[開発に必要な環境とセットアップ手順]
CI/CDパイプライン
[ビルド、テスト、デプロイの自動化]
モニタリング・ロギング
[監視項目とログ収集方法]
エラー戦略
エラー分類
- 回復可能エラー: [リトライで解決可能なエラー]
- 回復不可能エラー: [即座に失敗させるエラー]
エラーハンドリング方針
- ハンドリング方式: [例外処理、Result型、エラーコード等]
- リトライポリシー: [回数、間隔、バックオフ戦略]
- フォールバック: [代替動作、グレースフルデグラデーション]
エラーログ・通知
- ログレベル: [ERROR、WARN、INFO等の基準]
- アラート条件: [通知が必要なエラーの条件]
テスト戦略
テストピラミッド
- 単体テスト: [対象範囲、カバレッジ目標]
- 統合テスト: [対象範囲、実行タイミング]
- E2Eテスト: [対象範囲、実行環境]
テストデータ
- データ戦略: [フィクスチャ、ファクトリ、シード]
- モック/スタブ方針: [外部依存の扱い]
CI統合
- 実行タイミング: [PR時、マージ時、定期実行等]
- 失敗時の動作: [ブロック、通知等]
制約と前提
技術的制約
ビジネス制約
依存関係
参照
- タスク分解: planning-tasks スキルでTODO.mdを生成
- 関連ドキュメント: [リンク]
### ステップ6: ファイル出力
設計ドキュメントを書き出す：
```javascript
// docsディレクトリにDESIGN.mdを出力
Write(
file_path="docs/DESIGN.md",
content=designContent
)
ステップ7: セルフレビュー
生成したDESIGN.mdをセルフレビューし、問題がなくなるまで修正を繰り返す。
レビュー観点
- 完全性: すべての要件がカバーされているか
- 一貫性: 用語・表記・設計方針が統一されているか
- 実現可能性: 技術的に実装可能な設計か
- 明確性: 曖昧な表現や不明確な箇所がないか
- 整合性: 各セクション間で矛盾がないか
レビュープロセス
1. DESIGN.mdを読み返す
2. 以下のチェックリストで問題を洗い出す
3. 問題があれば修正してファイルを更新
4. 問題がなくなるまで1-3を繰り返す（最大3回）
セルフレビューチェックリスト
要件の完全性
設計の明確性
実装への橋渡し
問題発見時の対応
問題を発見した場合：
- 問題箇所を特定
- 修正内容を決定
- DESIGN.mdを更新
- 再度レビューを実行
3回のレビューで解決しない問題がある場合は、AskUserQuestionツールでユーザーに確認する。
設計の原則
アーキテクチャの原則
- 疎結合: モジュール間の依存関係を最小限に
- 高凝集: 関連する機能を同じモジュールに
- 単一責任: 各モジュールは一つの責任のみを持つ
- オープン/クローズド: 拡張に開かれ、修正に閉じている
- 依存性逆転: 抽象に依存し、具象に依存しない
設計の品質基準
- 保守性: コードの理解しやすさ、変更のしやすさ
- テスタビリティ: テストの書きやすさ、実行しやすさ
- スケーラビリティ: 負荷増加への対応能力
- セキュリティ: 脆弱性への対策
- パフォーマンス: 応答速度とリソース効率
品質チェックリスト
設計完了前に確認：
関連スキル
- planning-tasks: DESIGN.md完成後、このスキルを使用してタスク分解とTODO.md生成を行う
