ソフトウェア工学は、違った方向に行っているのかもしれませんね？

　昨日の、

UMLからNoUMLというのは、青い鳥な図を探していると思う
http://blog.goo.ne.jp/xmldtp/e/8ee5111962a4e2067bf00dbc9a9234d6

の続きみたいな話。

　ソフトウェア工学の傾向として、はじめの志はいいかもしれない。
　でも、ある方法、理論ができてしまうと、今度、「その理論を守ればいいのね」というカタチになりがちだと思う。

ＥＲ図など
　エンティティを作って、属性を埋めて、線（リレーション）でつなげばいいのよね

ＵＭＬだと、
　ＵＭＬで書いて、図を埋めればいいのよね。

ＴＤＤだと
　JUintで緑にすればいいのよね

　しかし、これらは、本質的に違ってきてしまう。

　たとえば、ＥＲ図をかくにしても、ＵＭＬをつくるにしても、お客さんの要望を聞いて、ステークホルダーが理解しやすくするためのモノだったけど、お客さんの要望を聞くことや、みんなの理解はさておき、図を書くことに集中してしまう。

　この結果として、本質的な、「要望を聞く能力」や「理解してもらうために必要な能力」とかは、あまり研究されず、整理術、整理法とでも言うべき図の書き方などが発展し、いろいろな概念が出てくるが、肝心な部分が発展しにくくなってきていると思います。

う～ん、ソフトウェア工学は、違った方向に行っているのかもしれませんね？