連載　オブジェクト指向と哲学
第16回　パターン言語 - ソフトウェアへの浸透

　前回は、パターン言語のキーワードである「無名の質」について考えました。「パターン言語とは何か」の説明は後にして、外堀から埋めてゆきます。

　パターン言語は本来の建築の世界よりもむしろソフトウェアの世界に取り込まれてきています。その流れは大きくふたつあります。第１はデザイン・パターンから始まった一連のソフトウェア・パターンの一大潮流です。第２は一連のオブジェクト指向開発プロセスへの影響です。統一プロセスRUPや、その対極として生まれたXPから始まったアジャイル開発ブームにパターン言語の考え方がとり込まれてきました。

●デザイン・パターン
　‘94年に出版されたGoFのデザイン・パターンは、ソフトウェア開発の世界に一大センセーションを引き起こしました。
　--
　“Design Patterns −Elements of Reusable Object-Oriented Software”[1]
　邦訳「オブジェクト指向における再利用のためのデザインパターン」[2]
　--
　この書籍はクリストファ・アレグザンダー（C.A.）のパターン言語に触発されてまとめられたものです。同著の始めにC.A.からの引用があります。

　「それぞれのパターンは我々の身のまわりで何回も起きる問題、および、それぞれの問題に対する解法のポイントを記述している。そこで我々は、これらの解法を何万回でも使うことができる。同じ問題に対する同じ解法を何度も何度も最初から考え直さずに済むというわけだ」[2]

　オブジェクト指向が「ソフトウェア部品の再利用技術」なら、パターンは「知識の再利用技術」と言える。

　単純化すれば「問題と解法」のペアをC.A.はパターンと名付け、そのアイデアがデザイン・パターンになったわけです。パターンという普通に使われている名詞にC.A.は別の意味付けを行い、それが支持されたわけです。

　GoFのデザイン・パターンは、過去様々な開発で何度も使われた設計のテクニックを調査し、パターンという視点で23のパターンとして集大成したものです。

　ちなみにこの書籍の初版では、各パターンのモデルはUMLではなくOMT法で記述されています。UML0.9がOMGに提出されたのが’96年なので、本書が出版された‘94年は正にUMLの前夜です。オブジェクト指向開発方法論の統一が議論されていた時代です。

　アーキテクチャ・パターン、アナリシス・パターンなど一連のソフトウェア・パターンが次々出版されてきました。従来の開発プロセスの問題に焦点を当てたアンチ・パターンという風変わりな書籍もやはりC.A.のスタイルを踏襲しています。

●パターン集とパターン言語
　一連のソフトウェア・パターンはパターン・カタログとしてとても有益なものです。役に立つのだからそれが単なるパターン集なのかパターン言語なのかという議論は利用者にとってはささいな問題です。

　UMLで表すと、パターン集はパターンで構成されています。個々のパターンは、単独で存在するのでなく他のパターンと関連します。（図1）

　パターン集とパターン言語の違いをUMLで表現するのは困難です。パターン言語にはパターン集にはない何らかの特性と振る舞いがある筈です。（図2）

　前回「SFC学習パターン」をパターン言語の事例として紹介しましたが、これは単なるパターン集、ノウハウ集以上に強力なパワーが内包されています。一つひとつのパターンはそれなりに有益なものですが、相互に関連するパターンのネットワークが強力なパワーを発揮します。前回述べたようにパターン言語とSECIモデルは全く別々の概念ですが、アレグザンダー方式でパターンを整理してパターン言語化してゆくと、いつのまにか知らずSECIモデルの４つの象限をカバーしてしまっています。学習パターン（言語）はいつのまにか知識創造パターン（言語）に進化しているのです。

　第１のムーブメントである一連のソフトウェア・パターンは必ずしもパターン言語化を目指したものではないようです。しかし第２のムーブメントであるソフトウェア開発プロセスへの流れはパターン言語を目指したものです。

●XP−eXtreme Programming
　‘99年に出版されたケント・ベックのXP[3]は、GoFのデザイン・パターンと並ぶ一大センセーションを引き起こしました。正にアレグザンダーのパターン言語なのですが、それを前面に出すと開発技術者は引けてしまうので、敢えてパターン言語という言葉を表に出さないでまとめられています。

　有名な「ペア・プロ」、「オンサイト・カストマ」、「テスティング」、「週40時間」など12のプラクティスがパターンです。これらは単独でも役立ちますが、相互に関連があり、すべてを最大限に、極端に（extreme）実践するのがXPという極端な開発プロセスです。

　この12のプラクティスは、ソフトウェア工学などの理論から導き出されたものではなく、著者達の開発プロジェクトでの経験に基づき集大成されたものなので、プログラマには説得力があります。

●場のクオリティ
　C.A.の目指しているものは建物や町のハードウェアだけのクオリティではなく、そこで生活する住民も含めた場のクオリティです。場のプレイヤーである住民が生き生きと活動でき(alive)、住民と建物や町が全体として一体感があり(whole)、住民は居心地のよさを感じられる(comfortable)など人間系を重視しています。

●品質とは？
　開発プロジェクトが目指すものはQCDです。顧客の要求を満足する高品質の製品を決められた予算で決められた納期までに完成させることです。
　品質という言葉、当然ながら通常は製品の品質を意味します。しかし品質が必要なのは製品だけではありません。要求の品質というものもあります。要求の品質は製品の品質に大きく影響します。さらに開発プロジェクトの品質も製品の品質に大きく影響します。
　XPから始まったアジャイル開発がプログラマに支持されたのは、人間系も含めた開発の場のクオリティに焦点を当てたからです。クオリティのある開発プロジェクトからクオリティのある製品ができる。

●XPが目指す「場のクオリティ」
　XPが目指すものは、開発チームのメンバーをいかに活性化させるか、モチベーションを上げるか、生産性を上げるかにあります。12のプラクティスは、開発プロジェクトという場のクオリティを作りだす源となる実践原理となるものです。プロジェクトのクオリティが結果として製品のクオリティを創出します。
　場としての開発プロジェクトの主なプレイヤーは、依頼主である顧客、完成したシステムの利用者、開発メンバーです。XPにはオンサイト・カストマというプラクティスがありますが、このカストマは依頼主と利用者の代表です。XPの12のプラクティスはこの開発プロジェクトのクオリティを作ります。XPがなぜプログラマに支持されているかというと、人間重視の開発の場のプレイヤーみんなが生き生きと仕事ができ(alive)、メンバー間および開発する製品の一体感のある組織であり(whole)、開発メンバーは快適で居心地のよい環境で仕事ができる(comfortable)からです。

【参考書籍】
　[1] Erick Gamma他, “Design Patterns−Elements of Reusable Object-Oriented Software” , ADDISON-WESLEY, 1994
　[2]本位田真一、吉田和樹【監訳】、「オブジェクト指向における再利用のためのデザインパターン」、ソフトバンク、1995
　[3]Kent Beck, ”eXtreme Programming eXplained”, ADDISON-WESLEY, 1999