★★★★☆ "UML モデリングの本質"

「いつか、この水準が標準になることを願う。」
"UML モデリングの本質"
タイトルに UML と付いているが、この本で初めて UML を学習するのは無理があるので、それを期待してはいけない。また、UML を覚えたばかりでは、すべてを理解することは難しいかもしれない。ある程度のモデリングを経験し、思い悩んでいる人こそが、この本から得るものがもっとも多いだろう。

私は、モデリングでもっとも難しいのは、"今まで見えなかったものを見る" ことだと思っている。普通に会話している時には、話している言葉の意味や対象とする物がころころ変わっているのだが、脳が勝手に補完してしまうので、変化にはなかなか気付かない。ところが、モデリングではそこを明確にすることを迫られるし、概念と対象物の分離を迫られるケースも多い。これは簡単なことではない。

日常生活において、映画のタイトルと、それが記録されているビデオテープを明確に区別しなければならないシチュエーションはないだろうし、飛行機の予約が実は "着席権" を買っていることだったと認識してるのは、認知科学者か法律家ぐらいなものだろう。しかし、モデリングに求められるのは、こういうことなのだ。いくつかの例を取り上げて、こういった実際のモデリングを伝えようとしている訳だが、文章だけでなく、モデルもじっくりと読んで、それをつかみ取ることが大切だ。

本書では、モデリングするだけでなく、さらに、「良いモデル」「美しいモデル」であることを要求している。目に見えないものの厳密性を追及し、それを紙の上に留めるだけでも難しいと云うのに…だ。とは云え、モデラーの自己満足を良しとしている訳ではないので、そこは誤解無きよう。著者とは違う理由を述べるが、現実問題として美しくなければ「読めない」のだ。間違いがあるのか正しいのかを検証できないモデルを基にして開発を進めるのは危険であるし、読み解くのに大幅な時間がかかっていては、厳しい納期に間に合わせることも難しくなる。リスクヘッジと生産効率の観点からだけでも、「良いモデル」であることが求められるのだ。

ただ、最初から良いモデルを書くことを要求しているのではなく、エスカレーション、リファクタリング、"揺さぶり" など、モデルを発展させてゆくプロセスも書かれている。形式的で無意味なレビューで次の工程に進んでしまう現場が多いと思うが、目的は儀式を行うことではないし、モデラーの能力を測定することでもない。システムを作ることこそが目的なのだから、こういう発展させるプロセスまでしっかりと盗み取ってもらいたいものだ。

UML を知っている人はいても、"ちゃんと" 読み書きできる人はまだまだ少ないが、モデリングの本質が理解されていないと云うか、価値が認められていないと云うか、システム開発の過程における途中成果物に過ぎないと軽視されているところに、"甘さ" があるような気がするが、このあたりの価値観が変わらなければならない。

今は、システム開発のためにモデリングを行っていることがほとんどだと思われるが、モデルは発注元の資産となるべきものだ。例えば「以前の在庫管理システム」「新しい在庫管理システム」では、帳票と画面、動かすハードウェアは異なっても、業務そのものはほとんど変わらない。管理項目が多少増えたり、取り扱う品目が変わったりしているかもしれないが、それらは巨木の枝葉に過ぎない。なのに、一からモデリング*1をやり直し、膨大な時間とコストをかけて開発をしているのだ。その上、うまくいかないケースが多いと云う悲惨な状況である。

間違いや矛盾を抱え、読みにくくて枚数が多いだけの文章しか見た事がなければ、なかなか分からないことかもしれないが、"モデリングの本質" の水準であれば、実装とは切り離された使えるモデルが成果物となる。紙の枚数は少ない上に、厳密に定義された正確なモデルは、何度でも再利用ができる。そうすれば、システム開発にかかる費用、期間は 1/3 程度で済む*2ようになるだろうし、迅速なビジネスの変化への対応性も大きく向上することになるだろう。

システムは既にインフラと呼んでもおかしくないほど企業にとっては欠かせないものであり、使いこなせるかどうかは将来の展望に大きく関わってくるはずだ。と云うことは、発注側こそがモデルを理解し、効果的に使いこなすことスキルを磨かなければならないのかもしれない。そういう層までこの本が読まれ、モデラーの需要が高まることを願っている。

UMLモデリングの本質 (日経ITプロフェッショナルBOOKS)

UMLモデリングの本質 (日経ITプロフェッショナルBOOKS)

*1:モデリングと意識していなくても、開発の中に間違いなく含まれている。意識されてない場合は、再利用は不可能だと思って間違いないだろうけど…。

*2:2/3 程度は無駄になってると云うこと。開発量も分からないうちに目分量で見積もりを出していることや、開発の時間の大部分は"よく分からないことを明確にする"ことに費やされているからだ。正味の開発時間は、たぶん 1/3 ぐらい。