パターンランゲージの形式と正当性

パターンランゲージについて調べ直している。
コプリエンの組織・開発工程のパターンランゲージの序文がとても意味深だったので、理解できたことをメモ書き。
「プログラムデザインのためのパターン言語―Pattern Languages of Program Design選集」にも記載されている。

【元ネタ】
生成的開発プロセス・パターンランゲージ

はじめに

生成的開発プロセス・パターンランゲージ - lamuuの勿忘草日記

Scrum:超生産的ソフトウェア開発のための拡張パターン言語

- XPとパターン Ralph Johnson'sの見解

- 組織パターンとプロセスパターン(石井 勝)

【1】アレグザンダーが生み出したパターン言語というアイデアを、IT業界にも使えないか、という発想が生まれた。
GoFもケントベックもカニンガムもコプリエンもその流れにいる。
その辺りの経緯は「パターン、Wiki、XP ~時を超えた創造の原則」に詳しく書かれていて、とても面白い。

GoFはデザインパターンというプログラミングの定石ともいえるパターンを作った。
コプリエンは、その直前に「生成的開発プロセス・パターンランゲージ」という論文で、ソフトウェア開発の組織・開発工程のパターンランゲージを42個提唱した。

【2】パターン言語の特徴は、「特定の状況(Context)で発生した問題(Problem)に対して解決法(Solution)を提示する」という定型的なスタイルで簡潔に形式知を説明してくれること。
例えば、GoFのデザインパターン24個も、ある特定の状況の特定の問題に対して有効なのであり、すべての状況で有用なのではない。

例えば、システム提案時に、顧客の現在の業務を洗い出した後、システム化であるべき姿を提示するプロセスがある。
このプロセスは、AsIs(現状の姿)に対するToBe(あるべき姿)を提示するわけだが、パターンはまさにその形式に当てはまる。
つまり、現状の問題点に対し、パターンが問題解決してあるべき姿を提示してくれるわけだ。

パターンの形式はいくつか流派があるが、コプリエンの形式はアレグザンダーのそれに近いらしい。

パターン名称(Pattern Name)：
問題の解決の仕方などが直感的にイメージできるような名前。

別名(Alias)：
上記のパターン名称の別名。すべてのパターンが別名を持っているわけではない。

問題(Problem)：
解決したい問題。

コンテキスト(Context)：
問題が発生しているまわりの状況や、問題を解決しようとしている人が置かれている状況。

影響する事柄(Forces)：
問題解決に際して影響を与える事柄や考慮しなければならない事柄。

解決策(Solution)：
問題解決策。

結果として生じるコンテキスト(Resulting Context)：
問題を解決したことによって生じる状況。

論理的根拠(Rationale)：
パターンが効果があることの論理的な根拠。

上記のパターン形式が従来のノウハウのような経験知よりも優れているのは、どんな問題に対して解決法が有効であるのか、というだけでなく、パターンで問題解決した後、どんな変化が生じるのか(結果として生じるコンテキスト)、パターンが有効であることの根拠の説明などを一貫して説明できること。
特に、影響する事柄(Forces)や論理的根拠(Rationale)では、他のパターンと組み合わせた方が良いとか、パターン適用後に別の問題が発生したら他のパターンを使え、など、パターンの関連性についてとてもよく考えられている。
パターンは、単なる思い付きのアイデアではない。
パターンは「生成的(generative)」である点がとても重要。

【3】だが、そのパターンが本当に正しいのか、という正当性の問題は残る。
はじめににも書かれているように、パターンの正当性は「ケーススタディと常識をよりどころとしている。」
何故なら、以下の理由が3点挙げられる。

(引用開始)
それらのパターンの“良さ”とか“悪さ”は、実験によって確かめることは困難である。第１に、組織の良さの測定は、必然的に多次元で複雑である。第２に、パターンの有効性が検証できるよう制限の強い制御変数を用いて大規模な社会的な実験をするのは困難である。第３に、そのような実験は長期間の関与が必要で（何ヶ月あるいは何年も）、多くのソフトウエア組織が、壊れやすく進化し続ける市場から見て、進んで費やしようと思う期間を超えている。
(引用終了)

パターンは現場の経験知、つまり、何度も繰り返し現れる問題とその解決法を形式知としてまとめたものであるがゆえに、本当にその解決方法は全ての現場でも使えるのか、という疑問は常にある。
パターンの正当性は、いくつかのケーススタディという事例と常識に依存しているために、パターンが問題の全てを解決しているのか、効果があるのか、という点は慎重な考察を必要とする。
コプリエンは、数多くの人たちの経験的観察から検証されていると補足説明している。

(引用開始)
我々は、相互作用に関連して組織で繰り返し発生するパターンを調べ、それらのパターンとある“良さ”の観測の関係が繰り返されるパターンに注目し、そして相関関係を分析する。ここで説明されるすべてのパターンにおいて、パターンを説明する論理的根拠に経験的な観察が付け加えられている。このパターンランゲージが高生産性の組織が持つ本質的な特徴を全体的に掴んでいるという主張は、これらのパターンを読んだ、多くの小さくて生産性が高い組織のCEO達によって検証されている。
(引用終了)

【4】パターン言語の文献を読んでいると、日本のIT業界ではプロジェクト管理やDOAを中心としたモデリング技法、製造業を発端とした品質管理の技法について歴史があるにも関わらず、なぜパターンのような形式知としてまとめられなかったのか、いつも疑問に思っている。
多分、日本のIT業界では、それらのノウハウは門外不出として公開できなかったため、各SIでバラバラのノウハウとして蓄積されていて、一つの体系としてまとめられなかったのが理由だろうと思っている。

忘れ去られた日本のIT技術～プロジェクト管理: プログラマの思索

忘れ去られた日本のIT技術～DOAと品質管理: プログラマの思索

コプリエンの組織・開発工程のパターンランゲージを読んでいると、XPのプラクティスと関連する箇所が多い。
Scrum:超生産的ソフトウェア開発のための拡張パターン言語によれば、Scrumに出てくる概念やプラクティスの背後には、コプリエンの組織・開発工程のパターンランゲージが関係しているという。
「アジャイルソフトウェア開発スクラム」でも、同様の記述がいくつか出てくる。

つまり、アジャイル開発の背後には、コプリエンのパターンランゲージが隠れていて、アジャイル開発がなぜ有効なのかという理由の一つには、コプリエンの組織・開発工程のパターンランゲージという優れたパターンがあり、すでに実証されているから、と言えるのではないだろうか。

チケット駆動開発も「ITSとバージョン管理の便利な使い方」から発生した現場の経験知の一つ。
だからこそ、パターン言語のような形式の方が、チケット駆動開発がなぜ有効なのか、という理由を明確にしてくれると思っている。
そして、チケット駆動開発のプラクティスをコプリエンの組織・開発工程のパターンランゲージで補強説明することで、プラクティスの特徴をうまく説明できるのではないか、と思っている。