ユースケース図でスコープを可視化する
「スコープを可視化する」記事で、ユースケース図はPMにとって強力なツールだと書かれている。
以前、開発している時、ユースケース図なんて何の存在意義があるのか?と疑問を持っていたが、実際、自分がプロジェクト管理者の立場になって、初めてユースケース図の重要性を認識した。
ユースケース図は、システムの仕様のスコープを整理するために使える。かなり有効に使えそうな予感がする。
自分がプロジェクト管理者になって、設計者に内部仕様書を書かせているが、曖昧な要件定義から作らせているので、ユーザに外部仕様を確認して調整する場合が必ずある。
その時、設計者に下記のように質問している自分に自然に気付いた。
未確定な仕様は、何が分かれば確定するのか?
未確定な仕様以外の部分は正しいか?
未確定な仕様の影響範囲はどれくらいか?
未確定な仕様をブラックボックスにして、作業を続けられるのか?
未確定な仕様が決まったら、工数はどれだけかかるか?
上記の質問をしている理由は、未確定な仕様を仕様書から切り離して、設計者の作業を続行させ、その間に未確定な仕様をユーザと調整したいからだ。
自分としては、仕様を機能単位に分割し、未確定仕様のスコープをできるだけ小さくしたい、という動機がある。
すなわち、ユースケースを洗い出し、ユースケース図の外枠を狭めているのと同じ。
ユースケース図の外枠がスコープに相当する。枠内には、システムで実現する機能(ユースケース)がある。だから、このユースケースはシステム内部でやるのか、あるいは、システムの外部でやるのかがハッキリする。
上記記事でも書いてあるが、スコープを意識する時、ユースケースの詳細度はあまり関係ない。
理由は、プロジェクトスコープはWBSのおかげではっきりしているので、ユースケースが大きすぎて工数が大きくなる場合は、スコープを基準にしてユースケースを分割できないか考えるようにしているから。
ユースケースとスコープを意識し始めて、幾つか気になることはある。
ユースケースの詳細度は、プロジェクト管理者と設計者で異なるように感じる。当然、設計者の方が細かい。プロジェクト管理者にとって、ユースケースとWBSはNearlyEqual。
又、アクターが単なるユーザだけではなく、外部システム(うちならHost)が自然に出てくる。システムを実現するために、データの主体を実行者にしてしまうことがよくある。
残りの問題は、ユースケースの種類とWBSに関係はあるか?とか、ユースケース図とスコープの関連をもっと研究してみる、とか。
「ユースケース実践ガイド―効果的なユースケースの書き方」を最近になって、もう一度読み始めている。
以前はさっぱり理解できなかったけれど、本の中にも「スコープ」のことが書かれている!
後でまとめよう。
| 固定リンク
「日記・コラム・つぶやき」カテゴリの記事
- Clubhouseは路上ライブや朗読のためのツールかもしれない(2021.04.04)
- ノートパソコンが入ってUSBポートが付属しているビジネスリュックを買ってみた(2021.03.21)
- デブサミ2021の感想~コミュニケーションスタイルがオフラインからオンラインに激変している(2021.02.25)
- 考えながら書く人のためのScrivener入門の感想(2020.12.06)
- 課題は問題点をひっくり返す表現だけで良い場合もある(2020.09.28)
「プロジェクトマネジメント」カテゴリの記事
- プロジェクトのリスクはコストの増減で管理する(2021.04.08)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
コメント