日々の破片

_ すべてが消えた

二度とFirefoxは利用しない。

すげぇ。2時間かけて書いた内容が一瞬で消え去った。

_ Hatching Twitter読了

30%読んだところでもうやめようかなとか言っていたが結局、読み終わった。とは言っても、最後まで3文に1文は意味が取れない単語があったりして（もちろんKindleなので辞書はひけるのだが、語意がわかったからといって文意が取れるわけではない）、どこまで読めたのかはすこぶる怪しい。怪しいのだが、おもしろかった。

30%読んだところまでは、面白ギークの生態観察だったわけだが、その後は、ベンチャーが急成長することで発生するさまざまな問題、ベンチャーキャピタルとの協力と反目、製品をとるかコンセプトをとるか収益をとるか、政治と自由、名誉（他者との関係）か矜持（自分の心持）か、友情か仕事か、といったさまざまな観点とともに物語は進むのだった。

10人規模のベンチャーから400人越えの中堅企業（規模は。資産価値からは大企業だ）への脱皮はどうあるべきで、それぞれの局面においてCEOはどうあるべきか、といった読み方をするならばビジネスストーリーだし、有名人戦略やプロモーション戦略に着目すればマーケティングストーリーだし、友情物語であったりもするし、おもしろい。ただしどうあっても技術の本ではない。1つだけ技術的観点が読者にアピールすることは、バックアップをまともにとらないサービスを許容するCEOは馘首されても当然ということだけだ。

キャラが立っているのだが、そこに作者の工夫があるように読めた。

つまり、Twitterとは何か？ というのが命題で、それに対して主要な登場人物がすべて立場を異にする。それが軋轢の要因となる。

Hatching Twitter (English Edition)(Bilton, Nick)

・イヴ・ウィリアムズ

優柔不断な性格のためローンチ時期を掴み損ねて、最初に起業した会社を潰してしまう（結果として出資してくれた父親に相当な迷惑をかける）。その後オライリーに勤めてだらだらしているうちに、自由な情報発信のためのツールとしてBloggerを作り、Googleに買収されて金持ちになる。が、Googleが肌に合わずに退職する。ぷらぷらしているところを向いの家に住むノア・グラスに頼まれてポッドキャスト企業のOdeoの共同出資者兼CEOとなる。アップルのポッドキャスト参入によってOdeoが空中分解した後に、別の会社を作ったりするが、結局、TwitterのCEOとなる。収益ゼロのTwitterにBloggerで得た資産をがんがん注ぎ込む。しかし、優柔不断な性格と人事に友情を混ぜ込むスタイルが収益化の足かせになるとベンチャーキャピタルから判断されて追放される（自身のCEO辞職動議の席でCEOはローテーションだとフェントンに言われて得心したようだ）。20億ドル以上の資産と奥さんと2人の子供と楽しく暮らす。Twitterはミニブログであり、自由な情報発信のためのインフラだ。

・ノア・グラス

海賊ラジオ局を運営していたが、うまくいかなくなってぷらぷらしているところを、向いの家にBloggerのイヴが住んでいることに気付いて近づき、友人関係となる。ラジオに次ぐメディアとしてポッドキャストに目をつけてODEOを起業するが、有名人をCEOに置きたかったのと出資額からイヴにその役割を渡す。ポッドキャストがぽしゃった時に、Twitterのアイディアに飛びつき、プロダクト化するためのさまざまな機能を考える。が、そのため実装者を占有することがあってジャックから嫌われる。しかも、ジャックの態度を親切からとは言え批判したりするため、憎まれる。さらにギークというよりはサンフランシスコアーティスト文化側の人間のため、Twitterの初期プロモーションをそちら側でやろうとして失敗する。などなどの要因からTwitter社の立ち上げ前にイヴからODEOを追放される。Twitterのサービス化への貢献度は非常に高かったのだが、そういった経緯から貢献者リストから完全に消されていた。最後はテック業界とは離れて（あるいは仲間たちが違うというだけかも）妻と幸福な家庭を作る。Twitterは、物理的には孤独であっても人びとに親密な繋がっている感を味あわせることができるチャネルだ。

・ジャック・ドーシー

ODEOに雇われたときは、パンク厨房プログラマーで、鼻ピアスとかしている。好きになった女性から聞かされた女子高生の携帯文化を元にTwitterのアイディアをODEOに持ち込む。イヴを半分おどしてノアを追放した後は名実共にTwitterを支配して最初のCEOとなる。以後、CEOにふさわしくあろうと、ピアスを外して社員の福利厚生に気配りしたりするが、口先だけで能力が伴わず、実利的な判断もできない（ただし、大して給料も出ていないのにハードワークを続けていることは書かれている）。最終的に、Twittのバックアップをまったく取っていないといった喫緊の問題に対して全くアクションを取らないことがベンチャーキャピタリストたちの怒りを買ってCEO職を追われる。というか、Twitterの資産がTwittの生データにあるということをベンチャーキャピタリストたちは早い時期から気付いていたことが驚きだよ。ところが閑職についたことを良いことに、マスコミに対して自分を徹底的に売り込み、イラクへ行ったり、本来呼ばれていないのにごり押しで参加したTIMEのセレブパーティで有名なインタビュアーに自分を売り込んでインタビューされたり（良くわからないのだが、徹子の部屋の黒柳徹子とか、笑っていいとものタモリみたいな位置の人だと思う）、いつの間にかTwitterを一人で作ったことにしていたりする。またスティーブジョブズの真似を徹底的にする（もうパンクロックは聞かずに、ビートルズを聞く）。その甲斐あって、フェントンのように巨大企業となったTwitterのCEOにふさわしいと考える協力者たちが次々に現れて、イヴの追放に成功する。ただし、スクェアも持っていることから、CEOの座はディックコストロに与える。1.5億ドルで購入した断崖にガラスの壁がせり出した豪邸で暮らしている。Twitterは、自分のステータスを他人に示すためのサービス。

・フレッドとビヤン

初期からのベンチャーキャピタリスト。怖い刑事と人情刑事のように、冷酷なフレッドと話がわかるビヤンでコンビを組んで、ちょっとでも投資が失敗しそうになるとCEOの首を挿げ替えにやって来る。イヴ「おれの何がまずいんだ？」フレッド「全部だ。お前が先週やらせた新しいWebインターフェイスだが、大嫌いだ。さっさと死ね」みたいな感じ。Twitterは投資先。

・フェントン

途中から出て来たベンチャーキャピタリスト。ジャックに心酔していて、イヴは役立たずだと考えている。Twitterはジャックが作った投資先。

・ビズ・ストーン

イヴのGoogle時代の友人。すごい貧乏でクレジットの借金が山ほどあって、イヴに助けてもらう。小動物が大好き。Twitterの共同出資者。Twitter社のキッチンに置いてある果物が夜のうちにネズミに齧られるので、他の社員が殺鼠剤を撒くかネズミ捕りを仕掛けるか相談していたら、泣きながら抗議した。イヴの追放を阻止しようと日本からプライベートジェットで帰国することを拒否したりして抵抗する（ジャックの追放も阻止しようとしたので、基本的にこの男はいいやつなのだ）。イヴが追放された後、ディックから仕事を取り上げられてしょうがいないので辞職した。それでも手元に200万ドルほどの資産が残ったので、でっかな家に貧乏時代からの恋人と一緒に暮らして、小動物のためのサンクチュアリを作ったりしている。Twitterはイヴと共同出資して作った会社。

