スコープや成果物に関しては、可能な限り曖昧さを排除しておくことが必要です。また、スコープや成果物に関して曖昧なプロジェクトは必ず失敗すると言われることもあります。amazonで昔購入したプロジェクト管理の参考書にも、そのように書かれて印刷されています・・
確かに、求められる成果物の要件が曖昧であれば、表現されていないまでも実は明確だった成果物のイメージと乖離した成果物ができあがってしまうかもしれません。何を作ってほしいのか曖昧だったら供給者側は怖くて契約もできません。要件はできるだけ詳細で具体的であれば、実装する側はその要件に沿った作業がしやすくなります。
—–
ただし、プロジェクトスタート時にスコープや成果物の要件を詳細に定義することは、実は難しいです。また、スタート時の要求がすべて明確になっているかと言えば、必ずしもそうでないケースがほとんどです。それは要件を提示する側、新しいシステムを獲得しようとする当事者に以下のような事情がある為です。
①スタート時の要求事項はラフでかつ部門毎に粒度にばらつきがあること、
②現場の当事者はITの専門家ではなく自然言語でそのまま要求を出すこと、
③新しい業務プロセスの適用によって出現する利点や制約に気づけないこと
—–
これに対して、ITのプロジェクトで良く見られるように、実装に入る前に要件定義のフェーズを独立させて設定しておくことで、”スコープや成果物の曖昧さ”に起因するトラブルを少なくすることができます。
要件定義の工程から外部の供給者、または社内の専門チームに委託する場合は、プロジェクトスタート時のスコープや成果物に関してはハイレベルのままで良いことになります。なぜなら、要求の精度をあげること（要求開発ともいわれます）自体を、コストをかけて、手法やツール/製品知識に習熟した専門家に期待できるためです。
その場合、供給者側はビジネスアナリストや、SME（Subject Matter Expert）と一緒に、自分達のほんとうに求めていることを理解してビジネスゴール達成の為に必要な仕組みや新しいプロセスを上手に引き出して欲しい、実装の為に新しい要求や制約事項を整理しなおして欲しい、と考えます。
—–
プロジェクトにおけるスコープ・マネジメントとともに、要件定義の工程はますます重要になってくるでしょう。モデリングは作図センスではなく、要求を引き出す力が求められます。これからは『スコープや成果物に関しては、可能な限り曖昧さを排除しておくことが必要』、ではなく、『スコープや成果物に関しては、それぞれの工程で求められる粒度に応じた曖昧さの排除が必要』である、という言い方が正しいのかもしれません。