« この本がスゴい!2004 | トップページ | 子どもにネットを教えるとき、心がけていること »

「プロジェクトの仕様」を表現する

PMにとってUMLは強力なツールだよもん、と書いた[参考]。あきぴーさんからトラックバック[参考]をいただいて、私の説明がまずかったことに気づいた(あきぴーさんありがとうございます)。私の記事では、「スコープ = 仕様」という紛らわしい書き方をしている。これだと「プロジェクトの範囲 = システムの仕様」とも読み取れてしまう。正しくは「スコープ ⊃ 仕様」であり、「プロジェクトの範囲 ⊃ システム仕様の実現」なり。

PMBOKアプローチなら、スコープにはプロジェクトスコープとプロダクトスコープと二つあり、プロダクト(成果物)の一つに設計書があり、その設計書で表現される仕様を定義するのに、UMLが有効だよ、という理屈。

UMLアプローチだと、ユースケース図を使うことで、システムに期待する振舞いを定義することができる。んで、システムの振舞い定義に有用なUMLなら、プロジェクトの振舞いにも使えるのではあるまいか、という仮説を立ててみる。つまり「UMLでプロジェクトの仕様を表現できないか」ってね。

ここから脱線。

やらなくてもいい作業がプロジェクトに組み込まれ、本来すべきことが実施されていない惨状を目の当たりにすると「どうして、それはプロジェクトですべき作業ではありません、と言えなかったんだろう」と強く感じるので

もちろん「そいつぁWBSで定義するんじゃないの?」というツッコミ上等。ちゃんとBreakdownされたWBSなんて見たことないので。んでもって、WBS書く側からは「何を作るのかが共有化・明確化されていないのに、作るもののためにどんな作業をすべきなのか、分かるわけないやんー!!」という怨嗟が。

本線に戻る。

プロジェクトの仕様がUMLで表現できるのなら、成果物を書く人とWBSを書く人が一致する(し、そうすべきだ)。

そして、成果物を明確化する仕事と、その成果物のために必要な作業を明確化する仕事は、クルマの両輪のはず。前者を優先するあまり後者を蔑ろにしていたのは私の狭量。だから「スコープ = 仕様」にしちゃったんだな。PG/SEの思考だと、どうしても「プロジェクトの範囲 ≒ システム仕様」になってしまう。これは間違い。この見方だと、教育費やコンティンジェンシープランなどを見落とす罠に陥る。

「UMLでプロジェクトの仕様を表現できないか」については、非常に興味深いネタとして考査中。もちろんモデリングは可能だが、かなりのボリュームになる。しかし、これまで経験してきたプロジェクトをモデリングすることでプロジェクトのパターン化ができないか、ひいてはプロジェクトデザインパターンができるのではないか? …などと聖夜に独り自問。浜の真砂は尽きるとも、世にデザパタのネタは尽きまじ。

--

|

« この本がスゴい!2004 | トップページ | 子どもにネットを教えるとき、心がけていること »

コメント

トラックバックありがとうございます。
PMBOK本を唯一開設しているBlogとして以前から拝見して参考にしておりました。
最近、プロジェクト管理者の立場になったので、プロジェクトを回すために、色んな意味のスコープをすごく意識するようになっています。
まだまだ未熟者ゆえ、DainさんのBlogで勉強させて頂きます。

投稿: あきぴー | 2004.12.24 23:07

kjy です。
最近は、中国で中国人SEにプロマネスキルをお伝えする仕事をやってます。
講師とかではなくて、実際のプロジェクトでHands On しながら現場でやってます。
プログラマまたはパッケージソフトのSE上がりの彼らに、広いスコープで考えることを教えるのにいつも苦労。
一例を挙げると見積り。
「見積もって。」とお願いしたら、テスト工数までは勘定に入れてきても、テスト準備とか、ユーザ教育とかのタスクが思い浮かばないからとても低く見積もる。
dianさん言うよに、事前にWBSを事細かに文書化するなんてことは、日々追われる現場ではできないんで、彼らの見積もりを見て逐次お話しながらノウハウを伝えています。
まーでもいまのとこ、楽しいけどね。

投稿: kjy | 2004.12.25 14:45

あきぴーさん、コメントありがとうございます。

あきぴーさんの記事のおかげで、プロジェクトスコープとプロダクトスコープを混ぜて書いていることが分かりました。ありがとうございます。UMLはプロダクト(の一部)を表現するために有益なツールですもの。