・ゴールドマン

イヴのGoogle時代の友人。イヴ追放後すぐにディックによって馘首された。なんというか、ここにただおるみたいな人でいつも居るのだが何をしているのか良くわからない（というか記憶に残っていない）。共同出資者ではある。

・ディック・コストロ

元コメディアンで、イヴのGoogle時代の友人。COOとしてTwitterに呼ばれる。実務能力があり、ちょっと年かさ、トークがうまい、要するにCEO向きなので、イヴ追放後のCEOとして白羽の矢が立てられる。ほんのちょっぴりイヴとの友情について考えるが、ベンチャー気分が抜けないTwitter社を本格的なビジネス組織へ作り変えるという使命に惹かれて、引き受ける。さらにCEOになった後には、独裁体制をひけるようにイヴグループの粛清を冷静に手掛ける。Twitterは社風を整風する対象。

・スヌープ・ドッグ：ビズを待つ間にカフェテリアで待ちくたびれてマリファナを吸って無礼講を始めてしまう。Twitterはマーケティングツール（というよりも何も考えていない）

ザッツ・マイ・ワーク・ヴォリューム2(スヌープ・ドッグ)

それにしても、口汚い人たちだな。

・豆知識：ジャックがイラクの空港へ軍用機で着陸するときに学んだ知識は役に立つ。飛行中はヘルメットを着用するのだが、着陸時はゲリラによる下からの銃撃に対抗するために、ヘルメットを股間に挟んで着席する。

_ 縮みゆく男

放射能といえば、巨大生物パニック映画だよなぁとか考えていて、何か呟いたらusaさんから逆に小さくなるのは無いか？ と聞かれた。

元々、プルトニウム人間の系譜を考えていたこともあるし、キングコングの昔から映画はでっかな化け物が大好きだから、小さいのは無いだろうなぁと答えた。それに特撮はでっかなものを1つ入れるほうが簡単だという技術問題もあるはずだし。

戦慄!プルトニウム人間 [DVD](グレン・ランガン)

でもウルトラQでも人口爆発に対応するために人を小さくする話はあったじゃんと返されて、ちょっと考えた。でも、今になってあらためて考えてみれば、あれは新聞記者の2人を除いてみんな小さくなるんだから、映像/技術的には2人の巨人だよな。サンダ対ガイラじゃないけど。

が、そのうち、頭の中にあるSF事典がリチャードマシスンの項目で止まった（最近は検索のディレイが結構ある）。

そういえば、縮みゆく男があった。

読んだことはないが、普通の人間が変形する話で、50～60年代の作品なら、放射能が原因に決まっている。で、アマゾンでリチャードマシスンからたどって見ると、確かに放射能の霧を浴びたことが原因になっている。で、お題はクリアしたが、Kindle版が結構安かったこともあって、せっかくだから買ってみた。

で、今日は体調が良くなくてごろごろしていたので読んだのだった。

やっぱり、マシスンは普通じゃないや。おもしろかった。

縮みゆく男 (扶桑社ＢＯＯＫＳミステリー)(リチャード・マシスン)

放射能の霧にやられて（というのが、第五福竜丸（こちらは雨だが）で有名になったこともあって、50～60年代には生物が変形する物語が作られたのだった。これが日本や米国ではトラウマとなって放射脳がたくさん生まれる原因となったわけだろうが、ビキニあたりでの実験の経緯やずさんな管理を知ると実にひどい話だ）直前に被った農薬が変化して代謝機能に作用して一日あたり3.6ミリ縮むことになった退役軍人（なんでこういう設定なんだ？ と思ったら、社会的に重要な意図があることが解題に出ていて納得した）の悲劇の物語だ。

冒頭の霧を被るシーンが終わると、すぐに舞台は1.5cmで、あと数日で消えてなくなる運命を怒りながら、蜘蛛に追っかけられて逃げるところとなる。

蜘蛛と戦い、巨大な日常用具に囲まれて必死に生きる描写と、どんどん縮むために、職を失い、家族関係が破壊され、見世物のように扱われたり、子供扱いされたり、変質者に狙われたり、不良の餌食にされかけたりと、社会から疎外されていく経緯が交互に語られる。おもしろい。

しかし読んでいると、異様なまでのショービニズムというか、マッチョ思考が支配していて違和感がありまくる。男はでっかくて逞しくあるべきなので、妻よりも小さくなることでどうしたことうしたというような心理描写ががんがん出てくる。いや、普通はそうは考えないだろうという常識が最初に来るので説得力がないし、まったく共感できない。

さらに変質者がステレオタイプな小児対象のホモということになっていて、こういう書き方がまた良識ある現代人のおれには不快感が湧く（片言のフランス語を混ぜてしゃべるのだが、そうそう、そういう記号があったなぁと思い出したり）。

しかし、読み進めているうちに、50年代のアメリカの価値観がわかってきて（というか知識としては知っていることなので理解はできる）、その思考法にしたがって読めるようになってくると、主人公にまったく共感できないのは変わらないが、思考方法を理解はできるようになってくる。

主人公が置かれているのは実に恐ろしい状況であった。（物理的には蜘蛛だったり、変質者であったりするのだが、身体が縮むことはそのままアイデンティティの崩壊なのだ）

リチャードマシスンは大したやつだ。書いた時代は50年代だし、設定はB級SFだが、ちゃんと思弁的な意味でのSFになっている。

Kindle版には珍しいことなのかも知れないが、90%までで本編は終わり、残りに解題、訳者解説、おまけに町山智浩の解説がついている（目次を飛ばして読み始めたので、そういう構成とは知らなった）。

解題はランボーの作者のマレルで、これが読ませる。というか、おそらく必要だったのだろうということは上で書いたように、本編には違和感があったから理解できる。紙の本なら、最初に解題を読んでから読むことになるだろうし、そのほうが良いだろう。主人公の思考方法が書かれた時代にマッチしているので、おれと同じく読んでいて違和感を持つ人が多いことは想像できる。マレルはそれを補おうとしている。

ランボー [DVD](シルヴェスター・スタローン)

40年代に太平洋戦争か、第二次世界大戦か、どちらかに通常は行き、そこで英雄となって帰還した若者たちは、50年代に会社員として暮らすことになる。冷蔵庫を始めとした電気機器や家具に囲まれた生活だ。テレビから流されるホームドラマは良き夫、良き父親のテンプレートを植え付け、それが規範として流通する。しかし、その生活を維持するのは難しく、しかも戦場とのギャップは大きい。

さらにマレルは論を進めてシシューポスの神話と対比させる。

シーシュポスの神話 (新潮文庫)(カミュ)

説得力がある。というか、ランボーって妙なシチュエーションの妙な映画だなと思ったが（単なるマッチョ映画っぽく思えるのだが、実際に観るとちょっと違うのだ）、作者がインテリも良いところだったのか。

・邪悪なものへの崇拝－石がパンとなる－神殿から飛び降りる という設定にはまったく気づかなかった。聖書を自由に引き出せないといろいろ読みすごしてしまうのだなぁとつくづく感じた。

・異形の者との出会いで一段成長するところは、美しい。

