発想言語（アブダクション・ランゲージ）の基本形式
以前このブログで、"「創造の知」の言語化 − なぜ僕はパターン・ランゲージをつくるのか？"というエントリで、「創造言語」（Creative Language）という概念を提唱し、それに関連する概念を整理した。
そのなかで、僕は、「創造言語」が創造を支援する言語であるということと、創造言語のひとつの形式が「パターン・ランゲージ」であるということを書いた。創造には、デザイン（問題発見・解決）的なものもあれば、そうではなく直感や経験にもとづく場合もある。そのなかで、デザインについてまとめたものがパターン・ランゲージなのだと考えた。
それでは、パターン・ランゲージではない創造言語には、どのようなものが考えられるのだろうか。今回は、そのひとつの案として、「発想言語」（アブダクション・ランゲージ）（とここで仮に呼ぶもの）について考えてみたい。
発想言語は、発想の型を記述した言語である。
パターン・ランゲージでは、context、problem、solutionという３つの要素で書いたのに対して、発想言語では、Context、Solution、Consequence の３つの要素が大切に思える。ただし、真ん中だけ「S」始まりなので、これを「C」に変えたくなり、Cで始まる「Clue」（手がかり、糸口、ヒント）という言葉で置き換えることにしよう。まとめると、こうなる。
発想言語（アブダクション・ランゲージ）の基本形式
Concext、Clue、Consequence
つまり、発想言語には、ある「状況」において、どういう「方法」でやると、どういう望ましい「結果」が得られる（と期待できる）のか、ということが書かれる。
このような形式がよいと考えたのには、これまでの僕らのパターン・ランゲージ制作の経験が関係している。
発想の仕方というのは、パターン・ランゲージの形式（context、problem、solution）では書きにくいのだ。というのは、発想の仕方で「こうするとよい」というのは、何かの問題を解決しているのではなく、ただそうするといいことがある、という経験則に過ぎないからである。そのため、発想の仕方について、無理矢理にパターン・ランゲージ形式でProblemを書こうとすると、とても嘘っぽいパターンになってしまう。そのような経験を何度もして、Probemを中心とするようなデザイン（問題発見・解決）の形式ではない記述形式の必要性を感じていた。
そこで、今回その代替案として、上記のような形式を考えてみたというわけだ。
なお、基本形式が変わることで、それら主要要素にぶら下がっている付加要素も、再編成されることになるだろう。例えば、パターン・ランゲージではProblemに付随していたForces（問題を生じさせている力）は、発想言語では、Consequenceにつけることにしたい。「Clueに従うとConsequenceを生む」ということを可能とする諸力を明らかにするのが、ConsequenceにおけるForcesだ。
このような「発想言語」というものも、パターン・ランゲージ同様、どんどん書いていきたい。
そのなかで、僕は、「創造言語」が創造を支援する言語であるということと、創造言語のひとつの形式が「パターン・ランゲージ」であるということを書いた。創造には、デザイン（問題発見・解決）的なものもあれば、そうではなく直感や経験にもとづく場合もある。そのなかで、デザインについてまとめたものがパターン・ランゲージなのだと考えた。
それでは、パターン・ランゲージではない創造言語には、どのようなものが考えられるのだろうか。今回は、そのひとつの案として、「発想言語」（アブダクション・ランゲージ）（とここで仮に呼ぶもの）について考えてみたい。
発想言語は、発想の型を記述した言語である。
パターン・ランゲージでは、context、problem、solutionという３つの要素で書いたのに対して、発想言語では、Context、Solution、Consequence の３つの要素が大切に思える。ただし、真ん中だけ「S」始まりなので、これを「C」に変えたくなり、Cで始まる「Clue」（手がかり、糸口、ヒント）という言葉で置き換えることにしよう。まとめると、こうなる。
発想言語（アブダクション・ランゲージ）の基本形式
Concext、Clue、Consequence
つまり、発想言語には、ある「状況」において、どういう「方法」でやると、どういう望ましい「結果」が得られる（と期待できる）のか、ということが書かれる。
このような形式がよいと考えたのには、これまでの僕らのパターン・ランゲージ制作の経験が関係している。
発想の仕方というのは、パターン・ランゲージの形式（context、problem、solution）では書きにくいのだ。というのは、発想の仕方で「こうするとよい」というのは、何かの問題を解決しているのではなく、ただそうするといいことがある、という経験則に過ぎないからである。そのため、発想の仕方について、無理矢理にパターン・ランゲージ形式でProblemを書こうとすると、とても嘘っぽいパターンになってしまう。そのような経験を何度もして、Probemを中心とするようなデザイン（問題発見・解決）の形式ではない記述形式の必要性を感じていた。
そこで、今回その代替案として、上記のような形式を考えてみたというわけだ。
なお、基本形式が変わることで、それら主要要素にぶら下がっている付加要素も、再編成されることになるだろう。例えば、パターン・ランゲージではProblemに付随していたForces（問題を生じさせている力）は、発想言語では、Consequenceにつけることにしたい。「Clueに従うとConsequenceを生む」ということを可能とする諸力を明らかにするのが、ConsequenceにおけるForcesだ。
このような「発想言語」というものも、パターン・ランゲージ同様、どんどん書いていきたい。
発想言語 | - | -