Pattern Language
Positioning
本サイトで扱う Failure Pattern は、 個別の問題や原因を分類するためのものではない。
繰り返し現れる状況と、 その状況下で生じやすい力学を単位として扱う点で、 Pattern Language の考え方と強く接続している。
ここで参照する Pattern Language は、 設計解法のカタログではなく、 問題を捉えるための思考単位としての Pattern を指す。
Scope
本 Appendix では、 Pattern Language の歴史的背景や体系的整理は扱わない。
Alexander や Coplien の議論は、 Failure Pattern という単位を採用する際の 思想的背景として参照されているにとどまる。
具体的な設計手法や組織パターンの適用については、 本サイトの対象外とする。
Mapping
以下は、本サイトの構成要素と、 Pattern Language の考え方との対応関係を整理したものである。
| 本文の要素 | Pattern Language における位置づけ |
|---|---|
| Failure Pattern | 繰り返し現れる状況を名前付きで扱う単位 |
| Context / Forces / Consequences | Pattern が成立する前提・力学・結果を分離して記述する構造 |
| Countermeasures | 解決策ではなく、力学をずらす方向性 |
| Resulting Context | Pattern 適用後に成立しうる新たな状況 |
Rationale
Pattern Language において重要なのは、 「正しい設計」を提示することではない。
特定の状況が繰り返し現れる理由と、 その状況下で取り得る判断の幅を、 共通言語として共有できる点にある。
Failure Pattern も同様に、 問題の原因を断定するためではなく、 現場で起きている状況を、 名前付きで指し示すための装置として設計されている。
References
- Christopher Alexander, A Pattern Language: Towns, Buildings, Construction, 1977.
- Christopher Alexander, The Timeless Way of Building, 1979.
- James O. Coplien, Software Design Patterns: Common Questions and Answers, 1994.
- James O. Coplien, Neil B. Harrison, Organizational Patterns of Agile Software Development, 2004.