誰もが目にしたことがあるこちらの本。
中身を読んでみると、なんのことはない、ソフトウェアを作っている人なら誰でも一度は考えたことがあるような内容です。
これを読んで「目からウロコ」、という人はあまりいない。

でも、ものすごく影響力のあった本です。
何がそんなに良かったのか？・・・あとまわし。

UMLが本格的にプロジェクトで利用されるようになったのも、このころです。Unified（統一）という名前が示すとおり、世界中の誰もが理解できる、設計書の共通言語として注目されました。

UMLは、慣れない人にとっては、変な絵がたくさん描いてある、幼稚な設計書のようにみえます。しかし、その幼稚さが大事でした。なぜなら、バカバカしいほど簡単にした絵は、だれもが理解できて、誰もがそれを描くことに参加できるからです。UMLが目指していた理想とは、そういうことでした。

そのことに理解を示すお客さんやSEは、まだまだ少ない時代だったと思います。今でもそうかもしれません。
UMLの普及が滞ったのは、UMLそのものにも原因があります。理想として目指していたほど簡単ではなかったこと、表現に曖昧さが残ること、ビジュアルが乏しいこと、WordやExcelに書き込むのが面倒なこと、など。確かにこれでは、理解をえるのは難しいのかもしれませんね。

本文とは関係ないけど、ここで、書籍の紹介。

数あるUMLの解説本の中で、この本がもっとも実践的でわかりやすいと思います。UML使ってみたけどいまいち不安なかた、オブジェクト指向設計に自身のない方、ベテランの方も、一度読んでみて下さい。これこそまさに、目からウロコ。

デザインパターンの功績は、作る方法の「名前を統一」したことにあります。これによって、世界中のSEは、ファイル名（あるいはクラス名・ディレクトリ名）を見ただけで、何をやるためのプログラムなのかを判断できるようになりました。新聞の見出しを斜め読みするように、プログラムソースコードを斜め読みできるのです。これは大きい進歩でした。

2000年よりもうちょっと後、オープンソースが普及したのは、デザインパターンによる「斜め読み効果」は無関係ではないと思います。実際わたしも、いろんなオープンソースのソースコードを読んできましたが、デザインパターンを覚えたおかげで、採用不採用の判断が確実にスピードアップしましたし、採用を決めたあとのメンテナンスも楽にできるようになりました。

つまり、ＵＭＬもデザインパターンも、本質的な目的は何かと言えば、「統一」して、みんなで会話できるようになりましょう、ということです。
標準語として英語を学ぶことと同じことかもしれませんね。

オレ流 All or Nothing 論法で、前回の最後になげかけた問いに、答えてみます。

他文化（他社・チームメイト・引継チームなど）との会話が必要ない「使い捨てプロジェクト」であれば、デザインパターンもＵＭＬもまったく必要ありません。※使ったほうが高くつくか安くあがるかは、そのプロジェクトチームに依って違うでしょう。

デザインパターンが本当に活きる瞬間は、開発している最中ではありません。

• システムを他のチームに引き継ぐとき
• ２年前に作ったシステムを改修するとき
• ライブラリを複数プロジェクトに展開するとき

などの、担当者が変わるときや長いインターバルから立ち上がるときです。

上流工程での「長期的な作戦」が絶対に必要です。それがなければ、プログラマがいくら「デザインパターンで作りました！」と粋がっても、優秀なプログラマは育つかもしれませんが、安くはなりません。


笑顔の奥で、そういうことをずっとつぶやいていた、2001年の営業活動でした。