要件分析

概要

曖昧なユーザーリクエストを具体的で実行可能な設計仕様に変換する。要件を深く理解し、技術的実現可能性を検証し、アーキテクチャを設計し、開発者が従える詳細な設計ドキュメント(DESIGN.md)を生成する。

注: タスク分解とTODO.md生成は planning-tasks スキルで行う

コアワークフロー

ステップ0: MUSTルールの確認（必須）

分析を開始する前に、../shared/references/must-rules.mdのすべてのMUSTルールを確認する：

•テスト駆動開発（TDD）は必須
•Tidy Firstアプローチは必須
•不確実性への対処は必須
•バックグラウンドプロセス管理は必須
•ドキュメント検索は必須
•コミット規律は必須

すべてのタスク分解はこれらのルールに準拠する必要がある。

ステップ1: 要件の理解と分析

ユーザーリクエストを複数の観点から分析する：

何を構築するか（What）

•コア機能の特定
•機能スコープの定義
•ユーザーインターフェース要件

目的と価値（Why）

•ビジネス価値の分析
•解決する問題
•成功指標

使用パターン（How）

•ユーザーインタラクションフロー
•統合ポイント
•パフォーマンス要件

タイムライン（When）

•納品期待値
•マイルストーン計画
•依存関係のタイミング

対象ユーザー（Who）

•ユーザーペルソナ
•アクセスパターン
•スキルレベルの考慮

ステップ2: 不確実性の解消

必須: 決して仮定を立てない

利用可能なツールを使用して既存の実装を調査する：

bash

# 関連する実装を検索
Grep(pattern="relevant-keyword")
Read(file_path="related-file")
Glob(pattern="**/*.{js,ts,py}")

情報が不足している場合、AskUserQuestionツールを使用してユーザーに確認する：

javascript

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

markdown

# [プロジェクト名] 設計ドキュメント

生成日: [日付]
ジェネレーター: 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

[他のエンティティ...]

code


### データフロー
[データの流れを図で示す、または文章で説明]

## API設計
### エンドポイント一覧

POST /api/auth/login - ログイン GET /api/users/:id - ユーザー情報取得 PUT /api/users/:id - ユーザー情報更新 [他のエンドポイント...]

code


### リクエスト/レスポンス例
```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を生成
•関連ドキュメント: [リンク]

code


### ステップ6: ファイル出力

設計ドキュメントを書き出す：
```javascript
// docsディレクトリにDESIGN.mdを出力
Write(
    file_path="docs/DESIGN.md",
    content=designContent
)

ステップ7: セルフレビュー

生成したDESIGN.mdをセルフレビューし、問題がなくなるまで修正を繰り返す。

レビュー観点

•完全性: すべての要件がカバーされているか
•一貫性: 用語・表記・設計方針が統一されているか
•実現可能性: 技術的に実装可能な設計か
•明確性: 曖昧な表現や不明確な箇所がないか
•整合性: 各セクション間で矛盾がないか

レビュープロセス

code

1. DESIGN.mdを読み返す
2. 以下のチェックリストで問題を洗い出す
3. 問題があれば修正してファイルを更新
4. 問題がなくなるまで1-3を繰り返す（最大3回）

セルフレビューチェックリスト

要件の完全性

• 機能要件がすべて網羅されている
• 非機能要件が具体的な数値で定義されている
• エラー戦略とテスト戦略が定義されている

設計の明確性

• アーキテクチャ図または構成が理解しやすい
• データモデルとAPI設計が具体的
• 技術選定の理由が明記されている

実装への橋渡し

• planning-tasksスキルでタスク分解できる粒度になっている
• 開発者が迷わず実装を開始できる情報量がある
• 依存関係と制約が明確

問題発見時の対応

問題を発見した場合：

•問題箇所を特定
•修正内容を決定
•DESIGN.mdを更新
•再度レビューを実行

3回のレビューで解決しない問題がある場合は、AskUserQuestionツールでユーザーに確認する。

設計の原則

アーキテクチャの原則

•疎結合: モジュール間の依存関係を最小限に
•高凝集: 関連する機能を同じモジュールに
•単一責任: 各モジュールは一つの責任のみを持つ
•オープン/クローズド: 拡張に開かれ、修正に閉じている
•依存性逆転: 抽象に依存し、具象に依存しない

設計の品質基準

•保守性: コードの理解しやすさ、変更のしやすさ
•テスタビリティ: テストの書きやすさ、実行しやすさ
•スケーラビリティ: 負荷増加への対応能力
•セキュリティ: 脆弱性への対策
•パフォーマンス: 応答速度とリソース効率

品質チェックリスト

設計完了前に確認：

要件分析

概要

コアワークフロー

ステップ0: MUSTルールの確認（必須）

ステップ1: 要件の理解と分析

ステップ2: 不確実性の解消

ステップ3: 要件定義の作成

機能要件

非機能要件

制約

ステップ4: アーキテクチャ設計

ステップ5: ドキュメント生成

docs/DESIGN.md

セキュリティ設計

認証・認可フロー

セキュリティ対策

パフォーマンス設計

最適化戦略

スケーラビリティ

開発・運用

開発環境

CI/CDパイプライン

モニタリング・ロギング

エラー戦略

エラー分類

エラーハンドリング方針

エラーログ・通知

テスト戦略

テストピラミッド

テストデータ

CI統合

制約と前提

技術的制約

ビジネス制約

依存関係

参照

ステップ7: セルフレビュー

レビュー観点

レビュープロセス

セルフレビューチェックリスト

問題発見時の対応

設計の原則

アーキテクチャの原則

設計の品質基準

品質チェックリスト

関連スキル