リレー形式で連載をやると、リズムと刺激が供給される点は（以前、山崎も 指摘していたように）いい点だ。けれど、相手＝山崎の言葉に触発されて、つ いつい、それに引きずられるって問題（問題じゃないかもしれない）もあるね。 つまり、割り込みの話題が頻繁に入りそうだ。そのせいで、多少長い射程で展 開しようとしていた話はブチブチに切れてしまう。‥‥と、いま述べたことは、 「セオリーの理論」の話に割り込みが入るよ、という言い訳。
今回はだいぶ長いけど、その内容からいって一気に言ってしまった方がいい ことだから、切り分けることはしない。
前回、山崎が同じ見出しで書いていた節を受ける。山崎の文面を「>」印で引 用したくなるのだけど、それは止めておこう。それをやると、安直に文章の量 がかせげちゃう。会話の雰囲気はでるけど、書き物としての品質は確実に低下 しちゃうからね。とはいっても、リレーのバトンのつもりで、見出しをコピー することくらいは許されるでしょう。
閑話休題 -- ソフトウェアの話だ： 商品としてのソフトウェアってのは、な んだか変なモノだよね。なんで、ソフトウェアがお金と交換可能なの？ 時 たま不思議になってしまう。ソフトウェアは、物質的な裏付けを持っていない。 CD-ROMのディスクとかパッケージの箱とか、紙のマニュアルとか、物質的な実 体を伴うこともあるけど、あれがソフトウェアの本質じゃない。それは誰だっ て分かっていることだ。物質的な形あるモノとして流通させたほうが、“普通 の商品”と似た扱いができるから、容積と質量を持つ箱に入れているだけだ。 ある種のまやかしだね。ソフトウェアを買うほうの心理的抵抗感や疑問を抑え るための策略なわけだ。その策略を弄しているほうも、内心「これって、無意味 じゃないのかな？」と感じたりしている（感じないヤツもいるだろうが）。
明治大学の夏井高人先生が、ソフトウェアは作った瞬間から供給過剰だと （そんな内容を）語っていたが、言われてみれば、そりゃそうなのだ。 誰か一人（例えば自分の子供）のために作ったゲームでも、100万人のユーザー を獲得する潜在的な可能性を持つし、実際にそれが起こり得る。これは、「シェ アウェアで大金持ち」といった夢のような成功譚を生み出す側面もあるが、 ソフトウェア作りが、産業あるいは経済活動として成立している基盤はかなり 危ういことをも示唆する。コピーすりゃ済むものに何で金払わなくちゃいけな いんだ、と言い張る人を納得させることはなかなかに難しい。
だがそうはいってもだ、ソフトウェアを創り出すために多大な労力をかけて いるほうとしては、やっても金にならないんじゃ、それこそやってられねーよ。 おまんまの食い上げだ。どうしてくれるんだ、おいっ。
いや、落ち着こう -- さて冷静になってみても、これってシリアスな問題だ。僕 は、ソフトウェアを作る作業は十分に面白いと思っている。が、趣味でやって いるわけにはいかない。年の割には子供が小さいから、それじゃ困るんだよな。 もっと実入りのいいショウバイに鞍替えして、土曜日だけ（日曜は子供と遊ぶ から）プログラミング、なぁーんてわけにもいかない。いまさら、新しいショ ウバイに転身できるとも思えないし、できることなら自分で面白いと思ってい ることで飯を食いたい。
と、個人的なことはいいとしてもだ（よくねーけど）、ソフトウェアの価値に応じて金銭的対 価を正当に要求するメカニズムないしはモデルってのは大事な話題でしょ。で、 ここで、僕が今かかわっているプロジェクトのことを引き合いに出そう。この 連載開始の案内で、山崎が触れていたChimera（キメラ）プロジェクトってや つ。このプロジェクトは、実はまったく実験的な目的だから、金銭的対価う んぬんが直接に関係するわけではないのだが、いつの日か製品となるとき、 「誰がどんなふうに使って、どう評価してくれるか？」と僕はいつも考えてい る。そして、その評価が金銭的対価につながるとも思っている。
Chimeraプロジェクトについて簡単に紹介しよう。
Chimeraプロジェクトは、ジャストシステムと共に進めている proof-of-concept（技術的アイディアが実現可能かどうか調べるための）プロ ジェクトだ。Chimeraについては、月刊『Java World』誌の2003年6月号と7月 号で概要を紹介している。とはいっても、雑誌のバックナンバーにアクセスす るのは容易じゃないから、一言で説明しておこう： Chimeraは、Javaで実装された 汎用のXMLハンドリング・プラットフォームである。XMLブラウザやXMLエディ タを作るための土台を提供する。実際に、Chimeraプラットフォーム上で動く アプリケーション（の参照実装）も動作している。ただし残念ながら、今のところ Chimeraの実行可能形式は配ってないし、公表できる技術資料もない。
Chimeraの特徴のひとつは、プログラマにもユーザーにも、相当に勝手なこと を許す点だ。よく言えば自由な環境と言うことになるが、下手をすると、ナラ ズ者をのさばらせたり、無政府状態を招くかもしれない。邪悪なプログラムコー ドから、プラットフォーム・カーネルや他の善良なコードを守る手段を提供し てない。つまり、プラットフォーム上に形成される、プログラム・コンポネント を成員とする社会は、善意と信頼に基づく社会になっている。
Chimeraにおいて推奨している約束ごと／作法はあるし、その作法に従ってく れると、いろいろとありがたい事 があるように作っている。これがフレームワー クというものだ。だが、多くのフレームワークとは異なり、Chimeraフレーム ワークは、約束ごとに従わないプログラム・コンポネントを拒絶しない。そうい うオキテ破りでも、それなりに動作する環境なのだ。
このような「安全性を犠牲にしてでも自由さを尊重する」という方針は、実験 的プロジェクトだから採用したという面も多少はあるが、実はChimeraの本質 的性格である。だから、いつの日か製品になることがあっても、この性格は残 るだろう。（「それでいいのか？」という議論はあるが、今する話題ではない。）
洋服には、出来合いの服とオーダーメイドの別があるが、ソフトウェアにも、 流通している汎用パッケージと注文生産品がある。非常に素朴な感覚として、 そこらじゅうに転がっている汎用パッケージに金を払うのはいやだが、自分の ために特別に作られたソフトウェアになら金を払ってもいい気がするだろ う。僕は、ユーザーに気持ちよくお金を払っていただく（＝僕らが食っていけ る）ポイントは、この素朴な感覚にあると思っている。
いろいろと細かい詮索をしたり、厳密な論理展開をしようとすれば、あまり に素朴なままでは済まないのだが、とりあえず "just for you"（あなたのた めにだけ、あなたにピッタリに作った）をキーワードとして提案したい。
ところで山崎も指摘しているとおり、現在のソフトウェアはゼロから手作り するなんてありえないから、just for youとは言っても、「あなたにために、 なにからなにまで手作りしました」ってことにはならない。ありていに言えば、 「あなたのために、部品を見つくろって組み立て（アッセンブリし）ました」 とか「あなたのために、カスタマイズ／チューニングしました」ということに なる。洋服だって食べ物だって、実のところ、アッセンブリやカスタマイズ／ チューニング作業で作られるものだ。
ここで話はChimeraに舞い戻るのだが、安全性を犠牲にしてまで「オキテ破り の勝手なことさえできる自由」を重視したのは、極端なまでのカスタマイズ可 能性を手に入れるためだ。安全でカッチリしたフレームワークによる限定的自 由という選択肢もあるが、フレームワークの設計者が想定できる程度の自由なん て、使う側からすると単なる不自由でしかないことが多い。プラットフォーム／ フレームワーク設計時に見落とした穴がやたらに“活用”されたり、設計者や 実装者が想像もしなかった応用をユーザーが見いだしたりする。それだったら、 最初から限定したり想定したりするのはやめよう、ということだ。
カスタマイズと一口にいってもいくつかのレベルがある。Chimeraの場合を 念頭におきながらも、一般論として 整理しておこう。カスタマイズ作業には、次の3つのレベルが あると考えるとよい。
パラメータの調整とは、要するに設定を変えるってことだ。適当なファイル を直接編集することもあれば、コマンドラインツールを使うこともある。最近 だと、ダイアログやウィザードのようなユーザーインターフェースから設定を 行うことが多いだろう。ソフトウェアの見た目の情報をまとめたものを、スキ ンとかテーマと呼ぶが、これも一種の設定だから、スキン／テーマの作成や変 更もパラメータ調整の部類に入る。
マクロ言語とかスクリプト言語とは、プログラミング言語ではあるが、比較 的簡単で、プログラムコード（普通これを「マクロ」とか「スクリプト」と呼ぶ） を書いてすぐに実行できる（業界用語ではインタプリタ方式ってこと）。例え ば、JavaScriptはよく使われているスクリプト言語だ。マクロ言語／スクリプ ト言語は、以前は「簡易言語」と呼ばれたりもした。敷居が低く、お手軽にプ ログラミングができる。そのようなプログラミング言語を使って、ソフトウェ アの機能を拡張することもまた、カスタマイズの一種である。
最後の実装言語によるプログラミングとは、そのソフトウェアを作るために 使ったのと同じプログラミング言語によってプログラムをすることだ。 ChimeraならばJava言語で作っているから、実装言語によるプログラミングとは Javaプログラミングのことだ。ただし、当のソフトウェアを無制限に改変して しまうのは、カスタマイズの範疇を超えている。前もって決められた約束の範 囲内でプログラムを追加する作業に限定しよう。Chimeraでは、約束の範囲内 で追加されるJavaプログラムをプラグインと呼んでいる。
Chimeraの設計と実装において、極端なまでのカスタマイズ可能性を確保する ために、ものすごくエネルギーを使っている。決め打ち（最初から固定）なら 楽だけどパラメータ化しているし、マクロ／スクリプトから操作可能にするの も容易じゃない（だから、できてなかったりするんだけどね、ナハハ）、プラ グイン・アーキテクチャ（方式、体系）もゼロから設計した。
実は、こういう一見柔軟性を高める努力が、逆説的にプログラマ／ユーザー の自由を奪うことがよくある。だから、そうならないように、まるで政治結社 のごとく「自由、平等、民主」と叫びながら日夜作業をしている。そう、つま り僕は、自由のために命をかけて戦っているのだ -- ってウソだけど。
さて、そこまで苦労して実現しているカスタマイズ機能を誰が使うのだろう か。誰がパラメータ設定をするの？ 誰がスクリプトを書くの？ 誰がプラグイ ンを作ってくれるの？ 僕はほとんどの人はまったくカスタマイズしないと思っ ている。えっ、それでいいの？ うん、それでいいのだ。なまじ、みんながカ スタマイズしてくれると期待しないほうがいい。カスタマイズするのは、ほん の一握りの人だ。だから、一切のカスタマイズなしでも十分に使えるものにし なくちゃならない、という別な（そして重要な）目標が生まれるわけ。
今した話のなかで、僕は2つのことを指摘したかったのだ、僕自身への反省 と自戒もこめてね。念のため2つの論点を繰り返そう。
１つ目は、アーキテクチャやフレームワークがプログラマ／ユーザの自由を 奪う可能性があること。特に、先進的、斬新、かっこいいアーキテクチャ／フ レームワークがその弊に陥りやすい。かっこよさが、勝手な思いこみや自己陶 酔の産物だってこともある。ちょっとダサめでも、単純（素朴と言ってもいい） で縛りがないほうがいい。設計者の思いを裏切るほどに自由でパワフルな環境 （むしろ生態系と呼びたい）が出来上がったら本望だね。
2つ目は、カスタマイズ可能性（柔軟性と自由性）はよい事ではあるが、ソフ トウェアの使い勝手が悪いことの言い訳には使えないってこと。「あなたの好 きなように調整できるのだから、お好みに応じて仕上げてください」と半完成 品で済ませるなんて怠惰だよね。誰でもが自分でカスタマイズできるわけじゃ ない。むしろ、カスタマイズなんてできない／しない人が大部分だ。だから、 カスタマイズ可能性とは独立に、完成品としての品質は要求されるのさ。
いままで出てきたいくつかの論点を、フィクションではあるが具体的な 文脈の中で整理することにしよう。1000人のユーザーがいることを想定する。 ここで、ユーザーのなかにはいろいろなタイプの人がいるとする。プログラミ ングができる人も混じっている。この1000人のユーザー達にとって、何が幸せ なのだろうか？ 1000人のユーザーにソフトウェアやそのカスタマイゼーションを提供する側はどうしたら いいのだろうか？ そして、冒頭からの問題意識である「ソフトウェアとお金 が合理的に交換可能か」も考えよう。
先ほど説明した“3つのレベル”でカスタマイズ可能なソフトウェアを1000人 の人が使うとき、900人はそのまま使う。何のカスタマイズもしないで使う。 デフォルトの作業ディレクトリを変えることもしないし、フォントの設定も変 えないし、スキンを取り替えることもしない。ましてや、キーバインドを割り 当て直したりしない。それで使いにくかったら不満をいう。あるいは不満さえ 口にださずに我慢する。あるいは、（これが最もありそうなことだが）不満を 感じることさえできない。
残る100人はパラメータ調整をするかもしれない。つまり、ちょっと“できる” 連中だ。設定ダイアロゴやウィザードを開いて試してみる。設定を保存してい るファイルを直接いじる強者もいるだろう。うまくいかないと、再インストー ルするくらいの気力もある。それでも、この100人のうち90人はプログラミングはしな い。パラメータ調整の範囲にとどまる。
さあ残るは10人だ。彼／彼女らはスクリプティングするスキルと気力を持ち 合わせている。ソフトウェアが最初からは持ってない機能でも、自分にとって 必要ならスクリプトを書いて実現する。だがそれでも、このうち9人は実装言 語まではあやつれない。
最後の1人、1000人のなかの1人が実装言語の使い手だ。（ここからプログラ ミングの用語が出現する、あしからず）プラグインのインターフェースを調べ て、アルゴリズムを記述してコンパイルする。手順に従って配備して、テスト とデバッグをする。すべてが首尾よくいけば、彼／彼女は、もとのソフトウェ アを深いレベルで拡張したことになる。
何のカスタマイズもしない900人のなかの相当数は不満さえ感じない、と言っ た。もちろん、ソフトウェアの出来が十分によくて満足しているなら、けっこう なことだ、何もいうことはない。だが、劣悪な状況におかれているにもかかわらず、 不満を感じることができいないとしたら、これは不幸だと思う。不幸だと思う のだけれど、僕はどうしていいかわからない。本人が不満に思ってないのだか らそれでいいだろう、という意見もあるし、どうこうするのは余計なお世話な のかもしれない。いや、どうこうするすべを僕は知らないのだ。だから、「不幸か もしれない、不満を感じない人々」の話は今これ以上はできない。
幸いにも（？）不満を感じる人なら、幸せになる道はあるかもしれない。仮 に、900人中300人が不満を抱えているとしよう。そして、カスタマイズできる ユーザー100人のなかの1割＝10人が、その不満を解消する手伝いをしてくれる としよう。この10人のなかには、設定をいじったりスキンを作る人もいるし、 スクリプト・プログラマ、そして（1人しかいない「あの」）ハードコーダー （実装言語でプログラムできる人）も含まれるだろう。
カスタマイズ能力を持つ10人が、どんな意図／思惑で300人に手を差し伸べる かは自由だ。友人・知り合いだからやってあげる、ってこともあるだろうし、 困っている人を助けたいという奇特な志があってもいい。ショウバイだと考え て対価を要求しても何も悪いことはない。
話を単純にするため、300人対10人という構図で話したが、設定をいじれる人 がスクリプト・プログラマの手を借りたいこともあるだろうし、スクリプトで は限界がありハードコードによるプラグインが要求されることもあるだ ろう。1000人のコミュニティのなかに、不満や要求があり、それに応じた対処 や解決を提供できる人も存在する。そのようなけっこう入り組んだ需要と供給を媒介している基盤 は、当該ソフトウェアのカスタマイズ可能性だ。
大部分の人が使わないカスタマイズ可能性が、ここで意味を持ってくる。僕 らが命をかけて（いやっ、ウソだけど）カスタマイズ可能性＝自由を確保しよ うとしている理由はここにある(*注1)。
『Java Wrold』の記事のなかでは、カスタマイズ可能性の重要さを、まった く違った視点と理由で説明してるんだよね。ダハハハハ、と笑ってごまかす。
1000人のユーザー・コミュニティが、美しい友情や気高い奉仕の精神で結ば れていると仮定する必要は何もない。今、逆に、みんなが「世の中ゼニや」と 考えていると仮定しよう。つまり、スキルを持つ10人は、300人の“市場”か らゼニを取ろうと考える。ならしてしまえば1人あたり30人の顧客を持つこと になる。顧客は困っていたり、何かを欲しがっているのだから、その問題が解 決されたり、要求が満たされれば対価を払うのにやぶさかではないはずだ。
しかも、解決や実現は、その人のために特別にあつらえたものだ。正確 にいえば、出来合いのプラットフォーム上での解決／実現なのだが、先にも注 意したように、文明社会におけるオーダーメードなんて所詮はアッセンブリなのだ から、これでも「あなたのためだけ」になっている。さらに言えば、30人の顧 客1人1人に対し、違った解決／実現を律儀に準備することも実際にはないだろ う。おそらくは、3種類の解決／実現パターンに味付けを変えて30人のニーズ を満たすことができる。
こうして、1000人のユーザー・コミュニティのなかに300人の市場が形成され、 10人の事業者が出現する。300人の人々は、just for you（just for me）のソフトウェアを手 に入れる対価として、10人のカスタマイザーに喜んで（少なくとも納得して）支払いをする。カス タマイズなしで使っている人の中で、デフォルト機能にほんとに満足している 人、たとえば100人くらいいるとして、その人々も対価の支払いに同意してく れるだろうから、市場と考えてよい。もともと出来のよいソフトウェアなら、 「最初から満足」の市場をうんと拡大できるだろう。
不満を感じず特に要求も持たない、かといって満足してると自覚もしない500 人はどうなるのかって。ほっておくしかないでしょう。この500人は、お金を 払ってまでどうこうしたいという意欲を持たないのだから、最初から市場では ない。だが、この500人を含めた1000人の母集団があるからこそ、不満を抱え たり心底満足したりする人々からなる500人規模の経済活動の場が生まれるこ とを忘れちゃいけない。すそ野を形成し、全ての上部構造を支えているのは、 無為の人々なのだ。
そうそう、そもそも1000人のコミュニティが生まれる端緒となった当該ソフ トウェア＝プラットフォームの提供者にも、なにがしかの見返りがあってもい いよね。僕自身はプラットフォームの提供者に近い立場だから、無視されちゃ 困るのだ。とはいっても、見返りの経路を具体的にイメージできてない。 お祭り広場を作って、自分自身も広場で屋台を引く手もあるだろうし、広場の ショバ代を徴収する手もあるのかもしれない。
いまの話のなかで、1000人、300人、10人なんて数値には何の根拠もない。定量 的に信用されても困る、当然だけど定性的なオモチャのモデルなのだ。いやむ しろ、モデルでさえなく、暗喩（たとえ話）と思ってもらった方がいい。僕が 強調したいのは、「余計な押し付けをする想像力の欠如した枠組みではなく、 ほんとうに（無節操で危険なほどに）自由なプラットフォームの必要性」なの だ。そのプラットフォーム上で、友愛と奉仕の精神のコミュニティが形成され ようが、せちがらい経済が支配する機構が出現しようが、知ったことではない （ちょっと語弊があるか？）。
ひょっとすると、こういう主張に対して、昨今のオープンソース・ムーブメ ントとの類似性を感じる人がいるかもしれない。そう思われてしまうと、僕と しては不本意で、愉快な気がしない。論点と結論が似てる面があるのは否定し ないけど、根本に据えている原理は違う。まったく正反対の点もある。そこら あたりもクリアにしたいのだが、1回分としてはだいぶ量が増えてしまったか ら、またの機会にしよう。