2012年12月22日土曜日

LispでOSを書く

(このエントリは、Lisp Advent Calendar 2012 の22日目である)

ELIS復活祭のとき、ELISのTCP/IPプロトコルスタックを書いたという方とお話する機会があった。ELISのプロトコルスタックはもちろんLispで書かれていた。その方がおっしゃるには、「C言語はよい。BSDからソースコードを持ってくればいいのだから。しかし、Lispで書かれたプロトコルスタックなどなかった。自分で書くしかなかった」ということだった。それにしても、LispでOSを書くというのは、いったいどんな感じなのだろう?

OS記述言語としてのLisp

UnixがCで書かれて以来、OSは、伝統的にCとその派生言語で書かれることになった。BSDやLinuxを含むUnix-likeなシステムはもちろんCで書かれている。Windows NTはC++を使っている。BeOSもC++で書いたし、MacOS XはObjective-Cを使っているのかもしれない。もしかすると、IBMのメインフレームなどでは事情が異なるのかもしれない。

Cとその仲間たちは、いわゆる高級言語の中でも抽象化のスペクトルのだいぶ下の方に位置している。つまり、ビットを操作するような処理が得意なのだ。だから、デバイスのレジスタを直接叩くような処理はCの得意とするところだ。

OSを構成するサブシステムの中でも、プロトコルスタックやファイルシステムは、デバイスを叩くというよりは、ある種のロジックを実装するものだ。80年代から90年代にかけて研究されたマイクロカーネルでは、これらのサブシステムはユーザプロセスとして実現されていた。

ソフトウェア工学の言葉を使うなら、OSのコア(マイクロカーネル)はデバイスへアクセスする「メカニズム」を提供する。上位のサブシステムは、そのデバイスをどのように使うか(例えば、ファイルシステムをどう構成するか)という「ポリシー」を実装する。

複雑なロジックを実装するためには、できるだけ抽象化のレベルの高い言語を使うべきだ。そして、もっとも抽象化のレベルの高い言語(のひとつ)はLispである。したがって、OSのサブシステムも、ある部分はELISのようにLispで書いてもいいはずだ。

FUSE + libfuse + Gauche + c-wrapper

LispでOSのサブシステムを書くというのがどんな感じなのか、試してみる方法をご紹介したい。私はCommon LispよりもSchemeの方が慣れているので、Gaucheを使うことにしよう。

1から新しいOSを設計するのは、楽しいかもしれないが時間もかかる。Linuxには、FUSE(Filesystem in Userspace)という、ファイルシステムをユーザ空間で実装するための仕組みがある。この仕組みを使って、Gaucheでファイルシステムを書いてみたい。

FUSEにつて簡単に説明しよう。Linuxカーネルは複数のファイルシステムを持っている。ext3, ext4, btrfsなどなどだ。それぞれのファイルシステムの開発者のために、カーネルとファイルシステムとの間に標準的なインタフェースが決まっている。このインタフェースをユーザ空間からアクセスできるようにする仕組みがFUSEだ。

最近のLinuxカーネルなら、FUSEは標準で組み込まれている。/dev/fuseがカーネルへのインタフェースだ。基本的には、普通のファイルアクセスのシステムコールを使って/dev/fuseを操作すればよいのだが、これをもう少し簡単に行うためのライブラリとして、libfuseがある。

libfuseはCのライブラリだ。libfuseをGaucheで使うにはCへのバインディングを書けばよいのだが、もっと簡単な方法は…そう、魔法のc-wrapperである。

hellofs (The Hello Filesystem)

ストレージを操作する本物のファイルシステムではなく(これは大仕事だ)、偽物のファイルシステム(Pseudo Filesystem)を実装してみる。これは、/procや/sysの一種と考えてよい。このファイルシステムは、FUSEのサンプルプログラムをほぼそのままSchemeで書きなおしたものだ(若干の手抜きをしたので、あまりいい例ではないかもしれない)。
#!/usr/bin/env gosh
# hellofs.scm (The Hello Filesystem)

(use gauche.uvector)
(use c-wrapper)

(c-load "fuse.h"
        :cppflags "-DFUSE_USE_VERSION=26"
        :cppflags-cmd "pkg-config --cflags fuse"
        :import '(fuse_operations
                  fuse_main_compat2
                  fuse_main
                  NULL)
        )
(c-load "stdio.h")
(c-load "string.h")
(c-load "errno.h")
(c-load "fcntl.h")
(c-load-library "libfuse")

(define hello-path "/hello")
(define hello-str "Hello world!\n")

