« スコープを公開する重要性 | トップページ | 失敗はプロジェクトマネージャーにとって経験にならない »

2004/12/23

ユースケース図でスコープを可視化する

 「スコープを可視化する」記事で、ユースケース図はPMにとって強力なツールだと書かれている。
 以前、開発している時、ユースケース図なんて何の存在意義があるのか?と疑問を持っていたが、実際、自分がプロジェクト管理者の立場になって、初めてユースケース図の重要性を認識した。
 ユースケース図は、システムの仕様のスコープを整理するために使える。かなり有効に使えそうな予感がする。

 自分がプロジェクト管理者になって、設計者に内部仕様書を書かせているが、曖昧な要件定義から作らせているので、ユーザに外部仕様を確認して調整する場合が必ずある。
 その時、設計者に下記のように質問している自分に自然に気付いた。

未確定な仕様は、何が分かれば確定するのか?
未確定な仕様以外の部分は正しいか?
未確定な仕様の影響範囲はどれくらいか?
未確定な仕様をブラックボックスにして、作業を続けられるのか?
未確定な仕様が決まったら、工数はどれだけかかるか?

 上記の質問をしている理由は、未確定な仕様を仕様書から切り離して、設計者の作業を続行させ、その間に未確定な仕様をユーザと調整したいからだ。
 自分としては、仕様を機能単位に分割し、未確定仕様のスコープをできるだけ小さくしたい、という動機がある。
 すなわち、ユースケースを洗い出し、ユースケース図の外枠を狭めているのと同じ。

 ユースケース図の外枠がスコープに相当する。枠内には、システムで実現する機能(ユースケース)がある。だから、このユースケースはシステム内部でやるのか、あるいは、システムの外部でやるのかがハッキリする。
 上記記事でも書いてあるが、スコープを意識する時、ユースケースの詳細度はあまり関係ない。
 理由は、プロジェクトスコープはWBSのおかげではっきりしているので、ユースケースが大きすぎて工数が大きくなる場合は、スコープを基準にしてユースケースを分割できないか考えるようにしているから。

 ユースケースとスコープを意識し始めて、幾つか気になることはある。
 ユースケースの詳細度は、プロジェクト管理者と設計者で異なるように感じる。当然、設計者の方が細かい。プロジェクト管理者にとって、ユースケースとWBSはNearlyEqual。
 又、アクターが単なるユーザだけではなく、外部システム(うちならHost)が自然に出てくる。システムを実現するために、データの主体を実行者にしてしまうことがよくある。

 残りの問題は、ユースケースの種類とWBSに関係はあるか?とか、ユースケース図とスコープの関連をもっと研究してみる、とか。
 「ユースケース実践ガイド―効果的なユースケースの書き方」を最近になって、もう一度読み始めている。
 以前はさっぱり理解できなかったけれど、本の中にも「スコープ」のことが書かれている!
 後でまとめよう。

|

« スコープを公開する重要性 | トップページ | 失敗はプロジェクトマネージャーにとって経験にならない »

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

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

コメント

コメントを書く



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


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



トラックバック

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

この記事へのトラックバック一覧です: ユースケース図でスコープを可視化する:

» 「プロジェクトの仕様」を表現する [わたしが知らないスゴ本は、きっとあなたが読んでいる]
PMにとってUMLは強力なツールだよもん、と書いた[参考]。あきぴーさんからトラ [続きを読む]

受信: 2004/12/24 19:53

« スコープを公開する重要性 | トップページ | 失敗はプロジェクトマネージャーにとって経験にならない »