回答。

プロジェクトのスコープは、プロジェクト内で実現すべきことと除外されるべきことを明確に定義することです。正確なスコープの定義は、作業の範囲を理解し、"要件の拡散"を防ぎ、リソースと期限を効果的に管理することを可能にします。

ビジネスアナリストはスコープを以下の方法で記述します：

• ステークホルダーのマップ。
• コンテキスト図、境界、インターフェース。
• ユーザーストーリーまたはユースケース形式の機能カタログ。
• "スコープ外"のマニフェスト（除外）。

主な特徴：

• プロジェクトのスコープは、要件の詳細な検討前に確定されます。
• これは、あらゆる変更の合意のための基準となります。
• チームのための実際の測定可能なコミットメントの範囲を設定します。

質問のトリック。

スコープを固定したとみなすために、主要な機能リストのみを定義すれば十分ですか？

いいえ。プロジェクトに含まれないことを明示的に示す必要があります。不明瞭な解釈や"隠れた"期待を避けるためです。

ビジネスアナリストは、有益だと考える場合、スコープを独自に拡大する権利がありますか？

いいえ。スコープの変更は、顧客やステークホルダーとの合意が必要であり、通常、変更要求（チャングリクエスト）を通じて正式に行われます。

スコープの合意後にプロジェクトの境界を変更できますか？

はい、ただし、変更管理の正式なプロセスを通じて行う必要があり、計画、コスト、期限を再評価し、すべての主要ステークホルダーの合意を得る必要があります。

よくある誤りとアンチパターン

• プロジェクトに含まれる/含まれないものの明確な区別がない。
• 期限や予算への影響を考慮せずに新しいタスクを追加する。
• スコープの合意が言葉のみで、文書化されていない。

実例

ネガティブケース

スコープが口頭で定義され、明確な文書がない。プロセス中に、ステークホルダーが"期待していた"追加のタスクが発生する。

利点：

• 柔軟性、新しいタスクへの適応能力。

欠点：

• プロジェクトが期限と予算を超える、チームと顧客の間で誤解が生じる。

ポジティブケース

アナリストがスコープを文書化し、除外を合意し、すべての変更が変更要求システムを通じて行われる。

利点：

• リソースの管理、透明性、プロジェクトの管理可能性。

欠点：

• 固定されたスコープは、変更の合意に追加の時間を要します。