某新書はタイトルが9割なので私もタイトルしか知らないが、たぶんそれで十分なのだろう。というわけでご紹介する。
さおだけ屋から竿竹を買った
私はヤクザが死ぬほど嫌いなので、この手の訪問販売にこられると心底頭にくる。執事のいる家に住みたい。
またもネタ切れのため設定の話をする。
作中の木更津は、現実の木更津より7割増しで栄えている。現実の木更津が今の2倍栄えても、ゲーマーズやアニメイトはできそうにないので、ああいう表現になっている。東京に近く若年人口の多い習志野市（人口16万、アニメイトあり）でも限界に近いと思われるが、現実の木更津市の人口は12万だ。
＊
朝のブリーフィングは、準備体操に似ている。
担当の官房職員が決まりきったことを淡々と説明して、今日のスケジュールを配る。たまに警護班のリーダーが発言して終わる。難しい問題が持ちあがることはめったにない。雰囲気もたるんでいる。けれど、ここで調子をつけておかないと、あとでミスが出やすい。
今日のスケジュールは、午後3時以降が空白になっている。
「陛下のご意向により、午後3時からご休息です。以上です」
緋沙子とのお別れに時間を割こうというお考えだろう。私は胸をなでおろした。
もし今日、陛下とお話しする時間がなければ、私の権限で作るしかなかった。護衛官がスケジュールを変更させれば、そのことは陛下のお耳にも入る。そうなれば、今日は朝からぎくしゃくとして、いつもどおりの日を演じることはできなくなったはずだ。
今日は朝一番から外出だった。出発までのわずかなあいだを、警護班と無駄話をして過ごす。時間がくると、玄関前の車回しに移動し、陛下のお出ましを並んで待つ。玄関にお姿が見えた瞬間、一日の仕事が始まる。
「おはよー、ひかるちゃん。今日もカッコよくてきれいだよ」
「おはようございます。私ごときがきれいなら、陛下は神々しくあらせられます」
陛下の車中での過ごしかたには、TV録画の鑑賞（たいていアニメ）、TVゲーム、読書、睡眠、私との雑談、などがある。今日は、TV録画の鑑賞だった。助手席のシートに埋め込まれたモニターを、真剣なまなざしでご覧になる。
私はそのお姿を、あまりまっすぐには見ないようにしながら、視界から外さない。仕事についたばかりのころは、こんなに長いことひとりの人間ばかり見ていたら頭がおかしくなるのでは、という気さえした。今では慣れてしまった。
見慣れた道を通り、目的地の千葉市労働会館に着く。ここは警護のしやすいロケーションで、国王の出席する催しによく使われる。今日は、高ツ石油の投資説明会がここで開かれる。陛下ご自身が投資を検討なさっているわけではない。政府がこの件に大いに肩入れしていることを、投資家たちにアピールするためのご出席だ。
国王を招くだけあって、千ロの政府からは副大臣クラスが出てきていた。ロシア語のスピーチには通訳がつく。私はロシア語がわかるので、こういう通訳は聞いていて面白い。陛下は、居眠りなさっていた。
昼食は、財団理事の茅場氏と。地方党組織の割譲派のことが主な話題になった。茅場氏によれば、割譲派の内部に温度差が広がりつつある、とのこと。それに対して陛下は、割譲派という枠にとらわれず、具体的な人物とその人間関係に注目すべきではないか、と示唆なさった。
午後は、袖ヶ浦市の図書館へ。この図書館は先月にオープンしたばかりで、今日は広報のためのご訪問だった。TVカメラが入るので、メイドの宮田さんが陛下のメイクをTV用に整える。陛下は館長とともに館内を一回りなさり、いくつか本をお手にとっては、TV映りのよさそうな適当なことをおっしゃった。陛下は、ラジオでは思うところをそのままおっしゃるが、TVではずいぶん手加減なさる。TVは編集の都合が厳しいため、お言葉は短く単純にまとめないと、ほとんど意味が通らないくらいに切り刻まれてしまう。陛下がTVよりもラジオを好まれるのには、こういう事情もあるだろう。
今日の仕事はここまでだった。帰りがけに、陛下のご希望で、木更津駅近くのアニメショップに寄ってゆく。本社は東京にあるチェーン店で、陸子陛下のために財団が誘致したと噂されている。いつ行っても繁盛している様子がないのを見ると、そういう噂が立つのももっともなことだと思える。実際は、陛下のご贔屓をあてこんで開いた店らしい。ご贔屓だけは狙いどおりにいったが、国王が贔屓にする店だからといって繁盛するほど商売は甘くない。
公邸に戻る。車中での陛下は、さきほどアニメショップでお求めになった雑誌をご覧になっていた。私はそのお姿を、視界の隅にとらえつづける。間違いなく私は、世界一、陛下のお姿を拝見している人間だ。
陛下は雑誌のページを閉じると、私に話しかけてくださった。
「月曜のネタのことなんだけどさ、大多喜町だよね。事典だと、なーんかしょぼいネタしかなかったんだけど」
陛下のおっしゃる『月曜』というのは、月曜演説のことだ。聴衆の地元民を前にして、演説地のことを褒めなければならない。国王になにも考えがなくても、官房職員が適当に仕入れてくるが、それだけでよしとなさるような陛下ではない。
「これといった名物がないのに無理をするよりは、イベントに絡めてはいかがでしょう。たとえば七五三の季節なら、子供を壇上に招かれてお祝いの言葉をおかけになれば、人々の気持ちを集めることができるでしょう」
千葉には、七五三を盛大に祝う地方が多い。
「そっか、イベントかー。来週のイベント…… うーん」
「たしか、十五夜がもうすぐでしたか」
「もしかして私、操られてる感じ？」
そうするうちに公邸に着く。
メイドたちが玄関に並んでいて、陛下をお迎えする。そのなかには緋沙子はいない。時計を見ると、緋沙子の出勤時間にはまだしばらく間があった。
私は通用口へと回る。公邸の玄関から出入りするのは、国王、客、理事だけで、ほかは通用口を使うことになっている。公邸内にある護衛官のオフィスにゆき、書類仕事にとりかかる。
護衛官はひとりで一個の省庁のようなものなので、御召車のガソリン代の伝票事務まで私がやることになっている（御召車は政府が提供している）。実際には、そういう事務は国王官房がやってくれていて、私は上がってきた書類に署名捺印するだけなのだが、それでも数が多いと馬鹿にならない手間だ。また、トラブルの報告などは、私自身が起草しなければならない。
今日は定型書類だけだったので、すぐに終わった。届いていた郵便物を調べると、内務省発行のテロ・ゲリラ活動月報があった。さっそく目を通す。私の研修は、過去10年間の月報を読むことから始まった。教官は、白書のたぐいなど１ページも読んだことのなかった私に、内務省の文書に出てくる独特の言い回しとその意味合いを教えてくれた。たとえば、「懸念すべき状態にある」という表現には、責任回避の意味合いが強い。が、具体的な誰かが「懸念を表明した」となると、その誰かが何かをしようとしている、という意味になる。
月報を読み始めてすぐに、携帯電話が鳴った。メイドの青木さんの携帯からだった。といっても、かけてきた相手は、おそらく青木さんではなく陛下だろう。陛下は携帯電話をお持ちでない。必要なときには、お側仕えの者から借りて済ませておられる。
電話をとると、案の定だった。
「ひかるちゃん、いまからこっち来れる？」
「はい。すぐに参ります」
「おねがーい」
私は読みかけの月報を机に置き、しおりを挟もうとして――そのしおりが役に立つことはないのだと気づいた。
私は、何秒間か、ぼんやりしていた。
結局、しおりは挟まなかった。私は執務室を出た。
Continue
Windows専用の言語処理系のひとつに、HSPというものがある。
HSPの機能のいくつかは、月の裏側から集めてきたらしい。不要とわかって捨てられたものを、わざわざ復活させている。たとえばC言語風のマクロだ。私見では、#defineと#ifdefは手動メモリ管理に次ぐ害悪だ。Stroustrup『C++の設計と進化』540ページより引用する：
マクロの定義は、環境の中や、コンパイラのディレクティブ、ヘッダファイルなど、いろんなところに潜んでいる。マクロによる置換はスコープという境界ルールを無視し、それどころか、勝手にブレースや引用符を挿入してプログラムのスコープ構造を変えてしまうこともある。（中略）その機能はあまりにも構造性を欠き侵略的なので、プログラマやメンテナ、コードを移植する人、ツールの作者などにとってつねに頭痛の種だった。
しかしHSPは当たった。同種のWindows専用の言語処理系のなかで、一番の大当たりになった。
なぜ当たったのか？ 私はこういう世界とはまったく縁がないので、説得力のある意見をとりあえず信じることにする。私の知るかぎり、もっとも説得力のある説明は、以下のとおりだ。
「インストーラ抜きの配布物がEXEファイル1個になる。それが本物っぽくて、いい」
VBの配布物はEXEファイル1個にはできない。ランタイムが必要だ。Perlは、PARを使えばEXEファイル1個にすることはできるが、PARを使うにはかなりの知識が要る。その点、最初の最初から「本物っぽい」配布物が得られるHSPは、人をひきつけたのだ――配布物がEXEファイル1個になるのが「本物っぽい」と感じるような初心者を。
初心者がなにを「本物っぽい」と感じるかは、なかなかわからない。彼らはカーゴ・カルトの世界にいる。
初心者でなくなるのは簡単だ。慣れればいい。だが慣れるだけではカーゴ・カルトからは抜け出せない。信仰しているカーゴ・カルトが、「ベスト・プラクティス」という名前になるだけだ。
『本物のプログラマはPascalを使わない』というあのエッセイは、そこの機微をよく捉えている。このエッセイによれば、本物のプログラマはFORTRANを使うのだという――FORTRANは当時のカーゴ・カルトだったのだろう。EXEファイル1個の配布物が「本物」であることと、FORTRANが「本物」であることのあいだには、大した違いはない。
さて、今日の本題に入ろう。ネイティブ・コンパイラ（ネイティブに実行可能なバイナリ・ファイルを生成するコンパイラ）を信仰するカーゴ・カルトについて。
基本を確認しよう。
C言語のコンパイラはC言語で書ける。C言語で書かれたCコンパイラは、自分自身をコンパイルできる。
問題は、最初の実行だ。世界で初めてC言語の処理系を書いたのなら、ご愁傷様だ――手作業でなんとかするしかない。だが、ほかにC言語の処理系がすでに存在していて使えるなら、手作業は必要ない。
さて応用である。
JITコンパイル型のJava VMは、自分自身を実行できる。
事の本質はCコンパイラとなにも変わらない。「最初の実行」という問題が、VMを起動するたびに起こるだけだ。なんらかの方法で起動しさえすれば、あとはVMが自分自身を実行する。起動方法としては、インタプリタ型のJava
VM（速度は非常に遅くていい）などが考えられる。そしてその起動用VMも、FORTHインタプリタのような極小のVM上で動かすことができる。最小限のFORTHインタプリタは非常に簡単に書けるので、アセンブラさえいらないくらいだ。
高度な動的最適化は、理論上も現実にも、コンパイル時最適化をしのぐ。ある程度以上のメモリのある環境なら、ネイティブに実行可能なバイナリは、BIOSとブートローダとカーネルのごく一部にしか必要でない。ネイティブ・コンパイラはほとんど不要だ。
（ただし、ネイティブでないコンパイラは相変わらず必要だ。コンパイル時の型チェックはプログラマを助け、冗長性の低いバイトコードは実行効率を高める）
EXEファイル1個の配布物。FORTRAN。ネイティブ・コンパイラ。
どれも、ある条件のもとでは、ベストな選択だ。だが、その条件を判断する知識が抜け落ちたとき、その選択はカーゴ・カルトになる。
このようなカーゴ・カルトを見分けるキーワードが、「本物」だ。
なにかを選ぶとき、それが「本物」だからという理由で選んではいないか。なにかが確かだと思うとき、その根拠がどこかで「本物」につながってはいないか。
選ばれて「本物」になる。確かだと思われて「本物」になる。だが、その逆は、カーゴ・カルトだ。
新しいOSを作ることが流行らなくなってから、長い年月が過ぎた。
念のため言っておくが、Linuxは新しくない。そしてWindowsも新しくない。どちらもC言語をベースにした、UNIXもどきのOSだ。1973年でOSの時間は止まった。いまも私たちはそこにいる。
おそらく私が生きているあいだには、OSは漸進的にしか進歩しないだろう。どのように進歩するかを、私の願望という形で予想してみる。
Java VMや.NET CLRを、カーネルに入れてほしい。もちろん、インタプリタでは話にならない。動的コンパイルされたコードが、カーネルモードで動かせるようになってほしい。メリットは以下のとおりだ。
・カーネルモードで動くコードを、かなり安全かつ簡単に書ける
Microsoftも、糞ドライバに青筋を立てるよりは、C#でドライバを書かせたほうがいい。というか、C言語で書かされるこちらも青筋を立てている。
・OSに依存しないドライバが可能になる
現在、ドライバはOSごとに違う。実用的な仮想マシンはOSよりも少ない（事実上2つしかない）ので、仮想マシンごとに違うほうがマシだ。また、一つのOSで同時に複数の仮想マシンを実行することもできる。
・カーネルモードとユーザモードの境界が柔軟になる
LinuxにはkHTTPdというものがある。これはHTTPのリクエストをカーネルモードで処理して高速化する（とはいえ現在の実装は、Apacheに比べれば速い、というレベルらしいが）。また、昔のLinuxでは、NFSサーバはユーザモードで動作した。現在ではカーネルモードで動いている。これも性能を出すためだ。
Windowsにも同様の事情がある。NT系列は、4.0まではディスプレイドライバはユーザモードだったが、4.0以降はカーネルモードになった。また、IISの6.0以降は、kHTTPdと同様のことをしている。
これらのカーネル化には批判が多い。カーネル化で得られる性能を、すべての人が必要としているわけではないからだ。もちろん純粋なマイクロカーネルもやりすぎだ。では、どうやって線引きすればいいのか？
そもそも、OSが線引きすること自体が間違っている。
カーネルモードとユーザモードの境界を、OSが決めるべきではない。決めるのはアプリケーションであるべきだ。アプリケーションは、必要とあれば気軽にカーネルモードを使えるべきだ。
分散アプリケーションでOSのユーザ認証を使えるようにしてほしい。
ユーザ登録と認証のあるWebアプリを作ったとしよう。Webメールなどだ。そのユーザ認証を、OSの機能で行うだろうか。WebアプリのユーザごとにOSのユーザアカウントを作成する――そんなことをするだろうか。おそらく、しない。だがWebアプリのユーザは、OSの管理下にある資源を使っている。
ということは、Webアプリのユーザは潜在的に、過大な権限を与えられている。別の見方をすれば、Webアプリはユーザ認証と資源管理を独自実装している。「暗号を独自実装してはいけない」というのは常識だが、「ユーザ認証を独自実装してはいけない」「資源管理を独自実装してはいけない」というアドバイスはまだ聞いた覚えがない。しかしこれらは明らかに、独自実装するには危険な代物だ。
WebアプリでOSのユーザ認証を使えるようになったとしても、RDBMSは？ それもOSのユーザ認証と一本化する。RDBMSは分散アプリケーションだ。
これらはすべて斬新的な進歩だ。「ゼロからHaskellで書き直せ」とか「CPUのアーキテクチャから作り直せ」といったドラスティックな進歩はいくらでも考えられる。実装することもできる。しかし、それ以上のものにはならないだろう。
斬新的にしか進歩しない世界でも、やることはたくさんあるし、C言語のコードを完全に消滅させることさえも夢ではない。ある日気がつくと、C言語のコンパイラがいらなくなっていた――そんな日が来るはずだ。
ネタ切れのため設定の話をする。設楽ひかるが仕事中につけている腕時計について。
ブランド指向のかたには悪しからずだが、オーデュマ・ピゲだのパテック・フィリップだのではなく、日本製のソーラー電波だ。アナログ3針、レディースサイズ、ガワとベルトはステンレス。つけている腕は左腕、フェイスは内側に向けている。
全身バリタチ風味な支度のなかで、髪と腕時計だけがフェミニン、という趣向である。
＊
私は朝食を職員寮の食堂でとる。私に出される食事は、護衛官専用と銘打ってあり、食材は陛下のお食事と同じだという。調味料や食器で差がつくので、陛下のお食事と同じ味とはいかないが、それでも、自炊する気がなくなるほどおいしい。
寮の住人は8人、勤務シフトは別々だ。誰かと食事の時間が重なることは少ない。今朝も私は食堂にひとりだった。
食べ終わり、お茶を飲みながら一息ついていたとき、
「みーっけ」
と、後ろから、腕を首に回された。
「美園さん、おはようござ――ぐ」
美園は回した腕を関節技に使い、私の首を締め上げる。
「ひかるさん、おはよう。同伴出勤しようか」
そう言って腕を外すと、今度は私の手をとった。そのまま食堂の出口へとひっぱってゆこうとしたので、
「お膳を戻さないと――」
「松本さーん、急ぐから、お膳ここに置いとくよ、ごめーん」
厨房から「あいよ」という返事がくる。
ひっぱられるままに職員寮を出ると、私は訊ねた。
「いったいどうしたんですか？」
すると美園は立て板に水の調子でまくしたてた。
「悩んでんの。まあ聞いてよ。
ひさちゃんがクビだっていうじゃない？ 万歳よ。といっても私は大人だからさ、ひさちゃんのこと好きなひかるさんの前では、残念そうな顔してあげてもいいよ。でも、まだ一週間経ってないからね。このあいだの屈辱、まだ忘れてないから、今日は万歳で許してよ。
このあいだの屈辱のことだけど、あれで私は負けたと思ったの。陸子さまはひさちゃんをネタにして徹底的にひっぱって遊ぶんだろうなって思ったし、それだとひさちゃんをクビにするわけないでしょう。こんなクソガキが陸子さまに大ヒットするなんて、って思いながら顔つきあわせて働くわけ。まったくこりゃ屈辱よ！ それをたった一週間で忘れてあげるっていうんだから、私って大人だよね。
ええと、なんだっけ？ ああ、そうだ。
ひさちゃんがクビになるわけない、でもクビになった。どういうこと？
もしかしてひかるさん、ひさちゃんとセックスしてみたら合わなくて嫌になって、それでひさちゃんがネタにならなくなってクビ？ だったら最高なんだけど、まさかそんなんじゃないよね。
考えてもわかんないから、いったいなにが起こってんの？ って聞きたいわけなんだけど、まだ答えないでね。
もしかしてこれ、私が事情を知っちゃうと、ヤバいことなんじゃない？
根拠はないんだけど、ただの勘なんだけどね、なんかこれ、もし私が知ったら、それが影響して悪いほうに転がっていくんじゃない？ ひかるさんと陸子さまとひさちゃんと、三人しか知らなければ大丈夫、っていうか、このままひさちゃんがクビになっただけで終わるのに、もし私が知っちゃったら、私までクビになったりとか、陸子さまのご威光に傷がついたりとかしない？
そのへんよーく考えてから、答えて。いったいなにが起こってんの？」
これだけ全部を一息に言われて、私は頭がぐらぐらした。そのせいか私は関係ないことを思いついて、口にした。
「美園さんは本当に、平石さんのことが嫌いなんですか？」
「あの子が私のいうこと聞くんなら、かわいがってもいいよ。かわいいところがあるってのは認める。でも今のひさちゃんだと嫌い。『私には陸子さまがついてるんだよ、あんたなんかにへいこらするかよ、へへーん』って顔してんだからさ」
「それだと私も大差ないと思いますが」
「ちがうね。ひかるさんは陸子さまのこと本当に好きでしょう。ひさちゃんは、いろいろ混じってる。強いものに媚びるみたいなところもあるし、陸子さまに見放されたら生活に困るっていう現実的な問題もあるし。そういうのは子供だからしょうがないけど、私がむかつくのもしょうがないのよ」
強いものに媚びる――権力崇拝。私は護衛官として、人々のそういう感情を嫌というほど見てきた。緋沙子にもそれがあるのだろうか。
生活問題。緋沙子は、自分の恋だけでなく、生活もかけて戦っている。『パパとママ、どっちが好き？ ――ってことですか？』。その言葉が、改めて重い。
「……私の知っている平石さんと、美園さんの知っている平石さんは、少し違うようですね」
「え、私、ひさちゃんの悪口とか吹き込んでる？ 吹き込んでるねえ。ほら私、ひさちゃんのこと嫌いだから、言っちゃうわけよ。できれば私だって、ひかるさんの見てるような、きらきら輝いてるひさちゃんを見たいもんだけど。
そうだ、きょう会ったら、『うちの子にならないか』って誘ってみようかな？ すごいツンデレかましてくれるかも？ いいなあ。やらないけどさ。ダンナに無断で養子は取れないわ」
通用門の詰所の警官が、私に敬礼した。私はつかまれていた右手を振りほどいて答礼する。その右手を、またすぐにつかまれる。
そのころようやく考えがまとまってきた。
「今回のことは、悪いことばかりではないと思うんです」
「あら大人発言」
美園の皮肉にはとりあわず、私は続けた。
「平石さんは誰かが守ってあげるべきです。その役目を引き受けるおつもりが陛下にないのなら、いっそ離れてしまったほうがいいでしょう。でなければ平石さんは、いつまでも期待しつづけて、裏切られつづけるだけです」
私の手をつかんでいる指の温度が、急に下がった。
「――ひかるさん、私はなーんにも聞かなかった。聞こえなかった。
さっきの養子のことだけど、けっこう真剣に考えてるの。あのひさちゃんが私にデレデレしまくるって思ったら、こりゃ、おいしいわ。私はひさちゃんを独占したいわけじゃないから、ほかに好きな人がいたって別にいい、っていうかそのほうが楽だ。
ひさちゃんだって、お父さんが欲しいんじゃない？ うちのダンナも出来はよくないけど、ひさちゃんに手を出す度胸はないね。お父さんだけじゃなくて、弟もいるし、おじいちゃんもいるし……
……もうちょっと、優しくしとけば、よかったな」
自分が言っていることの現実味のなさに、嫌気がさしたのだろう。最後はひとりごとだった。
Continue
少コミ第14号を読んだ。
新連載ラッシュである。第12号から1本、第13号から2本、この第14号から2本。予告によれば第15号から2本、そして第16号から少なくとも1本。ほとんど総入れ替えだ。
これだけ一度に始めれば、半分はすぐに打ち切りだろう。どれがどんな順番で打ち切られるかが注目である。現在の予想は以下のとおり。
少コミ新連載打ち切りレース：2006年第14号（6月20日発売）
◎ 山中リコ『桃色パンチ』
○ 悠妃りゅう『すぺしゃる・ダーリン』
△ 車谷晴子『美少年のおへや。』
さてレビューにいこう。
・しがの夷織『めちゃモテ・ハニィ』新連載第1回
主人公に特殊な行動パターンがある。すなわち、好みの男を見ると逆上して、性暴力に及ぶ。逆上が収まると、事のヤバさに耐えられず逃走する。この行動パターンに妨げられて今まで男ができなかったが、逆上と逃走のサイクルにもめげない男とついに出会った――という第1回である。
よい点として、ネームがよく練れている。気になる点として、彼氏役に味わいが欠ける。男が味気ないのは少コミ全般に共通する欠点だが、しがの夷織は少コミの中ではだいぶ腕の立つほうだ。この強みを生かさないと、面白くするのは難しいだろう。
採点：★★★☆☆
・水波風南『蜜×蜜ドロップス』連載第43回
次回最終回だというのに、「彼氏のご家族に認められるために頑張りました・なんとか乗り切れました」に終始している。
そういえば、『小悪魔カフェ』の次回最終回もかなり辛かった。次回最終回というのは難しいものなのかもしれない。
採点：★☆☆☆☆
・車谷晴子『美少年のおへや。』連載第2回
あらすじ：百合オチ。ほかにはなにもない。
ネームは前回よりは頭に入るが、これは私が百合オチをたくさん読んでいるせいかもしれない。
採点：★★☆☆☆
・山中リコ『桃色パンチ』新連載第1回
面白いまんがはみなそれぞれ違っているが、つまらないまんがはお互いによく似ている。共通点のひとつが、「共感することを禁じられた悪役」だ。
TVの時代劇の悪役には共感できる。彼らはみな色と金を求めている。色と金に共感できないほどの聖人は、おそらくTVなど見ない。
だが一体どういうわけか、つまらないまんがの作者は、別の道をゆく。悪役に共感するのは絶対にいけないと思い込んでいるのかもしれない。それにしても、いろいろな方法があるだろう。
・そもそも悪役を出さない
・「規則だから」「命令だから」で行動するロボットのような奴
・「宇宙人が電波で俺を操ってるんだ」というような気違い
だが一体どういうわけか、まるで判で押したように、「共感することを禁じられた悪役」を出す。
理由はわからない。もしかするとそれが一番簡単なのかもしれない。安易な道をゆくのが好きなら、まんが家のような茨の道はとうていお勧めできないが。
この作者が、まんが家として成功する可能性は、万に一つもないと断言する。
採点：☆☆☆☆☆
・咲坂芽亜『ラブリー・マニュアル』連載第2回
あらすじ：主人公が「好き」と言ったとたん、彼氏役がなびいてきた。
前回も今回も、主人公は「モテ」のために学校側と衝突している。2回続けてやったからには、なにか重要なことなのだと思うが、扱いが小さい。伏線かもしれない。
「モテ」は体制的な価値だ。学校も体制だ。だから、主人公が学校側と衝突するのは、2つの体制のあいだの代理戦争といえる。空虚ですさんだ戦いなのに、どうも作者にはそのことがわかっていないように思える。
さて余談だが、体制とはどんなものか？
体制はイメージをふりまく。学校という体制は、「勉強がよくできれば幸せになれる」というイメージをふりまく。モテという体制は、「いい男をつかまえれば幸せになれる」というイメージをふりまく。ソ連共産党という体制は、「よく働けば幸せになれる」というイメージをふりまく。体制のふりまくイメージのなかでは、各個人の事情はまったく考慮されない。
体制は約束を与えない。約束を破りつづける人は信用をなくすが、体制は約束を与えない。だから反例をいくら積み上げても、体制のふりまくイメージは汚れない。「勉強がよくできたのに不幸になった」「モテたのに不幸になった」という反例は、体制にはなんの影響も及ぼさない。
採点：★☆☆☆☆
・くまがい杏子『お天気注意報・』読み切り
主人公が留年寸前のピンチ、それを助けてくれる秀才の彼氏役、という話である。
いろいろ光っている。ネームの流れもいいし、画力も確かだし、彼氏役（メガネくんだ）も流麗にかわいく描けている。そしてなにより、魅力がある。16号から連載が始まるらしい。楽しみだ。
採点：★★★★★
・新條まゆ『愛を歌うより俺に溺れろ！』連載第10回
ブラック秋羅の悪行の現場にたまたま踏み込んでしまった水樹が、悪行を止めさせる。ブラック秋羅の悪っぷりに怯えつつも惹かれてゆく水樹――ではなく、そこはあっさり流して、普通にいちゃいちゃしている。
さすが新條まゆ！ おれたちに思いつかない事を平然と描いてのけるッ そこにシビれる！ あこがれるゥ！ ……と言いたいところだが、さすがにこれは新條ワールドに入れない。ブラック秋羅の悪はかまわないが、それへの水樹の反応があまりにも辛い。
採点：★☆☆☆☆
・池山田剛『萌えカレ!!』最終回
（「クララが立った！」風に）新が勝った！
というわけで私の予想（というか願望）が実現した。長生きすると人間いいことがあるものだ。
ラスト3回しか読んでいない私が言うのもなんだが、納得のいく最終回だった。拍手。
採点：★★★★☆
・青木琴美『僕の初恋をキミに捧ぐ』連載第21回
他に男を作ろうか――というのは叙述トリックで、真の彼女役（繭）は動いておらず、ライバル（照）の占有力の強さを思い知らされただけだった。照もここまで持ち上げられたからには、ただのダシでは収まらないだろう。今回はまだ照の強みは出てこない。「入院患者は寂しいから」と言い訳をしていたが、おそらくフェイクだ。
今回はネームがぎこちない。どうやら作者は、仕掛けるのはうまいが、手をつなぐのはそれほどでもないらしい。
採点：★★☆☆☆
・藍川さき『ぜんぶ、君のモノ』読み切り
ネームがあまりにもひどい。編集者は本当にこのネームにOKを出したのだろうか。1ページ目でダメとわかるネームを蹴れないとは、少コミ編集部になにが起こっているのだろうか。
採点：☆☆☆☆☆
・悠妃りゅう『すぺしゃる・ダーリン』連載第3回
「自分の男はモテる→私もモテないと愛想をつかされる」という謎の思考回路により主人公が空回りしている。
今回はネームが悪い。連載で、頭を使う時間がなくなった結果だろうか。
採点：★☆☆☆☆
今回は付録が別冊まんがなので、それも一言ずつ。
・久遠アリス『夏色★CUTE BABY』
無難、つまり見どころがない。
採点：★☆☆☆☆
・藤原なお『ラブ・カフェ』
動機と心理の整合性がおかしい。
採点：☆☆☆☆☆
・白石ユキ『ジェントル☆マニア』
秋葉原は見て描こう。
採点：☆☆☆☆☆
・福山ゆき『キミにはナイショ』
素直な感じがする。
採点：★☆☆☆☆
・真村ミオ『その先の恋の味』
主人公が変でいい。
採点：★★☆☆☆
・天野まろん『スパイシー★レシピ』
彼氏役が『かわいいオレ様』（第12号掲載）と似たようなオレ様なのがひっかかる。
採点：★★★☆☆
第4回に続く
客足が遠のく一方の蕎麦屋があるとしよう。
蕎麦屋の店主は対策を考えた。
1. もっとおいしい蕎麦を作って客を増やそう
2. 定食の客を増やして穴埋めしよう
どちらが正道で、どちらが破滅への道か、小学生にもわかる。
＜国産チーズ＞雪印、森永が増産へ 消費者の牛乳離れに対応
どうやらこの連中は、クソまずい高温殺菌牛乳を、あくまでも売り続けるつもりらしい。
「調査によれば消費者は牛乳の味に満足している」とでもいうのだろうか。もし蕎麦屋の店主が同じことを言ったら、気違い扱いされるはずだが。
経営者がビッグなビジネスを妄想するように、プログラマは自分の設計した言語を妄想する。どちらも、なんの役にも立たないが、やめられない。
この無益な行為のなかで、面白い言語機能を思いついた。ここにメモしておく。
public string Func()
{
using (FileStream fs = new FileStream("test.txt", FileMode.Open))
{
using (StreamReader sr = new StreamReader(fs))
{
return sr.ReadToEnd();
}
}
}
よくあるC#のコード片だ。
このコード片には、意味的な無駄が多い。
まず、もしC#に型推論があれば、こう書ける。
public string Func()
{
using (var fs = new FileStream("test.txt", FileMode.Open))
{
using (var sr = new StreamReader(fs))
{
return sr.ReadToEnd();
}
}
}
FileStreamだのStreamReaderだのと2回書かせるのは、カナ坊の陰謀としか思えない。
ここで重要なのは、fsもsrもその型はコンパイル時に決定している、ということだ。コンパイラは右辺の型でvarを置き換えているにすぎない。これと同様に以下の話も、実行時ではなくコンパイル時の話である。
さて、まだ無駄がある。fsとsrだ。これらの変数名はそれぞれFileStreamとStreamReaderを省略したものだ。綴りを変えてあるだけで意味的にはこれもやはりカナ坊言葉だ。
実は私はこのことで、かれこれ10年ほど悩んでいた。
私は、「よい名前（クラス名、関数名、変数名、名前空間名）のつけかた」を余すところなく説いた記事や本を10年以上探してきた。しかし、ある程度までのことは書いてあるものの、余すところなく、とまでのものには出会えなかった。やがて私は気づいた。これは、ある程度以上から先は、暗黙知でしかありえないことなのだと。
さらに進んで、こういう結論に達した――プログラミングから計算機科学を引き算すると、「よい名前」が残る。
設計や言語のよさは、よい名前をもたらすかどうかで測られる。よい名前についての暗黙知を持たないプログラマは、よいプログラマではありえない。つまるところ、「よい名前」こそプログラミングの極意だ。
サンプルコードは概して、よい名前を使わない。たとえば上のコード片では関数名がFuncになっている。実際のコードではこんな関数名は使わない。
だから私は悩んだわけだ。fsだのsrだのといった変数名は、Funcという関数名と同様、サンプルコードの世界からの悪しき流入であり、本当はもっとよい名前をつけられるのではないか？
だが私はついに発見した。これもやはりカナ坊の陰謀だ。こう書けるべきなのだ。
public string Func()
{
using (var = new FileStream("test.txt", FileMode.Open))
{
using (var = new StreamReader(FileStream))
{
return StreamReader.ReadToEnd();
}
}
}
ある変数スコープ内で、ある型の変数が1個しかありえないことが自明である、というケースは非常に多い。変数名のかわりに型識別子でバインドされる変数があっていい。上の例では、変数宣言から変数名を省略することで、そのような変数を宣言している。
こういう変数を、仮に「型バインド変数」と名づける。
クラスのメンバ変数にも型バインド変数は必要だ。ただしこの場合、メンバ関数内では、メンバ変数と同じ型あるいは親子関係にある型の型バインド変数の宣言を禁止すべきだ。つまり、こういう書き方はコンパイルエラーになるべきだ。
class MyClass
{
FileStream;
public string Func()
{
using (var = new FileStream("test.txt", FileMode.Open))
{
using (var = new StreamReader(FileStream))
{
return StreamReader.ReadToEnd();
}
}
}
}
親子関係にある型も禁止、つまり、どちらのFileStreamをStreamに置き換えてもやはりコンパイルエラーになるべきだ。
型バインド変数は、ある変数スコープ内である型の変数が1個しかありえないことが自明、というケースのためのものだ。変数スコープが上書きされるケースや、親子関係にある型が2つ出てくるケースは自明とはいえず、型バインド変数の出番ではない。（なお、型バインドのメンバ変数に代入するときは、左辺をthis.FileStreamと書く）
これだけで話が終われば平和で些細な言語機能なのだが、実はお楽しみはこれからだ。
型バインド変数はその変数スコープと特殊な関係にある。そして、上のコード片で、ReadToEnd()というメンバ関数がある型バインド変数はStreamReaderだけだ。
だから、こう書けていい。
public string Func()
{
using (var = new FileStream("test.txt", FileMode.Open))
{
using (var = new StreamReader(FileStream))
{
return ReadToEnd();
}
}
}
つまり、関数の名前空間に、thisのメンバ関数だけでなく、型バインド変数のメンバ関数も含める。これを仮に、「関数名前空間の拡張」と呼ぶ。
阿鼻叫喚の渦を巻き起こす超Perl級の言語機能に見える。しかし角を取る方法はいくらでもある。変数宣言時にimplicit指定子を要求するなどだ。それに、フールプルーフは実際に馬鹿を観察しないことには論じられない。先に進もう。
ローカル変数と同様、型バインドのメンバ変数のメンバ関数も、名前空間に含まれる。ちょっとクラス継承（実装継承）に似た働きをするわけだ。ではもっとクラス継承らしくしてみよう。以下のようなキャスト演算子を、デフォルトで定義するのだ。この機能を仮に、「デフォルトのキャスト演算子」と呼ぶ。
class MyClass
{
public FileStream;
...
public static implicit operator FileStream(MyClass mc)
{
return mc.FileStream;
}
}
一目瞭然だが、このMyClassのインスタンスをFileStreamにキャストして得られたインスタンスは、MyClassに戻すことはできない。しかし、そもそもダウンキャストは型システムの抜け道だ。そのためC#でもJava言語でも、ダウンキャストは明示的に指定しなければならない。ダウンキャストを前提に設計することは滅多にない。
ダウンキャストがどうしても必要なら、以下のように書ける。これは、ダウンキャストをデフォルトで提供するよりは、ずっと合理的なはずだ。
class MyClass
{
public MyFileStream;
class MyFileStream : FileStream
{
public MyClass;
public MyFileStream(string, FileMode, MyClass mc) : base(string, FileMode)
{
this.MyClass = mc;
}
}
}
ダウンキャストを例外として考えると、こんな考えが浮かぶ――こうしてみるとクラス継承のほうがむしろ、言語機能として一般性に欠けるのでは？
そもそもクラス継承を悪だとする議論は古くからある。この煽りを食って、Java VMと.NET CLRは多重クラス継承ができなくなってしまった。単一クラス継承が残されたのは、必要悪ということだろう。多重クラス継承が悪で単一クラス継承が善なのではない。「複数は耐えがたいが1個なら耐えられる」という妥協が、単一クラス継承の本質だ。
しかし私に言わせれば、多重クラス継承をなくしたことで、重要なものまで失われた。デザインパターンでいうコンポジションで、委譲のためのコードを書いたことがある人なら、わかるはずだ。委譲のためのコードとは、およそ非人間的なコピペだ。
では、そもそもクラス継承のメリットを、継承以外の手段で提供すればいい。型バインド変数＆関数名前空間の拡張＆デフォルトのキャスト演算子なら、それができる。
まとめ。
ある変数スコープ内で、ある型の変数を1個しか使わないことが自明、というケースがある。そのような変数のために、変数名のかわりに型識別子でバインドするという言語機能を考える。そのような変数を、型バインド変数と呼ぶ。
型バインド変数は、ローカル変数だけでなく、メンバ変数としても宣言できる。
関数の名前空間に、型バインド変数のメンバ関数を含める。この機能を、関数名前空間の拡張と呼ぶ。
型バインドのpublicなメンバ変数があるクラスは、その型へのキャスト演算子をデフォルトで備える。キャスト演算子を使うことで、その型でバインドされているメンバ変数が得られる。この機能を、デフォルトのキャスト演算子と呼ぶ。
型バインド変数＆関数名前空間の拡張＆デフォルトのキャスト演算子によって、クラス継承の機能を肩代わりできる。これはクラス継承の問題点を避けながら利点を得られ、さらに利点をより使いやすくしている。
さて、こんな機能が実装された言語を使える日は来るのか？ ありえない。
というわけでこれを、「妄想型プログラミング言語」と名づける。
とっくの昔にお忘れかもしれないが実はこれはSSなので、この欄だけでもSSらしくしてみたい。
緋沙子「道を誤ったのだよ。貴様のような攻めキャラのなりそこないは粛清される運命なのだ、わかるか！」
陸子「まだだ、まだ終わらんよ！ 」
これでだいぶSSらしくなったと思う。
（なにか誤解があるらしい）
＊
繰り返すこと。
親に虐待されて育った人は、自分の子を虐待するようになりやすい、と言われる。陛下がなさっていることも、そのようなものかもしれない。
――そう考えて私は、自分の頬を、手で覆った。陛下に平手打ちされたことを思い出して。
こうして物事は、よいことも悪いことも、繰り返すのかもしれない。それが文化とか、階級とか、民族になるのかもしれない。
でも、同じことを繰り返すのではない。カール・マルクスいわく、『歴史は繰り返す。ただし、一度目は悲劇として、二度目は茶番として』。一度起こったのと同じことは、二度と起こらない。
陛下がなさっていることも、陛下ご自身が受けた仕打ちと同じようでいて、実はまったく違う。
生まれて間もないうちに捨てられた陛下は、自分が捨てられたことを体験なさっていない。陛下は、事が終わってしまったあとで育ち、物心がつき、自分の生い立ちを知り、そしておそらくは、捨てられるという体験を、空想なさった。
その空想はどんな色をしていただろう。
いまはごく現実的な陛下も、幼いころには、生みの母親のことを優しく美しく思い描かれたのだろうか。ご自分が捨てられたことも、その優しさゆえの悲劇として、薔薇色に空想なさったのだろうか。
気持ちの沈んでいる日には、わざわざ憎むまでもないような下劣で愚鈍な女を、思い描かれたかもしれない。自分が捨てられたことも、ごくつまらない灰色の出来事だったと、自分自身に言い聞かせておられたかもしれない。
よほど薔薇色の空想でも、いまの緋沙子の現実ほどきらびやかではない。
母親を演じるのは、美しく賢い千葉国王。陸子陛下ほど豪華な母親を思いつくのは難しい。緋沙子を捨てるのは、けちな愚かさや運命のせいではなく、自分の欲望のため。その緋沙子も、哀れまれるだけの無力な赤ん坊ではなく、悲劇の主人公にふさわしい強さと気高さを備えている。
そして、緋沙子が捨てられても、結局はそれほどひどいことにはならない。緋沙子には、赤ん坊とちがって、ひとりで生きていけるだけの力がある。陛下も金銭面では緋沙子を支えてくださるだろう。緋沙子は、赤ん坊とちがって、自分というものを持っている。それはこの悲劇のあとも、さほど傷つかずに残るだろう。
陛下がどういう事情で捨てられることになったのか、私には知る由もない。けれど、どんな事情だったにせよ、これだけは間違いない――いまの緋沙子の現実のほうが、ずっといい。
繰り返すこと。
陛下は、生みの母親にされた仕打ちを、緋沙子に向かって繰り返している。けれど、繰り返しているのは同じことではない。それは一度目とは比較にならないくらい、美しく、鮮やかで、甘い。
私はできればよい人間でありたい。けれど私は天使のようになりたいとは思わない。自分のだめなところをすべて切り捨てて、完璧な人間になりたいとは思わない。私は美しい姿でありたいから化粧をする。けれど自分の顔を、天使の顔と取り替えてしまいたいとは思わない。それと同じことだ。
自分の顔を取り替えたくないように、陛下のお顔が天使のようであってほしいとも思わない。
陛下のお顔と同じく、お心も天使のようではなく、緋沙子を捨てようとなさる。
繰り返すこと。
自分がされたことを人にしてしまうとき、一度目よりも、甘く美しくする。
陛下のなさっていることは、悪い。けれどそこには、人間の素晴らしい力が発揮されている。天使ではなく、よい人間であるための力、悪いけれど、よいものが。
もし陛下のなさることが本当に間違っていれば、私は必ずお止めする。私にはそれができる。陛下をお守りすることが私の役目なのだから、陛下ご自身の過ちからも、お守りする。
緋沙子を捨てることのなかにある、悪いけれど、よいものが、私をそこまでゆかせない。陛下にとって悪いことだと、心の底から信じることができない。これでは、陛下をお止めできない。
なら、心の底から信じることをしよう。
信じること――私が緋沙子を守る。
私が陛下のかわりになれるはずもないから、私なりのやりかたで、緋沙子を守る。そんなことができるのかどうかも知らない。けれど、決意することは、信じることだ。
繰り返すこと。
『私とは会えなくなってもいい？』
それは一度目よりも甘く美しいだろうか。おそらく、きっと。
けれど。
Continue
まずはこちらをご覧いただきたい――『間違ったコードは間違って見えるようにする』
アプリケーションハンガリアンはコンパイラの関知しないところにあるので、コンパイルエラーを出してくれない。しかしC#なら、アプリケーションハンガリアンをやめて、型を使う方法がある。
using System;
namespace MyNS
{
struct Int32Derivative<T>
{
private Int32 val;
public static Int32Derivative<T> operator +(Int32Derivative<T> left, Int32 right)
{
return new Int32Derivative<T>(left.val + right);
}
public static Int32Derivative<T> operator -(Int32Derivative<T> left, Int32 right)
{
return new Int32Derivative<T>(left.val - right);
}
public static Int32 operator -(Int32Derivative<T> left, Int32Derivative<T> right)
{
return left.val - right.val;
}
public static Int32Derivative<T> operator *(Int32Derivative<T> left, Int32 right)
{
return new Int32Derivative<T>(left.val * right);
}
public static Int32Derivative<T> operator ++(Int32Derivative<T> left)
{
return new Int32Derivative<T>(left.val++);
}
public static Int32Derivative<T> operator --(Int32Derivative<T> left)
{
return new Int32Derivative<T>(left.val--);
}
public Int32Derivative(Int32 a)
{
val = a;
}
}
}
型Tはダミーだ。
Int32Derivativeを使うと、このように書ける。
using System;
namespace MyNS
{
using RowIdx = Int32Derivative<RowIdxStub>;
using ColIdx = Int32Derivative<ColIdxStub>;
class RowIdxStub
{
// nothing
}
class ColIdxStub
{
// nothing
}
class Program
{
static void Main(string[] args)
{
RowIdx ir = new RowIdx(0);
RowIdx ir2 = ir + 10;
int diff = ir - ir2;
ColIdx ic = new ColIdx(200);
ic++;
}
}
}
RowIdxとColIdxのあいだの演算や型変換がコンパイルエラーになるのはもちろん、RowIdx同士・ColIdx同士の足し算も失敗する。そしてRowIdx同士・ColIdx同士の引き算はちゃんとintを返す。
なお、私はこの手法を思いついただけで、実際に使ったことはない。あしからず。
会員2000人に電話でアンケート調査を行い、8割以上から「遮断サービスが必要」との回答を得る
このやりかたのソ連臭さを、どう説明したものだろうか。おそらくローレンス・レッシグが解説してくれると思うので、それを待ちたい。
Dave Craneほか著『Ajax イン アクション』（インプレスジャパン）を8割がた読んだ。
突然だが、戦場は4つの基本的な要素でできている。
・飢え
・埃
・糞
・シラミ
これだけは絶対に忘れないでほしい。飢え、埃、糞、シラミだ。
これらの四大要素があまり目立たない戦場も、ごく一部にはある。米軍の力はあらゆる不可能を可能にするらしく、毎日シャワーを使うことさえあると聞く。だがそういう恵まれた環境は例外だ。戦場は四大要素でできている。四大要素があるのではなく、四大要素でできている。24時間、四大要素のなかで暮らすのだ。
さて私の経験によれば、Ajax開発は、戦場の暮らしに少しだけ似ている。こちらの四大要素は、多様性、非常識、情報不足、テスト困難だ。
現代のほとんどのプログラマは、こういう経験をしたことがないはずだ。匹敵するものがあるとしたら初期の携帯Javaくらいか。私は深入りしなかったが、聞くところでは、どうやら四大要素でできていたらしい。
多様性について。
「非互換性」という問題はよく知られている。だがそれは真実をごまかした表現だ。非互換性というと、まるで2つの実装のあいだで起こることのように聞こえる。だから、「多様性」と言わなければならない。Gecko系ブラウザのバージョンごとの違い、Operaのバージョンごとの違い――思い出しただけで頭痛がしてくる（ろくに思い出せないが）。しかも、私の知っていることなど、ちょっと味見した程度にすぎないのだ。
非常識について。
どんな人間もかならず常識を持っている。「世の中にはこれとは違う常識もある」などとは夢にも思わず、まったく無自覚に信じていることがたくさんある。同様に、プログラミングの世界にも常識がある。
まず、JavaScriptという言語自体が、滅びた一族の最後の生き残りだ。JavaScriptのいくつかの機能（プロトタイプベースのOO機能やスコープチェーン）はエキゾチックに見える。しかし実は、1980年代半ばまでは、これが未来になるはずだった。あれほど将来性を感じさせていたSmalltalkが、あれほどあっけなくC++とJavaに敗れるとは、今でも信じがたい思いがする。このとき以来、「なんであれ動的なほうがいい」という考えは、仮説から信仰に変わった。いまだに「これからは動的言語」などと臆面もなく抜かす信者は有害なので全員死んでほしい――話がそれた。
滅びたとはいえかつては大きな一族だったので、そのつもりで調べれば理解できる。さあ理解した、というところでこれだ――IEのガベージコレクタは腐っている。Smalltalk系言語のガベージコレクタが腐っていて、しかも何年も修正されないままだとは、夢にも思わない。まさに非常識だ。
Ajax開発では、心の底から「ありえない」と叫ぶしかない非常識な事態に、ほとんど毎日出くわす。
情報不足とテスト困難について。
Ajax開発では、設計は無駄だ。最小限の設計ではなく、本当のゼロ設計でいい。どんな設計も、確認された事実のほかに、常識に依存している。そしてその常識は覆される。かなりの確率で、設計がまるごと覆される。だから設計は無駄だ。
設計がなければ、行動パターンは一つしかない。
なにも考えずにテキストエディタに向かい、書けそうなところから書く。いくつかのブラウザでテストする。動かないところで頭を抱え、printfデバッグをやりまくる。問題の原因をつきとめるのではなく（追いかけてもまるで蜃気楼のようにつかまらない。おそらく常識に囚われているせいだ）、症状を回避するための小細工を弄する――まるでプログラミングを覚えて三週間目の中学生の「ハック」な行動パターンだ。Ajax開発という世界のルールが、それを強制するのだ。
このハックで得た知識をもとに、正しい設計で書き直す？ 残念ながらそれは動かない。なんにせよ設計をした以上、それは必ず常識に依存しており、それは覆される（だから私はAjax用のJavaScriptライブラリに非常に懐疑的だ。prototype.jsがあれほど有名なのは、それ以上のものが作れないからではないか？）。意味のある動作をするアプリケーションなら、おそらく5回は設計をやりなおして、やっと動くようになるだろう――テストしていないブラウザで致命的なことにならないよう祈りながら。
もし、数十種類のブラウザで同時にテストしてくれる自動テスト環境があれば、物事はずっとよくなるかもしれない。ブラウザウィンドウをキャプチャして正解画像と比較し、マウスクリックもちゃんとエミュレートしてくれる環境だ。……しかし、テストケースごとに正解画像を用意する手間は？
飢え、埃、糞、シラミ。
いかにも「お手軽にそれっぽいことを書きました」的な本なら、こうした問題に背を向けているのも、やむをえないと思える。残念ながらこの業界では本とはそういうものだ。しかし、653ページの大著が、体系的としか思えないやりかたで四大要素に背を向け、たまに触れたときにも「こういうこともありますよ、でも大したことじゃないんですよ」という態度を取るのは、当然とはいえない。糾弾されるべきことだ。
そう、私は本書を糾弾しているのだ。本書は、Ajax開発という戦場の暮らしを、まるでホテル暮らしのように見せかけている。
SafariとOperaにJavaScriptデバッガがないことが、いったいどんな苦しみか。その苦しみを和らげるテクニックこそ必要だ。その話は、なんの一般性もないトリビアの寄せ集めになるだろう。しかし、それを言わずに「デザインパターン」などとぬかす奴がのこのこやってきたら、一発お見舞いする以外にない。だから私が一発お見舞いしているわけだ。
四大要素のない健全な世界なら、私も文明人らしく優雅にデザインパターンの話に終始したい。しかしAjax開発はそうではない。もう一度繰り返す。飢え、埃、糞、シラミだ。それがAjax開発だ。
『Cheese!』7月号増刊を読んだ。
ご存知でない諸氏のために説明すると、『Cheese!』は小学館の発行する少女まんが誌である。少コミの姉妹誌といった位置づけで、少コミより上の年齢層（中学生）をターゲットにしている。なお今回読んだのは増刊のほうであって本誌ではない。お間違えなきよう。
作品ごとのレビューはあまりにも辛いので、気になったテーマでまとめてみる。
少コミ系の少女まんがを読むかぎり、「モテ」という煽りからは逃れられない。では、「モテ」という煽りにどう向き合うか。
・素直に煽られて焦る・反発する
・煽りとして相対化する
・作家の考えをみる
などなど、さまざまなスタンスがありうる。
今回は、「モテる方法」、モテメソッドについての作家の考えをみてみよう。これはメガネ問題への態度から読み取れる。
モテメソッド的には、メガネをやめてコンタクトにするほうがいいのか？ それとも、メガネを生かすほうがいいのか？ これがメガネ問題だ。
まずは、腰を落ち着けて、よく考えてみてほしい。
他の事情を考慮に入れず、無条件にメガネをやめてコンタクトにすればいいというのは、自分の欠点を隠そうとする態度だ。それも、メガネが実際に欠点として働くからではない。
近世・近代の売春と婚姻について、少々調べたことがある（恋愛には疎いがあしからず）。その経験から言わせてもらえば、時と場合と相手を問わず無条件に欠点として働く欠点はただひとつ、「バカ」だけだ。バカ女がモテるのはエロゲーの中だけだ。しかし少なくともこの号には、バカという欠点を隠そうとする話はない。漢字や熟語が読めなくてしょっちゅう青ざめている主人公（といっても学力が怪しいだけで頭はいい）など面白そうなのだが、そういう話はない。それに対して、メガネ問題にかかわる話は3本もある。
メガネという欠点は、現実のものではない。お手軽に隠せるからこそ欠点として認識される、いわばスケーブゴートだ。それがわかっているかどうかで、話の説得力がまるで違ってくる。
嶋木あこ『好きになるまで待って』と、河丸慎『初エッチ×LV.0』では、主人公はメガネをやめてコンタクトにすることでキレイになる。どちらでも、メガネを外すことには重点はない。メガネ＝ダサい、という安易なまんが的記号として使われているだけだ。「無条件にメガネをやめてコンタクトに」とまではいえないようにも見える。
しかし、だ。
キレイになるという高度に複雑なプロセスが、安易なまんが的記号として表現されること――このやりかたに、作家のモテメソッドへの考え方を読み取らないわけにはいかない。しかも、そのまんが的記号は、「無条件にメガネをやめてコンタクトに」という発想に立脚している。
考えれば考えるほど、メガネ問題への回答はひとつしかない。「メガネを生かすほうがいい」だ。
本はるか『欲しいの？』は、この点では、正しい態度を示している。メガネに重点を置き、メガネを外さないままで、主人公をキレイに描く。そして、「別にいんじゃん？ メガネのまんまだって」と、乙女ちっくの時代に大流行した有名手筋でまとめている。
これでいいのか？ いや、よくない。
この有名手筋、「そのままの君が好き」は、「モテ」という煽りと両立しない。そればかりか、「キレイになりたい」という願望とも両立しない。
あれほど流行した有名手筋が、どうして今は廃れてしまったのか。その理由がここにある。「モテ」という煽りは少コミの特殊事情だとしても、「キレイになりたい」という願望は普遍的なものだ。「そのままの君が好き」は、単なる流行り廃りで廃れたのではない。この世の基本原理に反しているため、長続きしなかったのだ。
というわけで、この号のなかには、メガネ問題についての納得のいく結論は見つからない。「メガネを外してキレイになる」の安易さと、「そのままの君が好き」の弱点をどちらも避けた、新しい結論が必要だ。
新しい結論がまだないので、この話もオチがない。あしからず。
読者諸氏はどんな紅茶がお好きだろうか。
私のお勧めは、F&MのBreakfastだ。東京の店頭で買うのは難しく、今では日本橋三越にしか置いていない。昔は新宿京王デパートにもあったのだが。
これをミルクティーで飲む。牛乳は低温殺菌牛乳だ。スーパーの店頭が高温殺菌牛乳で占められているのを見るたびに、雪印事件は起こるべくして起こったのだと思わされる。
＊
言うまではわからなかった。
言った瞬間に、わかった。
私はなにか重大なことを言った。たとえ緋沙子がその重大さをわからなくても、わかっているのが私ひとりだけでも、それは重大なことだった。
愛の大きさは比較することができない。それがわかっているのに、愛の大きさを比較させようとするのは、いったいどういうことなのか。
緋沙子は最初、いぶかるように、わずかに目を細めて私の様子をうかがっていた。そしてすぐに、その表情が微笑みに変わる。
「パパとママ、どっちが好き？ ――ってことですか？」
どうにも答えにくい質問だった。緋沙子は母親と死に別れ、父親から性的虐待を受けて、子供の家（孤児院）に送られた。そんな人の口から出る『パパとママ』には、冗談にならない重い響きがある。
それで私はごまかした。
「ひさちゃん、やっと笑った」
言われると、緋沙子は笑顔をひっこめて、仏頂面になろうとした。
「私を口説くつもりなら、笑ってるほうがいいんじゃない？」
すると今度は、さっきの無防備な笑顔のかわりに、気取った笑顔を出してきた。
「設楽さま、はぐらかしたって、わかります」
私はなにか重大なことを言った。それは緋沙子にもわかったようだった。
「私は、陛下に申し上げちゃった。ひさちゃんは、私の一番大切な人ではありません、って」
「おかげで私はクビです」
その口ぶりは、緋沙子の歩く姿を連想させた。背筋をまっすぐにして、ぴんと胸を張った姿。孤独に押し潰されないように、戦う人の姿。
比較することのできない愛の大きさを、比較させようとするのは。『パパとママ、どっちが好き？』と子供に訊ねるのは。
愛されなくても悲しまず、愛されても怯まない、その徴。
つまり、愛していることの証。
愛の大きさの大小を、口にのぼせるのは。『一番大切な人ではありません』と私が言ったのは。
嘘をついている徴。
誰かを愛していないことを、愛の小ささにすりかえて、言い訳しているか。
あるいは。誰かを愛していることを、小さく見せかけて、ごまかそうとしているか。
『一番大切な人ではありません』と私が言ったのは、『陛下を愛するように愛しています』という意味。
「ごめん」
緋沙子は微笑んだ。今度は、気取ってもいなければ、無防備でもない。弓がたわんでいるように、楽しい秘密を知っている人のように、なにかの力を秘めて輝いている。
「ね、いま、調子が出てきました――」
そのとき、火にかけていたやかんが鳴りだした。私はキッチンにゆき、紅茶をいれる。居間に戻り、さっきよりは少し離れて座って、
「なんだっけ、調子が出てきたの？」
「……もういいです」
「ごめん」
「私は謝りません」
「そりゃ、ひさちゃんは悪いことしてないもの」
「いいえ。設楽さまに辛い思いをさせてます。悪いことです。
でも謝りません。
これからも、設楽さまに辛い思いをさせるつもりです」
ゆっくりと、なにかを確かめるように、緋沙子は言った。
声は静かだったけれど、心はたかぶっているのだろう。頬には赤みがさし、目は潤んでいる。
美しい。
あまりに美しくて、私は目をつぶった。
「――名前で呼んで。ひかる、って」
「ひかるさま、――」
緋沙子が身体を近づける気配がした。
抱きしめられる、と思っていた。けれど緋沙子は私の手をとると、その甲に軽くくちづけた。
目を開けると、緋沙子は私の手をとったまま、落ち着かなさそうにしていた。私の視線に気づくと、その手も離して、
「……お茶は、まだしばらく時間がかかるんですね」
「やっぱり今日は、調子が出ない？」
「はい。泣き落としなんて、カッコ悪すぎて、できません」
「それもそうか」
「でも、手ぶらで帰るのも嫌ですから、これからずっと、『ひかるさま』ってお呼びします」
そのあとは、以前と同じように、おしゃべりを楽しんだ。
このあいだの食器の話の続きをした。この週末に、緋沙子の家を訪ねる約束をした。
公邸の噂話をした。大沢さんは、お召し物にゴスロリを入れようと何度も企んでは、そのたびに陛下に跳ねつけられているとか。
陛下のことを話した。
『ひさちゃんはひかるちゃんが好きで、でもひかるちゃんは気がつかない、っていうのが理想だったんだけど』
『ひさちゃんがいなくなって、落ち込んでるひかるちゃんが、見たいんだー』
そんなことをおっしゃったという。
今日は私の帰りが遅かったので、話せる時間はあまりなかった。緋沙子をバス停まで送ってゆき、バスが来るまで、ずっと話していた。
「またね」
「はい。土曜日、楽しみにしてますから」
明後日にまた会うのに、私は、バスの窓に向かって手を振り、緋沙子も振り返した。
自分の気持ちが、痛いほどわかる。私は緋沙子が好きだ。
Continue
あらゆる人々と同じく、プログラマの耳に入る情報も、かなりの部分がテンプレでできている。
「××は役に立たない」というテンプレを聞かずに一週間を終えることはまずない。それでも、××の中身によっては煽られる人がいるのだから面白い（コメント欄）。
登場したばかりの新技術は、それがどのくらい役に立つのか、誰も知らない。だから、「金槌を使えば、ネジ回しなんかなくても、木材に木ネジを打ち込めますよ」というような極論を唱える人が出てくる。実際に木ネジを打っている人がこう主張するならまだいい。しかし、自分では打ちもせずに主張する糞野郎がぞろぞろと出てくるのだから目障りだ。その反動として、「金槌は役に立たない」という声の大合唱が始まる。
だから、「××は役に立たない」という声はいつものことであって、なんの問題もない。そういう声がやかましく聞こえてきたなら、××をかじっておいたほうがいい。他の人が、木ネジを打ち込むような真似をたっぷりやらかしてくれた後なので、同じ轍を踏まずにすむ。
問題は、そういう声が聞こえない技術だ。
「××は役に立たない」と言われないような技術は、以下のどちらかだ。
1. わずかな数の信者以外は誰も使っていない
2. おぞましいことが起こっている
1については解説不要なので、2について。
この世界では、本当に恐ろしいことが、現実に起こる。人間はそういうものをなかなか認識することができない。第二次大戦中の連合国では、アウシュビッツの存在など、ほとんど誰も信じなかった。ある意味では、アウシュビッツに収容された当のユダヤ人さえも、十分に信じてはいなかった。「絶滅収容所」なんてものは、どう考えても、ありそうにないことではないか？
プログラマの世界にも、そういうことが起こった――C言語だ。
「C言語は役に立たない」という声を、私はほとんど聞いた覚えがない。
もちろん、C言語は全能ではなかった。しかし全能でなければならなかった。だから、C言語の全能性を否定するようなものが、すべて抹殺されたのだ。「C言語は役に立たない」という声を発する人々が抹殺された。そういう人々のする仕事が抹殺された。C言語が人々を助けたのではなく、人々がC言語の鋳型に合わせて鋳直された。
幸いなことに、抹殺は完全ではなかった。C言語の全能性を否定するような仕事と人々も、ごく一部で生き残った。たとえば数値計算である。「C言語は速い」という神話では、彼らを抹殺することはできなかった。
C言語には、コンパイラによる最適化を妨げるような特徴がいくつもある。たとえば、参照がなく、そのかわりにポインタを使わせることだ。参照ではできてポインタではできない種類の最適化があり、これは数値計算の性能に致命的な影響を与えることがある。この性能の差はそのまま計算機時間の差に、計算機時間の差はそのままコストの差になり、このようにして示されるコストの差は、経営判断を決定的に左右した。
C言語は数値計算を支配することができなかったので、そのかわりに、「数値計算の世界にはFORTRANの資産が山ほどあって、しがらみを断ち切れない」というプロパガンダで取り繕うことになった。これにはいくらか真実も含まれている。それは、Pascalなどに移行せずFORTRANにとどまる理由ではあった。しかしC言語に移行しない理由ではなかった。
C言語の全能性のために、何が失われたか。
過去10年間のセキュリティ脆弱性情報から、メモリ管理関連のものだけを抜き出して眺めてみるといい。しかもこれは半永久的に続く。
だがこれは氷山の一角にすぎない。より巨大な損失は、生産性の分野にある。メモリ管理のために費やされたコストを測定する方法はない。だが、もし測れたとしたら、セキュリティ脆弱性による損失よりも百倍のオーダーで大きいだろう。
そして、量の損失ならまだ救いがある。質の損失はどうか。メモリ管理や文字列操作の難しさのために書かれなかったソフトウェアは、夢のなかにさえ出てこない。
おわかりだろうか。
人は、金槌で木ネジを打つ。その愚かさに気づかず、打ち続ける。けっして愚かではない何百万人もの人々が、何十年にもわたって。
おぞましいことだ。
「××は役に立たない」という声が聞こえるのは素晴らしいことだ。特に××にとって素晴らしいことだ。祝福といってもいい。
「××は必要だ」「使える」とばかり言われて、「役に立たない」と言われない××は危険だ。特に、たくさんの人が実際に××にかかわっているなら、それは、知性と決断力を総動員すべしというサインだ。
ところで、これは技術ではないが、祝福されない危険な××を思いついた。あなたはこんな声を聞いたことがあるだろうか。私はない。
「実務経験は役に立たない」
少コミ第13号を読んだ。前回からほとんど日が空いていないが、そういうタイミングで決心したのだから仕方ない。
「少コミ」がなんのことかわからない読者がいるかもしれないと気づいたので、解説しておく。小学館が発行する月2回刊まんが誌「少女コミック」のことだ。
・車谷晴子「美少年のおへや。」新連載第1回、ただし短期連載（？）の続編
主人公が家政婦になって金持ちの家に入り込む、というタイプの逆ハーレムである。謎解き要素のない『フルハウスキス』か。ただしこちらは少コミなので、家政婦ではなくメイドとなっている。短期連載かなにかの続編で、最初から主人公（小雪）と彼氏役（斎）がくっついている。
メイド服のデザインが辛い。ヘッドドレスのデザイン上の役割がわかっていない。ワンピースが前開きなのはどういう了見だろう（おそらく背中や肩が描けないからだと思うが）。資料もろくに検討せず、ほとんどなにも理解せずに描いたことが明白だ。
（ヘッドドレスのデザイン上の役割：
原理はわからないが、頭から斜めにでっぱっているものをつけると、萌えパーツとして機能する。同様のものに、看護婦のナースキャップ、To Heartのマルチの耳カバーなどがある。斜めでないと『神聖モテモテ王国』のファーザーのツノになるので要注意）
話のほうは、初エッチまでの努力と葛藤である。手筋手筋で進んでいる。オチは未遂なので、当分このまま引っ張るつもりだろう。
新連載第1回なのに、ネームがあまり感心しない。これは編集部で蹴ってほしかった。
採点：☆☆☆☆☆ 本当はもっと低い点数にしたい。
・池山田剛「萌えカレ!!」第33回、次号で最終回。
顔がそっくりな腹違いの兄弟（宝と新）の二者択一である。少コミでは、女を選ぶ二択だと、最初から結果が見える。逆に男の二択は、限界を超えて先を見せない。これも引っ張りすぎて明日を捨てている。『単行本ノ読者ニ尽クス者ガ、掲載誌シカ認メナイ私ニカナウワケガナイ』。少コミはジャック・ハンマーの世界なのだ。
「女の帰属先を試合で争う」という、古い懐かしい手筋が出てくる。登場人物の心理が精密になるとともに扱いづらくなって廃れたが、まだ完全に滅びたわけではないらしい。
宝と新の二択でどちらに行くか、私の予想（というより願望）を書いておこう。新だ。理由は、「別れた二人はまた元の鞘に収まる」というあの鋼鉄の法則を破るからだ。「元の鞘に収まるのが幸せ」というイデオロギーがどれほど有害なものか、筆舌に尽くしがたい。
採点：★★★☆☆
・青木琴美「僕の初恋をキミに捧ぐ」連載第20回
実は私は、青木琴美には先入観があった。
何年か前、たまたま少コミのある号を手にしたとき、『僕は妹に恋をする』の連載を（その回だけ）読んだ。ひどいものだと思った。絵はたいしたことがないし、話もネームも眠たい。これも『本はタイトルが9割』のたぐいか、と。
が、今回、その認識を改めた。
これが構成というものだ。実に自然な手で、うまい含みを作る。含みを生かすのもうまい。『僕は妹に恋をする』を読んでみたいという気にさせられた。思えば、少コミで男主人公の連載を持つからには、かなりの手練のはずなのだ。
話のほうだが、真の彼女役が動いた。主人公をライバルに占有されたので、他に男を作ろうか、という流れである。
採点：★★★★☆
・咲坂芽亜「ラブリー・マニュアル」新連載第1回
「モテ」という概念の煽動力はすさまじい。
「祖国」や「復讐」の煽動力は、歴史の授業で教えてくれる。それでもハマる奴はいくらでもいるが、馬鹿は放っておこう。しかし、さらに強力な「モテ」のほうは、誰もその煽動力を教えようとしない。
煽動は、口先で唱える目的を達成することができない。「祖国」を唱えて祖国を滅ぼし、「復讐」を唱えて踏みにじられる、そういう例は歴史上に事欠かない。「モテ」も同じだ。
この作品はまさに煽動だ。それも出来が悪い。「モテ」を「社会主義」に、「おしゃれ」を「労働」に置き換えれば、まるっきりソ連の体制文学になる。
煽動も、なんらかの真実を含んでいれば、価値がある。たとえば、おしゃれをする動機は、言葉にならない真実の潜む領域だ。『刑務所の中でさえ、女囚たちは郵便袋の染料で、自分たちの唇を赤くしているそうだ』（ジョージ・オーウェル『気の向くままに』180ページ）。
連載なので、第1回は煽りで、ここからいい話にもっていく、という可能性はある。「結局なに着てたっていいんじゃん→でもおしゃれしたいよね」という結論になればすべてよしだ。ただ、そこまで批判精神のある作品を少コミで読んだ記憶はないが。
ネームの流れはいい。が、やはり電波が足りない。
採点：★☆☆☆☆
・悠妃りゅう「すぺしゃる・ダーリン」第2回
話にトリックがある。なにを書いてもネタバレになるので、話については書けない。あしからず。
ネームはよどみなく流れ、笑いの使い方も的確だ。これなら彼氏役の造形が眠たくても問題にならない。
採点：★★★☆☆
・藤原なお「おねえちゃんの秘密」読み切り
どこかの遊園地でカップル用のイベント期間があり、それとのタイアップ作品らしい。
年下の男に遊園地に誘われて行き、カップル用のイベントに参加して、という話だ。年下の男とくっつく話をひさしぶりに見た気がする。花ゆめあたりなら連載でも（さらに男が小学生でも）見かけるが、少コミでは珍しい。
ネームの構成が弱い。もっといろいろな手で揺さぶりをかけるべきだ。タイアップ作品にどこまで望めるのかわからないが、広告としては読ませるほうだろう。
採点：★☆☆☆☆
・水波風南「蜜×蜜ドロップス」連載第43（？）回、次々号で最終回。
前号は第41回と扉絵にあったのに、今号では第43回と書いてある。どちらかに2話収録かと思って目次を見ても、また話のつながりからも、どうもそんなことはない。どちらかの誤植だろう。
絡みの合間に話が進む、といった趣だ。それでちゃんと納得のいくように話が進むのだから面白い。その話はというと、柚留が婚約者として可威の両親と対面する。そして当然、婚約にノーと言われる。
ところで、可威の父親は、食事中にも帽子をかぶったままだ。なんの意味があるのだろう。
採点：★★☆☆☆
・麻見雅「欲しがりなジュエル」読み切り、ただしシリーズ物。
ネームも話も面白いほど図式的で、『のらくろ』の時代のまんがを連想させる。『のらくろ』が小気味よく読めるように、この作品もなかなかいい。ただ、いくら図式的でも、宝飾品を衝動買いする主人公はどうかと思うが。
話は、ファンタジー要素の混じった怪盗物だ（このへんもまた『のらくろ』時代を思わせる）。衝動買いした宝飾品が、催淫の呪いのかかったもので、主人公を淫夢などで苦しめる。例によってのピンチのあと、問題の怪盗が現れ、主人公を満足させて宝飾品を盗んでゆく。
あらすじを書くとなにかねっとりした話のようだが、実物はやけにからっとしている。不思議な個性だ。
採点：★★★☆☆
・天音佑湖「恋敵は子猫ちゃん・」読み切り
生徒がみなペットを連れて登校するという謎ドリームな学校――をどう思うかが問題だが、ここで否を唱えるのは少コミ精神に反する。力強く共感するのだ。
学校の獣医が、主人公の猫を気に入り、それをきっかけに二人は接近、それは嬉しいけれど自分に関心を持ってほしい、という話である。
謎ドリームには共感しよう。共感する。共感した。
が、動物の絵が、あまりにも辛い。画面の構成も辛いので、どうも画力に根本的な問題があるらしい。
採点：☆☆☆☆☆
・新條まゆ「愛を歌うより俺に溺れろ！」連載第9回
私をむかつかせるのは簡単だ。「男なんかより うんと気持ちいいこと してあげるよ」といったセリフを書けばいい。前回、「共に この芸術品を 愛でようじゃないか…」とぬかして全読者を驚き呆れさせた奴の言うことではあるが、それでも私は律儀にむかつく。まったく簡単だ。
今回は、水樹のピンチ脱出と、ブラック秋羅のアピールが主眼らしい。蘭が水樹に申し出た「姫」の意味はまだわからない。永遠にわからずじまいになるかもしれない。過ぎたことは忘れる、男らしい作風なのだ。たぶん望月三起也『ワイルド7』から作劇術を学んだのだろう（嘘）。
設定の複雑さも含めて、この展開に読者がついてきているのかどうか、かなり疑問だ。
採点：★★★☆☆
・市川ショウ「恋愛＠ホーム」読み切り
目指しているものはなんとなく伝わってくるが、絵、ネーム、画面構成、あらゆる技術面で辛い。
採点：☆☆☆☆☆
・織田綺「小悪魔カフェ」最終回
前回はぐだぐだなだけだったが、最後はぐだぐだなりに気持ちよく終わった。ここに出てくる「走る」という手は、なかなか汎用性がありそうだ。
採点：★☆☆☆☆
第3回に続く
ウソ泣きについて。
この技を一度も使わずに一生を終えるのはなかなか難しいと思うが、ウソ泣きをまともに描いた小説・まんがは、ひとつしか思い出せない。さらに、そのひとつのタイトルが、どうしても思い出せない。
＊
涙は、いったん流れてしまえば、それほど長くは続かない。涙をこらえている時間に比べれば、ほんの一瞬だ。
居間に通してソファに座らせたころには、緋沙子はもうほとんど泣きやんでいた。さっきまでの緊張はすっかり解けて、いまは、昼寝中の飼い犬のように、静かに息をしている。
私はその隣に座って、手を握っている。
初めは、緋沙子を抱こうと覚悟していた。私にできることはそれくらいしかない。けれど、緋沙子がすぐに落ち着いたのを見て、覚悟を取り消した。欲しいと思わないときに抱くのは、緋沙子のプライドを傷つけるだろう。
沈黙を破ったのは緋沙子だった。低い声で、ぽつりと、
「すごい自己嫌悪です」
「ひさちゃんは、なにか悪いことしたの？」
「ウソ泣きしておねだりするなんて、カッコ悪すぎます」
「ウソ泣きなんて、いつしたの？」
「さっきです」
どうやら緋沙子は、さっきの涙を、ウソ泣きと言い張ることにしたらしい。
「でも、おねだりは、するんでしょう？」
と私が意地悪を言うと、緋沙子は気色ばんで、
「しません！」
「そうだったね。ひさちゃんは私を口説きにきたんだっけ」
緋沙子は口をへの字にして、目をそらした。そして、
「はい。でも、調子が出ないから、もう帰ります」
そう言って腰を浮かせた緋沙子に、
「自信がないから、もうしたくない？」
私はいつかのセリフを持ち出した。緋沙子はすぐに気づいて、頬を赤らめ、
「――はい。こう見えても繊細なんです」
と、いつかと同じセリフで応じて、腰をソファに沈めた。
私はいったんその場を離れてキッチンに行き、やかんを火にかけた。居間に戻って、遠くから声をかける。相手があまり近くにいると、話しづらいこともある。
「さっきも訊いたけど、もう一回訊くよ。
ひさちゃんは、どうしたいの？」
「陸子さまにお仕えしていたいです」
「私とは会えなくなってもいい？」
Continue
私は少コミを読んで育った。が、あまりにも昔のことだ。すぎ恵美子が『Cherryのまんま』や『子供じゃないモン！』を連載していた頃なのだ。現在の少コミとの距離は、マーガレットとの距離とほとんど変わらない。
現在の少コミにも、少しは触れている。新條まゆを読んでは驚き呆れ（褒め言葉）、刑部真芯にしばらく注目し（百合的なセンスを感じる）、いまは、しがの夷織に少し注目している（これも百合的なセンスを感じる――と書いて自分で思ったが、……共通点はゴスロリ？）。が、雑誌自体を続けて読む機会はほとんどなかった。
なかなか面白いことになっている、いつかまた続けて読もう――と思いつつ幾歳月が過ぎた。
今日こそがその日だ。私は少コミの第12号を買った。
ただ読むだけでは面白くないので、載っている作品の感想を書いていくことにする。
まったくの異文化の目で書くほうが面白いのだろうが、ここは無理せず、元少コミ読者的にいく。
本題に入る前に、表記について。ハートマーク等は入力が面倒なのですべて中黒（・）で書く。モノローグを引用するときは“”で囲む。
・悠妃りゅう「すぺしゃる・ダーリン」新連載第1回
現在の少コミでは、主人公の彼氏役は、なんらかの権力者であることが多い（私は、榊ゆうかの描くようなイマイチで愛嬌のある男のほうが好きなので、この傾向は気に食わない）。ラノベのヒロインがなんらかの権力者であるのと同じ理屈だ（こちらには文句はないが、そもそもめったに読まない）。
ただし、その権力のつけかたには違いがある。
少コミでは、どんなに無理やりにでも、現世的な権力をつける。ラノベでは、ファンタジー色の強い権力をつける。たとえば、新條まゆ『快感フレーズ』の咲也は人気歌手、おかゆまさき『撲殺天使ドクロちゃん』のドクロちゃんは天使、という具合だ。
（もちろん例外も多い。たとえば新條まゆ『悪魔なエロス』がそうだ。新條まゆは、少コミを体現しているかのように思われているが、こういう法則を積極的に破りにゆく。この積極性が彼女を第一人者たらしめているのだろう）
さて、本作品の場合、主人公（すみれ）の彼氏役（春日）の権力は、「カリスマ美容アドバイザー」だ。また、有名な美容整形外科医の息子でもある。
最近の少女まんがでは、つきあい始めるまでのシーケンスは適当にすっとばすことが多い。本作品では回想2ページだ。前半の大部分は、春日の権力と、すみれと春日の関係を描くことに費やされる。
折り返し点で問題が提起される。「すみれと春日の関係はあまり彼氏彼女らしくない」という例のパターンだ。そこですみれは春日をベッドに誘う。微妙な行き違いのあと、すみれが気絶してオチとなる。
考え抜いたネームだと思う。連載第1回なら当たり前のこととはいえ、よく考えてある。だが、それが見えてしまうこと自体の辛さはある。
春日の造形が無難で眠たい。権力者・魅力的・無難、これらのうち2つまでは同時に成り立つが、3つ同時はほとんどありえない。
採点：★★★☆☆
・水波風南「蜜×蜜ドロップス」連載第41回
主人公の彼氏役が権力者というにとどまらず、階級のある学園世界を舞台にしている。特権階級のメンバーがそれぞれ平民をひとり指名して、卒業までのあいだこき使う、というもの。特権階級側は「ご主人様」、指名された平民側は「HONEY」と称される。
上で述べた法則に従い、主人公（柚留）は平民で、その彼氏役（可威）は特権階級、両者はHONEYとご主人様だ。
前回まで学校側は、「HONEY」のことをまじめに考えてほしいという目論見で、大掛かりな茶番を仕掛け、今回それを終わらせた。生徒側は（特権階級も平民も）その目論見にはまり、「HONEYいいねえ」「ご主人様いいねえ」「この制度いいねえ」というムードになる。
茶番終了のほかにも、かつての敵（男）と和解し、安堵の流れで最終ページ、柚留と可威がいい雰囲気になっているところでカメラが引き、二人を見つめる第三者（女）が登場。女は柚留のよい影響力を認めつつ、「可威の生涯のパートナーでいるためには まだまだ不十分だわ」で締める。
ここまでの書き方でおわかりだろうが、むかつく。「人間的な触れ合いで階級意識を克服する」式の話は、「貧乏人は金持ちよりも道徳的に高いので愛される」式の話と同じくらい有害だ。
採点：☆☆☆☆☆
・青木琴美「僕の初恋をキミに捧ぐ」連載第19回
珍しくも男が主人公である。余命いくばくもない（にしては普通の学校に通学などもする）主人公が、『君が望む永遠』流に優柔不断している。とはいえ、真の彼女役はきっちり決まっており、現ライバルがどんな意味でも勝利を収める見込みがないことは、ネームから一目瞭然だ。
完全勝利が一目瞭然なのが辛い。ライバル側に感情移入したがる読者は一定の割合で存在する（私もそうだ）。なんらかの分がライバル側にないと辛い。だが、このノリからいって、最後まで分がなくて終わるとも思えない。次回かその次あたりで、ライバル側の分を出してきて、出し遅れの証文にするのではないかと危惧している。
あと、男主人公でまじめに恋愛物しているとエロゲー臭を感じるのは、私のエロゲー脳が作り出す幻覚なのだろうか。
採点：★★☆☆☆
・サトリタエ「初コイ×ホームラン」読み切り。ただし、お題が「ハニカミ」と定められている。
主人公の彼氏役が、珍しくも野球少年である。話は、初デートを淡々と描き、取ってつけたように問題提起＆オチをつけて終わる。
アウトドアのスポーツマンには肌にトーンを貼るべきだと思うが、貼っていない。面構えも男っぽくない。思えば少コミでは昔から、スポーツマン的な男っぽい顔をほとんど見ない。脇役・チョイ役でもだ。描けないのか、描かせてもらえないのか。
導入部のネームが猛烈にぎこちない。手筋を知らないのだろう。ネームの流れのいい少女まんがを徹底的に分析してからやりなおせ、と言いたい。
採点：★☆☆☆☆
・咲坂芽亜「ラブリー・レッスン ～夏服編～」読み切り。ただし、すでに完結した連載の続編らしい。
主人公がカリスマ店員に、制服のコーディネートやヘアメイクを教えてもらう。そのおしゃれパワーでもって、（未来の）彼氏役と張り合う。当然最後はくっついて終わる。
ネームの流れがいい。だが、作品の性質上、それ以上のものはあまりない。変な匂い、変な電波が出ている作家は、こういうものは描かせてもらえないのかもしれない。
採点：★☆☆☆☆
・千葉コズエ「君のキャンバス」読み切り
絵も話も、少コミ的なところがまるでない。「ちょっといいと思っていた男の、知られざる一面（絵を描くこと）を発見→それをきっかけに接近→気合負けしないようにおしゃれに頑張る→それをからかわれる→泣く→ごめん」。
今号で一番ネームがいい。話自体もネームも、手筋手筋で進むので、特になにも言うことがなくて困るが、ぴったり噛み合って機能している。ただこれも電波が足りない。
採点：★★★★☆
・織田綺「小悪魔カフェ」連載第17回
次号で最終回とのこと。
前回までは、主人公を二人の男で取り合っていたらしいが、今回でぐだぐだな終わらせ方をしている。どうでもいい。
採点：☆☆☆☆☆
・新條まゆ「愛を歌うより俺に溺れろ！」連載第8回
現在の少コミの第一人者、新條まゆである。
かなり複雑な設定だ。私自身まだよく理解していないが、とにかくわかったことを書く。
男海山高校という男子校と、聖野薔薇女子学院という女子校がある。どちらもドリームなハイソ学校らしい。聖野薔薇には「王子様」がいる。主人公（水樹）だ。男海山にも「姫」がいる。主人公の彼氏役（秋羅）だ。水樹は校内でバンド活動をやっており、このバンドは名前を「ブラウエローゼン」という。秋羅は、聖野薔薇の校内に女装して潜入し、聖野薔薇の生徒のふりをして、ブラウエローゼンのメンバーとして活動している。しかもボーカルだ。
秋羅は、『フィガロの結婚』のケルビーノのような奴らしい。女が声をあて女装もするショタなのに、女を口説くのが大好きだ。ターゲットは水樹である。今回は、いよいよお楽しみを、というところでスケジュールに押されてストップがかかる。
聖野薔薇のイベントに、ブラウエローゼンが揃って出席する。このイベントで、水樹は上級生の美咲に会う。美咲はかねてから水樹に手を出す機会をうかがっていたらしい。このシーンが面白いので引用する。
「水樹… 会えるのを楽しみにしていたよ 僕は堂島美咲 よろしくね」
水樹：“この人が3年の王子様か… ムチャクチャ キレイじゃんか!!”
「初めまして お目にかかれて光栄です」
「水樹… 今夜 僕の部屋においで… 一緒に すてきな夜を過ごそう…」
「あ… でも あたし今夜は…」
“秋羅と一緒に…”
「いいね…」
美咲は一輪の百合の花を渡した。すると背景のモブがこれに反応して、
モブ：「美咲様が ゆりの花を!?」
モブ：「やっぱり今年のお相手は あの子なのね」
モブ：「なんか… うらやましい――っ」
“え…!? 何!? この ゆりの花… なんか意味でもあるのか!?”
この直後、秋羅が割り込んできて美咲を口説きにかかる。事を理解していない水樹をかばおうとしてのことなのだが、水樹には通じず、美咲の部屋を訪れることになる。
この百合の花はどうやら、「私の部屋に来なさい。来たら襲うのでよろしく」というメッセージらしい。秋羅が別のところで窮地に陥っているあいだ、水樹は美咲に襲われる。そこに現れたのが――突然だがここで設定の説明に戻る。
男海山高校には二人の権力者がいる。蘭と累依だ。累依は秋羅に執心しているらしい。蘭はミステリアスという役どころらしい。この二人には、秋羅のバンド活動のことはバレている。二人は聖野薔薇のイベント会場に現れ、さらに蘭は――突然だがここであらすじに戻る。
そこに現れたのが蘭である。蘭は水樹に、「助けてやるかわりに俺の姫になれ」と申し出る。この「姫」がどんな意味かは説明されていない。おそらくは、男装して男海山高校に潜入するという意味だと思うが。
よくまあこんな複雑な設定を、と驚いた。平均的な少コミ読者の頭でついていけるのだろうか。ちなみに私は、登場人物が6人を越えると、とたんに理解度が下がる。
理解するまでが大変だったが、わかってみると面白い。ケルビーノ（秋羅）が活躍すると楽しそうだ。
採点：★★★★☆
・天野まろん「かわいいオレ様」読み切り、デビュー作
少コミ的でないどころか、少女まんが的でもない。はっきりした性的嗜好を持っている主人公を、久しぶりに見た気がする。絵も、少女まんがよりは、男オタクの流れのほうが強い。
ショタ好きの主人公が、ツンデレのオレ様攻めに口説かれる話である。話もネームもよくできている。内容的には文句はない。が、電波的に、匂いのレベルで、「こいつと私の道は重ならない」と感じる。
採点：★★★☆☆
・池山田剛「萌えカレ!!」第32回
つきあっていた男（宝）を、事故で他の女（亜美）に取られて、その男の腹違いの弟（新。顔が宝にそっくり）とつきあいはじめた主人公（ひかる）。が、宝はやっぱりひかるがいいと思い直し、口説きにかかる。もともと宝が好きだったひかるとしては、ここが考えどころ。ひかるを取られたくない新としては、ここが踏ん張りどころ――で次号に続く。
理屈の通し方が、手筋といえば手筋だが、あまり好きになれない系統のものだ。ネームは微妙に能がない。
採点：★☆☆☆☆
・しがの夷織「キスだけじゃかえさない」最終回
彼氏役がアイドル、というのはよくある話だ。さらに主人公の弟もアイドルで、しかも主人公のことを好き、というところがいかにもこの人らしい。最終回なので、彼氏役の「アイドルやめる宣言」で盛り上げている。
「百合を描く人は近親相姦も描く」という相関関係があるような気がしている。この作者もその例に入ってくれるよう祈る。
理屈の通し方が、私の好きな系統のものだ。いい電波が出ている。単行本で読んでみたくなった。
採点：★★★★☆
・高田りえ「ガバ・カワ」最終回
悪魔が人間に惚れて力をなくして消滅し、人間に生まれ変わって終わりである。
話もネームもいいが、電波が足りない。
採点：★★★☆☆
第1回とあって、説明が長くなった。次号からはもっと短く書く。
第2回に続く
年をとるのは嫌なものだ。「どうすればプログラミングできるようになるんですか？」と聞かれるようになる。
愚問だと思うが、聞かれるものはどうしようもない。ここに答を書いておく。
1. この業界の語彙と概念を覚える
どんな業界でもそうだと思うが、大きな疑問を持つことは禁じられている。
「どうして携帯電話のメールのパケ代は着信側が払うの？」
ああ、サリー、そいつは訊いちゃいけないことなんだよ。なぜかっていうと、NTTドコモの野郎は、日本中のマスコミっていうマスコミに大量の広告を出して、広告料でマスコミを口封じしてるんだ。
サラ金の奴らも同じことをやってるんだ。アイフルが業務停止命令を受けるまで、アイフルを告発する報道なんてなかっただろう？
そうなんだ、サリー。広告をガンガン出してる奴らは、後ろ暗いことをしても平気だから、平気で後ろ暗いことをする。奴らには気をつけろ。サラ金とは関わるな。携帯電話は持つな。そうすれば、お前みたいな質問をしなくてもすむし、そうすれば、くだらない嘘を信じたりすることもないんだ。
まだお前の質問に答えてなかったね、サリー。教えてあげよう。
それは、NTTドコモがあくどい金儲けをしたからなんだ。もう少し細かくいうと、NTTドコモがiモードを開発したときに、開発責任者がそうしようと決めたんだ。奴がどれだけデタラメをやったか、俺はちゃんと知ってるよ。
他の奴らに同じことを訊いたら、それらしい答をもらえるかもしれない。「技術的」な奴をね。でもそれは全部嘘だ。NTTドコモに踊らされてるか、そうでなきゃ、物事を「技術的」に見るのが好きなだけだ。
iモードの開発責任者は罰されなかった。それどころかNTTドコモはiモードで大儲けした。それを見て、他の携帯キャリアも、同じことをした。
悪は滅びる、だなんてことは俺には言えないよ。サラリーマンなんてものがこの世に出てくる前から、サラ金みたいな奴らはいたんだ。
サリー、広告をガンガン出してる奴らには気をつけろ。嘘を信じなくていいように。
「昔と今を比べたら、3D CGはすごくリアルになったのに、どうして音声合成はへっぽこなままなの？」
SFXには金がかかるけど、声はどんな声でも金がかからないからさ。
そりゃ、「技術的」な話はいくらでもできる。そういう話のなかには、本当の話もある。だがね、その技術を支えてるのは、金なんだよ。大昔のハリウッド・スターの声を再現するために1千万ドル出す奴がうようよいたら、いまごろエロゲー声優なんてもんはいなくなって、声モデラーなんて商売が流行ってるかもしれないな。
さあ、サリー、そういう本質的な質問はこれくらいにして、勉強するんだ。そうすれば、もうちょっとくだらない質問ができるようになるぞ。「どうしてJava言語にはレキシカルクロージャがないの？」とかな。それは、「ヒープメモリをアロケートするときには必ずnewキーワードを使うこと」っていうルールを決めたからなんだ。たぶん、Guy Steele Jr.も、スタックたんが好きだったんだろうな。でもスタックたんの時代はもうとっくに終わってる。Parrot VMもLua 5.0もスタックレスさ。
お前もこういうオタクっぽい格好いい話がしたいだろう？ さあ、勉強するんだ。
2. 問題を、新しく学んだ語彙と概念で理解するようにする
道具箱に金槌しか入っていないと、どんなものでも釘に見えるようになる。釘に見えないものは、そもそも認識できなくなる。
財産を金しか持っていないと、どんなものでも金で買えると思えるようになる。金で買えないものは、そもそも認識できなくなる。
これは人間の本性で、克服できるものではない。存在は意識を規定する。
だから、釘を打つように、金で買うように、プログラミングするのだ。そういう状態になれば、「プログラミングで解決するべき問題が見つからない」などということはなくなる。
3. 1と2をひたすら続ける
この業界の一番いいところは、飽きがこないという点だ。新しい語彙と概念が、それこそ雨のように降ってきて、歴史の排水溝に流れ込み、忘却の海へと降りてゆく。
いい雨が降らないと思ったら、忘却の海に遊びにゆくといい。なかには復活するものもある。たとえば、スタックたんが余命いくばくもないので、コルーチンはきっともうすぐ復活する。
4. 生命、宇宙、そして万物についての（究極の疑問の）答え
このエントリをここまで読んで、それでもなお「どうすればプログラミングできるようになるんですか？」と訊くのなら、仕方ない、はっきり申し上げよう。
私も知らない。
いつかどこかで誰かが、こんなことを書いていた。
「子供は幸せの国にいる。その国では、どんなに辛くても、幸せそうな顔をしていなければならない」
＊
そのたたずまいが、すべてを物語っていた。緊張と葛藤、絶望と意思、そんな心の動きが、人のかたちになって立っているのが、いまの緋沙子だ。
立っている――それさえも不思議なくらいだった。姿勢や仕草が、ひどくアンバランスで、ちょっと風が吹いただけでも倒れてしまいそうだ。
自分のただならぬ雰囲気に、緋沙子は気づいていないようだった。
「こんな夜分に押しかけて――」
私を待つあいだ、使い慣れない言葉を、何度も頭の中でおさらいしたのだろう。もごもごと早口に詫び口上を述べ立てようとした。私はそれを遮って、
「ひさちゃんは、どうしたいの？」
緋沙子は大きく息を吸いこんだ。その音を聞くだけで、痛ましいほどの緊張が伝わってくる。
「――今日は、設楽さまを誘惑しにきました」
問いと微妙に噛みあわない返事。泣き顔と区別がつかないようなぎこちない笑顔。
私は、どうしようもなくて、微笑んだ。いまの緋沙子が誰かを口説こうとするのは、水を燃やそうとするようなものだ。馬鹿げている。けれど。
「設楽さまは本当は、陸子さまの護衛官でいれば満足なんです。恋のお相手なんかよりも、護衛官のほうが責任重大で、設楽さまはそういうのが好きなんです」
立っているのがやっとのはずなのに、緋沙子は戦いを始めた。陛下のお側に残るための戦いを。急所を見抜く目は曇っていない。けれど。
つい数時間前に、『もう身体の関係にはなりません』と陛下にお約束申し上げた。けれど。
私は緋沙子を抱きしめた。
「ひさちゃん、泣きたそうな顔してる」
「あ――」
無防備な声がひとつ漏れて、涙の堰が破れた。
Continue
エンタープライズCMSは黒歴史になったらしい。
だが、CMSは甦る。CMSの現在の実装がどんなに腐っていようと、その概念自体は、人類の夢を表現しているからだ。
Webバブルは甦った。DHTMLはAjaxへ、コミュニティはSNSへ、プッシュはRSS配信へとそれぞれ名前を変えたが、その中身はまぎれもなく、Webバブルの夢だ。「ウェブをテレビのようにする」という夢もやはり甦り、その地歩を固めつつある。最後にして最大の夢、小額決済も、近いうちに敗北から立ち上がるだろう。今度もまた敗れるかもしれないが、彼らは何度でも立ち上がる。何兆円の損害を積み上げても、彼らを止めることはできない。何度でも呼び名を変えては投資家をあざむき、金をドブに流し込み続けるだろう。それが人類の夢だからだ。経済活動が経済合理性を作り出すのであって、経済活動が経済合理的に行われるのではない。
さて、エロゲーである。
いま私の手元には、某エロゲーの開発用データがある。ファイル数は11,776個、サイズは0.98GB。これが小さすぎて参考にならないと思えるのだとしたら、たぶんあなたはコンシューマ機用ゲームの開発者なのだろう。
この経験を元に、エンタープライズCMSのあるべきユーザモデル（そのシステムの動作についてユーザが抱く世界観）と実装について私見を述べる。
まず、ユーザモデルから。
コンテンツの基本的な単位はファイルであるべきだ。
ワークフロー情報（バグ追跡やバージョン管理）は別として、コンテンツ自体はファイルを基本的な単位とすべきだ。
一般人の知能からいって、ファイルがこれほど理解されていること自体が奇跡だ。ユーザがMITかベル研でないかぎり、ファイル以外の単位が理解されると考えることはできない。
ファイルが基本的な単位なので、CVSやSubversionのように、リポジトリを使うことになる。
作業用コンテンツ（ファイル）は、CVSやSubversionのように、ローカルディスク上にコピーすべきだ。
これは実装の詳細ではなく、ユーザモデルだ。ユーザモデル上、ローカルディスクとネットワークストレージは別物だ。（認証がなく、非共有の、ユーザが一人しかいないネットワークストレージなら、速度しだいではローカルディスクとみなせるかもしれない）
「ファイル本体はサーバ上にあって、リッチクライアントで編集する」というのは妄想だ。メールの読み書きくらいは素人でもする仕事だが、プロがコンテンツを作るのは、まったく別のことだ。雑誌の付録を組み立てるようなつもりでは、自動車のエンジンを組み立てることはできない。
変更のコミットは、ファイルの保存とは別動作であるべきだ。
理由は2つある。1. コミット時にコメントを書くことで、その更新の意図を記録できる。2. やりかけの状態をコミットして、リポジトリやワークフロー情報を汚すことがない。
ファイル名の変更管理はCMSの核心である。
人間は不適切なファイル名をつける。どんなに完璧な命名規則を作り、どんなに賢いファイル名監視システムを配備したところで、無駄だ。不適切なファイル名は必ず発生する。不適切なファイル名が発生したら、対応策は2つしかない。ファイル名を適切なものに変更するか、あるいは変更せず放置するか、だ。
変更する場合には、変更前と変更後のファイルが内容的に同一のものであることをユーザに知らせる必要がある。それも、変更時に通知して終わりではない。変更情報が必要になった瞬間に通知が目に入る必要がある。また、ファイル名が変更されたときには、ワークフロー情報もそれを同一のものとして追跡する必要がある。
CMSが、独立した部品の寄せ集めではなく、システムとして統合されたものである必然性は、ここにある。
リポジトリ内のファイルには必ずワークフロー情報が付随するが、逆は真ではない。つまり、まだ存在しないファイルについてのワークフロー情報は存在しうる。
たとえば、リポジトリにアクセスしない作業者のために、発注・納品・リテイクというワークフローに対応する必要がある。納品まではファイルは存在しないが、ワークフロー情報は存在する。また、納品後のファイルから納品前のワークフロー情報をたどれる必要がある。
こういうユーザモデルをどのように実装すればいいか。
手始めに、作業用コンテンツ（ファイル）のための専用ファイルシステムが必要だ。
これは第一に、ファイル名の変更管理のためだ。ファイル名の変更を超えてワークフロー情報を追跡するには、ファイルシステムと関わることになる。TortoiseSVNはWindowsシェルのプラグインという形でこれをやっているが、動作の重さなどで、あまりいい印象がない（今はよくなっているかもしれない）。
また、専用ファイルシステムを使うことで、リポジトリからの差分取得の方法を細かくコントロールできる。たとえば、差分取得をバックグラウンドで動かしたり、ファイルが開かれるときまで遅延させたりすることができる。
コミットや差分取得のUIは、TortoiseSVNのようにWindowsシェルのプラグインとしてもいいが、それだけですべての作業をやるのは損だ。専用のアプリケーションのほうが使いやすい。ファイルを読み書きするときはExplorerなどで普通に開き、ワークフロー情報を見たり更新をコミットしたりするには専用アプリケーションを使う。
ワークフロー情報は、うっかりすると、途方もなく複雑な代物になる。ばっさりと単純にしなければならない。一例として以下のルールを示す。
・ワークフロー情報は、掲示板のスレッドのように、コメントの連続という形をとる（ワークフロー・スレッド）。それ以外の形式のワークフロー情報は存在しない。
・ワークフロー・スレッドのコメントには、ファイルを添付することができる。この添付ファイルは変更できない。
・1個のリポジトリ内ファイルには、必ず1個のワークフロー・スレッドが対応する。
さてここまで、CMSというと必ず出てくるようなことを、ほぼすべて省略してきた。検索・作業のアサイン・審査と承認・Webテンプレート・ストリーミング・Web掲示板などなどだ。
こうしたことはすべて、まったく重要でない。
これらの機能は、ユーザモデルを構築しない。ユーザモデルの上にどう載せるかが問題になるだけで、ユーザモデルを別物に変えるよう迫ることはない。たとえばWebテンプレートは、ファイルとファイルの関係として扱える（それ以外の設計はすべて呪われている）。作業のアサインはワークフロー情報中にWiki的な記号で書ける。承認は電子署名だ。検索はインデックスを、Web掲示板はRDBを扱う必要があるが、いずれにせよ正規化されている。正規化されているというのは、ファイル名に悩まないということだ。名前に悩まないような問題は、大した問題ではない。
そうそう、いうまでもないが、Webサーバを中心にしたCMSはすべてクソだ。あれらはWebテンプレートとWeb掲示板からスタートしている。機能は提供するが、管理とは無縁だ。「箱から出してすぐ使える」的な擁護も的外れだ。ここまで縷々書いてきたようなリポジトリ型CMSでも、「箱から出してすぐ使える」初期状態で配布することは簡単だ。しかもテンプレートなどがローカルファイルとして編集できる。「PHPで書いてあるからホスティングサービスで使いやすい」？ では、CVSやSubversionは、どうしてもC言語で書かなければならないのか？ 専用ファイルシステムが必要なのはクライアント側だけだ。サーバサイドはどんな言語でもいい。
以上、CMS業界の常識からはかけ離れた話をしてみた。
だが、CMS業界の常識よりは私のほうが、未来に近い。CMS業者は何万行もの糞の山を抱えており、しかもそれを売らなければならない。私はいまのところ一行も持っておらず、おそらくこれからも持たないだろう。
私は挑戦者を待っている。
参考：
巨大な格差「ザ・グレート・デバイド」／データベースは20世紀の代物
CMSはジャングル状態にある