メッセージ。 - diary

『私という病』について1つ疑問なのは、みんなこのことを
話題にして、どうしたいの？ということ。どうしたいの？

ぼくは、中村うさぎさんの本を読んで、この人と友達だったらなと
思った。この人の悩みを聞いて、ぼくも悩みを話して、
一緒にお酒を飲んで、街を歩いて、なにかできることがあるなら
してあげたいと思った。

や、そんなことはおこがましいし、そこまで責任取れないというか、
この人をそこまで好きになれる自信がないというか（まぁその前に
好かれる自信だわな）、「『本当に』それをできるのか？」と問われたら
意気地なしになっちゃうけど。

でも、なんとなく、ぼくの持つ何かを賭ければ、この人の「病」を
いくらかでも軽減できるんじゃないだろうかと思ったのは事実。
おこがましいね。（笑）

でもでもでもさー。そういう関係の人が一人いれば、もし自分が逆の
立場になったとき心強いじゃん。そういう人になら、つらいとき、
涙の1つも見せられるような気がするじゃん。

「私という病」がもし存在するのならね、男と女の間の壁がそれを
作っているというよりも、あなたとわたしの間の壁がそれを作って
いるのじゃないかと思うのですよね……。

http://d.hatena.ne.jp/masataka_k/20060518/1147918377
http://d.hatena.ne.jp/masataka_k/20060519/1148030420
http://d.hatena.ne.jp/masataka_k/20060522/1148278384

あ。これは面白い。とくに最後のやつは流行るオープンソースという
切り口で説得力がある感じ。文章力で読まされているだけかもしれないけどｗ。
あっけらかんとした感じが、Javaの人たちらしいなぁと思った。
とりあえずメモ。

うーん。大野さんの日記にコメントをしたつもりが、
反映されないなぁ。

何度も同じコメントを送るのはやらしいので（それと、
送ったつもりのコメントとは別の論点について書きたく
なったので）、ここに書いてみます。

大野さんは「本能」と「病」を分けて考えていますよね。
これはなぜでしょうか？ 本能を是とし、それ以外を
「病」として否定することは、本件を考えるうえで、
妥当なのでしょうか？

たとえば、本能として一般に認知されている（と思われる）
男は一夫多妻を求め、女は一夫一妻を求めるという説が
正しいとするならば、もはやそこに軋轢、つまり病の種が
存在するからです。

現在の社会形態において、男は一夫多妻という本能的
欲求と一夫一妻という社会的欲求の中で分裂的な要求を
強いられているのです。そりゃあ病むというものですよ。

つまり、本能を全肯定する一方で病を全否定するなどと
いうのは矛盾した論理なのです。本能を肯定した時点で
病の存在も肯定しなければならない。あるいは、もはや
男女が別の星に住むか。

……男からしてみれば、抑圧された自我の中で、二次元や
架空という幻想の世界に逃げこむという行動は、
できるだけ他人に迷惑をかけない、妥当かつ良心的な
防衛規制だと思いますよ。違いますかね？

だから、病は必要悪だと思います。とくにとりたてて
騒いだり、「男の病」、「女の病」などと分けるのは
乱暴だと感じます。生きるということは、病を背負う
ということです。だけど、健やかなるものもそこにある。
それぞれの病があり、喜びがある。是でも非でもない。
ぼくはそう思います。

# 急いで書いたので穴があると思われます。
# つっこみ歓迎ということでお願いします。m(_ _)m

ゆきちさんが企画された、未踏に採択された人たちの同窓会「ESPer2006 未踏集会」が5月20日にあった模様。話には聞いてたけど、満席とのことで行かなかったのだ。でも楽しかったそうで、行きゃあよかったなぁ。

 未来のいつか/hyoshiokの日記

 

 懇親会ではデモあり、プレゼンありで非常に楽しかった。これだけのすごい人が一同に集まったというのがすごいすごい。

 だけど、みんな孤独なんだよなあ。ネットワークしてなくて、だからこれだけの人が集まって、ネットワークしたいわけだから、ある意味、日本という社会システムからはじき出されちゃった変な人たちなのかなあ自分は、とか思った。