(define (hello-getattr path stbuf)
  (memset stbuf 0 (c-sizeof (c-struct 'stat)))
  (cond ((string=? (cast  path) "/")
         (set! (ref stbuf 'st_mode) (logior S_IFDIR #o755))
         (set! (ref stbuf 'st_nlink) 2)
         0)
        ((string=? (cast  path) hello-path)
         (set! (ref stbuf 'st_mode) (logior S_IFREG #o444))
         (set! (ref stbuf 'st_nlink) 1)
         (set! (ref stbuf 'st_size) (string-length hello-str))
         0)
        (else (- ENOENT))))

(define (hello-readdir path buf filler offset fi)
  (if (not (string=? (cast  path) "/"))
      (- ENOENT)
      (begin (filler buf "." NULL 0)
             (filler buf ".." NULL 0)
             (filler buf ((#/^\/(.*)$/ hello-path) 1) NULL 0)
             0)))
      
(define (hello-open path fi)
  (if (not (string=? (cast  path) hello-path))
      (- ENOENT)
      (if (not (= (logand (ref fi 'flags) 3) O_RDONLY))
          (- EACCESS)
          0)))

(define (hello-read path buf size offset fi)
  (memcpy buf hello-str (string-length hello-str))
  (string-length hello-str))

(define hello-operators (make (c-struct 'fuse_operations)))

(set! (ref hello-operators 'getattr) hello-getattr)
(set! (ref hello-operators 'readdir) hello-readdir)
(set! (ref hello-operators 'open) hello-open)
(set! (ref hello-operators 'read) hello-read)

(define (main args)
  (fuse_main (length args)
             args
             (ptr hello-operators)
             NULL
             ))
マウントすると、マウントポイントにhelloというファイルが現れる。このファイルにはお馴染みの文字列が格納されている。
# mkdir /tmp/hello
# ./hellofs.scm /tmp/hello -d -s
...
# ls /tmp/hello
hello
# cat /tmp/hello/hello
Hello world!
マウントするときに、シングルスレッドモード(-sオプション)を指定することに注意して欲しい。libfuseは、その中で新たなスレッドを生成する。このスレッドはGaucheのスレッドではないので、この中からSchemeの関数をコールバックすることはできない。

FUSEを使ってストレージを操作するようなファイルシステムを作りたいのなら、デバイスノードを読み書きすればよい。また、ユーザ空間でできることは何でもできる。例えば、EvernoteやGoogle Driveにアクセスするようなファイルシステムを作ることもできるはずだ。

* * * 

OSのカーネルはますます大きく複雑になっている。Unixの第6版のソースコードは、印刷したものをブリーフケースで楽に持ち歩くことができるほど小さかった。今日のLinuxのソースコードを印刷して持ち歩くことは、不可能ではないが紙の無駄である。

 Unix第6版の時代からプログラミング言語の世界は大きく進歩した(もちろんLispはUnix第6版の時代から存在したのだが)。ところが、今日のOS開発者は、これら進歩的プログラミング言語の恩恵に与っていない。 

そろそろ、OS開発にも、次の世代のプログラミング言語を使ってもよいのではないかと思う。ELISは商業的には成功しなかった。しかし、ELISの開発過程で多くの知識が蓄積されたはずだ。(非常に失礼な言い方だが)ELISの開発者がまだ生きている今こそ、そのチャンスである(失礼しました)。

2012年12月15日土曜日

豊かな社会

私の母校は、工学部のみの小さな単科大学だ。工学部のみの大学であっても、いわゆる一般教養の授業がある。そのための常勤の教員もいる。特に人文社会系の講義のことを、私たちは単に「社会系」と呼んでいた。

私たちにとって、「社会系」の授業は悩みの種だった。これらの単位が、進級のための条件になっていたからだ。私たちは、エンジニアリングを学ぶために大学へ入った。そのために授業料も払った。確かに西洋思想史は興味深いかもしれないが、エンジニアリングとの接点を見出すことはできなかった。

大人になってから、「あの時もっと勉強しておけばよかった」と思わない人はいない。私もその例に漏れない。30歳を過ぎて思うには、もっと真面目に「社会系」の勉強をしておけばよかったのである。

実は、エンジニアリングと「社会系」は密接に関係していた。なぜなら、エンジニアリングとは、社会を豊かにする方法だからだ。学生時代の私は、エンジニアリングの方法論にばかり捕らわれ、その目的が見えていなかった。

19世紀の経済学者は未来を悲観した。保守主義者もマルクス主義者も、産業革命の行き着く先はユートピアではないという点では意見が一致していた。しかるに、二つの世界大戦を挟み、ヨーロッパ、アメリカ、日本を含む国々には、豊かな社会が誕生した。これらの国々の共通点は、エンジニアがたくさん住んでいるということだ。

失われた10年だか20年だか知らないが、日本企業が不調である。パナソニックが赤字という。シャープも赤字という。任天堂でさえ赤字という。日本の製造業は軒並み「オワコン」と言われる。どうしてしまったか?

日本の製造業も、学生時代の私と同様、方法論にばかり捕らわれ、社会を豊かにするという当たり前の目的が見えなくなっているように思う。私も、ついこの間まで日本の製造業に身をおいていたのでよくわかる。もっとも、彼らが捕らわれている方法論は、経営学のそれであるようだ。

何をもって社会の豊かさとするかは難しい。今年のはじめに、ロボット掃除機のルンバを買った。まるでSFの世界にいるようだった。ハインラインの『夏への扉』に出てくる家事ロボットのようだった。私の生活は豊かになった。

今年ももう終わりだ。毎年、その年のテーマを設定することにしている。来年のテーマは「社会系」にしようと思っている。今年のうちに、古本屋行きを免れた教科書を発掘しなければならない。

2012年12月13日木曜日

『オペレーティングシステム 設計と実装 第3版』を読んだ

1953年、ワトソンとクリックによりDNAの二重らせん構造が発見されたとき、生命には神がかり的なものは何もないことが明らかとなった。以来、生命をめぐる神学上の諸々の問題は、科学とエンジニアリングの問題となった。本書を読めば、読者は、オペレーティングシステムのカーネルについて同じ発見をすることになる。

本書は、私の家の積読本コーナーにもう長いこと置かれていた。本書の原書が出版されたのが2005年。本書は、その翻訳として2007年に出版された。翻訳が出版されてすぐに手に入れたのだが、ずっと読めずにいた。何度か読もうと挑戦したものの、途中で挫折してしまっていた。読書会にも参加したが、途中で脱落してしまった。

今回、何度目かの挑戦で、ようやく読み終えることができた。実は、この本を読むのには、少々コツがあったのだ。本書は、1000ページを超える大著である上、本の後ろ半分がソースコードという、かなり特殊な本である。

本書では、カーネル、デバイスドライバ、メモリ管理、ファイルシステムのそれぞれのオペレーティングシステムのコンポーネントについて、それぞれひとつの章が割り当てられている。それぞれの章は、以下の順番で構成されている:
  1. オペレーティングシステム理論
  2. MINIXによる実装の概要
  3. MINIXのソースコード解説
  4. ソースコード
ただし、ソースコードは、すべてまとめて本の後ろ半分に付録となっている。1と2は普通に(つまりシーケンシャルに)読むことができる。問題は、3と4を如何に読むかである。

今まで私がどうやって読もうとしていたかというと、3と4を逐一対応付けながら読もうとしていた。つまり、ソースコードをちょっと読んで、該当する解説を読み、そしてまたソースコードに戻るという具合だ。

この読み方は、非常にしんどい。本文とソースコードとを、頻繁に行ったり来たりしなければならないからだ。すなわち、コンテキストスイッチのオーバーヘッドが大きい。

コツは、ソースコードを先に読むことだ。解説を読まずに、まず、ソースコードを読めるところまで読む。多少わからないところがあっても、本文で解説されていることを期待して、どんどん読み進む。ソースコードをある程度まとまった量(私には1ファイル分くらいが丁度よかった)読んだら、解説に目を通す。すると、自分の理解が正しかったり、あるいは間違っていたことがわかる。

本書は、Linux誕生のきっかけとなった事で有名だ。しかし、オペレーティングシステムの教科書としても非常によい本である。本書の、オペレーティングシステムのソースコードを読むことで学ぶというアプローチは、オペレーティングシステムの真の姿を明らかにする。

著者のTanenbaumは述べている:
実際のOSの真の姿は、知性的な興奮に満ちたものとは程遠く、マイナーな雑用を行うコードの集まりである。しかし、このようなコードこそシステムの可用性を向上するためには非常に重要なのである。(p.637)
また、その少しあとで、こうも述べている:
優れたシステムと平凡なシステムの違いは、スケジューリングアルゴリズムのすばらしさではなく、細部まで正確に仕上げる配慮にあるのである。(p.637)
私自身の学生時代を思い返してみると、オペレーティングシステムの授業では、スケジューリングやページングのアルゴリズムばかりが印象に残っている。そして、オペレーティングシステムとは、普通のプログラムとはどこか異なる、摩訶不思議な、何か神がかったものという印象を持ってしまっていた。

ワトソンとクリック以来、生命は単なる有機化合物の塊となった。本書が明らかにしたように、オペレーティングシステムも、単なるCプログラムの塊に過ぎないのだ。

2012年11月17日土曜日

Unixの自由

TechLION vol.10に行ってきた。村井純さんのお話を聞いてきた。村井純さんといえば、Unixとインターネットを創った男だ。もう古い本だが、村井純さんは、Bachの『UNIXカーネルの設計』の翻訳者でもある。この本は、私が初めて読んだカーネルの本だ。この本でOSとは何かを学び、Unixとは何かを学んだ。今、私がLinuxの仕事をしているのも、この本のおかげだ。

今や、Unixだらけだ。Linuxであり、BSDである。Solarisであり、MacOS Xである。WndowsですらPOSIX APIを備えている。IBMのメインフレームでもLinuxを使う顧客がいるという。スーパーコンピュータもそうだ。Androidもそうだ。どうしてこうなってしまったか?

村井純さんが学生の頃、最初に教授に指示された仕事が、DECのPDP-11用OSであるRSX-11の逆アセンブルであったという。もちろん手作業である。村井純さんは、この作業でOSを学んだという。

その後しばらくしてUnixが登場する。Unixの特徴には、ファイルによる抽象化がある。一見奇妙なfork/execモデルも特徴と言える。しかし、一番の特徴は、Cで書かれていること、そしてそのソースコードを読むことができるということだ。

村井純さんがおっしゃるには、Cで書かれたUnixは遅かったという。ハードウェアベンダーがカリカリにチューンしたOSにはとてもかなわなかったという。しかし、それでもUnixを選んだ。なぜなら、Unixには自由があったからだという。

あるソフトウェアが自由とはどういうことか? もっと単純で物質的な道具について、その自由を表明したら少し奇妙な印象を受けるだろう。例えば、「ハサミは自由である」と言ってみたらどうか?

もちろん、ハサミは自由だ。アナタは、ハサミを使って自由に紙を切ってよい。封筒を開けるのに使ってよい。お菓子の袋を開けるのにも使ってよい。ハサミの使用目的は「切る」ことだ。ハサミが自由であるとは、アナタは何を切ってもよいということだ。もちろん、夜道で人を切りつけてはダメだ。犯罪行為は、道具に関わる自由の例外である。

ソフトウェアも道具だ。Unixにもハサミと同様の自由を認めてよいはずだ。つまり、Unixの使用目的について、アナタは自由である。問題は、Unixの使用目的とは何かということだ。UnixはOSなので、OS一般の使用目的と言い換えてもよい。

OSの教科書をめくると、OSには2つの機能があると書いてある。リソースの管理と、APIの提供だ。これらの機能は、アプリケーションプログラムを書きやすくするためにある。ナマのハードウェアを触るのはしんどい。

したがって、OSの使用目的とは、その上でアプリケーションプログラムを書いて動作させることと言っていいだろう。つまり、アナタは、そのOSで、自由にアプリケーションを書いたり動作させてよい。

どこかで何かを間違ったのだろうか? RSX-11上でアプリケーションプログラムを書いたり動作させることに関して、DECは自由を制限していたのだろうか? そんなはずはないと思う。村井純さんはどの自由のことを言ったのだろう?

帰りの電車の中で、思うところがあってRaymondの『The Art of Unix Programming』を読み始めた(こういうときSafari Books Onlineは最高!!)。この本の、あるセクションのタイトルが目に止まった。それこそ、Unixに固有に認められる自由だった。すなわち、Raymondが言うことには、「Unix Is Fun to Hack」である。

Unixには、アプリケーションプログラムを書いたり動作させたりするというOS一般に認められる自由の他に、ハックする自由がある。ハックの対象は、Unixのカーネルの内部まで及ぶ。つまり、Unixは中身を調べて、場合によっては改造してもいいということだ。そのためには、高級言語で書かれていたほうがいい。

アプリケーションプログラマの中には、RSX-11を好む人もいただろう。Unixは遅いし、誰かのハックのおかげでクラッシュするかもしれない。しかし、多分ハッカーはUnixを好む。誰だって、RSX-11を逆アセンブルしたくはないだろうし、逆アセンブルしたとしてもRSX-11のハックは地下でやるしかない。

道具に関する自由というコンセプトは、アメリカの銃規制の問題を思い起こさせる。アメリカでは合法的に銃を所持することができる。しかし、銃は犯罪にも使われるため、アメリカ人の中には銃を規制したほうがよいと考える人もいる。

銃の使用目的は、何かを撃つことだ。つまり、銃の自由とは、アナタはその銃で何かを撃ってもよいということだ。もちろん、人を撃ったらダメだ。ハサミで人を切りつけては行けないのと同じだ。

銃規制に反対する人は、単に銃を奪われることだけでなく、自由を奪われることを恐れているのではないかと思う。逆に賛成派は、多少の不自由を受け入れればよりより社会になるよ、と言っている。

ハックする自由。なんだか当たり前の結論に至った。Richard Stallmanなんかが一生懸命主張しているのも、つまるところはハックする自由なのだろう。Linuxをはじめ、オープンソースのソフトウェアが普及したのもハックする自由があったからだ。結局みんなUnixの仲間なのだ。

2012年5月6日日曜日

リアルタイム・コンピューティングとカント主義

ミラクル・リナックスに入社してちょうど3ヶ月が経った。試用期間が終わり、正式(?)に採用となった。散々遅刻したのにクビにならなかったので、ほっとしている。これからはフレックスタイムが使えるので、大いに寝坊できるとうものだ。

4月末に、「実績レビュー」なるものがあった。社長以下各セクションのトップを集め、プレゼンを行い、この3ヶ月の仕事を見てもらって、継続して雇うかどうかを判断してもらおうというわけだ。これが、1時間も時間がとってあった。長い。

困ってしまった。私のプレゼンのスタイルは、「瞬発力で勝負」というものであって、せいぜい15分がいいところ。そもそも、1時間もしゃべる話題がない。うっかり口を滑らせて、「Linuxでリアルタイム・コンピューティングをやりたい」と言ってしまったところ、思いの外盛り上がった。

コンピューティングの世界で、「リアルタイム・コンピューティング」ほど誤解されている概念は無い。単に「レスポンスタイムが短い」という意味でリアルタイム・コンピューティングと言う人もいるし、「計算機内部の時間の流れと外部の時間の流れが同期している」という意味で言う人もいる。

私が思うに、「処理のデッドラインが設定されている」というのが、リアルタイム・コンピューティングの定義だ。デッドラインとは、その間に処理が終わって欲しいという時間である。デッドラインを過ぎる(デッドラインミス)と、計算結果の意味が失われる。リアルタイム・コンピューティング技術とは、いかにしてデッドラインを守るかという技術だ。

デッドラインミスが起きたときに何が起きるかはシステムによる。例えば、画像の乱れなど、一時的なパフォーマンスの低下として無視できる場合もある。飛行機の墜落や100億円の人工衛星が失われるなど、「大惨事」が起きるかも知れない。現実には、ほとんどのリアルタイム・システムは前者のグループに属する。ほとんどの場合、デッドラインミスは、単に無視できるか、上位のプロトコルでリカバリーできる。

一般的に、コンピューティングの世界では、パフォーマンスとは「速さ」だ。一方、リアルタイム・コンピューティングの世界では、パフォーマンスとは、あくまでも「デッドラインの尊守」である。計算が速いこととデッドラインの尊守は矛盾する概念ではない。しかし、イコールではない。

一般的なコンピューティングの世界にいる人には、この点をなかなか理解してもらえない。「リアルタイムだろうが何だろうが、速ければ文句ないだろう?」というわけだ。確かに文句はないのだが、それだけでは何か大事なものを見落としているような気がするのだ。

そこで、ひとつうまい説明を思いついた。すなわち、一般的なコンピューティングは、ベンサムの「功利主義」の世界である。一方、リアルタイム・コンピューティングは、「カント主義」の世界である。

功利主義やカント主義というのは、政治哲学の概念である。どうしてこんな比喩を思いついたかというと最近サンデル教授の本を読んだからなのだが、この喩えは、一般的なコンピューティングとリアルタイム・コンピューティングの違いをよく現していると思う。

時代的にはベンサムのほうが古い。ベンサムの功利主義は、最大多数の最大幸福とも呼ばれる。幸福最大原理である。ベンサムは、よりよい社会のためには、「効用」を最大化せよと説いた。効用とは、社会のすべての快楽を合計し、それから社会のすべての苦痛を引き算することで得られる。

ベンサムの視点でコンピューティングの世界を見てみよう。効用の定義は単純だ。効用とは「速さ」だ。すべての処理時間を合計し、それが最も短くなるようにすればよい。

コンピューティングにおける功利主義的技術の例として、キャッシュメモリがある。キャッシュメモリを使用すれば、全体の処理時間を短縮できる。しかし、個々のメモリアクセスに注目するならば、キャッシュミスが発生した場合、そのメモリアクセスの処理時間はわずかに延びる。すなわち、まずキャッシュを見にいき、そこに目的とするデータが無いならば、キャッシュを無効にし、さらにメインメモリを見にいく。この一連の処理の後、レジスタにデータがロードされる。しかし、全体としては、効用(速さ)は最大化(最小化)される。

さて、功利主義への批判は2つある。第1に、少数の意見が無視されることだ。第2に、そもそも論として、快楽や苦痛など人それぞれなのだから、それを「効用」なるある種のスカラー量に押しこむことができるのかということだ。

カントは、「人は皆尊敬されなければならない」とした。少数の意見を無視したり、人によってバラバラの価値観をひとつの尺度に押しこむことは、人々を尊敬しないことだとした。

カントの考えは難しい。尊敬とは何か? 尊敬を「デッドラインの尊守」と考えるならば、カント主義はリアルタイム・コンピューティングと似ているような気がする。少数の処理であれ、デッドラインは尊守されなければならない。プロセッサのパワーに対してタイトなデッドラインを設定する処理もあれば、余裕のあるデッドラインを設定する処理もある。いずれにせよ、デッドラインは尊守せねばならない。

再びキャッシュメモリについて考える。リアルタイム・コンピューティングにおいては、キャッシュミスによってキャッシュメモリの恩恵を受けられない処理があることは、それ自体では問題としない。問題は、キャッシュミスの予測が非常に難しいため、キャッシュミスを考慮した設計ができないことだ。予期せぬキャッシュミスは、予期せぬデッドラインミスを招くかも知れない。カントの目には、キャッシュメモリは非常にリスキーだ。

ベンサムもカントも理論家だ。しかし、多くの政治家は実務家である。現実の社会では、功利主義もカント主義も、どちらが優れているとは一概には言えない。実務家である政治家は、これらをうまく組み合わせ、最適のところでバランスするのである。

我々プログラマも実務家である。リアルタイム・コンピューティングをやっているからといって、例えばキャッシュメモリを排除してしまうのは惜しい。タイトなデッドラインに処理を押しこむのはそれ自体一苦労だし、上にも述べたように、たまのデッドラインミスであれば許容されることが多いという現実もある。

リアルタイム・コンピューティングの実務家としては、功利主義的技術とカント主義的技術をうまく組み合わせ、システムの仕様を睨みながら、最適のところでバランスするのである。


2012年4月28日土曜日

リアル本屋の楽しみ

亀有に引っ越してきて非常に不便なのが、近くに大きな本屋がないことだ。藤沢には、駅前にジュンク堂と有隣堂があり、まさに本屋戦争の様相を呈していた。亀有だって住んでいる人の数はそれなりなのだから、もうちょっと大きな本屋があってもよさそうなものである。

一時期は、本はすべてAmazonで買っていた。リアル本屋で面白そうな本を見つけても、家へ帰ってAmazonで注文していた。Amazonにはリコメンド機能があるからだ。Amazonで買い物をすればするほどリコメンド機能が賢くなる。このリコメンド機能をかなり頼りにしていた。

しかし、最近、リコメンド機能などどうでもよくなってきた。要は、似たような本ばかり読んでもしょうがないのだ。読書も娯楽である。新しい知識と出会う楽しみがある。幅広い、ときには意外な本が読みたいのだ。

この点において、Amazonのリコメンド機能は退屈だ。いわゆる「紙おむつとビール」理論は、売る側にとっての「意外性」であって、買う側にとっての「意外性」ではない。買う側は、そもそも、最初から紙おむつとビールを買いに来ているのである。

リアル書店のいいところは、そこに人間の意思が働いていることだ。大きな本屋へ行くと、新刊書と売れ筋のコーナーの他に、様々な「フェア」が催されていることがある。

例えば、「経済学の古典を読もう」みたいなフェアが開催されていて、そこにケインズの「一般理論」が置かれていたりする。非常に有名な本であるが、普通の人は読まない。そもそも、そういう本を読もうと思いつかない。しかし、そういう本が置かれていて目に入れば、読んでみようかなという気になるかも知れない。

亀有に大きな本屋がないので困っていたのだが、よく考えたら神保町まで行けばいいことに気がついた。神保町は、三田線で大手町の一個隣りである。大手町までは定期で行ける。別に、希少な古本を探しているわけではないが、世界最大の古書の街なら、「意外性」に出会えること間違いない。

3月末にリニューアルオープンしたばかりの、東京堂書店へ行ってみた。フロア面積としては、近くの三省堂本店などにははるかに及ばない。しかし、リアル本屋の楽しみを凝縮したような店である。1階から3階まで見て回ったら疲れてしまった。嬉しいことに、カフェが併設されている。

Kindleの日本進出が近いと言われている。喜ばしいことである。しかし、そうなると、リアル本屋の存在はますます重要になる。はじめから欲しい本がわかっているのなら、人々はネットで買うだろう。リアル本屋は、「なんか面白い本はないか?」という人々に応えねばならない。そのとき、どういう本を出してくるか? 書店員の腕の見せどころだ。

2012年3月10日土曜日

技術者の倫理

ミラクル・リナックスに入社して1ヶ月経った。3月からまた新しい人(NetBSDハッカー!!)が入ったので、昨日は歓迎会だった。つまりは飲み会なのだけれども、ミラクルの人たちと話していてひとつ驚いたことがある。彼らは、会社の飲み会で技術の話をするのだ。往年の親指シフトから、最新の(?)GNU Hurdまでが話題に上がった。

技術者には個性というものがある。強みである。もちろん、弱みともなりうる。前職の三菱電機では、マネジメント上の最大の焦点とされたものに、技術者の個性の無効化がる。無効化という言葉が過激すぎるなら、均質化と言い換えてもよい。逆に、ちょっと過激な言葉を使うならば、前職のマネジャーたちは、技術者を交換可能な標準化された部品とみなした。

天才的技術者がいたとする。すべての製品を彼の天才に頼っていたとする。ある朝、彼が交通事故に遭うようなことがあれば、直ちに事業は破綻する(スーパーコンピュータの父であるシーモア・クレイは交通事故で亡くなった)。したがって、天才的技術者への依存はリスクである。

前職のマネジャーたちは、シーモアの天才的コンピュータ設計能力のごときを利用しないという戦略によって、このリスクを回避しようとした。仕事を設計する際、シーモアの能力を最大限に引き出すようにはしなかった。シーモア以外の技術者でもできるように仕事を設計し、その仕事をシーモアに与えた。そうすれば、シーモアが交通事故に遭っても、別の技術者が引き継ぐことができる。

この戦略は、第1に、組織にとって不幸である。シーモアの能力が本当に価値ある製品を生み出すことができるものだとするならば、当然ながら、この戦略は価値ある製品を生み出さない。技術者の個性を無効化するということは、その組織の生み出す価値も無効化するということだ。

本質的に価値のない製品を売るためには、その製品があたかも価値があるかのごとく見せかけなければならない。例えば、無理な低価格化を行う。これは、多くの場合、技術者の賃金を下げる(サービス残業なども含む)ことによって行われる。一見、低価格は消費者にとってよいことのように思える。しかし、実際には、消費者はよりよい価値を得るチャンスを失っている。

第2に、シーモア自身にとっても不幸である。確かに、シーモアに与えられた仕事は、シーモアほどの天才をもってすれば容易にこなすことができるだろう。しかし、恐らく、シーモアは楽して稼ぐために技術者をやっているのではない。技術者なら誰もが知っていることだが、技術者は仕事そのものを報酬とみなす。自身が良い仕事をしたと思ったとき、最大の満足を得る。

仕事から満足を得られないならば、技術者は単に去るかもしれない(シーモア・クレイはいくつかの組織を転々としている)。もっと悪いシナリオは、技術者が、与えられた仕事に自らの能力を最適化してしまうことだ。余剰の能力を捨ててしまう。他へ移った技術者は、新しい組織で新しい価値を生み出すチャンスがある。能力を放棄した技術者は、もはやいかなる価値を生み出すこともできない。

今、日本企業に元気がないと言われる。なぜ、今の日本にはGoogleやAppleが生まれないのかと言われる。なぜ、日本にはこれだけ多くの企業がありながら、GoogleやAppleのような製品を生み出せないのかと言われる。

当然である。技術者の個性の無効化という戦略では、価値ある製品は生み出せない。技術者の個性の無効化によって、組織の産み出す価値は無効化され、技術者は能力を放棄してしまう。

本田宗一郎や松下幸之助の時代には、日本企業も価値を生み出していたはずだ。価値を生み出したからこそ、日本製が選ばれ、日本経済は発達した。しかし、彼ら戦後日本経済のヒーローが去った後、残された日本のマネジャーたちは、もう彼らには頼るまいと思った。そして、技術者の個性を無効化することを思いついた。その結果、日本製は急速に魅力を失い、退屈な技術者が残った。

私が、前職の同僚たちとの飲み会で最も不満だったことは、彼らが技術について話そうとしないことだった。少なくとも、親指シフトが話題に上ったことはなかった。彼らは、そもそも技術に興味がなかった。技術など、とっくに放棄してしまっていた。話題の中心は、会社の愚痴だった。

昨日の飲み会で、ミラクルの技術者は、少なくとも現時点では技術を放棄していないことがわかった。ミラクルのマネジャーは、技術者を標準化された部品とは考えていないのだろう。私はたまたまミラクルを選んだが、若い企業はどこもそうなのかもしれない。

若い会社は、市場規模は小さいかも知れない。前職とミラクルとでは、売上の単位が違う。しかし、人々は何のために市場を生み出したのかを思い出さなければならない。企業とは何かを思い出さなければならない。

技術とは、昨日よりよい明日を得るために今日行う活動である。市場とはこの活動を加速させる舞台であり、企業とは舞台で踊る主体である。

企業の規模は目的ではない。売上とは、企業がどれだけ価値を生み出しているかを評価するベンチマーキングであって、それ自体が企業の目的ではない。テストの点数それ自体が勉強の目的ではないのと同じである。

どんなに売上を上げていても、もはや価値を生み出せなくなった企業は速やかに市場から退場しなければならない。あるいは、その売上を、価値を生み出す活動へと注入しなければならない。絶対にそうしなければならないというわけではない。これは、倫理の問題である。

ミラクルに入社して1ヶ月、技術者として、私は何だか救われた気がしている。前職では、私は、自身が十分な価値を生み出していないことに気づいていた。このことに後ろめたさを感じていた。仕事とはそういうものだと、自分を誤魔化していた。

ミラクルでは、そのようなバツの悪い思いをしなくても済みそうだ。雇用とは契約である。企業は労働者に何物かを求め、労働者はそれに答える。しかし、労働者も企業に何物かを求める。企業はそれに答えなければならない。

私は、ミラクルに、個性を潰さないで欲しいと要求する。個性を持った、強みと、当然ながら弱みも持った技術者として扱って欲しいと要求する。そうすれば、私は最高の仕事を約束する。少なくとも努力はする。これが、技術者としての倫理である。

2012年2月26日日曜日

タクシードライバー

先日、飲み過ぎて上野で終電を逃したことがあった。仕方がないので、上野から亀有までタクシーで帰った。4000円ほどだった。普段、私はあまりタクシーに乗ることがないのだが、そのとき私の乗ったタクシーには、後部座席に小さな液晶モニタが設置されていた。色々な広告が流れていた。

そこで流れていた広告で知ったのだが、今都内のタクシー会社数社で、タクシーを呼ぶためのスマートフォンアプリを作っているらし。広告によると、スマートフォンに内蔵されたGPSの位置情報を用いることで、今までのように電話で呼ぶのに比べ、よりよい配車が可能になるとのことだった。

私の父はタクシードライバーだった。かつて、タクシードライバーとえば、一種の自由業であった。父や父の友人は、9時から5時まで会社に縛られるのが嫌でタクシードライバーになったのであった。自分の気の向くままに車を走らせることができるし、疲れたときは橋の下で休憩することができた。お客を乗せることさえできれば、何をするのもドライバーの自由だった。

父は働くのが嫌いだった。お酒は飲む方ではなかったが、よく、友人たちと麻雀をやっていた。パチンコも好きだった。私も、小学校へ上がる前から、よくパチンコ屋へ連れていかれた。景品のお菓子をもらえるのが楽しみだった。

父は不まじめなドライバーであったが、そんな父でも家族を養うことができたのは、これはもちろん母の多大なる苦労があったわけだが、父がタクシードライバーとして必要なスキルを持っていたからであった。

タクシードライバーは、第1に、道を知らなければならない。第2に、交通情報を知らなければならない。道を知っているだけでは不十分だ。お客を運ぶというのは、地図を見て最短距離を走ればいいというものではない。時間帯によって、道の混雑具合は変わる。どこかで道路工事が行われているかも知れない。

第3に、お客について知らなければならない。地域によっては流しのタクシーが禁止されているところもあるが、「本物の」タクシードライバーは流しの客で稼ぐ。空港や駅で客待ちするのは素人だ。お客がちょうどタクシーに乗りたいと思ったときにタイミングよく現れるのが、プロのタクシードライバーである。

父の時代には、タクシーという産業はドライバー個人のスキルに大きく依存していた。タクシードライバーとは、職人的職業であった。タクシー無線は存在したが、個々のドライバーは組織化されているとは言えなかった。実際、組織に属さない個人タクシーはかなりの売上をあげていた。売上を独り占めできるからだ。意欲のあるドライバーは、個人タクシーをやりたがった(父はやりたがらなかった)。

ところが、2000年くらいから様子が変わってきた。カーナビとGPSの導入である。カーナビが80年代から存在したことを考えると、2000年というのはちょっと遅い気もする。しかしこれは、あらゆる職人に共通する気質で説明できる。産業革命当時、ヨーロッパの職人たちは機械を破壊する運動を行った。現代のタクシードライバーにとって、カーナビの存在は、交通のプロである彼らのプライドを傷つけるものだったのかも知れない(ちなみに、タクシーへのAT車の導入も遅かった)。

ともあれ、タクシーに革命が起きた。職人的ドライバーの時代は終わり、カーナビとGPSによる配車システムの時代がやってきた。どんなに優秀であっても、橋の下でサボるドライバーは必要とされなくなった。

小泉政権下でタクシーの自由化が行われた際、多くの若いドライバーがタクシー業界に入ってきたそうだ。彼らがタクシーに入ってこれたのも、この新しい配車システムのおかげである。新しいドライバーには、かつてのようなスキルは必要とされない。必要なのは、安全運転とサービス精神だ。

技術者としての私は、このような技術によるイノベーションを歓迎する。昨日よりよい明日を手に入れた。これこそ技術の目指すものである。件のスマートフォンアプリは、さらに良い明日をもたらすだろう。

一方で、父の気質を受け継ぐ者として、なんとなく寂しい感じもする。今のタクシーに父の居場所はない。父はもう亡くなったが、今父のような人間がいたとして、つまり私のことだが、どのような職業に就けばよいのだろうか? 誰だって、ときには橋の下でサボりたいのではないのではないか?

私が上野で乗ったタクシーの運転手は、年配の男性だった。父と同じ時代を生きたのではないかと思う。彼も、かつては職人的スキルで稼いだのかも知れない。車には、もちろんカーナビが搭載されていたし、ギアはATで、後部座席には液晶モニタまであった。もはや、かつてのスキルは必要ない。

時代が変われば、働くものに要求されるものも変わってくる。当然である。それを寂しく感じてしまうのは、単に変化に追従できていないのかも知れない。もちろん、昔にもよいところはあったろう。しかし、我々はよりよい明日を選んだのではなかったのか。

父の時代は終わった。今は私の時代である。父の時代は父の時代として、懐かしむことはあっても、寂しく思う必要はない。私は技術者として、昨日よりよい明日のため、新たなる技術に挑戦するのみである。ちなみに、そんな私は、awkとsedでシェルスクリプトを書いている。

2012年2月8日水曜日

タンメンのうまい店

転職に伴い、藤沢から亀有に引っ越してきた。そろそろ2週間半が経つ。ようやく、亀有にも慣れてきたので、最近はタンメンのうまい店を探している。

藤沢には「千里」という中華料理屋があって、そこのタンメンがなかなか美味しかった。藤沢駅前のダイヤモンドビルの横の道を曲がったところにある。大船にもあるらしいが、そこは行ったことはない。

私は中華料理にはまったく詳しくないのだが、ラーメンの中でも、タンメンは味付けが難しい方なのではないかと思う。塩ラーメンに茹でた野菜を乗っけただけだと思ったら大間違いだ。

タンメンの味付けのポイントは、スープの塩分だと思っている。普通のラーメンは麺が主体であるから、麺と一緒に食べてちょうどよい塩加減にすればよい。ところが、タンメンの場合、野菜と麺があるので、どちらにとってもちょうどよい塩加減というものを追求しなければならない。これが難しい。

野菜にあわせてしまうと、麺を食べたときに塩分が強すぎる。逆に、麺にあわせてしまうと、野菜を食べたときになんだか水っぽい。藤沢の千里のタンメンは、このあたりが絶妙であった。

店によっては、野菜を軽く炒めて味をつけてから麺に乗っけるところもある。しかし、これだと、どうしても炒める時に使った油がスープに浮かんでしまう。私としては、タンメンはあっさりしていたほうが好みなのだ。

亀有駅前に、チェーン店の「日高屋」がある。値段も安くて遅くまで開いているので非常に便利なのだが、ここのタンメンは非常に塩分が強い。野菜を食べるのにはいいのかもしれないが、正直私の口には合わなかった。

今日は、駅前のイトーヨーカドーのそばにある「和」という中華料理屋に行ってきた。「和」というとなんだか日本料理屋みたいだが、これは「かず」と読むらしい。早速タンメンを食べてきたわけだが、野菜と一緒に食べるにはちょっと塩分が足りない印象を受けた。しかし、スープ自体は美味しくて、日高屋よりはこちらのほうが好みだ。

やっぱり千里のタンメンはやっぱり偉大である。亀有でタンメンのうまい店があったら教えてほしい。

2012年2月5日日曜日

ランチの話題は?

2月からミラクル・リナックスで働いている。まだ3日しか働いていない。この3日間は、ほとんど研修だった。来週から、本格的に業務に入るのだと思う。実は、入社して早速、非常に困難な事態に陥っている。それは、エンジニアリング上の問題ではない。ヒューマン・リレーションズに関わる問題だ。すなわち、ランチの話題である。

前職では、この問題は簡単だった。山奥の工場だったので、周りにランチをとるような店はなく、会社の手配する弁当を食べていた。また、省エネのためと称して、昼休み開始から15分ほどで消灯された。したがって、電気のついている15分間で弁当を黙々と掻き込み、午後の業務が始まるのを自席で静かに待つ(大抵の人は寝る)のである。

ミラクルでは事情が異なる。ミラクルでは、ランチとは、各自が自由に食べるものだ。弁当を持ってくる人もいれば、コンビニに買いに行く人もいる。近くのお店に食べに行く人もいる。ありがたいことに、私も、近くへ食べに行くグループに入れてもらっている。

ここで、驚くべきことに、ミラクルの人たちは話をしながらランチを食べるのである。難しい話題ではない。どこの回転寿司がおいしいとか、そういったことだ。しかし、黙々と掻き込む事に慣れている私には、これが難しい。私にとっては、「話す」か「食べる」かのいずれかであって、「話しながら食べる」は無いのだ。

さらに、困難極まるのが、このときの話題である。何を話していいのかわからない。昼休みに仕事の話を持ち出すのは、なんだか野暮ったい。じゃあ、他に何を話すかというと、とくに思いつかない。その結果、はじめは他の人の話題に相槌を打っていたつもりが、いつの間にか黙々と掻き込んでいる。そして、私だけ早く食べ終わってしまう。

外にランチを食べに行くなど、夢にまで見たサラリーマン生活だ。ミラクルでは、ランチのメニューまで会社に支配されることはないし、食べてる途中に消灯されることもない。しかし、あらゆる自由には責任が伴う。ランチの自由には、適切な話題を選択する責任が伴う。

世のサラリーマンは、この困難をどうやって乗り越えたのだろう? アドバイス求む。

2012年2月1日水曜日

三菱を去る日

1月いっぱいで三菱電機を退職した。新卒で入社してから、この4月で丸6年になるところだった。実は、退職にあたってのエントリを、同じタイトルで前々から用意していた。三菱の官僚主義に辟易していた私は、三菱のやり方について、そのエントリでこき下ろす予定だった。だが、気が変わった。

最後の出勤が終わったあと、6年間住んだ独身寮へ行った。部屋の鍵を返すためだ。まだ部屋に置いたままになっていたゴミを処分し、掃除機をかけた。そして、鍵を返すために管理人室へ行った。管理人さんは、なぜかいつも私をフルネームで呼ぶ。私は鍵を返し、簡単にお礼を述べた。管理人さんも何か言った。

瞬間、私は、目から涙が出そうになっていることに気づいた。私は慌てて管理人室をあとにし、駅へと向かった。管理人さんが何を言ったのか、正確には覚えていない。しかし、励ましの言葉だったのは確かだ。

管理人さんのその言葉は、私の頭脳で解釈される前に、私の心の中の大きく膨らんだ風船を突き刺してしまった。風船は弾け、中の物が溢れ出し、私はうかつにも涙を浮かべてしまった。風船の中身は何だったのか?

退職当日というのは意外と忙しい。あれやこれやの手続きに、机周りの整理。それが終わったら、お世話になった人への挨拶だ。しかし、上に書いたように、私は三菱が嫌で辞めるのであるから、特に誰かに挨拶して回ろうとは思っていなかった。親しい友人には事前に退職を知らせてあったし、同期入社の仲間たちにはメールで知らせた。手続きや机の整理は午前中でほとんど終わってしまったので、午後は缶ジュースなど飲みつつのんびり過ごした。

定時になって、課の人たちの前で挨拶をした。挨拶が終われば帰っていいわけだが、持ち帰らなければならない荷物が多かったので、フロアの友人にあげてしまおうと思った。形見分けというわけだ。そこで、私は「形見」を持ってフロアを歩きまわった。

フロアを見渡すと、色々な人たちの顔があった。私は、その中の実に多くの人と、この6年の間に一緒に仕事をしてきたことに気づいた。一緒にデスマーチを乗り越えた人もいたし、一緒にお酒を飲んだことがあるだけの人もいた。挨拶回りなどしないと決めていたはずなのに、私は彼らに声をかけた。彼らは気持よく送り出してくれた。

私の三菱電機での6年間は、常に不幸だった。デスマーチも経験したし、体調を崩したこともあった。そもそも、担当する仕事が退屈極まりなかった。しかし、ひとつだけ素晴らしいことに、私がどんなに苦しい時でも、私のそばには常に誰かがついていてくれた。私はひとりで置いておかれることはなかった。疎外されることもなかった。

これが風船の中身だった。駅へと向かう道で、このことに気づいた。私は、薄暗い路地へ駆け込み、静かに涙を流した。私は、再び駅へと歩き出した。途中のコンビニでコーヒーを買おうと思った。寮の近くの、馴染みのコンビニだった。コンビニの外に、大きな黒い犬がつながれていた。飼い主は買い物中なのだろう。私は、その犬の頭を撫で、ようやく落ち着きを取り戻した。

私は三菱の官僚主義を嫌った。これを書いている今も嫌いだし、そういうやり方は私には合わないと思う。しかし、私が見逃していたことに、その官僚主義の中にいる人々は皆善人だった。もしかすると、彼らも官僚主義を嫌っているかも知れない。さらに、官僚主義と日々戦っているのかも知れない。

彼らは残り、私は去った。何だか、私だけがさっさと逃げ出してしまったような気もする。退職を後悔しているわけではない。だが、すごく不思議な気持ちだ。彼らのためにも、というのは変な表現だが、次の職場ではがんばろうと思う。

ありがとう、三菱電機。この6年間は本当は幸せだったのだ。素晴らしい人達と過ごせたのだから。

2012年1月15日日曜日

『一般意志2.0』を読んだ

今年の正月休みも実家へ帰っていた。1日だけ地元の友人たちと会い、あとは本を何冊か読んで過ごした。その中に、東浩紀さんの『一般意志2.0』というのがあった。帰省前に、藤沢のジュンク堂で見かけ、Twitterで話題になっているのを思い出して購入したものだ。

この本は、GoogleやTwitterといった現代のWebテクノロジーを、ルソーやフロイトなどの過去の思想家の視点から解釈してみせる。これは、Webテクノロジーを、社会的・政治的・人間的側面から眺めてみることである。

私はプログラマだ。だから、どうしても技術的な側面ばかりに注目してしまう。もちろん、社会的側面があることはわかっている。しかし、具体的に社会にどう影響を与えたか、あるいは今後与えうるかと問われると、答えに窮してしまう。せいぜい、「10年前、20年前とはずいぶんと違った世の中になったな」としか答えられない。

この本は、ひとつのヴィジョンである。アラン・ケイのダイナブック、スティーブ・ジョブズの美しいコンピュータと同じだ。あるいは、60年前の人が空想した、原子力で動く自動車だ。未来は、この本のとおりになるかもしれないし、ならないかもしれない(多分ならない。ヴィジョンの平均値は「実現しない」である)。それでも、この本は我々の想像力を大いに喚起する。

この『一般意志2.0』だが、Amazonでのレビューは、星1つから星5つまで評価が割れている。こういう本は議論を呼ぶ。議論を呼ぶ本は面白い。私も、大いに楽しんだ。

だから、このエントリを読んでいてまだ本書を読んでいない人は、ぜひ読んでみてほしい。あなたは大いに感銘を受けるかもしれないし、東浩紀は何という大ばか者だと思うかもしれない。しかし、何も印象に残らないということはないはずだ。