_ ネコのドラミング

休日に朝寝していたら、いきなりドンドコドンドコと太鼓の音が聴こえて来て目が覚めた。

一体何が起きているのかときょろきょろしたら、ネコが段ボールの爪とぎハウスの屋根を乱打している。

その様子から、爪を研いでいるのではない。そもそも段ボールの爪とぎハウスは屋根に乗ったりして、自分たちで壊してしまって、別に用意したポールで爪研ぎをするようになってからもう随分立つ。

一体、なんだろう？ と不思議に思ったが、その時はそのまま二度寝してしまった。

その後、何度か太鼓乱打を聞かされたことがあって、不思議なこともあるものだ、これはナムトラヤーヤーとか唱え始める前兆か、と首をひねったものだ。

それがある日、氷解した。

ネコがトイレから出てくると、まっすぐ爪とぎハウスの廃屋へ向かい、いつものように太鼓乱打するではないか。今までは、太鼓乱打で初めて目をやっていたので前段に気付かなかったのだ。その後も注意して見ていると、トイレから出ると廃屋へ向かうことがわかった。

おおなるほど。トイレの砂がおが屑を固めた奴だから、粉が足の裏について気になるのだろう。それで、掌を叩いて粉を落としているに相違ない。

常陸化工 トイレに流せる木製猫砂 7L × 6個入り(-)

ネコっておもしろいなぁ。

_ なかむらたん

なむとらやーやーってでたらめなのかと思ったら、なかむらたんで始まるまともなお経だったのか。

_ 杉野王国またはドレメの大通り

雅叙園に行くには目黒駅を降りた後にとんでもない坂道を下りる必要がある。

デブサミの日に雪が降ると、何人かは滑り落ちて目黒川にはまって、そのせいで毎年何人かの不運な開発者が失われる始末だ。

これが実に不思議だった。落ちるのがわかっているのに、なぜ坂を下る必要があるんだろう？ 少なくとも百段階段を昇りきったあたりは、坂の上に等しそうに思える。細川力蔵はどうして上に入り口を作らなかったんだろう？ あれほどのアイディアマンなら、ケーブルカーかロープウェイで御殿におりるように出来たはずだ。そうすれば大和屋の先駆けとしてさらに高く評価されただろう。

と、常々不思議に思っていたのだが、先日、雅叙園に行くことになったら、連れが坂を下りずにまっすぐ進むじゃ無いか。思わずそっちじゃないよ、と言ったら、怪訝な顔をする。

ついていくと、そこは杉野の王国だった。

杉野女子短大は名前を聞いたことがあるし(今は杉野服飾大学短期大学部服飾学科なのか)、ドレメ（ドレスメーカー）という名前も聞いたことがある。が、広大な区画にさまざまな関連施設を並べたドレメの聖地になっているとはまったく知りもしなかった。用がないからだといえばそれまでだけど、通りの名前もまさにドレメ大通りで、両側にずらりと杉野の息がかかった建物がそびえ立つ。なんだここは？ と驚いた。一大学園都市じゃん。

（地域教室を開催しているおおきな教会があって、そこのでっかな十字架にも威圧されたけど、それは杉野とは関係なさそうだ）

で、しばらくすると突然アマゾンの看板が立っていて、そこからアリコタワーへの道があって、エスカレータやエレベータを乗り継ぐことで、雅叙園に坂道を下りずに行けたのだった。こんな便利なものがあるとは知らなかった。

が、それよりも、ますます目黒という不思議な場所に魅惑されるのだった。

（特に山の手線−目黒川（環状6号）に挟まれた地帯）

・御殿山から桜並木のあたり

・車で夜中に徘徊するのが楽しすぎる茶屋坂界隈

・突如高い塀に囲まれて行く手を遮る謎の自衛隊の研究所

（環状六号と七号に挟まれた地帯）

・池がいっぱいあるお不動さん

・通りと住宅のギャップが異様な学芸大学界隈

本当に良くわからない場所だ（というか、江戸時代に拓けた場所はだいたいそうだけど、特に目黒は明治−昭和にかけての都市化が遅れたので妙なんだろうな）

ミシンと日本の近代―― 消費者の創出(アンドルー・ゴードン)

(この本がおもしろそうだなぁというところから、ドレメ大通りを思い出したのだった)

_ 調べずに考えるなんでミシンが廃れたんだろう？

元々は山形浩生の経済のトリセツを読んでいたら、ドレメとかミシンのことが出ていたので、ドレメ王国を思い出したのだが、1960年代生まれとしては、確かに不思議かも知れない。子供の頃はミシンがあり、母親が服を作っているのを良く見た。

1970年代を間に挟んで確かに服飾には変化があった。

たとえば、1970年代の終わり（1980年代の初めかも）には、ブリーフかトランクスか論争ってのがあった。なぜそれが論争になるのかと言うと、それまで下着はBVDというブランドに代表されるブリーフか、サルマタが主流だったのだが、ある日気付くと、JOCKEYというブランド（実は福助）のトランクスが大躍進していたのだった。（というように、何かのきっかけでがらりと風潮が変わることがある）

でも、そういうことではないな。

ひとつはジーンズ＋Tシャツというどう考えてもミシンの出番がない服装がメジャーになったということがありそうだ。ジーンズの裾上げを母親に頼んだら、針を3本くらい折ってしまって、これからは店でやってもらえと引導を渡された記憶がある。最初にジーンズのパンツを買って貰ったのが1972年頃（外苑の花火大会の出店で買ってもらったのでやたらと覚えている）だから、まさに70年代の始まりだ。

それから服の価格が急に安くなったというのもある。突然、母親が安かったからといって何着も買ってきたのを覚えている。

そして布が変わったことだろう。布が安くなったのだ。

1970年代に親戚の織物工場（紡績工場かも）が倒産したので印象が強いのだが、その頃、国内の繊維に関係する工場がばたばたと無くなっていった。原因の1つは、ニクソンショックというか、対ドルレートが円高基調になったことだろう（このため、繊維（糸とか布）が輸出から輸入に変わった）。技術の進展で合繊が使い物になったということも上げられそうだ。

ストッキングが使い捨てに近かった時代から、洗濯機で洗って再利用可能なくらい丈夫になった。丈夫になり、材料費が安くなれば面積も大きく、便利になる。具体的にはパンティー部分がくっついたストッキングは1968年に売られ始めたらしいが、どんどん丈夫になったということから、完成形になったのが1970年代と思う。（それまではガードルについた靴下止めで留めるストッキングだったということで、留める部分の金具の仕組みがおもしろいなと子供の頃に母親のガードルを見て考えたのを覚えている）。今じゃガーターベルトで留めるストッキングは趣味の世界だ。

布が安くなるということは、こういうことだ。

糸（高い）→布（さらに高い）→プレタ（服に加工した分、さらに高くなる）→ 日常的には買えない

糸（高い）→布（さらに高い）→布を買ってきて服を作るほうがお得

糸（高い）→毛糸を買ってきてジャカード織りくらいは家でもできるけど、木綿の布を作るのは無理

↓

糸と布（輸入で安い）→プレタ（服に加工してもリーズナブルな価格）→日常的に買える

もし、布地ではなく服を買ってきても、その価格が数年前の布の価格とそれほど変わらなければ、よほどの倹約家か趣味のミシン踏みでなければ、直接服を買うほうを選択するだろう。