ふぅむ……。

こないだ、いつものように終電に乗っていたら、
同業者らしい人の会話が耳に飛び込んできた。

隣りに立っていたおじさんと女の子。
おじさんのほうは、ロマンスグレーでちょっといい
スーツを着た管理職って感じかなぁ。
女の子は、まだ若くて20代半ばに見えた。

配属されてからこのかた、上に付く同僚がみな脱落して、
まだ2年目のころから一人で客先に行っていたという彼女。
「まだ私、何も分からないのにお客さんのところに行って、
見よう見真似で打ち合わせしたり仕様書作ったりして、
しんどかったです」って。

男のほうは、たぶん育ってきた職種が違うのだろう。
「ふぅん。そうなのかぁ」と相槌を打つばかり。
現場の過酷さを理解できない、してあげられないという風でもあり、
小さな女の子の力強い言葉に気圧されるようでもあり。

「だから、いまの仕事はだいぶ楽です。
あのころは何か、……先が見えなくて。
先輩たちがどんどんいなくなって、私たちも休めなくて。
それが何年も続くと、体がおかしくなってくるんです。
本当に体が動かなくなって。
だからあのころに比べれば、いまの仕事は全然楽です。
いまの仕事のほうが、断然楽ですねー」。

そうつぶやく彼女は、はるか遠くを思うように、
夜の街並みを見つめていた。
男は何も、言葉を返せなかった。

抽象的で情緒的な日記ばっかり書いてたらいかんなーと思い中。
だって、毎日まいにちそんなのばかり読んだり書いたりしてたら、頭おかしくなるよ。
それになんか、あざといし。
つーことで、具体的な何かを出したくて一応手は動かしているんだけど、
なかなかうまくいかないっすねー。

たとえばいまは、

