プログラマの思索

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

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

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

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

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

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

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