その代償として、国内の織物工場が淘汰され、ミシンが消えた。

1970年はMILK（さるがに半世紀もやっていると全然違うものになっているんだな、と驚いた）の創業年でもある。表参道がファッションを発信するための場所となった。というわけで、1970年代はキミシマといったオートクチュールではなく、プレタポルテが日本で活動を開始した年代でもある。

洋品店のあり方の変化。

子供が小学生の頃、商店街での聞き取り調査というのを社会科の授業でやっていて、それがおもしろかった。

洋品店が生き残っていて、それは物心がついてからそういう店があることは知っていたが、実際に買ったことはなく、不思議な存在だったのだが、その調査（お店の人への聞き取り）がおもしろかった。

洋品店というのは、基本的にお客が来るものではなく、季節の変わり目にお得意様のところへ、新しい洋服をおさめる商売なのだった。まるで富山の薬売りだ。まだ、旧家が残っているところなら商売は成り立つだろうが、そうでなければ消える運命の商店だ。

1970年前後は巨大団地の出現もあって、首都圏への人口移動が大きかったと仮定する。

すると、あらたに流入した人たちは、どこで服を買うのだろうか？ 町の洋品店は彼ら用ではない。とするとスーパーマーケットや百貨店となるだろう。プレタポルテが生まれると、その下位が成り立つ。需要があるので、それなりの服飾が市場に出回る（確か、デザイナーズブランド（本当のプレタ。コレクションを開く）−キャラクターズブランド（2番手。基本的にまねっこ）−その他（名前では勝負しないで、百貨店などに卸す専門）という階層があったはずだが今はどうだか）。団地妻はまだミシンを踏むかも知れないが、単身者用の服飾マーケットが成立する（マーケットが成立することで競争が生まれ、質は上がり、価格は下がる。ますますミシンの出番は減る）。ジーンズショップが儲かった時代だ。

思いつくのはこんなところかな。

_ 日本型ソフトウェア開発

日本企業のありかたは、グローバライゼーションしたといっても、まだまだ独特なようだ。

ということを【公開】第30回IT勉強宴会「最近感じる日本企業のITの問題と展望～「ソフトを他人に作らせる日本、自分で作る米国」を読んで」を見て考えてみる。

これは、江戸時代に端を発する呉服屋システムや、鎌倉時代に端を発する武家システムや、平安時代に端を発する荘園システム（宇治拾遺物語や今昔物語を読めば、五位という係長の悲哀や、右大臣専務の勇断などがごろごろしていて、まるでビジネス小説だ）に（奈良時代は唐の律令制度のパクリとなり、それは平安時代への過程で超克されたのでそこまで遡る必要はない）、明治になって入って来た株式会社システムを和魂洋才した結果生まれたシステムだからだと仮定する。

今昔物語集・宇治拾遺物語 (新明解古典シリーズ (7))(桑原博史)

そして、実は、そのシステムは良いものだとさらに仮定する。

バブルが崩壊した後、妙に反省し過ぎてグローバライゼーションだ、成果主義だとやって、かえって泥沼に沈みこんだ企業群をわれわれは見てきている。そこで、それらのシフトの原因となった仮定が間違っているとする。つまり反省し過ぎて、本来は原因が無いもの、つまり日本式企業システムに原因を求めてしまったことが間違っていたということだ。バブル経済が崩壊すれば、逆転してデフレ基調になり、その結果、商品市場に物があふれ、その結果、労働市場に失業者があふれることになるという経済の動きと、日本式経営には何の関係もない。

一方、SIについて考えてみる。

これは、IBMが持ち込んだシステムを時間をかけて日本流にアレンジしたものと言える。その原動力となったのは、銀行の第一次～第三次までのオンライン化だ。また、それとは別に国鉄の予約システム開発もある。

だが、かたや平安時代の荘園システムに端を発する1000年の日本式企業システムに比較すれば、たかだか半世紀の歴史しかないものだ。

マッチするはずがない。

そこで、1000年SIerが生存した状態を想像して、それにあわせてシステム構築のありかたを考え、それにすり合わせていくことが実は、最も正しい日本企業用のシステム開発のありようではないか？

とはいえ1000年未来を予測するのは難しい。

そこで、逆に考える。1000年前のシステム開発と、荘園システムなり、武家システムなりの組み合わせから、開発のありようを抽出すれば、現代の日本企業で成功するシステム開発のありようというものが見えてくるはずだ。

つまり、洋魂和才がSIerの生き残る道なのだ。

_ 詳細設計書は死んだ。とっくの昔に死んでいる。でも生き返る必要はある

流儀や呼び名はいろいろあるだろうが、ここでは3種類あることにする。

・要件定義書

要件を定義したもので、ユースケースについて記述したものだ。

・機能設計書

要件を機能として記述したものだ

・詳細設計書

機能を実装に落とし込むものだ

で、詳細設計書って何それおいしいの？ ということだが、もちろん不味い。むしろ毒だと言うべきで、そんなものを記述するよりさっさとプログラムを書けば良いし、その時間を使ってテストプログラムを書けばさらに良い。

特に、1990年以降、オブジェクト（あるいはクラス）ライブラリが拡充され、APIがほとんどなんでもやってくれて、コンポーネントがそこら中に転がり始めてからは、単にそれらをグルーでつないでいくのがほとんどなのだから、そんなものを書いてもまったく意味がない。

しかし、実はそう単純でもない。

問題は詳細なビジネスルールにある。本来ビジネスルールは要件なのだが、ユースケースで考えると、詳細なビジネスルールはユースケースレベルとして記述するのが難しい。

例として、ある商店では、以下のように買い物客からの買い上げ額を計算するとする。

・商品は総額表示されていたとしても、消費税を抜いた額とする。

このとき、式として総額表示*100/(100+消費税%)を利用する

・ただし、同一商品を複数購入した場合は、（総額表示×個数)*100/(100+消費税%)を利用する

・もし割引販売した場合は、総額に対して割引、その結果の額から……

・もし買物券を出されたら、合計金額（税込）に対して一度消費税を抜いた額を求めて……

・3個で幾らという売り方をした場合は、3で割り切れない場合に、どう消費税を割り当てるか。同様に割引した額をどう割り当てるか。

こういったことは要件としては実は明らかにならず、いざ機能を定義する時にわかることがあり、しかも、機能を定義した後に、実際にコード化する時に相互に矛盾を発見することがある。

粒度の問題なのだ。そして、機能の定義にすらあてはまらないほど細粒度となることがある。

いや、それはプログラムするからいいじゃん。

というのは、一面の真実でしかない。

上のような計算を行うメインフレーム上のCOBOLのプログラムが1980年代に造られて（消費税は無いけれど、代わりに物品税のようなものはあったりする）、案の定、あまりに細かいビジネスルールは要件にも機能にも出ていないとする。というか、出ていない。

それを21世紀になって、Javaで書き直すとする。

30年経過したのだから、ゼロベースで考えるか？ というと、そうはいかない。会計上のビジネスルールには基準としての継続性があるからだ。

そこで、COBOLを……読めない。

COBOLならばまだ良い。PL/Iで書かれていたら？ 当時の流行の4GLで書かれていたら？

