requirements-gathering

要件収集

目次

• 概要
• 使用する場面
• クイックスタート
• リファレンスガイド
• ベストプラクティス

概要

効果的な要件収集によって、何を構築するのかについて共通認識を確立し、プロジェクト後半での認識のずれや高額な変更を防げます。

使用する場面

• プロジェクトのキックオフと計画
• 機能開発の開始
• プロダクトロードマップの計画
• システムのモダナイゼーションプロジェクト
• 顧客のニーズの把握
• ステークホルダー間の認識合わせ
• ユーザーストーリーと受け入れ条件の作成

クイックスタート

最小限の実用例：

# Identify and analyze stakeholders

class StakeholderDiscovery:
    STAKEHOLDER_CATEGORIES = [
        'End Users',
        'Business Owners',
        'Technical Leads',
        'Operations/Support',
        'Customers',
        'Regulatory Bodies',
        'Integration Partners'
    ]

    def identify_stakeholders(self, project):
        """Map all stakeholder groups"""
        return {
            'primary': self.get_primary_stakeholders(project),
            'secondary': self.get_secondary_stakeholders(project),
            'tertiary': self.get_tertiary_stakeholders(project),
            'total_to_engage': self.calculate_engagement_strategy(project)
        }

    def analyze_stakeholder_needs(self, stakeholder):
        """Understand what each stakeholder needs"""
        return {
// ... (see reference guides for full implementation)

リファレンスガイド

references/ ディレクトリにある詳細な実装：

ガイド	内容
ステークホルダーの把握	ステークホルダーの把握
要件抽出の手法	要件抽出の手法
要件ドキュメント	要件ドキュメント
要件の検証と承認	要件の検証と承認
要件トレーサビリティマトリクス	要件トレーサビリティマトリクス

ベストプラクティス

✅ DO

• 主要なステークホルダー全員に早い段階で参加してもらいます
• 要件を書面に記録します
• 具体的で測定可能な表現を使います
• 受け入れ条件を定義します
• MoSCoW メソッドを使って優先順位を付けます
• ステークホルダーの承認を得ます
• トレーサビリティマトリクスを作成します
• 要件を定期的に見直します
• 必須要件とあると望ましい要件を区別します
• 前提条件と制約を記録します

❌ DON'T

• 記憶や口頭での合意に頼ります
• ステークホルダーの意見を聞かずに要件を作成します
• 曖昧な表現（すばやく、簡単に、など）を使います
• 非機能要件を省略します
• 制約や依存関係を無視します
• 些細な詳細まで過剰に文書化します
• 要件定義のフェーズを急いで進めます
• ステークホルダーの合意なしに構築します
• 手順を踏まずにスコープを変更します
• エッジケースやエラー条件を見落とします