書くことより、読むことを教えるべきでは

現在、ある会社のUMLを使った新人教育のお手伝いをしています。この教育のテキストは要件定義、設計、実装、テストの一連の流れをもつ課題を通じ、その局面ごとに使われるUML図、たとえば要件定義ならユースケース図、設計ならクラス図というように代表的なUML図を学んで行きます。各UML図の学習は

その図の意義、目的等の説明
その図の書き方(文法)の説明
サンプル図を使って、その図の説明
課題の流れ応じた図を書かせる
書いた図をレビューする (隣の人や講師がレビュー)

という流れで、教えています。これはプログラミング言語の教育などでも行われている手順だと思います。

何度かこの教育のお手伝いを行っているのですが、それほど上手く行ってる様には思えません。例えば、ユースケース図やステート図では半数以上の受講者が、無理矢理に処理の流れを書いてしまいます。

その原因は、テキストに書かれたサンプル図が必ずしも適切でない等もありますが、出来てない人を指導していると、その図に対する理解と課題の間のギャップが埋められていないように思えます。
例えば、ステート図とは「状態」とその遷移を書くのですが「状態」という言葉は説明されていますが、課題の中でどれが状態なのか抽出できてなかったり、「状態の遷移」と「処理の流れ」違いが明確になっていなかったりします。

既にプログラミングと設計を何年か行っているがUMLを全く知らない人に対して、上の流れで行った場合は、もう少し理解度が高いと思います。それは、仕事の中で、「状態」や「遷移」というものを意識し、UMLではないですが、何らかの図法や記法を使って書いていたりするからだと思います。 Java言語をちゃんと理解しているプログラマーは、Ruby言語の本を一冊読めば、ほぼ直ぐに Rubyでプログラミングできると同じです。

新人に上の流れで教える際に足りないのは何でしょうか？
今回おしえていて、 "3. サンプル図を使って、その図の説明" ではないかと思い当たりました。彼らが課題を書く時点で知っているステート図は、サンプルの図１つのみなのです。課題がサンプルとかなり似たものであれば、サンプルを少し変更して課題を書き上げられるかも知れません。ただし、それではサンプルに似てない図は書けないままです。

サンプル図の数を、もっとたくさん提示し、その図を読んでもらう練習を行ったらどうでしょうか。いろいろなパターンの図を読むことで、頭の中に、その図のイメージが作り上げられて行くのではないでしょうか。また、彼らが新人教育が終わり現場に配属された際に、いきなりUMLを書く事は無いわけで、まずは先輩等が書いたUMLをもとにシステムを理解したり、実装したりする仕事が主なはずです。その際にはUML図を読む能力が必要です。

今回の教育では今からUML図を読む量を増やすのは無理なのですが、私が今後行うソフトウェアの教育では、ソースコードや設計図面を読むことに時間を使うようにして行きたいと思います。