アカウント名:
パスワード:
立花隆が「知のソフトウェア」で KJ 法を評して言った「頭の回転の鈍い人が、集団で物を考えるのには向いている」に私も同意しています。紙にわざわざ書き出してそれを並びかえるという作業をなんでわざわざしなければいけないのか、それがとうとう理解できなかった。
が、発想法は人それぞれなので、KJ 法がいいという人がいることは、それはそれでまったくいいのですが、「KJ 法を GUI で実現しました」とか「この新インタフェース技術を KJ 法に応用しました」的な研究が世の中にはゴロゴロしていて、それがどう見ても KJ 法をさらに効率悪くしたものでしかないというのにはまいりました。しかもそいつら、そのツール結局自分達で使ってないんだ。なんというか、研究ネタに困ったら KJ 法を移植する、という文化が一部にはあるらしい。それだけ見ても、KJ 法のありがたみがわかるってもんだよね、とこれは行き過ぎた皮肉。多くの人が現に KJ 法は役に立つとしておりますから (e.g. 上野千鶴子)、世の中に大きな影響を与えた故人には、敬意を表します。
#似たような位置づけにあるのが、「デザインパターン」。
KJ法はどうだか知りませんが、建築の方のパターンは集団での思考の道具としては似たような特性でしょうね。どちらもあまり興味がないのでよく調べていませんが……。
で、翻ってソフトウェアの方のパターンは、当たり前のノウハウを当たり前に共有するための記法です。もし「デザインパターンに書かれていることは当たり前で何も新しくない」という印象を持たれても、それが本来の姿です。パターンに書かれているのは「解法」ではなく「用法」なのですから、解法が斬新でないことを批判しても何にもならなかったり。
建築のパターンの方こそが、ソフトウェアのパターンのモデルだと聞いたことがあります。本質的な話ではないですが、歴史的には。
# 死ぬほどオプトピですいません。
都市計画という課題に対して、関わる人々の価値観や思いを、語彙(各パターン)の組み合わせによる物語として記述し構成する……ってコンセプトでやっているのが建築の方パターン。その形式だけを持ってきてノウハウ(ここでは「どういう状況で、どういう問題にどうアプローチするとうまくいく」という知識)の記述・共有に使っているのがソフトウェアのパターンです。
元コメントでKJ法に似ていると書いたのは、建築のパターンのアプローチです。
ただ両者は似ているようで結構違っていて、建築の方のパターンではプロジェクトに関わる人々がパターンを構築することで都市計画という"物語"を共有する、ということが目標で、そのプロジェクトで通用すれば良いので再利用はあまり考えていません。別プロジェクトではまた別のパターンが生み出されたりします。対してソフトウェアのパターンは、知識の記述と再利用に重点が置かれています。ソフトウェアの方では、さらに形式化を進めようと、UMLやその他の記法を使って厳密に表現するアプローチもあります。
違いは記述形式にも現れていまして、建築の方のパターンは原則として散文形式(一部「*** (thereforeを意味します)」といった区切りやパターンの名前などの構造はあります)なのに対して、ソフトウェアのパターンの記述ははっきりと項目分けされているのが特徴です。もちろんBeckのアナリシスパターンのように建築のパターンに近い形式をとるなどの例外はあります。
このようにパターンを考える人々の中でも立ち位置に結構な広がりがありまして、パターンを協働の道具立てと見なす立場を取る人から、単なる知識の記述手段と見なす人まで様々で、相手がどのような立場なのか知っておかないと話が混乱する原因になったりします(苦笑)。なお、「パターン言語」「生成的」「対称の破れ」といった用語を多用する場合は前者に属する方とみてよいと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
KJ法にはいい思い出がない (スコア:3, 参考になる)
立花隆が「知のソフトウェア」で KJ 法を評して言った「頭の回転の鈍い人が、集団で物を考えるのには向いている」に私も同意しています。紙にわざわざ書き出してそれを並びかえるという作業をなんでわざわざしなければいけないのか、それがとうとう理解できなかった。
が、発想法は人それぞれなので、KJ 法がいいという人がいることは、それはそれでまったくいいのですが、「KJ 法を GUI で実現しました」とか「この新インタフェース技術を KJ 法に応用しました」的な研究が世の中にはゴロゴロしていて、それがどう見ても KJ 法をさらに効率悪くしたものでしかないというのにはまいりました。しかもそいつら、そのツール結局自分達で使ってないんだ。なんというか、研究ネタに困ったら KJ 法を移植する、という文化が一部にはあるらしい。それだけ見ても、KJ 法のありがたみがわかるってもんだよね、とこれは行き過ぎた皮肉。多くの人が現に KJ 法は役に立つとしておりますから (e.g. 上野千鶴子)、世の中に大きな影響を与えた故人には、敬意を表します。
#似たような位置づけにあるのが、「デザインパターン」。
Re: (スコア:1)
KJ法はどうだか知りませんが、建築の方のパターンは集団での思考の道具としては似たような特性でしょうね。どちらもあまり興味がないのでよく調べていませんが……。
で、翻ってソフトウェアの方のパターンは、当たり前のノウハウを当たり前に共有するための記法です。もし「デザインパターンに書かれていることは当たり前で何も新しくない」という印象を持たれても、それが本来の姿です。パターンに書かれているのは「解法」ではなく「用法」なのですから、解法が斬新でないことを批判しても何にもならなかったり。
Re: (スコア:1)
建築のパターンの方こそが、ソフトウェアのパターンのモデルだと聞いたことがあります。
本質的な話ではないですが、歴史的には。
Re:KJ法にはいい思い出がない (スコア:1)
# 死ぬほどオプトピですいません。
都市計画という課題に対して、関わる人々の価値観や思いを、語彙(各パターン)の組み合わせによる物語として記述し構成する……ってコンセプトでやっているのが建築の方パターン。その形式だけを持ってきてノウハウ(ここでは「どういう状況で、どういう問題にどうアプローチするとうまくいく」という知識)の記述・共有に使っているのがソフトウェアのパターンです。
元コメントでKJ法に似ていると書いたのは、建築のパターンのアプローチです。
ただ両者は似ているようで結構違っていて、建築の方のパターンではプロジェクトに関わる人々がパターンを構築することで都市計画という"物語"を共有する、ということが目標で、そのプロジェクトで通用すれば良いので再利用はあまり考えていません。別プロジェクトではまた別のパターンが生み出されたりします。対してソフトウェアのパターンは、知識の記述と再利用に重点が置かれています。ソフトウェアの方では、さらに形式化を進めようと、UMLやその他の記法を使って厳密に表現するアプローチもあります。
違いは記述形式にも現れていまして、建築の方のパターンは原則として散文形式(一部「*** (thereforeを意味します)」といった区切りやパターンの名前などの構造はあります)なのに対して、ソフトウェアのパターンの記述ははっきりと項目分けされているのが特徴です。もちろんBeckのアナリシスパターンのように建築のパターンに近い形式をとるなどの例外はあります。
このようにパターンを考える人々の中でも立ち位置に結構な広がりがありまして、パターンを協働の道具立てと見なす立場を取る人から、単なる知識の記述手段と見なす人まで様々で、相手がどのような立場なのか知っておかないと話が混乱する原因になったりします(苦笑)。なお、「パターン言語」「生成的」「対称の破れ」といった用語を多用する場合は前者に属する方とみてよいと思います。