要件ヒアリング

目次

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

概要

効果的な要件ヒアリングにより、構築する内容についての共通理解が確立され、プロジェクト後期での調整ミスと高額な変更を防ぐことができます。

使用する場面

• プロジェクトのキックオフと計画立案
• 機能開発の開始
• 製品ロードマップの計画策定
• システムの現代化プロジェクト
• 顧客発見
• ステークホルダー調整会議
• ユーザーストーリーと受け入れ基準の作成

クイックスタート

最小限の動作例:

# ステークホルダーを特定および分析する

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

    def identify_stakeholders(self, project):
        """ステークホルダーグループをすべてマップする"""
        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):
        """各ステークホルダーのニーズを理解する"""
        return {
// ... (詳細な実装についてはリファレンスガイドを参照)

リファレンスガイド

references/ディレクトリの詳細な実装:

ガイド	内容
ステークホルダー発見	ステークホルダー発見
要件ヒアリング技法	要件ヒアリング技法
要件ドキュメンテーション	要件ドキュメンテーション
要件検証と承認	要件検証と承認
要件トレーサビリティマトリクス	要件トレーサビリティマトリクス

ベストプラクティス

✅ するべきこと

• 重要なステークホルダーを早期に関与させる
• 要件を書面で記録する
• 具体的で測定可能な言語を使用する
• 受け入れ基準を定義する
• MoSCoW法を使用して優先順位付けする
• ステークホルダーの署名を取得する
• トレーサビリティマトリクスを作成する
• 要件を定期的に見直す
• 必須要件と付加機能を区別する
• 前提条件と制約を記録する

❌ してはいけないこと

• 記憶または口頭での合意に依存する
• ステークホルダーの意見なしに要件を作成する
• あいまいな言語を使用する (素早く、簡単に、など)
• 非機能要件をスキップする
• 制約と依存関係を無視する
• つまらない詳細を過度に記録する
• 要件フェーズを急いで進める
• ステークホルダーの合意なしに構築する
• プロセスなしにスコープ変更を行う
• エッジケースとエラー条件を忘れる