会計は長く、プログラミング言語の流行（生存期間）は遥かに短い。会計の長さとためを張れる寿命を持つのは自然言語だ。

今、Javaで記述したシステムが20年後に動いていることをおれは想像できない。

しかし、細粒度のビジネスルールが20年後でも同じことは想像がつく。

そして20年後（希望としてはもっと早いほうがSIビジネスには良いわけだが）システムは更新されるだろう。

そのとき、Javaを解読できる開発者が生き残っているだろうか？ それが問題だ。Javaならだれでも読める？ 20年後のプログラミングパラダイムに慣れきった開発者に解読できるのか？

（粒度の問題ともうひとつある。システム更改というときに、既存のシステムの要件と機能については、基本的におざなりとなることが多いことだ。これは予算と時間の問題だろう。システムを更改する場合、現在を100とすると、40を捨てて、60を残し、80が追加となるということが行われる（100→100なら余程のことがなければ更改は行う意味がない）。40の選別と80の設計に比重がかかり、60は今ある資料が出てきて終わってしまいかねない）

詳細設計書は不要だが、機能の定義よりは1段低レベルな仕様書はやはりあったほうが良い。

まとめると、要件定義はユースケースベースとなるため、アルゴリズムのレベルでの記述を入れる余地がない。

機能定義はアーキテクチャとモジュールの定義が主眼となり、詳細レベルの記述まで落とし込むことは難しい（難しいのは、記述方法が確立していないからとも言えるし、機能定義に、計算順序のような詳細レベルの記述が混ざるとスコープが失われることが問題となる）。

プログラミング言語の寿命は短い。

そのくらいスコープを取って考えないと意味ないよ。

_ 続き

では、どうすれば良いかだが、そんなもの自分の飯の種なんだから自分で考えれば良いわけだ。別におれの知ったことではない。

ただ、今はわかっているが、10年前にはわかっていなかったことがあって、それがちょっともったいなく感じている。

詳細なビジネスルールというのは、2種類に分けられる（もっと多いかも知れないが、少なくとも2種類はわかっている）。

1つは、上でもあげたが、計算式だ。どういう順序で計算するか（お金は最低が1円になるのにもかかわらず、割合を使うことがあるので、どうしても小数点以下となり、それを四捨五入するのか、切り捨てるのか、切り上げるのか、1個単位でそれをやるのか、累計してからそれをやるのか、といったことがルールとなる。結局、それはその企業に固有なのだ。もっとも全く新規ならパッケージに合わせれば済むのだが、次の更改時に別業者がRFPに勝ったりすると、現在のパッケージの式に合わせる必要が出てくるので、長期で見れば、結局はルールが明かになっている必要がある）。

もう1つは、データの組み合わせ方法だ。

そこでわかることがある。後者は実際問題としてそれほど問題とならない。SQL Serverでやっていたのを、Oracleにリプレースしたりその逆だったり、Postgresに変えたりといった、RDBの交換でも、よほど小汚いストアドプロシージャが山ほど作られたりしていなければ、ビューを既存の形式に合わせてやると大抵同じルールを適用できる。正確には、同じSQLを適用できる。パフォーマンスチューニングは別の話だ。

同じことを前者に適用することを考える。

COBOLはともかくとして、VBもともかくとして、現代のモダンな言語（最悪でもJavaを想定してみよう）以降であれば、仮に20年後、30年後であったとしても、DSLが利用できる。

要は、多倍長数の算術演算が記述でき、関数を組めて、開発に利用するプログラミング言語とのインターフェイスにオーバーヘッドがかからないDSLがあれば良い。つまり、すべてのビジネスルールをそのDSLで記述し、それを仕様とする（どうせDSLなのだから、きれいな文書の清書機構も組み込めば良いね）。

DSLといっても、実現方法はいろいろあるのだから、仮にJavaで実装するのであれば、地の部分（SOAで組むか、Webアプリケーションで組むか、Swingで組むかといったことは、ビジネスルールのレイヤーではないから、要件に合わせれば良い）はJavaで普通にプログラミングすれば良く、ビジネスルールについては、専用の簡単な（というのは、機能は限定されているのだから）インタプリタか、速度が必要ならばコンパイラを作れば良い。仮にLISPで組むのなら、マクロにするのだろうな。

そのようにして、ビジネスルールをシステム（機能仕様によって規定される部分をここではシステムと呼んでいる）そのものの実装から切り離せば、システムの主となるプログラミング言語がJavaから別の言語に移行したとしても、システムのアーキテクチャがWebではない20年後の何かになろうが、ビジネスルールを記述したDSLの実行エンジンをその言語で実装すれば良いのことになる。

同様に、別のSIerに乗り換えたとしても、納品物であるDSLの記述仕様と、記述されたビジネスルール集をシステムの変更されない箇所の仕様として提供して、適用させれば良い。当然、新規開発されるもののうち、ビジネスルールに属するものは、すべて同じDSLを適用させる。もっとも、力づくでDSLで記述したビジネスルールを開発に利用するプログラミング言語ネイティブに変換されてしまうと、何の意味もないので、そこがプロポーザルで守らせる肝となる。

ビジネスルールとシステムをDSLを介して疎結合させることが、最も優れた解だろう。

20世紀の最後は、コンポーネントを作るプログラミング職人と、そのコンポーネントを使ってグルーでビジネスロジックを組むということが語られていた。しかし実際にはそんなにうまくいかなかった。というのは、グルーといってもプログラムはプログラミング言語であり、どれだけコンポーネントがあっても、システムを組むためのロジックが山ほど必要となるからだ。MVCに単純化すれば、Vの相当数が既存のコンポーネントで提供されていても、それを組み合わせるプログラミングが必要で、Mを固めるプログラミングが必要で、コントローラにもプログラミングが必要だからだ。

ジェネレーティブプログラミング (IT Architects’Archive CLASSIC MODER)(クシシュトフ・チャルネッキ)

ビジネスルールは変わらないのだから、そこをシステムの実装非依存なDSLとして分離することが、詳細仕様書を切り捨てるための正当な道だとおれは考える。

_ 死の都

土曜日は、新国立劇場でコルンゴルトの死の都。

まさか、生きている間（というよりも、さらに未来になればなるほど消える可能性があるのだから、死んだ後も同じか）に死の都を日本の舞台で観られるとは考えもしなかった。素晴らしい。

まず何よりも、舞台美術の美しさに身悶えする。奥行を出すために奥に向かって狭くなる室内空間を作り、左右の壁の棚はフォトスタンドなどで埋め尽くし、床にはガラスのドールハウスのようなものや、赤いバラの花瓶、小物入れなど。中央にベッド。天上は1幕では平面だったように思うのだが（あいまい）、2幕では夜の光が差し込む穴があく。奥は、1枚1枚に高さがある鎧戸のようになっていて、向うにブルージュの街並みが俯瞰で見えるときがある。最初写真のようだが、2幕では立体的な街並みとなり、3幕になるとお祭りの行列が見えるによう開放される。

全体は白いのだが、1幕では死者の部屋、2幕では夜の水の上、3幕では現実の赤い夢とそれから覚めた後の白々とした日常色に変わる。

マリーは線の細めな黙劇の人が、最初はベッドにカバーで覆われている。途中から歩き出す。マリエッタは赤が印象的な（バラの花と、彼女だけが赤い）登場の仕方をする。お金持ちなのねなどとセリフの端々にマリエッタがマリーの反対側の存在だということを示す。

