高品質で変化に強いシステムは，アーキテクチャの良し悪しに依存する。だがアーキテクチャの設計は，外部システムとの連携や性能・信頼性の確保など考慮すべき点が多く，困難を極める。そこで利用したいのが，先人たちが生み出した方式設計のひな型である「パターン」だ。
ここ数年で，「パターン」という言葉がよく使われるようになった。読者も耳にしたことがあるだろう。
そもそも「パターン（Pattern）」とは，ある問題の解決策をテンプレート（ひな型）として記述したものである。問題を解決する手順や方法が記されているため，パターンを利用することで，迅速かつ確実に問題を解決できる。採用したパターン名をお互いに伝え合えば，メンバー間のコミュニケーション・ギャップも少なくなる。ただし，何でもパターンになるわけではない。再利用の価値があるものだけがパターンとなる。
パターンそのものの起源は古く，1970年代に米カリフォルニア大学のC.アレキサンダー教授が著した「パタン・ランゲージ―環境設計の手引」と「時を越えた建設の道」（ともに鹿島出版会刊）という書籍に始まる。この中で，建築のセオリーをいくつかのパターンにまとめ，その有効性を提唱したのだ。
このパターンを，ソフトウエアの分析，設計，実装に適用したのが「ソフトウエア・パターン」だ。具体的には，「XP（eXtreme Programming）の父」と呼ばれるケント・ベック氏らが，1987年にソフトウエア開発にもパターンが有効であることを初めて発表。この業績が，1993年に発足した「Hillside Group」と呼ぶパターンに関するコミュニティや，「PLoP」というパターンのイベントに受け継がれた。
そして日本でも，1999年にソフトウエア・パターンのコミュニティ「JPLoP」が発足。2003年には情報処理学会のソフトウエア工学研究会内に，「パターンワーキンググループ」が発足した。ここで，ソフトウエア・パターンに関する様々な研究・啓蒙活動が行われている。
こうしたコミュニティやワーキンググループ，実際の開発現場において，ソフトウエア・パターンの有効性は既に実証されている。
ただ注意すべきなのは，すべてが「パターンありき」ではないことだ。筆者も昔そうだったが，パターンを覚えたての頃はとかくパターンを使いたがる。だがパターンは「問題」に合わせて適材適所で利用すべきものだ。何にでもパターンを使えばよいわけではない。重要なのは，パターンの特徴を正しく理解し，システム開発の各場面によって使い分けることである。
そこでPart4では，基本設計フェーズで利用できるパターンの種類や特徴について解説していこう。基本設計に携わっているエンジニアはしっかりと理解してほしい。ある程度の知識を持っているエンジニアも，復習のつもりで読んでいただきたい。
基本設計で使える3パターン
一口にソフトウエア・パターンと言っても，開発フェーズごとに利用できるパターンは異なる（図1）。基本設計フェーズで利用できるパターンとしては，（1）「インテグレーション・パターン」，（2）「アーキテクチャ・パターン」，（3）「アプリケーション・アーキテクチャ・パターン」の3つがある（表1）。
これらのパターンは，基本設計フェーズの中でも特に方式設計（アーキテクチャ設計）で利用価値が高い。方式設計では，要件定義フェーズで定義した機能要件や非機能要件，制約条件を実現するために，ハード／ソフトの構造（アーキテクチャ）を明確にし，具体的な実装方針を決定する。ここで，上に挙げた3つのパターンが有効に利用できる（図2）。
1つ目のインテグレーション・パターンは，外部システムとの連携方法を決定するためのパターンである。
方式設計では，最初に外部システムとの連携手段を決定する。外部システムがメインフレームであればELT（Extraction Load Transformation）と呼ぶファイル転送の仕組みを選択できるし，外部APIやプロトコルが明確であれば，外部呼び出しによる連携が可能だ。場合によっては，外部システム側に連携手段を持たせることも検討すべきだろう。こうした外部システムとの連携手段をパターン化したのがインテグレーション・パターンだ。最も代表的なものは，グレガー・ホペ氏の「Enterprise Integration Pattern（EIP）」である。
