> 「ＸＰをパターンランゲージとしてみると」といいましたが、
> ＸＰの場合、Coplienの組織パターンとはかなり違います。
> ＸＰにおいては、Alexanderの言うCenterとしてのパターンしか
> ないように感じています。そして方法論とは、本来もっともっと
> 広い世界から、オブジェクトの数を減らし、要約し、抽象化し、
> そしてできたものではないかと思っています。
>
> パターンランゲージは、常に開かれていますし、理論的根拠と
> 言うよりは、この根拠はコミュニティにより支えられているものです。
> また、その関係上、文化(Culture)に大きく依存します。
> 私としては、方法論などと言う狭い捉え方よりも、パターン
> ランゲージとして開かれたものを楽しみたいと思っています。
私自身あまりまとまった考えを持っていないのですが、あえて現
在の私の捉え方を述べれば、上記のようなパターンと方法論の関
係はデザインパターンとプログラム、文法と文章、生成プロセス
と成果物、といったものと思います(この場合パターンランゲージ
が生成プロセスに相当し、方法論が成果物)。この捉え方において
は方法論とパターンランゲージは同一次元のものではないことに
なります。
> ただ、「方法論的」という点で、思い出すことがあります。
> これもCoplienの話ですが、彼のプロジェクトではまず
> パターンランゲージを構築することからはじめます。
> これは、Alexanderの『オレゴン大学の実験』にあるのと、
> ほぼ同じものです。自分達が立っている文脈には、常に独自なものが
> あるため、自分達の適したパターンランゲージをまず構築します。
> ＃この多様性を無視したならパターンランゲージとはいえないでしょう。
> また、おそらく適宜自分達が直面した状況に対して、
> 適切なパターンを取り入れていくとも思います。
これはパターンランゲージ自体を構築するための方法論であり、
通常いうところのソフト開発の方法論に対するメタ方法論なので
はないかと。
(1)パターンランゲージを構築するための方法論->
(2)方法論に関するパターンランゲージ->
(3)ソフト開発の方法論->
(4)ソフト開発->
(5)ソフトウェア
> この方法は面白いと思いました。しかし、このやり方ができるのは、
> パターンランゲージのエキスパートがいる場所だけのように思います。
> ＃個人的にはどうにかしてこの方法を使おうと努力はしています。
> さらに、難しいのはそれを受け入れる土壌です。自分達で決断していける
> コミュニティやカルチャが必要です。これは『オレゴン大学...』を読めば、
> パターンランゲージの導入が大きなショックをもたらすのがわかります。
>
> そういうことなので、個人的には「方法論」としてパターン
> ランゲージを提示することは難しいと考えています。
> ＃「ソフトウェア方法論」には納まりきらないような。
深いですね…私もよくわかりません。
> ＸＰの場合は、うまく要約ができているので取り込みやすく、
> 実際の実践によりリードできる人たちが多くなっているようです。
> また現在のソフトウェア開発の土壌にもマッチするように
> 考えられていると思います。
>
> そして、その先で、ＸＰはパターンランゲージを取り込み
> はじめるような気がしています。経験知が個人や集団に集積され、
> さらに個人や集団を超えた姿が見え、それを十分再利用できる
> とわかったときに、たぶん。
集団としての経験知の蓄積&再生産のプロセスをXPは明示的に記述
していないような気がします。個人の裁量に任されているという
か…むろん間接的にはそれを強力に促しているのは誰しも同意す
ることと思いますが…。うがった見方をすればこのプロセスを規
定(固定?)しないのがXPの人気の秘訣(?)かもしれません。(この部
分は半分冗談ですが。)
--
Michitaro Horiuchi / Access Co.,Ltd.
horiuchi@....jp / horiuti@....jp