物語はローデンバックの原作とはいろいろ変えてある（むしろブリュージュである必要すら無い……だからタイトルにブリュージュが付かないのかも知れない）。

死都ブリュージュ・霧の紡車 (1984年) (フランス世紀末文学叢書〈8〉)(ジョルジュ・ロデンバック)

1幕。ブリギッタの歌手が実に良い。パウルのケールという人は癖がない歌手なのかな。良くわからない。マリエッタのミラーという人の歌は硬い感じできれい。Gluck, das mir verbliebの始まる直前、マリエッタがちょっと早めに出そうになったのかな？ というところはあったが、悪くない。1幕を通して聴くと、実はそれほどメロディアスではなく、むしろ音色旋律に近い作りで、劇中歌だけが歌として成立しているように感じる。それにしても地の部分と盛り上がりの曲としての演出がしっかりしていて、なるほど、これは20世紀的で映画音楽の始祖だなと感じる。

2幕は、ピエロの歌が素晴らしくて（友人のフランクの二役というのは後で知った）、こんなきれいな歌が隠れていたのかとちょっと驚いた（というか、Gluck以外にも歌があるのか）。最後に女声コーラスが入るのだが、それが最初の合唱で実に効果的だ。ピエロに歌わせるためにマリエッタがライン育ちは歌がうまいからというような台詞を歌うがそういう言い伝えがあるんだろうか？ ローレライかな。その後はラインという言葉に引きずられて、どうにもジークフリートのように聴こえてくる。ただ、後半はおそらく本来はもっと官能的な音楽（ちょうどトリスタンの2幕みたいに）となるべきなのだろうが、そこまでではなく、そうすると動きの少なさが目立って退屈した。

3幕は曲がすばらしい。オーケストラが高揚した直後に金管が抜けたところでマリエッタが歌い出す。歌の最後のほうでヴァイオリンのソロがからみあって（一丁ではなく、三丁くらいあるように聴こえた）異様な美しさがある（ここに限らず、弦の鳴らし方が美しい）。そこから本格的な合唱が入る。ブリュージュの祭りらしい。

パウルによる実に自分勝手でショービニスティックなセリフがあり、マリエッタによる抵抗がきて、絞殺する。

そこで、夢を壊した現実の夢から覚める。1幕は現実なのだが、それは死者と共棲する夢で、2幕と3幕の初めは夢なのだが、それは生者の夢で、その夢が死者との共生を破壊して、その夢から覚める。さて今は本当に現実なのだろうか。演出の照明の使い方は現実の現実を示す。

Gluck……をO Freundに変えて歌い直す。明るくすっきりと。同じ曲を2回使うのか、まるでリゴレットのようだというか、これだけ流せば印象的だなとコマーシャルな作り方をちょっとおもしろいなと思ったら、さらに生が死を分かつときと最初のGluckのほうに戻してもう一度。きれいな終わり方だが、意味深だ。と考えながら聴いていると、終わっていないのに盛大に拍手が始まってギクっとした。集中して聴いているのにノイズが入るのは心臓に悪い。

3回目の歌詞が、翻訳のせいか、それとも本当にそうなのかはわからないが、普通の言い回しとは逆転していて興味深い。

死が分かれをもたらすのではなく、生が別れをもたらすという感覚（そこがパウロの持つ夜郎自大っぷりとも言える。実際、彼は生きている間にマリーをどう扱っていたのだろうか。常に中心に自分があるので、マリーの死＝死が分かつではなく、自分の生＝生が分かつということになるなのだろう。もっとも、このような極度な自己感触の肥大化が世紀末芸術の本質なような気がしてきた。なるほど1914年が待っていたはずだ。で、この作品は1920年、作者23歳のときだが、準備に4年かかったとあるので作り始めたのは10代からだ）こそが、パウルがブリュージュに隠棲していることなのだから、友よと歌ったあとに、この歌詞が出てくることは少しも解決になっていないようにも感じる（おお友よの明るさに比べると、再び陰影が生じている）。

そうか、今年は1914年からの100周年なのか。

トラストD.E (1957年)(イリヤ・エレンブルグ)

追記：1幕、2幕、3幕、すべてが50分という時間設定には感心した。良くそんな作り方ができたな（というか、したな）。

_ なぜ弱いやつが弱いやつを叩くのか

妻が図書館で多分間違って借りてきて放り出すのも口惜しいのか、おれに読めと貸してくれたので読み始めたが、なかなかうんざりして飛ばしながら、ほぼ読んだ（まだ数章残している。また、巻末の解題は読んでいない）。

ハマータウンの野郎ども (ちくま学芸文庫)(ポール・E. ウィリス)

1970年代英国の中学に通う労働者階級の子弟のうち特に男子生徒を、旧制度校の非順応派（野郎ども、ラッド）、順応派（耳穴小僧）、新制度校の非順応派、順応派、といったグループに分類し、相違を調査し（定性調査で、なぜ定量調査ではないかについては理由が最初にある）、教育の価値や社会構造の成立について調査した本だ。（早いうちから職業訓練的な性格を持った学校へ進めさせるのが良いのか、それともジェネラルな教育を与えるほうが良いのかといった模索をしていた頃だ）

特に重点は、最悪の存在である、野郎どもに向けられる。

ラッドといえば、a lad insaneでそういう言葉があるのは知っていたが、日本語だと野郎どもというよりも、ヤンキーとかDQNというニュアンスだな。でも誇らしげに自称というか自分をカテゴライズするのにも利用しているから、硬派というのが近いのかも知れない。全然アラジンセインのイメージとは異なって驚いた。

アラジン・セイン 40周年記念盤 (完全生産限定盤)(デヴィッド・ボウイ)

著者はおそらく社会民主主義者で、問題意識は、なぜこの連中（階級制度上は明らかな弱者であり、そのことに対して反抗的でありながら、しかしなぜかやはり家族と同様に中学を卒業するやいなや肉体労働に従事することになり、そこで止まってしまう）が革命に向かおうとせずにむしろ（結果的に）保守的なのか、その理由を知りたいということだと推測する。1970年代らしい。もちろん、それに対して逆方向に強めれば、反革命的であることが望ましい勢力にとってはありがたい結果となるので、両方に利用できる調査だ。

それにしても、1970年代の英国と今の日本の近似っぷりには驚かされる。

明らかに野郎どもは国境を越えた存在だ。

家父長的に高圧的に出る教師には一目をおくが、しかし教師には基本さからい、特に話を聞こうという姿勢を見せると弱虫野郎と考えて徹底的に馬鹿にし、卒業式にはここが最後の見せ場とばかりに消火器の栓を抜いたりして大騒ぎをし学校を破壊する。順応派はそれが順応派であるという理由で軽蔑しいじめ、地元の先に就職した先輩にはぺこぺこし、男であることがすべてだというような良くわからない価値観を振りかざし、卒業するとありつくことができれば肉体労働に従事する。

学校を始めとした既存の権威に反抗的な姿勢を示すが、その結果、逆に画一的な価値観を持ってしまう。父親のことは嫌いで反抗的であるが、にもかかわらず、親父はしっかり稼いでくる。それが男だ、と尊敬らしきものを持つ。そのため、家での父親の「今日は職場で～にがつんとくらわせてやった」みたいな話を聞き、ショービニズムに染まっていく。

