ソフトウエアパターンとは何か
ソフトウエアパターンとは
これから3回ほどで、ソフトウエアパターンについて紹介したいと思います。今回は、ソフトウエアパターンとは何で、どのようなものがあるのか、全体像をつかんでもらいます。
ソフトウエア開発の現場でパターンというと、まずはGoF（Gang of Fourの4人組）のデザインパターンのことが想起されるでしょう。オブジェクトを実装クラスと切り離して生成できるようにするFactoryパターンだとか、再帰的な木構造で汎用的なコンポーネントを作り出すためのCompositeパターンだとか、オブジェクト間の通知の仕組みをほかのオブジェクトと独立に登録管理できるObserverパターンといったものが代表例です。
皆さんも、アプリケーションを設計したり・改良したりする際にお世話になったことがあるのではないでしょうか。デザインパターンとは、よく出くわす典型的な設計課題に対する一般的な設計解法をペアにしてカタログ化したものですから、具体的な設計上の問題にぶつかったときに参照してヒントにできるわけですね。
世の中一般には、「ワンパターン」と言ってパターンは創造性がない、融通がきかない、固定的なもののあり方を示す言葉です。しかしながら、ソフトウエアパターンといった場合には、それはソフトウエアに関する情報共有のために構造化されたフォーマットのことを指すのです。創造性・独創性よりも標準化され共通のスタイルで整理されていることに意味があります。どのパターンも共通のフォーマットで5W1Hが意識されて記述されているため、それを適用したいと思うユーザーは適切なパターンを見つけやすくなっているわけです。
ソフトウエアパターンの構成
ソフトウエアパターンは図1-1のようなテンプレートに従って記述されています。例えば、GoFのCompositeパターンであれば、
名前：Composite（複合オブジェクトの意）
状況：階層的ファイルシステムの開発
問題：ディレクトリ（ファイルやディレクトリを入れ子に含む）とファイルを区別なく取り扱いたい
解決：抽象クラスコンポーネントを用意し、そのサブクラスとしてLeafObject（ファイル）とComposite（ディレクトリ）を定義するとともに、Compositeをコンポーネントの集約とせよ
結果：LeafObjectもCompositeも同じインターフェースで区別なく利用できるようになる
理由：ディレクトリとファイルの論理的な階層構造と利用時の認知的な入れ子構造の実現が、共通のインターフェースをもつ抽象クラスコンポーネントの導入と適合する
という具合です。
このようにパターンというのは、ある分野のノウハウ・知識をできるだけ的確にパッケージ化・カプセル化した1つの単位だということがわかります。「名前、状況、問題、解決、結果、理由」という項目のセットで構造化された知識モジュールになっています。つまりパターンはナレッジマネジメントを構成する基本要素だと言えます。
ですから、これを利用して問題を解決したいパターンユーザーは、自分の置かれている状況を「前提」として把握し、その前提に含まれる制約条件（考慮点・特性）を「フォース」として解きほぐしていくことによって、その問題にもっともフィットした「解決の仕組み」が見つかるというわけです。こうなって初めて、複数のフォース（力）のバランスのとれた解決策（構造）のパターンをうまく選び出せ、ユーザーの抱える問題が与えられた前提のもとで解消されることになります。
クリストファー・アレグザンダーとパターン・ランゲージ
もともと建築・都市工学の世界でクリストファー・アレグザンダーがパターンの考え方を提唱したときには、それは253個のパターン記述が、「住みやすいよい街を生む」という意図の大目的のパターンから「よい環境を作り出す」ための中項目のパターンへそして個々の空間や建物の具体的な「よい形を作る」ための小項目のパターンへと有機的に結びついてネットワークを形成し、まさに「パターン・ランゲージ」を構成していました。個々のパターンという単語が文法に従って文や言語つまりランゲージを生み出す、ということです。
建築家は、パターン・ランゲージの全体像を常に参照しながら、ユーザーの要求と現場の状況と作業の目的を把握しつつ、複数のパターンを選択し組み合わせながら仮設検証型で設計・施工を実施してはユーザー参加で妥当性をチェックして見直しを掛け、全体の方向性と個別設計・施工の整合性を常に図りながら作業を段階的に行っていくのです。トップダウンとボトムアップのバランスをパターン・ランゲージを用いて行うという感覚です。
ここでは建築以外のパターン・ランゲージの例をお見せしましょう。慶應義塾大学湘南藤沢キャンパス（SFC）で井庭 崇研究室を中心に開発された、学習のための「学びのパターンランゲージ」の試みです。学生が自分自身の学びをデザインしながら学ぶことを支援し、しかもそれを変にマニュアル化せずに伝えるための手法としてパターン・ランゲージ化が行われたのです。
重要なことは40個の学習のパターンが適切に記述されモジュール化されているだけでなく、有機的な概念ネットワークを構成しているということで、一本道の単純な手順を示すマニュアルにならずにすんでいる点です。ユーザーである学生個人個人の目標やニーズ・状況にあわせて、学習方針やスタイルを模索し気付きを得ながら継続的・進化型で適用できることです。
パターン・ランゲージとアジャイル型ワークスタイルの融合
アレグザンダーの例でも学びのパターンの例でも、建築家集団や大学組織といったコミュニティーにおいて有形無形の知識や知恵を共有し、実践に生かせるようにするための仕掛けだということが重要です。したがって、パターン・ランゲージは固定的なものではなく、常にみんなで適用の成果をフィードバックしていく形でメンテナンスし、ランゲージを進化させていくという意識が重要になります。
そのためにも、パターン・ランゲージとプロジェクトベースの活動、参加型ワークショップ形式の学習、アジャイルプロセスにもとづくワークスタイル、こういった活動様式と融合して初めて、パターン・ランゲージはナレッジマネジメントの強力なツールとなることでしょう。
その他のソフトウエアパターン
現在、ソフトウエアに関するパターンは図3-1に示すように、分野別のもの、分析・設計・実装のフェーズごとのもの、マネジメント系のもの等々、さまざま登場しており、個別には活用されていると言えます。
しかしながら、ソフトウエアの世界でパターンとして親しまれているデザインパターンやアナリシスパターンは残念ながらパターン・ランゲージを構成していません。あくまで個別の問題状況に対して典型的な解法構造を提示するというカタログ的な位置づけが中心です。
一方で、Coplienらのプロセス／組織パターンはプロジェクトや組織の運営を目的としてランゲージ化され有機的なプラクティスの集合体として構成されています。またIBMがまとめたeビジネスパターン（第2回で紹介予定）も業種・ビジネス形態からアプリケーションスタイル、論理アーキテクチャ、物理アーキテクチャ、製品選択まで含めて体系化を狙って（まだまだ荒削りではありますが）アーキテクチャパターン・ランゲージを構成しています。
またアジャイルプロセスの代表であるXP（eXtreme Programming）は、利用しているアジャイラーの皆さんにはそのように理解されてはいませんが、実は価値観（コミュニケーション、シンプルさ、フィードバック、勇気、リスペクト）、基本ルール（ビジネス価値駆動、……など10個）、基本原理（フィードバックが基本、単純さの仮定、変化を抱擁）、プラクティス群（仕事をスケールさせるための実践、継続的なプロセスの実践、理解の共有の実践、プログラマーの幸福の実践）、個別プラクティス（ペアプログラミング、計画ゲーム、…など12個）が有機的にネットワークを形成しパターン・ランゲージを構成しているのです。
現在のソフトウエア開発方法論の2大発明であるパターンとXPとはいずれもアレグザンダーの思想に多くを負っているというのはまぎれもない事実です。
ソフトウエアの設計の方法を整理する際に、パターンとは別にソフトウエアエンジニアリングの原理にもとづいてシンプルな少数の原則を提示するというやり方があります。
有名なのは、James Martinの『オブジェクト指向設計原則（クラス編5個、パッケージ編5個）』です。これらはパターン・ランゲージにはなっていませんが、個別のノウハウのカタログというよりは、体系的な知恵（設計指針）を示していると言えるでしょう。実際、23個あるGoFのデザインパターンのほとんどは、「開閉原則（OpenClosed principle）」（抽象クラスを導入することで、クライアントに対しては共通インターフェースで閉じているように、なおかつ開発者はそのインターフェースの実装バリエーションを追加できること）を中心にいくつかの原則を組み合わせることで生成できることがわかります。したがって、設計原則が身についているアーキテクトはごく自然にデザインパターンを現場で適用できるはずだということになります。
ソフトウエアパターンの全体像
今回ご紹介したさまざまなパターンや原則を2次元平面にマッピングしてみましょう。
縦が目的性―汎用性の軸、横が個別的―有機的の軸ですから、特定ドメインのパターン・ランゲージは右上の第1象限、特定目的のアプリケーションフレームワークは左上の第2象限に配置されます。具体的な設計目的をもつデザインパターンやアーキテクチャパターンは第2象限、プロジェクト成功のノウハウをまとめたアンチパターンや業務ドメインにかかわらない、構造を重視した分析パターンであるストリームラインモデリングは左下の第3象限、具体的な知識・手段というよりは知恵や方針を体系化したプロセス組織パターンや学習パターンは右下の第4象限に位置づけられるように思います。
第1象限に位置づけられるのがパターン・ランゲージです。ビジネスモデリングのためのパターンとしてアナリシスパターンがありますが、これはまだカタログ的です。一方最近登場した「REAビジネスパターン」（第3回で紹介予定）はパターン間の関係性が明確なのでランゲージにはなりきっていませんが体系性は相当感じられます。そしてIBMの「eビジネスパターン」（第2回で紹介予定）になるとビジネスレベル・アプリケーションレベル・論理設計レベル・インフラ設計レベル・製品選択レベルとかなり明確にアーキテクチャのランゲージ化が志向されています。
オブジェクト指向設計原則は具体的課題解決と直接結びついているわけではないので知恵の一種と言えますが、ソフトウエア工学の体系性も併せ持つので、中少し下にしました。ここで興味深いのは、パターンランゲージを生んだアレグザンダーがここ10年ほど、パターンそのものや、自然・建築・人工物を含めた美的な形そのものを生み出すよりも根源的な原理としての「Nature of Order」（自然な「秩序」の本質）をまとめていることです。これはまさに右下の究極の第4象限に位置づけられるでしょう。
第1象限右上から第4象限右下への急転回が何を意味するのか、この転回がソフトウエア設計の方法論にも波及する可能性があるのか、などは非常に面白いテーマです。
【参考文献】
C. Alexander『パタン・ランゲージ―環境設計の手引』鹿島出版会、1984
羽生田栄一ほか『ソフトウエアパターン入門～基礎から応用へ～』SRC、2005
Kent Beck『XPエクストリーム・プログラミング入門―変化を受け入れる』ピアソンエデュケーション、2005
W. Brown, R. Malveau, H. McCormick, T. Mowbray『アンチパターン：ソフトウエア危篤患者の救出』，ソフトバンク，1999
「学習パターンの公開」（http://learningpatterns.sfc.keio.ac.jp/index.html）
