ソフトウエア・パターン(Software Pattern)とは,ソフトウエア開発における「問題(Problem)」と「解決策(Solution)」を一つの組みとして示した文書(文章や図,絵,サンプル・コードなど)のこと。名前に「ソフトウエア」と付いているが,その実体はソフトウエアではない。通常は,特定の分野に関する複数のパターンをカタログとしてまとめ,書籍やWebサイトを通じて公開される。

 パターンの目的はソフトウエア開発で直面する様々な問題とその解決策を明快に示すことだ。先人の経験に裏打ちされていることから,パターンは先人の知恵とみなすことができる。パターンで示されている問題に実際に直面したとき,そこに書かれている解決策は大いに参考になる。

 例えば,最も知名度の高いパターンにGoF(Gang of Fourの略)の「デザイン・パターン(Design Pattern)」がある。このパターンは,主に詳細設計で直面しがちな問題を23種類のパターンとして示している。その中のオブザーバー(Observer)パターンでは「あるオブジェクトの変化を他のオブジェクトに伝えたいが,通知したいオブジェクトを静的に決定できない」という問題を提起。その上で「通知するオブジェクトに対して共通のインタフェースを実装し,それらを変化するオブジェクトに登録する」という解決策を示している。

開発の難しさが急拡大を後押し

 これまでソフトウエア・パターンと言えば,ソフトウエア開発の分析,設計,実装の各フェーズを対象にしたものが中心だった。具体的には,クラス/データモデルの分析フェーズでは「アナリシス・パターン」や「データモデル・パターン」,基本設計フェーズでは「アーキテクチャ・パターン」や「エンタープライズ・インテグレーション・パターン」,詳細設計では「デザイン・パターン」,実装フェーズでは「イディオム」――といった具合である。

 ところが,ここに来てパターンの適用範囲が急速に拡大している(図1)。背景にあるのは何か。パターンに詳しいサイクスの宗雅彦社長は「分析/設計/実装といったエンジニリング・プロセスの知識だけでは,高品質なソフトウエアを素早くかつ確実に作れなくなったこと」と見る。言うまでもなく,開発すべきシステムは大規模化・複雑化し,短納期や高品質への要求も高まるばかり。そうした中では,ソフトウエア開発の「問題」も分析,設計,実装にとどまらない。これを受けて,適用範囲が広がりを見せているのだ。

図1●適用範囲が急拡大するソフトウエア・パターン
図1●適用範囲が急拡大するソフトウエア・パターン
従来型のエンジニアリング・プロセス(分析/設計/実装)に関するソフトウエア・パターンには,最上流の業務分析に関するパターンが追加された。また,マネジメント・プロセスやテスト・プロセスといった新分野のパターンも登場した
[画像のクリックで拡大表示]

 では,具体的にどんなパターンが登場しているのか。その方向性は大きく三つある。一つは業務分析など,より上流工程に焦点を当てたパターン。二つ目はマネジメントに関するパターン。そして三つ目はテストに関するパターンだ。順番に詳しく見ていこう。

パターンの起源は建築の世界にある
 ソフトウエア・パターンの歴史は意外に古い。起源は,建築家であるC.Alexander氏が1970年代に著した「パタン・ランゲージ―環境設計の手引」と「時を超えた建設の道」という本に遡る。これらの本では,よい社会を作り上げるための建築のセオリーを「パターン」として定義。「癒し(Heal),修復(Repair),成長(Growth)の三つを“よい社会”の条件としたC.Alexander氏の発想は斬新。ソフトウエア開発でも学ぶべきところが多い」と,「Alexander読書会」を主宰する一人である横河電機の沖田直幸氏(IA事業部 システム事業センター プラットホーム開発部 技術スペシャリスト)は説明する。

 その後,1987年にXPの提唱者であるKent Beck氏らがソフトウエア開発でもC.Alexander氏の考え方が有効なことを提唱。1993年にはパターンに関するコミュニティ「Hillside Group」が発足し,ここで毎年主宰する「PLoP」と呼ぶイベントで,様々なパターンが発表されている。

出典:日経SYSTEMS 2006年11月号 134ページより
記事は執筆時の情報に基づいており、現在では異なる場合があります。