「プロジェクトの仕様」を表現する
PMにとってUMLは強力なツールだよもん、と書いた[参考]。あきぴーさんからトラックバック[参考]をいただいて、私の説明がまずかったことに気づいた（あきぴーさんありがとうございます）。私の記事では、「スコープ ＝ 仕様」という紛らわしい書き方をしている。これだと「プロジェクトの範囲 ＝ システムの仕様」とも読み取れてしまう。正しくは「スコープ ⊃ 仕様」であり、「プロジェクトの範囲 ⊃ システム仕様の実現」なり。
PMBOKアプローチなら、スコープにはプロジェクトスコープとプロダクトスコープと二つあり、プロダクト（成果物）の一つに設計書があり、その設計書で表現される仕様を定義するのに、UMLが有効だよ、という理屈。
UMLアプローチだと、ユースケース図を使うことで、システムに期待する振舞いを定義することができる。んで、システムの振舞い定義に有用なUMLなら、プロジェクトの振舞いにも使えるのではあるまいか、という仮説を立ててみる。つまり「UMLでプロジェクトの仕様を表現できないか」ってね。
ここから脱線。
やらなくてもいい作業がプロジェクトに組み込まれ、本来すべきことが実施されていない惨状を目の当たりにすると「どうして、それはプロジェクトですべき作業ではありません、と言えなかったんだろう」と強く感じるので
もちろん「そいつぁWBSで定義するんじゃないの?」というツッコミ上等。ちゃんとBreakdownされたWBSなんて見たことないので。んでもって、WBS書く側からは「何を作るのかが共有化・明確化されていないのに、作るもののためにどんな作業をすべきなのか、分かるわけないやんー！！」という怨嗟が。
本線に戻る。
プロジェクトの仕様がUMLで表現できるのなら、成果物を書く人とWBSを書く人が一致する（し、そうすべきだ）。
そして、成果物を明確化する仕事と、その成果物のために必要な作業を明確化する仕事は、クルマの両輪のはず。前者を優先するあまり後者を蔑ろにしていたのは私の狭量。だから「スコープ ＝ 仕様」にしちゃったんだな。PG/SEの思考だと、どうしても「プロジェクトの範囲 ≒ システム仕様」になってしまう。これは間違い。この見方だと、教育費やコンティンジェンシープランなどを見落とす罠に陥る。
「UMLでプロジェクトの仕様を表現できないか」については、非常に興味深いネタとして考査中。もちろんモデリングは可能だが、かなりのボリュームになる。しかし、これまで経験してきたプロジェクトをモデリングすることでプロジェクトのパターン化ができないか、ひいてはプロジェクトデザインパターンができるのではないか? …などと聖夜に独り自問。浜の真砂は尽きるとも、世にデザパタのネタは尽きまじ。
--
| 固定リンク
| コメント (7)
| トラックバック (0)
最近のコメント