« 全てのビジネスは金融商品 | トップページ | ホワイトボックステストをやるなら
クラス設計を見直せ »

2004/08/08

WBS洗い出しは難しい

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

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

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

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

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

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

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

|

« 全てのビジネスは金融商品 | トップページ | ホワイトボックステストをやるなら
クラス設計を見直せ »

プロジェクトマネジメント」カテゴリの記事

日記・コラム・つぶやき」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/49479/1231095

この記事へのトラックバック一覧です: WBS洗い出しは難しい:

« 全てのビジネスは金融商品 | トップページ | ホワイトボックステストをやるなら
クラス設計を見直せ »