さらに、この「気づき」からUMLをプロジェクトスコープにまで適用してみたら? という閃きが生まれました。誰かが既にやってそうですが…

白状します。PMについてあれこれ偉そうなことを書いていますが、一人でPMをやったことはありません。PMのサポートやタスクマネージャで経験を積んでいるところです。未熟故のカン違いはどうぞツッコミを入れてくださいませ。

--

kjy さん、コメントありがとうございます。

プログラマやSEに仕事が振られるときには、既にタスクは割られて(breakdownされて)いるため、そこばかりを見て育った人はどうしても狭量になりがちでしょう(かくいう私もそうです)。

もちろんプロジェクト全体を見渡せる大局的な視座を持つPG/SEも確かにいますが、ごく少数かと。これは個人の問題ではなく、単に「考えたこともなかった」というだけでしょう。UMLを使って、どういうタスクがプロジェクトに求められているかをモデリングすることは、PG/SEにとって良いトレーニングになるのかな、と思ってみたり。

中国、韓国のプログラマと仕事をする機会がありますが、プログラマとして非常に優秀だなーと感じています(もちろん「日本人」と比較して)。日本語の壁さえなければ、日本のプログラマ市場を席巻すること必至でしょう。

kjyさんの話を聞いていると、プロジェクトマネージャも近々そうなるような気がします。

投稿: Dain | 2004.12.25 22:39

Dainさん:
 設計の前の要件定義、その前の企画、といったいわゆる上流工程(上流社会みたいでこのコトバは嫌いなんですけど)が中国やインドに流れてゆくのは、位置エネルギーの法則と同じだと思います。
 今は、ソフトウェア製造工場としての感が大きいですが、ソフトウェア開発を包含するプロジェクトマネジメントも自らが担当するようになりますよ。なんたって、ずっと昔にいくつもの大規模プロジェクトを経験している国ですから。(兵馬俑とか、万里の長城とか...)

 ここから愚痴。
 なのにうちの会社のおえらいは、いまだに中国を見下して単なるプログラマとしてしか捕らえていないし、これからもそうだと思ってる。変化が読めない人たち。そんな会社から抜け出せない自分もなさけねー。

投稿: kjy | 2004.12.27 11:21

kjyさん、コメントありがとうございます

どうして中国人を見下しているかはよく分かりませんが、相手を貶めることで相対的に優位に立とうとしているつもりなのでしょうか… 今はプログラマとして一緒に仕事してますが、じきにPM手法を手にするのは必至ですね。

大規模システム開発ためのマネジメント手法は、メインフレームを通じてIBMから富士通、日立へと受け継がれています。盗(と)られるのは仕方がないとして、日本ならではの付加価値がつけられないのかなぁなどと妄想してみたり(例えば製造業の「すりあわせ」とか)

投稿: Dain | 2004.12.28 01:26

毎度こんばんは。
私の周りにも中国の方が増えています。年配の方が彼らを見下すのは、幼少の頃の記憶というか親、周囲からの教育によるものでしょうか、と思います。残念なことですが。
私は見下すというより(今は)使う側として気をつけないと(危ないぞ)と思うことが多々あります。例えば本国への私的な長電話(周りには自分の言葉が解らないと思ってやっている)や(彼らにしてみれば)チョットした手抜きはなかなか無くなりませんねぇ。
ただ最近は上司が見ていなくても自発的に動き、隅々までちゃんと仕事をやる人が増えきました(あくまで主観)。これなら管理も任せて良いかなと思える今日この頃です。
逆に日本人(で仕事ができると評価されてて若くも無い人)が影でズルするようになってきました。とほほ...

投稿: 鉛のZEP | 2005.01.08 00:03

鉛のZEPさん、コメントありがとうございます

中・韓プログラマの「手抜き」にあったことはありませんが、コメントの日本語がヘンなのには閉口したことがあります。凄いのは勉強量。まさに「猛勉強」という言葉がピッタリのごとく勉強しています。

そういう彼らを、何を根拠に見下すのかが分からない… 見下している「年配の方」の年齢がもっと上ならば「満州」というキーワードで解けるのですが。そのうち追いつき追い越されるぞと思いながら、こちらも勉強の毎日です。

投稿: Dain | 2005.01.08 22:54

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 「プロジェクトの仕様」を表現する:

« この本がスゴい!2004 | トップページ | 子どもにネットを教えるとき、心がけていること »