(time (let loop ((count 6502) (out '()))
    (if (= count 0)
        (reverse out)
        (loop (- count 1) (cons count out)))))

というコードをZaurusで動かして、「なんで0.1秒もかかるんやろ？」とか
悩んでいます。「(cons count out)」の部分を「out」にすれば、
0.05秒で実行できちゃうのです。

やりたいことは、Wikiページレンダリングの高速化。
レスポンスタイムを0.5秒以下にしたいんですけどねー。
consって案外重いんやろか……。consするときのメモリアロケート（メモリアロケートしてるとして）が重いとか？
うーんうーん。まーそんな日々ですねー。

 Latest topics > 馬鹿正直の理由 - outsider reflex

 

 僕は「愚かで馬鹿でかっこわるい自分、事ある毎にボロが出まくりの自分」が嫌いだし、「理論的に矛盾なく筋が通った賢くてかっこいい強固な自分、ボロの出ない自分」が好きだ。今の自分がそうであるかどうかではなく、そうありたいと思うのだ。

ええー!? これはぼくは逆だなぁ。ぼくは、「愚かで馬鹿でかっこわるい自分、事ある毎にボロが出まくりの自分」が好き。「理論的に矛盾なく筋が通った賢くてかっこいい強固な自分、ボロの出ない自分」にはたいして興味を持てない。

だって、理論的に矛盾なく、筋が通って賢くてかっこよくて、ボロが出ないなんて、計算機でいいじゃん。とくに、計算機がコモディティ化したいまのご時世なら、そんなのは低コストで実現できてしまうよね？ だったらそういうのには、あまり価値はないような気がする。

むしろ逆に、愚かで馬鹿でかっこわるくて、事あるごとにボロが出まくりで、だけど味のある、意味のある、好きになれる何かのほうが、いいじゃん。論理的じゃなくて、汚なくて、愚かで、なんの価値もなくて、どうしようもない何かのほうが愛せるじゃん。

たとえ1000年前、10000年前に生まれたとしてもそう。神さまのように完璧なものよりも、不完全な人間や動物や草木や月夜のほうが、語り合うに値する。そういうもののほうがかっこいい。ぼくにとっては。彼らとこの世界の美しさを語り合いたい。彼らこそがこの世界の美しさだと思えるし、自分もそうありたい。

最近気になる言葉があって、それは「最適化」なんだよね。
人が使っているのを見たとき、自分がポロッと口に出したとき、
あれ？ と思う。

「最適」に限らず「最」が付く言葉は、ちょっと難しい。
だって、最も適切かどうかなんて、なかなか分からないじゃん。
物事にはいろんな見方があるんだし、時間が経って後で気付くことだって
たくさんある。

「最も適している」とか、「一番ふさわしい」とか、
そういうことを求めるのも重要なことだとは思うけど、
それと同じぐらい大事なのは、急がないことのような気がする。
「最も」とか「一番」とか、時間をかけて、ゆっくり知れば
いいんじゃない？

とくに人と人が関係するときには、余計にそうなんだと思う。
その場その場で、必要な言葉を交わせなかったとしても、
本当のことを言えなかったとしても、
お互いが本当に言いたかったことを、人の心は感じることができる。
だから、時間をかければ近付いていける。

あなたにもぼくにも、時間はちゃんとある。それってなんかいいよね。

霞が関官僚日記2.0 - web2.0特集をしながらついて行けない雑誌

ううむ。ま、それはいいとして。このミニスカートはたしかにグッと来るものがありますね。グッ！と来ました。グッ！

要は、出版界にとっての「最終原稿」というのは、紙というアーキテクチャ、しかもA4とかB5とか四六判とかに最適化されたバイナリデータなんですね。一方で、執筆者、しかも理系の人は、「最終原稿」を「デジタルテキスト」と考えているんだと思います。（ぼくも理系の人間なので、そう考えたくなるほうです）

たぶん、両者における溝の1つは、「コンパイラの存在」を前提としているかどうかだと思います。コンパイラがあれば、ソースコードとなるテキストを編集しておいて、それをコンパイルして紙用バイナリをいくらでも吐き出せるだろうと。そして、最終原稿のデジタルテキスト（ソースコード）も手に入るだろうと。

でもこう、出版界というところでは、それほど抽象度高く、レイヤ分けして作業できていないんです。まず、コンパイラというものが存在しない。なぜか？ ぼくも「デジタルテキスト」が欲しくて、コンパイラを作ろうとしたのですけどねー。でも挫折しました。挫折の理由として1つ挙げられるのは、ソースコード（テキスト）の文法などというものは存在しないし、仮に作ったとしても執筆者にそれを強制できないということです。

「だったら、文法の違いを吸収するコンパイラを作ればいいじゃん。原稿のテキストなんて複雑なセマンティクスを持たないんだし」。そう。そう思って、文法吸収器も作ったんですけどねー。これも次第に使わなくなりました。そもそも、いただく原稿が決定的文法じゃない場合が多くって。しかも、コンパイラのような抽象レイヤをかますと、生成されたファイルのチェックも必要になります。このチェックがまた、ねぇ。自動テストツールを作るにしても、エントロピーが結構大きくて。結局普通にやる（従来のシステムを使う）ほうが効率的だということになりがちでした。うがががが。

……って、つらつら書いてるけど、長いなぁ。この話題って読みたいですかね？ 個人的には、喋り出すと止まらない話題なんですけど。。。とりあえずここまででやめときますｗ。

森博嗣さんが、原稿の校正などについて書かれていた。ぼくもけっこう、普段この問題で悩んでいるので、困惑の様子がよく分かる。同じような悩みを持つ人を見つけてうれしいなぁ。

 MORI LOG ACADEMY: 2006年05月12日 アーカイブ

 

 　何度も何度も書いていることだが、僕は行の最初に「ー」や「…」が来るのが嫌なので、これを禁則処理してもらっている。雑誌の連載時には諦めていて、指摘しないことが多いが、せめて自分の本くらいは、自分の好きなフォーマットにしたいと思って、編集部に要求している。

 　しかし、これが簡単にはできないのだ。そんなこと、プログラムで処理すれば良い（現にパソコンのワープロはできる）はずなのに、出版界では残念ながらこの処理ができない。だから、僕自身がすべて赤を入れて、こう直してくれ、この文字を送れ、ここで詰めてくれ、と指定をしている。しかし、どこかを直せば、新たに禁則が生じることもある。だから、それも見越して修正を指定している。それでも、完璧には直らない。

これはソフトウェアで禁則処理できると思うけどなぁ。QuarkXPressやInDesign（雑誌や広告で使われるソフト）を使っている分には少なくとも設定できるはず。文芸の世界では、別のソフトを使っているのかなぁ。よく分からないのだけど。できてもおかしくないと思う。一応、（雑誌しか知らないですが）そういう設定をしている例があるということで。

 　もう１つ、ついでに書いておくと、自分が書いた本のテキストデータを自分で持っていないことが不思議だ。最初の原稿は手元にある。しかし、ゲラ校正で赤を入れ、直した結果の最終原稿というものが、デジタルテキストとして存在していない。印刷所にはあるのだろう。でも編集部と作者は持っていない。印刷された本しかない。プリンタで紙に印刷したら、もとのファイルを消去してしまうのと似ている。この感覚も僕には信じられないことである。

この感覚は本当によく分かる。なんていうのかなぁ。プログラミングの工程で言うと、テキストデータがソースコードで、最終原稿が実行ファイルに当たるんだよね。で、出版界では、最初に執筆者からもらった原稿こそテキストデータ（ソースコード）の状態で扱うのだけど、それ以降の工程では、印刷されたもの（実行ファイル）を元データとして扱う感じに近い。

だから赤入れという作業は、実行ファイルにパッチを当てるような感じで行われている。ある部分を変更すると、別の部分のアドレスが変わって、それを直すとまた……みたいな感じ。そうやって、徐々に完成に近付けていく。すごくアドホックで労働集約的だと思うけど、じゃあ実際どうすればいいかというと……なかなか難しい。

たとえばTeXやHTMLで原稿を書いても、抽象度の低いタグを使いたくなるときがあるのと同じ感じといえば分かってもらえるかなぁ。「ここで改ページしてほしくない」とか、「ここに50mmスペースが欲しい」とか、「1ページの中にたくさん図を入れたいのだけど、人手でレイアウトしないと美しくならない」とか。ほかにもたくさんたくさん、雑多なことで悩ましい事象が発生する。

それを解決しようとしたら、深みにはまらざるを得なくなっちゃうわけですね。本当はみんな、バイナリ（実行ファイル・具体的なデータファイル）なんていじりたくない。抽象度の高い、扱いやすいテキストデータをベースに作業したい。でも、なかなかねぇ……。（ちなみに、印刷所の人からすれば、「バイナリのほうが扱いやすい」のですよね。そういうのも問題をややこしくしていると思います）

で、上記なんですが、実は説明の都合上ちょっと不正確な部分があるのです。というのは、「実行ファイル」と表現した最終原稿なんですが、可読性がそんなに低くない電子データの状態で扱っているのです（現場によって違う可能性もあります）。HTMLみたいな感じで、たくさんメタタグ（少し正確に言うとレイアウト情報）が入っているとは思うのですが、「自分が書いたテキストが入ってるなぁ」ぐらいは識別できる状態のはず。PDFファイルから「テキストデータを抽出」ってやると、グチャッとなったテキストを得られるけど、そういう感じ。

もしそういうのでよければ、出版社との交渉次第でもらえると思います。ただし、権利関係が難しいと考えます。出版社からすれば、「レイアウトに費したコストや、企画・流通との調整コストなどはうちのものだし、できれば渡したくない」という考え方ですね。そういうこともあり、「権利やデータの壊れ具合といったシチメンドクサイことを考えるのなら、出版された本からスキャンしたほうが早いや。個人的に使いたいだけだし」、あるいは「たしかに本が手元にある」というのが、たぶん一般的に妥当とされている落としどころなんだと思います。

GMailを使っていると、ぼく宛てにいただいたメールもgoogle.comに
アーカイブされるので、ぼくだけの問題ではないのだと思った。長尾さんの文章を読んで。
できるだけ普通の構成でメール環境を作ったほうがいいのかもしれない。

でも、実際やるとしたら、どうすればいいのかなぁ。
なんだかんだいって、GMailを便利に使わせてもらっている。
メールシステムの管理コストを自分で支払うのはしんどいなぁ。