今日はUMLの講習会

　社外の講師を呼んで自分はその講師のサブとして仕事をやったけど結構面白い事が判明。

その１：
　課題を与えられた場合結構みんな同じような考えになってUMLの図を描こうとして同じような過ちに陥るって事。

　設計という作業は答えがあるようでないようなもの。その中で色々なUMLの図が出来上がってくるのを想像していたけど、みんなの答えは結構似通ったものになっていた。しかも１人躓く人がいると同じように躓いている人がいる。

その２：
　この講習の前、Javaの講習も同じようにサブ講師として動いた事があったけど、そのときJavaのコーディングに躓いていた人がいて、「UML覚えられるのかなぁ」と思っていたが、その人今回は結構うまくUMLの図を描いていたりする。また他の人では逆もしかり。

　人には得意って言うか、楽に仕事ができるフェーズってのがやっぱりあって、その人は「実装」寄りの事柄より「設計」よりの事がうまいのかなぁと思った次第。

UMLのサブ講師をしてみて感じたことは、受講者の年代が上がるほどUMLの図を描く順番にこだわる傾向がある。ユースケース→オブジェクトの切り出し→クラス図→シーケンス図と、必ずこの順番に作らなくてはならないみたいな。

　たぶんこれは管理という局面から見ているのだと思う。自分の場合で恐縮であるが、UMLは自分の頭の中を整理するために作っている事が多い。なのでクラス図、シーケンス図などの図と自分でわかりやすい図を平行で作っていくこともある。

　何がいいたいかというと、順番に表現できるということはWBSの作業項目に落とせるということで、今日はユースケース、明日はオブジェクトの切り出しと何かウォーターフォールのように仕事を振ることができると勘違いしているのではないかということ。

　ただ、XPとかプロトタイプとかいろいろあるけど自分の周りでは基本はウォーターフォール型のプロジェクト管理が多いと思う。またウォーターフォールの中にプロトタイプをねじ込んだみたいなものとか。その中に当てはめていかざるを得ない状況のなかで自分はどうやって上司を納得させながら作業項目を見ていかなくてはならないかと思った次第。