構造化スキルとUMLモデリング

2日連続で法律を構造表現する話を書いたが、そのついでにネットをブラウズしたら次の記事を見つけた。
http://www.atmarkit.co.jp/fbiz/cinvest/serial/expert/07_03.html

タイトルはなんと「“構造化スキル”を鍛えて、問題発見力を高めよう!」である。自分としては、データモデリング以外の場面でUMLモデリングを利用するのは、ちょっとしたお遊びぐらいに考えていたが、似たようなことをまじめに考えていらっしゃる方がいたので驚いた。そして、やっぱりそうなのかと思えたので、ちょっぴり嬉しくも感じた。

実際、上記の文章の主張と、今回の連載で自分が書いたモデリングのパターンはよく似ているところがある。物事の関係として挙げられている5つの中で「分類」と「全体と部分」の2つは、自分も基本パターンとして取り上げたから。

しかし両者には本質的な違いがある。この違いは、物事を整理する基本的な単位として、インスタンス(個々の物事)、クラス(同じ性質を持つ物事の集まり)のどちらを使うかに起因しているように思える。上の記事で「分類」「全体と部分」「並列」「原因と結果」「時系列」と整理しているのは、いずれもインスタンス同士の関係で、描かれている図もオブジェクト図に相当する。しかし自分が連載で説明したパターンはすべてクラス図であり、集合同士の関係や集合の要素が共通に備える性質を表現している。

実は、戦略コンサルが使うロジカルシンキングの手法と、IT技術者が使うUMLやデータモデリングの違いはここにあると思っている。戦略コンサルの仕事は企業の課題を整理して、進むべき方向や打つべき施策を提言することである。主に対象とするのは、ある企業の“具体的な”課題や目標である。「課題と対策」の関係が多対多であることがわかっても、具体的な課題や対策が何かを特定できなければ改善のしようがない。

一方、IT技術者の仕事は最終的にソフトウェアを作ることである。特定の企業向けにソフトウェアを作るにしても、取り扱う情報は“不特定多数の”顧客や商品、取引先を扱えるように均一化する必要がある。このため集合論をベースにした構造表現が必要になる。

この、戦略立案や業務分析段階での構造表現ではインスタンス同士の関係の分析が重要で、ソフトウェア開発段階以降からはクラス同士の関係の分析が重要になる、という違いは今勤めている会社で前者の仕事に実際に関わったことで学んだ。したがって、システム開発より以前の段階に過度にUMLを持ち込むのはナンセンスというのがここ数年の持論である。(ただし業務フローにアクティビティ図やDFDを使うのは問題ないけどね)。

UMLをビジネスモデリングでも利用したいならば、オブジェクト図のセマンティクスをもっと充実させるべきだと思う。