requirements-discovery

要件の発見

構造化された質問、ステークホルダー分析、仕様策定を通じて、体系的に要件を引き出します。曖昧なプロジェクトのアイデアを、具体的で測定可能な仕様に変換します。

このスキルを使用する場面

• 曖昧な説明から新規プロジェクトや機能の要件を収集するとき
• ニーズや制約を明らかにするため、ステークホルダーへのインタビューを実施するとき
• プロダクト要件定義書（PRD）を作成、または構成するとき
• 明確な境界と優先順位を定めてプロジェクトのスコープを定義するとき
• 明確に定義された受け入れ基準を含むユーザーストーリーを作成するとき
• 非機能要件（パフォーマンス、セキュリティ、スケーラビリティ）を特定するとき
• ステークホルダー間で相反する優先事項を調整するとき
• 実装に引き継ぐ前に要件が完全であることを検証するとき

クイックリファレンス

タスク	リファレンスを読み込む
インタビューの手法、PRD の構成、スコープの定義、ユーザーストーリーマッピング	skills/requirements-discovery/references/elicitation-techniques.md

基本原則

• 「どのように」より先に「なぜ」を尋ねる：想定した解決策ではなく、ユーザーの真のニーズを明らかにします
• ソクラテス式の質問：思い込みではなく、質問を通じて発見を導きます
• 段階的な精緻化：大まかな目標から具体的で検証可能な基準へと進めます
• ステークホルダー間のバランス：特定の意見だけが支配的にならないよう、多様な視点を取り入れます

ワークフロー

1. 発見

解決策を定義する前に、問題領域を理解します。

• すべてのステークホルダーとその役割を特定します
• 自由回答式と選択式の質問を用いて、構造化されたインタビューを実施します
• ユーザーペルソナとその課題をマッピングします
• 制約（技術、予算、スケジュール、規制）を把握します

2. 仕様策定

生の入力を構造化された要件に変換します。

• 機能要件と非機能要件を含む PRD の草案を作成します
• 受け入れ基準を含むユーザーストーリーを作成します
• MoSCoW または同様のフレームワークを使用して優先順位を付けます
• スコープの境界（明示的に対象外とするもの）を定義します

3. 検証

実装前に、完全性と整合性を確認します。

• ステークホルダーと仕様をレビューします
• 受け入れ基準が検証可能かつ測定可能であることを確認します
• 成功指標と KPI の基準値を設定します
• 未解決の質問とフォローアップ項目を記録します
• 実装への引き継ぎ資料を準備します

よくある間違い

• 問題を理解する前に解決策に飛びつく
• 要件を反復的に精緻化するものではなく、固定されたものとして扱う
• 非機能要件（パフォーマンス、セキュリティ、アクセシビリティ）を見落とす
• 対象外とする範囲を定義しない
• 客観的に検証できない受け入れ基準を作成する
• 実際のユーザーやステークホルダーとの検証を省略する