プログラマの思索

　スコープ管理が難しい理由は、ステークホルダー同士の頭にあるスコープが大きくずれているからではないか。

　PMBOKを解説しているHPを見たら、スコープには、「成果物スコープ」と「プロジェクトスコープ」の２つがあるらしい。
　成果物スコープとは、プロジェクトの成果物を定義するもの。例えば、納品のためのプログラムや仕様書。
　プロジェクトスコープとは、成果物を作り出すために行う作業の分担を表すもの。例えば、要件定義、設計、テスト、データ移行、ユーザー教育など。

　普通は、成果物スコープからプロジェクトスコープを作っていく。つまり、WBSを作るのと同じ。
　だから、WBSがしっかりしていれば、プロジェクトスコープが曖昧になることはないはず。

　しかし、WBSが曖昧な場合もある。初めてのユーザ、初めての技術を使ってプロジェクトを始める場合、成果物に対するステークホルダーの認識が一致していても、成果物を作り出す作業が見えないため、WBSに漏れ抜けが発生することが多い気がする。すると、ユーザは、たったこれだけの成果物を作り出すのに、何故こんなに工数がかかるのか、とSIerに問い詰める事態になったりする。
　だから、ステークホルダー同士のスコープに対する思惑は、WBSがしっかりと固まるまで違いが顕在化しないと思う。

　更に、ステークホルダーが多ければ多いほど、スコープのずれが大きくなる可能性がある。そして、全てのステークホルダーが認識するスコープをすり合わせる手間もかかる。
　プロジェクトが発足した後で、ステークホルダーは増えることはあっても減ることは、現実では殆どありえないのではないか？

　XPなら、WBSを作る作業は計画ゲームに相当する。しかも、1人日で収まるタスクまで詳細化するし、チームへ顧客を巻き込んでいるから、ステークホルダーの認識のずれは小さいと言える。
　
　何故、プロジェクトでスコープ管理が大事なのか？
　理由は、スコープがステークホルダー同士の利害関係に直接依存しているからだろう。
　プロジェクトマネージャーがスコープ管理をするということは、ステークホルダー同士の利害関係を解きほぐすだけの政治能力があるという意味も含まれていると思う。
　プロジェクトマネージャーの仕事は難しい(m_m)

P.S.「スコープ管理はプロジェクト計画書から始まる」の内容と似ているよな(m_m)