WBS洗い出しは難しい

　最近のシステム開発では、プロジェクトが動き出した途端に、仕様がコロコロ変わる時が多い。
　変化に対応するには、どんな手法が必要か？
　プロジェクトマネジメントは、結局、WBSの洗い出しから始まるように思う。

　だが、WBS洗い出しは難しい。
　理由は、まず、作業分担まで詳細化する手間が大きすぎる。管理工数を開発工数とは別に確保せねばならないが、普通のプロジェクトでは、5～10％以下しか割り当てられないので、高度なスキルが要求される。
　更に、仕様変更やトラブルのために、せっかく作ったWBSにマッピングされたスケジュールを書き直す事が多い。しかも、スケジュール変更をチームメンバーに徹底させる手間がかかるから。

　XPやCMM/CMMIのような開発スタイルでも、同じ問題は発生するのではなかろうか？
　XPなら、開発するスコープを計画ゲームで制限する。更に、タスクカードを作る作業がWBS洗い出しに相当する。

　CMM/CMMIでも、要求管理というプロセスで、要求そのもののスコープをステークホルダーの意思決定の元に決定してしまう。決定した要求仕様を覆すには、ステークホルダーの意思決定を再度行わねばならない。
　WBS洗い出しは、ウォーターフォール型開発のように、開発計画書を作って、プロセスを定義して､タスクを決めて、という風に定められた手順で膨大なドキュメントを作りながら、決めていく。

＃その意味では、XPもCMMもスコープ管理、WBS洗い出しの手法は似ている。
＃しかし、それらの手法が編み出された動機が全く違うのだから、相違点に着目すべきだと思う。

　XPもCMMも、変化に俊敏に対応することを目的にしているように思うが、その目的が本当に達せられたのか、疑問に思う所はある。
　変化に対応するのが難しいのは、変化に対応できる環境作りだけでない。変化を受け入れた時の影響が具体的にどれだけ大きいのか、更に、変化に対応できるだけの手間がどれだけなのか、が分かりにくい事にあると思う。
　例えば、システム保守で、仕様変更のたびに全ソースと全RDBを見直している時、調査工数そのものの大きさと、仕様変更を実施するための見積工数の正確さが結局、プロジェクトの成功/失敗を左右する。

　つまり、WBS洗い出しの調査工数と、WBSの正確さがプロジェクトの成功/失敗を左右しているように思う。
　但し、WBS洗い出しのような管理工数は、プロジェクトの規模によって異なるらしい。（「ソフトウェア開発の定量化手法」参考）
　そこにヒントがある気がする。