知能/知性は原因ではないということは早くから言及される。特にラッドのリーダー格の生徒の自己分析や他者分析の鋭さについて、その言葉を含めて考察している。にもかかわらず、結局は反知性主義にそまり、その能力は社会改革に利用されることはなく、家父長的な価値観に染まり、肉体労働に従事することになる。

むしろ、順応派のほうがあまり賢くはない。そのため、従順であるわけだが、そのため学業に励み、結果的に最終的にはより高い学歴を持ち、より安定した生活を送ることになる。

興味深いのが、ラッドの差別意識についての分析だ。

かれらは、移民特に他人種を差別する。同じ学校のアジア人をゴミ扱いし、暴力を振う。黒人に対してもゴミ扱いし、暴力を振う。

アジア人は相対的に上位の職につくため、同じ労働の場にはいない。したがって、学校を離れれば、オカマ野郎（男らしくない＝ダメな人間）という評価をくだし、その存在を馬鹿にすることで、心の平静を取れる。

ラッドの価値観では、直接的な肉体労働による何かをなしとげる感覚は、男らしさの唯一の証明であり、そのために、最下等の労働につくことに倒錯した誇りを持つ。したがって、その仕事が下等であればあるほどむしろ誇らしい。

しかし、そういう仕事は下等なゆえに、より安価な労働力に割り当てることができる。したがって、労働市場での競合は黒人の移民となる。下位労働が誇らしいという感覚と、下位労働はしょせん下位労働で、おれさまだからこんなすごいことをやれるんだぜ、という誇りは、お前より安くても文句を言わないあいつのほうが良いという、経営側が突きつける現実の前に太刀打ちできない。そのため、「あいつ」はおれさまより弱いくずだ、ということを確認しないでは心の平静つまり誇りを保たずにはいられない。その確認作業が差別として表出される。

で？

と、残りの章を読むことになるのだが、今の英国についてのレポートを読んだり、日本の現状を見たりする限り、適度な娯楽と端金を与えておいて、たまに暴れさせればいいやんというのが（著者は違うだろうが）政治的な結論のようだ。

そこで考えるのは、とにかく技術をどんどん進歩させて、さっさと肉体労働という市場を無くしてしまうのが取りあえず、人類にとっては一番重要なことのようだ。あらゆる肉体労働は機械にやらせるのが一番だな。

_ 相対性

とは言え金太郎飴ではある。

_ Dart

アスキーの鈴木さんからプログラミング言語Dartを頂いた。

また新しい言語か、と思いながらパラパラ見てみると、なんか雰囲気が良いので少しまじめに読んでみた。

JavaScriptとJavaとC#の良いとこどりと書いてあるが、特徴は次のところだろう。

・関数の記述はC#やJavaのラムダ式のように楽ちん。例）(x, y) => x * y

・EclipseベースのIDEが最初から用意されている

・型名の明示が可能（finalのような修飾子もあるし、リストとマップにはジェネリクスも利用できる）なので、型チェックを最初からされるのが好きな開発者でもOK（TODO:varで宣言した変数に限り、JavaScript並の自動型変換がある（便利ではあるけど諸刃の剣なのでそこを宣言で制御できるのなら良いと思った）かどうかは、ぱらぱら読んだだけだとわからなかった）

・クラスベースだが、必ずしもクラスを使う必要はない。インターフェイスもクラスで代替

・WebSocket、HTTPリクエスト、RESTfulなAPIとかそのあたりは用意万端。

・JavaScriptトランスレータが用意されているので、普通のWebブラウザでクライアントコードを実行できる

・シングルスレッドだけどisolateという（ファイバー相当なのかな）実行単位を持つ。

・サーバーでの実行も可能（Node.jsの置き換えを狙っている雰囲気がある）

JavaScriptの置き換えを狙っていて、そのためのソフトウェアエコシステムを揃えているのが特徴ということなのだろう。あとは、HerokuがいきなりDartで開発できれば良いのだろうけど、当然のようにビルドパッケージが用意されていた。

といった具合。

プログラミング言語Dart(Chris Buckett)

なかなか面白そうだ。

_ これでお仕舞いもやしもん

もやしもんの最終巻を買って読んだ。

いやー、もう買わなくてもいいかなぁと思いながらもなんだかんだと読み続けて、最後はかっちりとしめてきた。というか、菌が顕現してこそのもやしもんだなぁと他愛もなく感動してしまったよ。

もやしもん(13)<完> (モーニング KC)(石川 雅之)

いいよーという麹菌の言葉に思わず涙。（けいぞう、も良かったね）

実に良い終りだった。

_ 取っ掛かりを網羅したUNIX入門書

アスキーの鈴木さんから、DART本と同時に、はじめてUNIXで仕事する人が読む本もいただいた。こちらは普通に読んだ。

これは良い本だった。UNIXとのおつきあいがあまり無い人には強くお勧めしたい。

が、ちょっと勘違いすると、とんでも本扱いされる危険もありそうなので、この本の良さについて説明する必要がある気がする。

はじめてUNIXで仕事をする人が読む本(木本雅彦)

まず、この本のすぐにわかる特徴は2点ある。

網羅性の高さと、本の薄さだ。

木村さんが第三部の目次を掲げてなんか良さそうと書いている。目次を見るとLANとWANの違いから、OSI参照モデル、IP（V4,V6）、TCPとUDP、アプリケーションプロトコル、そしてセキュリティまで網羅しているからすさまじいのだが、おそらく勘違いしている。

第三部はここまで網羅しているのに、ページ数は50ページに満たないのだ。

ソフトウェアライセンス（第11章）も、「ライセンスを考慮する理由」と「オープンソースライセンス」の2つの節から構成されているから、おお、と思うと合わせて2ページだ。

そもそも全体が250ページに満たない。1バイトでカウントできる情報量しか持たないのだ。

この本の特徴は、まさにそこにある。網羅性の高さと本自体が持つ情報量の少なさだ。

網羅性が高いのに情報量が少ないというと、辞書や事典を想像すると良いかも知れない。

この本は、事典ではないが、UNIXというOSを構成している（多少は文化も含む）あらゆる構成要素を

・生活環境（Life with UNIXみたいだ）

・プログラミング環境

・ネットワーク技術

の3つの切り口からその特徴を示し、その特徴を構成する各要素について概略を示したものだ。

事典ではないから、先頭から最後まで読むことを前提としているし、そういう書き方をしている。しかし、個々の内容を掘り下げるつもりはあまり無いらしい。とはいえ、vim、Emacs、shellや、RCS、Subversion、GITについてはコマンドを含む使い方を示している。なぜRCSと思うが、それによりCVSを説明する必要がなくなるからだろうし、ちょっと掘ったディレクトリに自分のためのバージョン管理をするにはRCSで十分なこともあるからかも知れない（この～を教えておけば～'はその応用だから不要というのが全体のトーンに近い）。

入門書にはおそらく2種類ある。

1つは魚の釣り型の具体的な説明をした本だ。その本を読めば、（たとえばたまたま取り上げられている題材がカサゴの磯釣りなら）カサゴの磯釣りについては熟知できるだろう。しかし、そこから釣堀でマスを釣るための方法まで敷衍して考えられるか、冬に湖にワカサギを釣りに行くための方法を得られるかはわからない。普通は無理だろう。

