Novel Factories
物語は抽象化と洗練化の下意上達／上意下達が相互に行われて良いソリューションが得られる。
小説の書き方、なんていうのは、作法程度にほんの少しだけ知っていればいいと思うし、全くしらんでもいいとすら思っている。
作法をしらないより知っていた方がいいけど、それを直ちに準拠枠と信じ込むのは性急ではないか。それはJAVAでプログラミングするとき、SUNのJAVAコーディング規約を知っている方がいいというのと同じレベルであると、わたしは認識している。
小説という現象を抽象化したら、沢山いろんなアイディアが浮かんでくる。
小説という形式はアイディアの実装法でしかない。
その実装方法が活字であるのは、その一つの実装方法でしかない。
先ほどの譬えでいうと、そのアイディアをJAVAプログラミング言語（あるいはプログラミング言語によって）で解決しなければならないなんて、誰も強要していない。
小説の中の活字、つまり記号は何をしているのか。
その役割を明確にモデル化する。
モデル化することによって、活字プラットフォーム実装から解放される。
テクストの振る舞いをモデル化する。そのモデル化は繰り返し行われるだろうが、収束しえない。自然言語による小説の実装は、プログラミング言語とは異なり曖昧さが許容されるからだ。しかも日本語のように、「である」と「だ」すら明確に切り分けられない実装をモデル化すると、無数のアスペクト、ビューにマッピングされたモデルが発生することになる。
そこでは、ある取捨選択が行われるだろう。
実装上の問題を重要視する消費者にとってそのモデルは、要件を満たしていない、と言われるだろう。
しかし、小説のモデル化は、小説を家内制手工業で行ってきた小説家たちにとって、産業革命的である。
プロット（ロシアフォルマリズム的な厳密な定義でなく、通俗的な意味での）があり、それを実装するのは真に創作的な行為ではない。プロットの各項目には、「かくかくしかじかの結果を得られる」と宣言がなされていればよい。
その結果、自動的に実装された−そこで実装されたコードの引用文はデータベースより抽出されるものを含む−退屈なソリューション（その一実装として小説もありえる）に、真に創作的なアスペクトを織り込む。
こんなことは、今まで小説がかかれてきた技法だというかもしれないが、これを明示的、自覚的に行うことが重要だ。なぜならば、これがわたしたちが、国語の授業で習ったことなのだ。
小説家はいつだって活字という実装の指の隙間からこぼれおちていくアイディアに涙を流さんばかりに責任を感じていた。
要件定義はユーザの同意を得なければならない。でもいまでは、作者すらもユーザとなりえる。モデル化された小説がさらに抽象化された概念との間にただならぬギャップを生み出すが、そのギャップを埋める仕様が（だいぶ時代錯誤な感もあるが）創作的な行為の一つとなる。
小説というソリューションによって、わたしたちが効率的かつ大量に感動し、泣き、笑うためのNovel Factoriesという考えは、
- わたしというユーザが“特定のビューから”モデル化した
- ブログという力場における
- 日本語による
- 一つの実装
である。
Novel Factoriesという発想は、ユーザの二重化（多重化）を筆頭に仮説的であるが、この発想自体が後退的でニヒリスティックなパロディだということもご賢察の通りであると思う。
