パターンを使うもう一つの動機～パターン言語の構築よりも設計・実装・運用のノウハウをカタログ化する

パターンを使う動機が2種類あり、最近は別の動機があるという記事を見つけたのでメモ。

【元ネタ】
Ajaxデザインパターン｜Ouobpo

パターンの次世代｜Ouobpo

【参考】

パターン言語の構造と事例 from akipii Oga

SECIモデルの具体例(Scrum・チケット駆動開発など) from akipii Oga

(引用開始)
　以前も書いたが、この書籍で見られるのも、知識を体系化するための技法としてのパターン言語だ。本書から引用すれば、次の通りだ。
Since the Ajax Patterns began to be published, the focus has always been on the "Ajax" and not the "Patterns."
（このAjaxパターンを公開し始めてから、常に「パターン」ではなく「Ajax」に力点を置いてきた。）
発見されるべきものとしてのパターンではなく、知識をまとめるツールとしてのパターンの動きは、今後ますます充実していきそうだ。
(引用終了)

(引用開始)
　つまり、ここで挙げた2つの書籍はどちらも、パターンを書くために書いたものではなく、著者が言いたいことを上手く伝えるための手段として、書籍の形式としてのパターンが選ばれただけなのだ。

　結果的にできあがる書籍は同じようなパターン書籍であったにしても、この両者の執筆スタンスの違いは大きな違いを生み出すと考えられる。
　パターンを書籍の一形式として扱う場合、パターンを書く、という行為に対する自制はほとんど効かなくなる。
　「古典的な」パターンコミュニティにおいては、パターンとは時間の試練によって鍛えられたものであって、決して斬新な発明であってはならないという認識がある。パターンの著者たちは、「実際に三回以上出会ってからでないと、それをパターンとして記述してはならない」というルールをもっている。
　しかし、パターンを単にコミュニケーションを円滑にするための形式だと捉えてしまうと、こうした厳格な自制は働かなくなっていくだろう。
　コミュニケーションの手段というエクスキューズによって、よりカジュアルにパターンをでっち上げられるようになる。
　（HohpeやEvansが軽い気持ちでパターンを書いたと思っている訳ではない。
　彼らは長年の経験から、何度も使ってきたノウハウを文書化したはずである。
　私が指摘したいのは、今後パターンがたんに書籍の一形式になりうる可能性である）
(引用終了)

古典的なパターンの考え方は、長年の経験から、繰り返し出現する問題やその問題解決を抽出し、カタログ化し、パターン言語としてまとめるためのものだった。
しかし、最近の特徴として、「エリック・エヴァンスのドメイン駆動設計」「Ajaxデザインパターン」では、知識を体系化するための一技法としてパターンが使われているらしい。

この考え方にはとても共感する。
XPでは、プロセスのパターンを故意に「プラクティス」と呼んで、実践的な運用ルールとして提示し、その過激さの裏でその重要性を示した。

更に１歩進めると、現場で得られた経験知、実践知は、パターンという形式でまとめることで、そのノウハウを再利用できるだけでなく、コミュニケーションを促進することもできる。

何らかの事象に「パターン名」という名前をネーミングすることで、その言葉に新たな価値を注入し、よりたくさんの現場で実践されて、検証されて、人々の中で確かな知識や概念として定着していく。

以前の下記のTwitterを思い出しながらすごく共感している。

Twitter / quicy: チケット駆動開発は、ミニマムなライトウェイト手法に一通りの体系化とカッコいい名前を与えてくれたことが、ものすごく大きな功績だと思います。

Twitter / sakaba37: それまでどこのメーカーでもしていたことが、プロダクトラインと言う言葉ができて議論できるようになりました。チケット駆動開発もその言葉の普及は重要なことの一つだと思っています。

Twitter / sakaba37: 新しい言葉がはやる時、その言葉は新しい意味・新しい価値を持っている。チケット駆動開発という言葉がはやるのも、多くの人がその価値を感じているからだろう。