「プロジェクトの仕様」を表現するPMにとってUMLは強力なツールだよもん、と書いた[参考]。あきぴーさんからトラックバック[参考]をいただいて、私の説明がまずかったことに気づいた(あきぴーさんありがとうございます)。仕様」という紛らわしい書き方をしている。システムの仕様」とも読み取れてしまう。システム仕様の実現」なり。PMBOKアプローチなら、スコープにはプロジェクトスコープとプロダクトスコープと二つあり、プロダクト(成果物)の一つに設計書があり、その設計書で表現される仕様を定義するのに、UMLが有効だよ、という理屈。UMLアプローチだと、ユースケース図を使うことで、システムに期待する振舞いを定義することができる。システムの振舞い定義に有用なUMLなら、プロジェクトの振舞いにも使えるのではあるまいか、という仮説を立ててみる。「UMLでプロジェクトの仕様を表現できないか」ってね。やらなくてもいい作業がプロジェクトに組み込まれ、本来すべきことが実施されていない惨状を目の当たりにすると「どうして、それはプロジェクトですべき作業ではありません、と言えなかったんだろう」と強く感じるのでもちろん「そいつぁWBSで定義するんじゃないの?」というツッコミ上等。BreakdownされたWBSなんて見たことないので。もって、WBS書く側からは「何を作るのかが共有化・明確化されていないのに、作るもののためにどんな作業をすべきなのか、分かるわけないやんー!!」という怨嗟が。プロジェクトの仕様がUMLで表現できるのなら、成果物を書く人とWBSを書く人が一致する(し、そうすべきだ)。成果物を明確化する仕事と、その成果物のために必要な作業を明確化する仕事は、クルマの両輪のはず。前者を優先するあまり後者を蔑ろにしていたのは私の狭量。仕様」にしちゃったんだな。システム仕様」になってしまう。この見方だと、教育費やコンティンジェンシープランなどを見落とす罠に陥る。「UMLでプロジェクトの仕様を表現できないか」については、非常に興味深いネタとして考査中。モデリングは可能だが、かなりのボリュームになる。...などと聖夜に独り自問。浜の真砂は尽きるとも、世にデザパタのネタは尽きまじ。»コメントトラックバックありがとうございます。PMBOK本を唯一開設しているBlogとして以前から拝見して参考にしておりました。最近、プロジェクト管理者の立場になったので、プロジェクトを回すために、色んな意味のスコープをすごく意識するようになっています。未熟者ゆえ、DainさんのBlogで勉強させて頂きます。最近は、中国で中国人SEにプロマネスキルをお伝えする仕事をやってます。しながら現場でやってます。プログラマまたはパッケージソフトのSE上がりの彼らに、広いスコープで考えることを教えるのにいつも苦労。一例を挙げると見積り。」とお願いしたら、テスト工数までは勘定に入れてきても、テスト準備とか、ユーザ教育とかのタスクが思い浮かばないからとても低く見積もる。dianさん言うよに、事前にWBSを事細かに文書化するなんてことは、日々追われる現場ではできないんで、彼らの見積もりを見て逐次お話しながらノウハウを伝えています。まーでもいまのとこ、楽しいけどね。14:45あきぴーさん、コメントありがとうございます。あきぴーさんの記事のおかげで、プロジェクトスコープとプロダクトスコープを混ぜて書いていることが分かりました。ありがとうございます。UMLはプロダクト(の一部)を表現するために有益なツールですもの。いう閃きが生まれました。誰かが既にやってそうですが...白状します。PMについてあれこれ偉そうなことを書いていますが、一人でPMをやったことはありません。PMのサポートやタスクマネージャで経験を積んでいるところです。未熟故のカン違いはどうぞツッコミを入れてくださいませ。さん、コメントありがとうございます。プログラマやSEに仕事が振られるときには、既にタスクは割られて(breakdownされて)いるため、そこばかりを見て育った人はどうしても狭量になりがちでしょう(かくいう私もそうです)。プロジェクト全体を見渡せる大局的な視座を持つPG/SEも確かにいますが、ごく少数かと。これは個人の問題ではなく、単に「考えたこともなかった」というだけでしょう。UMLを使って、どういうタスクがプロジェクトに求められているかをモデリングすることは、PG/SEにとって良いトレーニングになるのかな、と思ってみたり。中国、韓国のプログラマと仕事をする機会がありますが、プログラマとして非常に優秀だなーと感じています(もちろん「日本人」と比較して)。日本語の壁さえなければ、日本のプログラマ市場を席巻すること必至でしょう。kjyさんの話を聞いていると、プロジェクトマネージャも近々そうなるような気がします。22:39Dainさん:設計の前の要件定義、その前の企画、といったいわゆる上流工程(上流社会みたいでこのコトバは嫌いなんですけど)が中国やインドに流れてゆくのは、位置エネルギーの法則と同じだと思います。今は、ソフトウェア製造工場としての感が大きいですが、ソフトウェア開発を包含するプロジェクトマネジメントも自らが担当するようになりますよ。なんたって、ずっと昔にいくつもの大規模プロジェクトを経験している国ですから。(兵馬俑とか、万里の長城とか...)ここから愚痴。うちの会社のおえらいは、いまだに中国を見下して単なるプログラマとしてしか捕らえていないし、これからもそうだと思ってる。変化が読めない人たち。そんな会社から抜け出せない自分もなさけねー。今はプログラマとして一緒に仕事してますが、じきにPM手法を手にするのは必至ですね。大規模システム開発ためのマネジメント手法は、メインフレームを通じてIBMから富士通、日立へと受け継がれています。01:26毎度こんばんは。私の周りにも中国の方が増えています。年配の方が彼らを見下すのは、幼少の頃の記憶というか親、周囲からの教育によるものでしょうか、と思います。私は見下すというより(今は)使う側として気をつけないと(危ないぞ)と思うことが多々あります。本国への私的な長電話(周りには自分の言葉が解らないと思ってやっている)や(彼らにしてみれば)チョットした手抜きはなかなか無くなりませんねぇ。最近は上司が見ていなくても自発的に動き、隅々までちゃんと仕事をやる人が増えきました(あくまで主観)。これなら管理も任せて良いかなと思える今日この頃です。逆に日本人(で仕事ができると評価されてて若くも無い人)が影でズルするようになってきました。00:03鉛のZEPさん、コメントありがとうございます中・韓プログラマの「手抜き」にあったことはありませんが、コメントの日本語がヘンなのには閉口したことがあります。「猛勉強」という言葉がピッタリのごとく勉強しています。見下している「年配の方」の年齢がもっと上ならば「満州」というキーワードで解けるのですが。そのうち追いつき追い越されるぞと思いながら、こちらも勉強の毎日です。答えが見つからないときは、問題を変えてみよう。(哲学はなぜ間違うのか)本は読まなくても書評を書くことはできる。