もう1つは、釣竿の種類、糸の種類、釣り場の種類、どういう魚が釣りに向いていて（逆に網に向いていて）、餌にはどういう種類があり、交通手段として海であれば～、川であれば～、というユニバーサルな入門書だ。書くためには幅広い知識、経験、取捨選択のセンス、いろいろなものが要求されるため難しく、しかもすぐに直接的な役にも立たない。明日カサゴの磯釣りに行きたい人に与えてもだめだろう。

完全に後者の本なのだ。ここに網羅された情報を叩き込んでおけば、それが必要となったときに、こういう場合には～を使えばできるはずだとわかる（わからなくても何か思い当る程度でも良いのだよ）ので、あとは検索するなり、特化した本を入手するなりすれば良い。まさに仕事をするために全体像を俯瞰し、特徴を知ることができる。

そのため、なんで今更こんなものが？ という要素技術が出てくることがある。例えばOSI参照モデルだし、RCSだし、Telnetだ。

ほぼ間違いなく、OSI参照モデルのインスタンスを仕事で使うことは無いだろう（銀行関係とかだと無いわけではないと思うが）。

しかし、ネットワークの多層化された構成モデルを頭に入れておくことは仕事で使うには必要かも知れない。そして多層化モデルとしてOSI参照モデルはうまくできているのだから、その階層について概略が説明されていることは大いに意味がある。

ちょっと違うが、背景知識の有無というのは問題が発生したときにとても重要となる。

たとえば、HTTPSでクライアント側のテストを手伝っていて、うまく疎通確認ができないという問題があるとする。サーバー側のWebアプリケーションのデバッグトレースにひっからないし、そもそもアクセスログにも出てこない。そこでクライアントからのリクエストが出ていないようだとサーバー側は言う。いや、送っているはずだ、とクライアント側は言う。

そこでルータではないか、ロードバランサーではないか、と始まるのだが、そこを疑う前にまず内部を疑う必要があるのでは？ とネットワークのプロトコルスタックの絵が見えていれば考えることができる。SSLのレイヤー（SSのレイヤーとは書けないし、難しいな）で接続を拒否している可能性が高いからだ。

よく、つながらないけどpingしたら応答が返るんですよというようなほとんど役に立たない（ゼロではない）情報がついた報告があったりするけど、どうして全体でものごと考えないのかと小一時間系なことが起きるのが仕事というものだ。そこはとりあえずtelnetでポート25を叩いてみろとか。でもtelnetを知らない人はそういう発想自体ができない（本書でも軽くtelnetの応用例としてポート23以外を叩くことにも触れている）。

つまりこの本には表面的にしか物事を読めない人にアピールするネガティブな要素として

・掘り下げがない

・（telnetとかRCSとかOSI参照モデルなど）古い情報が多い

・使わないエディタや古臭いコマンドの使い方にページが割かれている

・これを読んでもLinuxのインストールはできない

というようなことがあり、おそらくアマゾンには上記の特徴をあげつらった星1つが得意満面に出てくるだろう。

しかし、少しでも物事を掘り下げて考えられる人間にとっては、まず編集とファイルを操作する最低限のコマンドについては具体的に説明があり（必要であれば、古いUNIXでも使えるように古典的なコマンド/方法を示し）、さらに専門的な内容に知識のパスをつけられるように全体像をつかめるようにしてある。

つまり、古典的な入門書の名著と呼ばれるものを、現代で再実装した内容となっている。

志が高い良い本だ。

追記）達人出版会からも販売された。

_ 知性の敗北について

自分のことを棚上げしないととても書けないことではあるが、4月が近づいて新入社員とかが見えてくるからか、IT関連の業界の人に対して～を学べ系の記事（ブログ）が目につくにようになってきた。

そこに、どうしようもなく、ダメな言質を見かける。ひどすぎる。常識もなければ良識もなく、つまりは知性のかけらも見られない言葉だ。

まず、その時の旬の技術や、基礎的な知識についてのお勧め群、これらは良い。というよりも、そういう業界なのだから当然だ。それがもしかしたら一過性で数か月しか持ちそうもない流行りものだとしてもだ。

問題は、「英語を学べ」というやつ。

技術書は翻訳は遅いし不正確だから原書で読めとか。

そのての言葉たちだ。

まさに負け犬の遠吠え、敗者の論理、敗北主義者の泣き言だ。

いやしくも、きみたちは、コンピュータ技術者だろう？ 違うのか？ 違うならば、ご意見はご無用。何もわかっていない人は口を噤むべきだろう。ちなみに噤むは「つぐむ」と読む。「つむぐ」と読み間違えて言葉を紡いでしまったのかと教養を疑わざるを得ない状況だ。

コンピュータ技術者であれば、正答はひとつしかない。

コンピュータ技術を利用して、機械翻訳をするから、英語は学ぶ必要はない。

そこから出発しなければ話にならない。何のためのコンピュータだ？

で、「とは言っても、まだリアルタイムな音声識別は……」とか「リアルタイムな音声合成は……」といった制約があるから、ヒアリングとトーキングは学ばないとね。

あたりまでなら許容できる。

ところが、技術書を読むなら、とか、技術書の翻訳は遅いから、とか、はなから相手にしているのが、読み書きの世界なわけだ。

これを技術的敗北主義と言わずしてなんと呼べば良いのだろうか？

それにしても何の疑念も持たないのかね。その程度にしかコンピュータ技術のことを重んじていないのかね。だとしたらおこがましい発言だよなぁ。

_ Ruby-2.1.1インストーラ

readlineのバグ（コンソール出力の問題かも知れないけど）をまだ見ていないので作る気はなかったのだけど（irbが使い物にならない）、ソケットの問題がどうにもならないので、パッケージを作りました。

今回からは、リファレンスマニュアルにDiceさんがCCで公開してくださっているRubyリファレンスマニュアル chm版リミックスを同梱するようにしました。どうもありがとうございます。一番サイズが小さい標準版を入れています。

なお、上で書いているソケットの問題というのは、子プロセスにソケットが引き継がれることです。どうもMSDNを読むと、親子の会話に便利だろうというような思い付きでデフォルトを子プロセス引き継ぎにしたようなのですが、ついWinddows7sp1までは抑制する方法がなかった（プロセス作成時にハンドルすべてを引き継がないように設定することは可能だけど、それは極端過ぎる）ため、Rubyでは特に何もしていなかったために発生します。

これ、なぜ大問題にならないのかすごく不思議なのだけど、

・サーバで実行する場合はMongrelなり、Ennou（おれだな）なりを使ってrubyのTCPServerを使うことはあまりない

・普通のWebアプリケーションで、プロセスを起動してそれが長期間実行される子プロセスを実行するというようなパターンがない

といったところでしょう。

これが最悪なのは、デバッグしていてスクリプトを終了、再起動してもEADDRINUSEでエラーになるわけではなく、どうもポートを食われているのではないかと気づいてnetstat /bで掴んでいるプロセスを特定しようとしてもシステムという意味ない表示しかされないことです。

というわけで、usaさんにパッチを作っていただいたので、適用しています。ありがとうございます。助かります。

Ruby MSIパッケージからダウンロードしてください。