analyzing-requirements

ユーザー要件を分析し、システム設計ドキュメント(DESIGN.md)を生成します。ユーザー要件が曖昧または不明確な場合、システムアーキテクチャの設計が必要な場合、大規模な機能開発の設計仕様が必要な場合、技術的実現可能性の検証が必要な場合に使用します。不明点はAskUserQuestionツールで確認します。

$ Installieren

git clone https://github.com/skanehira/dotfiles /tmp/dotfiles && cp -r /tmp/dotfiles/claude/skills/analyzing-requirements ~/.claude/skills/dotfiles

// tip: Run this command in your terminal to install the skill

SKILL.md

View on GitHub →

name: analyzing-requirements description: ユーザー要件を分析し、システム設計ドキュメント(DESIGN.md)を生成します。ユーザー要件が曖昧または不明確な場合、システムアーキテクチャの設計が必要な場合、大規模な機能開発の設計仕様が必要な場合、技術的実現可能性の検証が必要な場合に使用します。不明点はAskUserQuestionツールで確認します。

要件分析

概要

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

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

参照ルール

設計原則: rules/core/design.md（SOLID、高凝集度、低結合度）

コアワークフロー

ステップ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)を生成する。

テンプレートは design-template.md を参照。

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

設計ドキュメントを書き出す：

// docsディレクトリにDESIGN.mdを出力
Write(
    file_path="docs/DESIGN.md",
    content=designContent
)

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

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

レビュー観点

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

レビュープロセス

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

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

要件の完全性

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

設計の明確性

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

実装への橋渡し

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

問題発見時の対応

問題を発見した場合：

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

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

品質チェックリスト

設計完了前に確認：