『一般意志2.0』を読んだ
今年の正月休みも実家へ帰っていた。1日だけ地元の友人たちと会い、あとは本を何冊か読んで過ごした。その中に、東浩紀さんの『一般意志2.0』というのがあった。帰省前に、藤沢のジュンク堂で見かけ、Twitterで話題になっているのを思い出して購入したものだ。
この本は、GoogleやTwitterといった現代のWebテクノロジーを、ルソーやフロイトなどの過去の思想家の視点から解釈してみせる。これは、Webテクノロジーを、社会的・政治的・人間的側面から眺めてみることである。
私はプログラマだ。だから、どうしても技術的な側面ばかりに注目してしまう。もちろん、社会的側面があることはわかっている。しかし、具体的に社会にどう影響を与えたか、あるいは今後与えうるかと問われると、答えに窮してしまう。せいぜい、「10年前、20年前とはずいぶんと違った世の中になったな」としか答えられない。
この本は、ひとつのヴィジョンである。アラン・ケイのダイナブック、スティーブ・ジョブズの美しいコンピュータと同じだ。あるいは、60年前の人が空想した、原子力で動く自動車だ。未来は、この本のとおりになるかもしれないし、ならないかもしれない(多分ならない。ヴィジョンの平均値は「実現しない」である)。それでも、この本は我々の想像力を大いに喚起する。
この『一般意志2.0』だが、Amazonでのレビューは、星1つから星5つまで評価が割れている。こういう本は議論を呼ぶ。議論を呼ぶ本は面白い。私も、大いに楽しんだ。
だから、このエントリを読んでいてまだ本書を読んでいない人は、ぜひ読んでみてほしい。あなたは大いに感銘を受けるかもしれないし、東浩紀は何という大ばか者だと思うかもしれない。しかし、何も印象に残らないということはないはずだ。
この本は、GoogleやTwitterといった現代のWebテクノロジーを、ルソーやフロイトなどの過去の思想家の視点から解釈してみせる。これは、Webテクノロジーを、社会的・政治的・人間的側面から眺めてみることである。
私はプログラマだ。だから、どうしても技術的な側面ばかりに注目してしまう。もちろん、社会的側面があることはわかっている。しかし、具体的に社会にどう影響を与えたか、あるいは今後与えうるかと問われると、答えに窮してしまう。せいぜい、「10年前、20年前とはずいぶんと違った世の中になったな」としか答えられない。
この本は、ひとつのヴィジョンである。アラン・ケイのダイナブック、スティーブ・ジョブズの美しいコンピュータと同じだ。あるいは、60年前の人が空想した、原子力で動く自動車だ。未来は、この本のとおりになるかもしれないし、ならないかもしれない(多分ならない。ヴィジョンの平均値は「実現しない」である)。それでも、この本は我々の想像力を大いに喚起する。
この『一般意志2.0』だが、Amazonでのレビューは、星1つから星5つまで評価が割れている。こういう本は議論を呼ぶ。議論を呼ぶ本は面白い。私も、大いに楽しんだ。
だから、このエントリを読んでいてまだ本書を読んでいない人は、ぜひ読んでみてほしい。あなたは大いに感銘を受けるかもしれないし、東浩紀は何という大ばか者だと思うかもしれない。しかし、何も印象に残らないということはないはずだ。
ハッカーセントリックな企業文化
TechLION vol.5に行ってきた:
http://www.usptomonokai.jp/wp/?p=2068
自称プロの酔っぱらいである楽天のよしおかさんが、「ハッカーセントリックな企業文化」について語るということだった。Twitterを見ていると、すでに楽屋でビールを飲んでおられたようだった。さすがプロである。
よしおかさんはこう言う:
では、ハッカー的モノづくりと、非ハッカー的モノづくりを隔てるものは何だろうか? どうして、ハッカーのほうが素晴らしいモノづくりができるのだろうか? これは、ハッカーと非ハッカーがモノづくりに対してとる態度の違いに現れているように思う。
モノづくりにおいて、リスクを回避する最も簡単な方法は、モノを作らないことだ。もちろん、モノがなければシステムは作れないので、実際にはコンポーネントを買ってくることになる。これは、実際に私の現場でも行われていて、COTS(Commercial Off The Shelf)というカッコイイ名前で呼ばれている。
COTSを利用するメリットは、そのコンポーネントに関するあらゆるリスクをベンダーに転嫁できる(と非ハッカーは考える)ことだ。COTSのバグが見つかったら、ベンダーへ怒りの電話を入れればよい。彼らが徹夜で直してくれるはずだ(と非ハッカーは考える)。
ハッカーは、既存のコンポーネントを組み合わせてシステムを作る事自体には反対しない。むしろ、そのようなモノづくりは「巨人の方に乗る」ものとして賞賛されさえする。実際、ハッカーはオープンソースのコンポーネントをよく利用する。問題は、そのコンポーネントに対する「態度」だ。
例えば、あるコンポーネントでバグが見つかったときに、「そのコンポーネントはCOTSなので私には関係ありません」と言って責任逃れをするのは非ハッカー的態度だ。このような言い訳はハッカーとしてのプライドを大きく傷つけるものだし、こういう言い訳をする人間はハッカーではないと他のハッカーから見なされる。
ハッカーがオープンソースを好む理由もここにある。ソースがあって自分でいじくり回すことができるからこそ、すべての責任を取ることができる。すべてをコントロールすることができる。責任逃れはできないのだ。
ここからわかることは、ハッカーは自分の作った製品やサービスに対して非常に責任感が強いということだ。これは、ハッカーの一見自由奔放なイメージとはかなり違う。実は、非ハッカーのほうが責任感がない。非ハッカーは、いかにして責任を取らずに済むかを考える。
だから、もし本当に素晴らしいモノづくりがしたいのなら、ハッカーの態度を真似るべきだ。次に何か責任逃れをしようと思うときがあったら、グッとこらえて「自分の責任」にしてしまおう。自分でデバッグに乗り出そう。そして、いつでもそうできるようにオープンソースを採用しよう。
でも、どうしてもハッカーセントリックな企業文化が自分の会社に根付かないのなら、他のハッカーを探して別の会社に移るというのも手かもしれない。世の中には、ハッカーはたくさんいるはずだ。
http://www.usptomonokai.jp/wp/?p=2068
自称プロの酔っぱらいである楽天のよしおかさんが、「ハッカーセントリックな企業文化」について語るということだった。Twitterを見ていると、すでに楽屋でビールを飲んでおられたようだった。さすがプロである。
よしおかさんはこう言う:
良いソフトウェア、良いシステムを作りたいなら、最高のプログラマを雇うべき。見も蓋もない話なんですよ。ここで言う「最高のプログラマ」というのが、ハッカーということなのだろう。
では、ハッカー的モノづくりと、非ハッカー的モノづくりを隔てるものは何だろうか? どうして、ハッカーのほうが素晴らしいモノづくりができるのだろうか? これは、ハッカーと非ハッカーがモノづくりに対してとる態度の違いに現れているように思う。
モノづくりにおいて、リスクを回避する最も簡単な方法は、モノを作らないことだ。もちろん、モノがなければシステムは作れないので、実際にはコンポーネントを買ってくることになる。これは、実際に私の現場でも行われていて、COTS(Commercial Off The Shelf)というカッコイイ名前で呼ばれている。
COTSを利用するメリットは、そのコンポーネントに関するあらゆるリスクをベンダーに転嫁できる(と非ハッカーは考える)ことだ。COTSのバグが見つかったら、ベンダーへ怒りの電話を入れればよい。彼らが徹夜で直してくれるはずだ(と非ハッカーは考える)。
ハッカーは、既存のコンポーネントを組み合わせてシステムを作る事自体には反対しない。むしろ、そのようなモノづくりは「巨人の方に乗る」ものとして賞賛されさえする。実際、ハッカーはオープンソースのコンポーネントをよく利用する。問題は、そのコンポーネントに対する「態度」だ。
例えば、あるコンポーネントでバグが見つかったときに、「そのコンポーネントはCOTSなので私には関係ありません」と言って責任逃れをするのは非ハッカー的態度だ。このような言い訳はハッカーとしてのプライドを大きく傷つけるものだし、こういう言い訳をする人間はハッカーではないと他のハッカーから見なされる。
ハッカーがオープンソースを好む理由もここにある。ソースがあって自分でいじくり回すことができるからこそ、すべての責任を取ることができる。すべてをコントロールすることができる。責任逃れはできないのだ。
ここからわかることは、ハッカーは自分の作った製品やサービスに対して非常に責任感が強いということだ。これは、ハッカーの一見自由奔放なイメージとはかなり違う。実は、非ハッカーのほうが責任感がない。非ハッカーは、いかにして責任を取らずに済むかを考える。
だから、もし本当に素晴らしいモノづくりがしたいのなら、ハッカーの態度を真似るべきだ。次に何か責任逃れをしようと思うときがあったら、グッとこらえて「自分の責任」にしてしまおう。自分でデバッグに乗り出そう。そして、いつでもそうできるようにオープンソースを採用しよう。
でも、どうしてもハッカーセントリックな企業文化が自分の会社に根付かないのなら、他のハッカーを探して別の会社に移るというのも手かもしれない。世の中には、ハッカーはたくさんいるはずだ。
xv6を読む:メモリアロケータ
実行時に、プロセスやカーネルにページを割り当てるため、xv6はメモリアロケータを使用する。メモリアロケータは、未使用のページのフリーリストを管理している。カーネルからの要求に従って、フリーリストからページを割り当てる。
カーネルの起動処理で、フリーリストを未使用のページで満たさなければならない。ここで、鶏と卵の問題が生じる。すなわち、フリーリストの初期化処理を行うためにはカーネルに物理メモリが割り当てられていなければならず、カーネルに物理メモリを割り当てるためにはメモリアロケータが動作しなければならない。
xv6では、フリーリストの初期化を二段階で行うことで、これを解決している。main関数から呼び出されるkinit1関数と、kinit2関数がそれである。関数呼び出しの関係を以下に示す:
main
:
+->kinit1
| +->initlock
| +->freerange
| +->kfree
+->kvmalloc(前回説明。kinit1で初期化したページを使用する)
:
+->kinit2
| +->freerange
| +->kfree
:
ここで、xv6のアドレス空間について少し説明する。仮想アドレス空間を左に、物理アドレス空間を右に示す:
4G->+----+
/| |\
Device | |
\| |
0xFE000000->|----|
/| |
| |
Free Memory | | Kernel Space
| |
\| |
end->| | +----+<-4G
| | | |\
+0x100000->| | | | Device
KERNBASE->| | | |/
/|----|/ |----|<-PHYSTOP
| | | |\
| | | |
| | | |
| | | | Extended Memory
| | | |
User Space | | | |
| | | |
| | |----|/
| | | |<-0x100000
| | | |<-I/O Space
| | | |<-640k
\| | | |<-Base Memory
0->+----+ +----+
Vertual Physical
仮想アドレス空間では、カーネルは上位2GBにマップされる(KERNBASE=2GBに定義されている)。したがって、ユーザプロセスは2GBまでのアドレス空間を利用できる。カーネルのテキストとデータは、仮想アドレスでKERNBASE + 0x100000〜endの間にロードされる。これは、物理アドレス0x100000〜end - KERNBASEにマップされている。
物理アドレス空間で、カーネルの後ろ、すなわちend - KERNBASEからPHYSTOPまでの空間をページとして利用する。メモリアロケータは、この部分をフリーリストとして管理する。PHYSTOPは240MBに定義されている。
xv6はブート時のページテーブルとして、entrypgdirを持っている。entrypgdirは、仮想アドレスの0〜4MBを実アドレスの0〜4MBへ、仮想アドレスのKERNBASE〜KERNBASE + 4MBを実アドレスの0〜4MBへマップするよう設定されている。前回説明したkvmallocでカーネルページテーブルが作成されるまでは、カーネルはこのページテーブルを用いてアドレス変換を行う。すなわち、xv6は、カーネルのサイズは少なくとも4MBより小さいものと仮定している。
さて、kinit1では、end〜4MBまでの物理アドレス空間を4KBのページに分割し、フリーリストに登録する。この処理を行うのが、freerange関数とkfree関数である。kinit1は、main関数内で以下のように呼び出されている:
kinit1(end, P2V(4*1024*1024));
ここで、P2Vマクロは物理アドレスを仮想アドレスに変換するマクロである。このマクロは、単に引数 + KERNBASEに展開されるだけである。
freerange関数は、以下の処理を行う:
以上で、フリーリストの初期化の第1段階が完了した。これで、4MBまでの範囲で、メモリアロケータはページを割り当てることができる。
フリーリストの初期化の第2段階であるkinit2関数は、main関数のかなり後のほうで、以下のように呼び出されている:
kinit2(P2V(4*1024*1024), P2V(PHYSTOP));
4MBからPHYSTOPまでの物理アドレス空間を、フリーリストに登録する。以上でフリーリストの初期化はすべて完了し、メモリアロケータを使用することができる。
カーネルの起動処理で、フリーリストを未使用のページで満たさなければならない。ここで、鶏と卵の問題が生じる。すなわち、フリーリストの初期化処理を行うためにはカーネルに物理メモリが割り当てられていなければならず、カーネルに物理メモリを割り当てるためにはメモリアロケータが動作しなければならない。
xv6では、フリーリストの初期化を二段階で行うことで、これを解決している。main関数から呼び出されるkinit1関数と、kinit2関数がそれである。関数呼び出しの関係を以下に示す:
main
:
+->kinit1
| +->initlock
| +->freerange
| +->kfree
+->kvmalloc(前回説明。kinit1で初期化したページを使用する)
:
+->kinit2
| +->freerange
| +->kfree
:
ここで、xv6のアドレス空間について少し説明する。仮想アドレス空間を左に、物理アドレス空間を右に示す:
4G->+----+
/| |\
Device | |
\| |
0xFE000000->|----|
/| |
| |
Free Memory | | Kernel Space
| |
\| |
end->| | +----+<-4G
| | | |\
+0x100000->| | | | Device
KERNBASE->| | | |/
/|----|/ |----|<-PHYSTOP
| | | |\
| | | |
| | | |
| | | | Extended Memory
| | | |
User Space | | | |
| | | |
| | |----|/
| | | |<-0x100000
| | | |<-I/O Space
| | | |<-640k
\| | | |<-Base Memory
0->+----+ +----+
Vertual Physical
仮想アドレス空間では、カーネルは上位2GBにマップされる(KERNBASE=2GBに定義されている)。したがって、ユーザプロセスは2GBまでのアドレス空間を利用できる。カーネルのテキストとデータは、仮想アドレスでKERNBASE + 0x100000〜endの間にロードされる。これは、物理アドレス0x100000〜end - KERNBASEにマップされている。
物理アドレス空間で、カーネルの後ろ、すなわちend - KERNBASEからPHYSTOPまでの空間をページとして利用する。メモリアロケータは、この部分をフリーリストとして管理する。PHYSTOPは240MBに定義されている。
xv6はブート時のページテーブルとして、entrypgdirを持っている。entrypgdirは、仮想アドレスの0〜4MBを実アドレスの0〜4MBへ、仮想アドレスのKERNBASE〜KERNBASE + 4MBを実アドレスの0〜4MBへマップするよう設定されている。前回説明したkvmallocでカーネルページテーブルが作成されるまでは、カーネルはこのページテーブルを用いてアドレス変換を行う。すなわち、xv6は、カーネルのサイズは少なくとも4MBより小さいものと仮定している。
さて、kinit1では、end〜4MBまでの物理アドレス空間を4KBのページに分割し、フリーリストに登録する。この処理を行うのが、freerange関数とkfree関数である。kinit1は、main関数内で以下のように呼び出されている:
kinit1(end, P2V(4*1024*1024));
ここで、P2Vマクロは物理アドレスを仮想アドレスに変換するマクロである。このマクロは、単に引数 + KERNBASEに展開されるだけである。
freerange関数は、以下の処理を行う:
- 引数vstartとvendで渡された仮想アドレス空間(範囲)についてPGSIZE(4KB)ごとにkfree関数を呼び出す
- 引数vで渡された仮想アドレスが以下の条件にない場合、パニックする:
- ページ境界に合っていない
- endより小さい
- v2p(v)がPHYSTOP以上である
- vから1ページ分、メモリ領域を1で埋める
- vをフリーリストにつなぐ
以上で、フリーリストの初期化の第1段階が完了した。これで、4MBまでの範囲で、メモリアロケータはページを割り当てることができる。
フリーリストの初期化の第2段階であるkinit2関数は、main関数のかなり後のほうで、以下のように呼び出されている:
kinit2(P2V(4*1024*1024), P2V(PHYSTOP));
4MBからPHYSTOPまでの物理アドレス空間を、フリーリストに登録する。以上でフリーリストの初期化はすべて完了し、メモリアロケータを使用することができる。
xv6を読む:アドレススペースの作成
xv6というOSがある。これは、UNIX V6をベースに(?)MITで開発された教育用のOSである。x86アーキテクチャで動作する。MITなどのアメリカの大学が凄いと思うのは、授業の教材や講義の録画をネットで公開してしまうことである。xv6もテキストとソースコードが公開されている:
http://pdos.csail.mit.edu/6.828/2011/xv6.html
xv6のテキストは、解説とソースコードがLions' Commentaryのように2分冊になっている。それぞれ100ページ以下である。テキストを読み進めてみると、xv6は、x86アーキテクチャとその応用であるOSを勉強するのに格好の教材になりそうだ。
そこで、勉強の成果を忘れないようにメモしておくため、そして、もしかしたら私のメモが役に立つという人もいるかもしれないので、このブログでまとめていくことにする。もちろん、ツッコミは大歓迎である。今回は、アドレススペースの作成である。
OSのブート後、main関数が呼ばれる。最初に、main関数では、アドレススペースの作成が行われる。ここでは、仮想アドレスから物理アドレスへマップするページテーブルを作成する。x86での仮想アドレスは3つの部分を持つ。以下に、mmu.hから引用する:
main
:
+->kvmalloc
| +->setupkvm
| | +->mappages
| | +->walkpgdir
| +->switchkvm
:
setupkvm関数では次の処理を行う:
mappages関数は次の処理を行う:
http://pdos.csail.mit.edu/6.828/2011/xv6.html
xv6のテキストは、解説とソースコードがLions' Commentaryのように2分冊になっている。それぞれ100ページ以下である。テキストを読み進めてみると、xv6は、x86アーキテクチャとその応用であるOSを勉強するのに格好の教材になりそうだ。
そこで、勉強の成果を忘れないようにメモしておくため、そして、もしかしたら私のメモが役に立つという人もいるかもしれないので、このブログでまとめていくことにする。もちろん、ツッコミは大歓迎である。今回は、アドレススペースの作成である。
OSのブート後、main関数が呼ばれる。最初に、main関数では、アドレススペースの作成が行われる。ここでは、仮想アドレスから物理アドレスへマップするページテーブルを作成する。x86での仮想アドレスは3つの部分を持つ。以下に、mmu.hから引用する:
+--------10------+-------10-------+---------12----------+
| Page Directory | Page Table | Offset within Page |
| Index | Index | |
+----------------+----------------+---------------------+
\--- PDX(va) --/ \--- PTX(va) --/
仮想アドレスは、それぞれ10ビットのページディレクトリインデックスとページテーブルインデックス、そして12ビットのページ内オフセットからなる。それぞれの意味を以下に示す:
アドレススペースの作成は、main関数からのkvmalloc関数の呼び出しで行う。setupkvm関数でページディレクトリを作成し、それをswitchkvm関数でCR3レジスタに設定する。関数の呼び出し関係を以下に示す:
main
:
+->kvmalloc
| +->setupkvm
| | +->mappages
| | +->walkpgdir
| +->switchkvm
:
setupkvm関数では次の処理を行う:
- ページディレクトリ用に1ページ(4KB)を割り当てる
- 次の各カーネル領域について、mappages関数を呼び出すことで、ページテーブルを作成し、ページディレクトリエントリに書きこむ:
- 作成したページテーブルを、1のページディレクトリに書き込み、返す
ここで、各カーネル領域は任意の大きさでよい。mappages関数に領域のサイズを渡すことで、必要な分だけページテーブルが割り当てられる。
- walkpgdir関数を呼び出し、引数で渡された仮想アドレスに対応する、ページテーブルエントリを取得する
- エントリにマップする物理アドレス、アクセス権、存在ビットを書きこむ
- 領域全体をマップし終わるまで1から繰り返す
walkpgdir関数は次の処理を行う:
- ページディレクトリから、ページディレクトリインデックスに該当するエントリを引く
- 1で引いたエントリの存在フラグが立っていれば、ページテーブルを取得する(エントリに記述されているアドレスに存在するはず)
- 2でない場合、関数の引数でallocフラグに真が渡された場合(この場合はそうである)、新たに1ページ取得し、これをページテーブルとする。このページテーブルの物理アドレス、存在ビット、書き込み可ビット、ユーザ空間ビットを、1で取得したエントリに書きこむ
- 2または3で取得したページテーブルから、ページテーブルインデックスに該当するエントリのアドレスを返す
以上で、アドレススペースを作成した。ただし、ここで作成したのはページテーブルまでで、物理ページの割り当ては行っていない。次回は、テキストに従って、物理メモリの割り当てに進みたい。
スキルかセンスか?
ちょっと前の話になるのだが、「デザイナ&エンジニア交流会」というのに参加してきた:
http://design1.chu.jp/setucocms-pjt/?p=1770
SetsucoCMSというオープンソースのCMSがあって、それを作っている子たちによく遊んでもらっている。今回、彼らが勉強会をやるということで、私も誘われた。デザイナやエンジニアと言っても、ここでは「Web」デザイナ、「Web」エンジニアである。Webにとんと疎い私としては、そこはまったくの異文化圏である。そこでの交流は、なかなか刺激的であった。
中でも非常に新鮮だったは、普段接することのないデザイナと話す機会を持てたことだ。そして、彼らと話してわかったことには、どうやら彼らは、デザインがセンスだとエンジニアに思われていることに強い不満を持っているらしい。
確かに、「デザイン」というと、何だか芸術的なものを連想してしまう。実際、私もデザインはセンス、つまり才能によるところが大きいのだろうと何となく思っていた。しかし、デザイナの彼らに言わせれば、デザインには理論があり、練習によって習得できるものであって、したがってデザインはスキルであるという。
ここでちょっと野球を考えてみる。長嶋茂雄さんといえば往年のスター選手だ。あるとき、ホームランの打ち方を聞かれた長嶋さんは、「ボールが来たら、よく見て打て」と大真面目に答えたそうだ。長嶋さんにとっては、それがホームランの理論であり、練習によって習得したということだろう。
デザイナが、デザインがセンスだというエンジニアの思い込みに不満を持つということは、その裏返しとして、彼らは、エンジニアリングはスキルだと思っているのかもしれない。しかし、この思い込みが必ずしも正しくないことは、プログラマなら誰もが知っている。
確かに、プログラミングには理論が存在する。ソフトウェア工学と呼ばれているものがそれだ。プログラミングの外にいる人の目には、プログラミングとはソフトウェア工学の実践であって、練習によって習得できるものと映るかもしれない。しかし、そうだとしたら、どうしてこんなにも多くのソフトウェア開発プロジェクトが失敗するのだろう? プログラマはみんなあまりにも怠惰過ぎて、練習を怠っているということだろうか?
私が思うに、プログラミングは野球みたいなものだ。ソフトウェア工学は長嶋さんのホームラン理論に似ている。この理論は間違ってはいないが、本当にホームランを打とうとするなら、理論以外の何かが必要だ。そして、重要なことは、あの長嶋さんでさえ、毎回ホームランを打てたわけではないということだ。
交流会の後の懇親会で、私はデザイナの一人に、「エンジニアリングはスキルですか?」と聞かれた。私は、「ある部分はスキルでしょう。しかし、センスが必要な部分もたくさんありますよ」と答えた。この時は酔っ払っていたのでうまく説明できなかったが、私が言いたかったのは、つまるところエンジニアリングとはホームラン理論だということだ。
だから、デザイナは、自分たちがやっていることがスキルかセンスかなんて悩む必要はないと思う。たぶん、デザインもホームラン理論だ。部外者から見るとセンスに見えるかもしれないが、実際にはスキルとセンスの混合物なのだろう。
最後に、今回の交流会を主催し、そして私を呼んでくれたSetsucoCMSのみんなにお礼を言おう。彼らはとても若く、パワフルで、情熱に溢れている。そして何より、彼らはものづくりに対してとても真面目である。彼らの今後の活躍には私は大きく期待するし、また、今後もこういった交流会に呼んでほしいと思う。
http://design1.chu.jp/setucocms-pjt/?p=1770
SetsucoCMSというオープンソースのCMSがあって、それを作っている子たちによく遊んでもらっている。今回、彼らが勉強会をやるということで、私も誘われた。デザイナやエンジニアと言っても、ここでは「Web」デザイナ、「Web」エンジニアである。Webにとんと疎い私としては、そこはまったくの異文化圏である。そこでの交流は、なかなか刺激的であった。
中でも非常に新鮮だったは、普段接することのないデザイナと話す機会を持てたことだ。そして、彼らと話してわかったことには、どうやら彼らは、デザインがセンスだとエンジニアに思われていることに強い不満を持っているらしい。
確かに、「デザイン」というと、何だか芸術的なものを連想してしまう。実際、私もデザインはセンス、つまり才能によるところが大きいのだろうと何となく思っていた。しかし、デザイナの彼らに言わせれば、デザインには理論があり、練習によって習得できるものであって、したがってデザインはスキルであるという。
ここでちょっと野球を考えてみる。長嶋茂雄さんといえば往年のスター選手だ。あるとき、ホームランの打ち方を聞かれた長嶋さんは、「ボールが来たら、よく見て打て」と大真面目に答えたそうだ。長嶋さんにとっては、それがホームランの理論であり、練習によって習得したということだろう。
デザイナが、デザインがセンスだというエンジニアの思い込みに不満を持つということは、その裏返しとして、彼らは、エンジニアリングはスキルだと思っているのかもしれない。しかし、この思い込みが必ずしも正しくないことは、プログラマなら誰もが知っている。
確かに、プログラミングには理論が存在する。ソフトウェア工学と呼ばれているものがそれだ。プログラミングの外にいる人の目には、プログラミングとはソフトウェア工学の実践であって、練習によって習得できるものと映るかもしれない。しかし、そうだとしたら、どうしてこんなにも多くのソフトウェア開発プロジェクトが失敗するのだろう? プログラマはみんなあまりにも怠惰過ぎて、練習を怠っているということだろうか?
私が思うに、プログラミングは野球みたいなものだ。ソフトウェア工学は長嶋さんのホームラン理論に似ている。この理論は間違ってはいないが、本当にホームランを打とうとするなら、理論以外の何かが必要だ。そして、重要なことは、あの長嶋さんでさえ、毎回ホームランを打てたわけではないということだ。
交流会の後の懇親会で、私はデザイナの一人に、「エンジニアリングはスキルですか?」と聞かれた。私は、「ある部分はスキルでしょう。しかし、センスが必要な部分もたくさんありますよ」と答えた。この時は酔っ払っていたのでうまく説明できなかったが、私が言いたかったのは、つまるところエンジニアリングとはホームラン理論だということだ。
だから、デザイナは、自分たちがやっていることがスキルかセンスかなんて悩む必要はないと思う。たぶん、デザインもホームラン理論だ。部外者から見るとセンスに見えるかもしれないが、実際にはスキルとセンスの混合物なのだろう。
最後に、今回の交流会を主催し、そして私を呼んでくれたSetsucoCMSのみんなにお礼を言おう。彼らはとても若く、パワフルで、情熱に溢れている。そして何より、彼らはものづくりに対してとても真面目である。彼らの今後の活躍には私は大きく期待するし、また、今後もこういった交流会に呼んでほしいと思う。
電子書籍は安い?
Amazon Kindleの日本語版が年内登場とか言っている。日本でも書店や出版社などが独自に電子書籍を出していたが、各社ばらばらで足並みが揃っていないようで、私は買い控えていた。Kindle DXですでに英語版を利用している身としては、今回のAmazonの発表は非常に嬉しい。もっとも、私のKindle DXで日本語書籍が読めるのかという心配はある。400ドルもしたのに…。
よく、電子書籍の値段はいくらが適当かという話題を見かける。書店や出版社も、適正な価格付けに困っているのかもしれない。消費者にとっては、中間に書店や卸業者が入らない分、電子書籍は紙の書籍に比べるとコストが安いように思える。したがって、当然、電子書籍の値段は紙の書籍より安くしろということになる。実際、Amazon.comのKindle書籍は、紙の書籍に比べて圧倒的に安い。
しかし、ちょっと待ってほしい。モノの値段というのは、はじめに利益ありきで決まるものではない。物の値段は、「消費者がいくらなら買うか」によって決まるものではないのか? 消費者が1万円出してでもほしいと思うものなら、たとえ原価が100円であっても1万円で売っていいはずだ。だから、いったん中間の書店や卸業者のことは忘れて、いくらなら電子書籍を買うか考えてみよう。
私が英語版Kindleを使っていて、これは便利だと感じた機能はざっと以下のようなものだ:
まず、1についてだが、これは紙の書籍でも可能だ。媒体が何であろうともコンテンツは同じはずだからだ。また、2と3も、従来から紙の書籍で我々がやってきたことだ。ノートを取るときに本に直接書きこむのが嫌な人は、ポストイットを使うとよい。4はブックマークで代用できる。
では、5と6はどうか? 私のKindle DXは9.7インチある。重量もそこそこで、通勤電車でつり革に掴まって読書するには大きすぎる。そこで、私は電車内ではスマートフォンで読んでいる。会社に着けばPCがあるので、PC版を使うことができる。そして、素晴らしいことに、これらはすべて同期されているのである。実際、私は、通勤時にKindleで読書をするのに、ポケットにスマートフォンを入れているだけでKindle端末や、それを入れるかばんは持ち歩かない。
これが紙の書籍だったらどうか? 文庫や新書であれば電車の中でも読むことはできる。しかし、分厚い技術書の場合、つり革に掴まったまま読むのは難しいだろう。もちろん、紙の本は会社でも読むことができるが、家で続きを読みたいのなら、持って帰らなければならない。そして、本を持ち運ぶためにはかばんが必要だ。したがって、紙の本は電子書籍より不便そうだ。
次に7だ。検索といえば、ディジタルのお家芸である。もちろんKindleでも可能であるが、全文検索しているのか、それとも事前に決めてあるキーワードのみ検索しているのかはちょっとわからない。もっとも、全文検索したとして、どれだけ意味のある結果が得られるかは疑わしいが。
一方、紙の書籍の方は、後ろに付いている索引が検索に相当するだろう。索引は、ご存知の通り、事前に決めてあるキーワードのみが記されている。ただし、最近の本はそうでもないようだが、稀に、索引に記されているキーワードの少ない、あるいはそもそも索引自体のない書籍が存在する。技術書でこれをやられると非常に困る。というわけで、検索についても、電子書籍に歩があると言っていいだろう。
次に、8と9である。これは、言うまでもなく電子書籍の勝利だろう。技術書や技術系の教科書は分厚いものが多い。特に洋書はそうである。アメリカの学生などは、あんなに分厚い教科書を毎日学校まで持っていくのだろうか? そして、分厚いということは、当然保管場所に困るということなのだ。その点、電子書籍であれば保管場所はまったく問題にならない。そもそも、データをローカルに保管する必要すらない。Kindleの場合だと、ノートやブックマークも含めて、すべてAmazonのサーバ上に管理されている。
最後に、10だ。誤植などは本にはつきものである。これは、紙だろうと電子だろうと変わらない。紙の場合は、誤植があった場合、正誤表をWebサイトなどで公開することになる。この正誤表の問題点は、公開されたことがわからないことだ。何となく出版社のサイトを見ていて正誤表に気づくことがある。
一方、電子書籍であれば、アップデートをネット経由で配布すればよい。誤植が発見された時点で、逐次配布することができる。実際、私の持っているKindle書籍の1冊は、端末付属の3G回線を介してアップデートされた。事前にアップデートに関するメールもきたし、大変満足している。したがって、この点も電子書籍のほうが便利だ。
さて、こうして電子書籍と紙の書籍を比べてみると、電子書籍のほうが消費者にメリットがありそうだ。もちろん、紙の書籍にも良い点があるということは私も認識している。例えば、芸術的な装幀や、芸術的な装幀や…うーん…そうだ、乱暴な扱いにも強い!
だが、一般的な読書であれば、少なくとも私は電子書籍を好むだろう。だから、私は電子書籍を安くしろとは言わない。紙の書籍と同じか、あるいはちょっと高くても電子書籍を選ぶ。実際、電子書籍には、サーバの運用や、原価より低く設定された端末本体の値段(カミソリ本体とカミソリの刃の話と同じだ)など、紙の書籍にはなかったコストもかかっているのだ。
電子書籍の値段を考えるとき、これらのメリットを中心に考えれば、自ずと適当な値段がわかるだろう(上記のように、私の答えは、紙と同等かちょっと高くてもよい)。書店や出版社の立場で考えると、電子書籍でできることを更に増やせば、これはつまりサービスを充実させることであるから、値段を上げてもよいだろう。
もう何十年も前から、これからは電子書籍の時代だと言われてきたが、ようやくその時代がやってきた。電子書籍を中心に、本のあり方というのも変わってくるのかもしれない。なお、出版社や書店が、どうしても電子書籍を紙の書籍より安くするというのなら、私はもちろん大歓迎である。
よく、電子書籍の値段はいくらが適当かという話題を見かける。書店や出版社も、適正な価格付けに困っているのかもしれない。消費者にとっては、中間に書店や卸業者が入らない分、電子書籍は紙の書籍に比べるとコストが安いように思える。したがって、当然、電子書籍の値段は紙の書籍より安くしろということになる。実際、Amazon.comのKindle書籍は、紙の書籍に比べて圧倒的に安い。
しかし、ちょっと待ってほしい。モノの値段というのは、はじめに利益ありきで決まるものではない。物の値段は、「消費者がいくらなら買うか」によって決まるものではないのか? 消費者が1万円出してでもほしいと思うものなら、たとえ原価が100円であっても1万円で売っていいはずだ。だから、いったん中間の書店や卸業者のことは忘れて、いくらなら電子書籍を買うか考えてみよう。
私が英語版Kindleを使っていて、これは便利だと感じた機能はざっと以下のようなものだ:
- (当然ながら)普通に読書できる
- ブックマークできる
- ノートをかける
- わざわざブックマークしなくても直前にどこを読んでいたか記憶しており、次に端末を起動したとき、そのページを開いてくれる
- Kindle端末以外にも、PC、Webブラウザ、スマートフォンなどで読める
- 上記端末等で、書籍、ブックマーク、ノート、直前に読んだページを同期できる
- 検索ができる
- 1000ページを超えるような技術書でも楽に持ち歩くことができる
- 保管に場所をとらない
- 誤植等があった場合、本のアップデートができる
まず、1についてだが、これは紙の書籍でも可能だ。媒体が何であろうともコンテンツは同じはずだからだ。また、2と3も、従来から紙の書籍で我々がやってきたことだ。ノートを取るときに本に直接書きこむのが嫌な人は、ポストイットを使うとよい。4はブックマークで代用できる。
では、5と6はどうか? 私のKindle DXは9.7インチある。重量もそこそこで、通勤電車でつり革に掴まって読書するには大きすぎる。そこで、私は電車内ではスマートフォンで読んでいる。会社に着けばPCがあるので、PC版を使うことができる。そして、素晴らしいことに、これらはすべて同期されているのである。実際、私は、通勤時にKindleで読書をするのに、ポケットにスマートフォンを入れているだけでKindle端末や、それを入れるかばんは持ち歩かない。
これが紙の書籍だったらどうか? 文庫や新書であれば電車の中でも読むことはできる。しかし、分厚い技術書の場合、つり革に掴まったまま読むのは難しいだろう。もちろん、紙の本は会社でも読むことができるが、家で続きを読みたいのなら、持って帰らなければならない。そして、本を持ち運ぶためにはかばんが必要だ。したがって、紙の本は電子書籍より不便そうだ。
次に7だ。検索といえば、ディジタルのお家芸である。もちろんKindleでも可能であるが、全文検索しているのか、それとも事前に決めてあるキーワードのみ検索しているのかはちょっとわからない。もっとも、全文検索したとして、どれだけ意味のある結果が得られるかは疑わしいが。
一方、紙の書籍の方は、後ろに付いている索引が検索に相当するだろう。索引は、ご存知の通り、事前に決めてあるキーワードのみが記されている。ただし、最近の本はそうでもないようだが、稀に、索引に記されているキーワードの少ない、あるいはそもそも索引自体のない書籍が存在する。技術書でこれをやられると非常に困る。というわけで、検索についても、電子書籍に歩があると言っていいだろう。
次に、8と9である。これは、言うまでもなく電子書籍の勝利だろう。技術書や技術系の教科書は分厚いものが多い。特に洋書はそうである。アメリカの学生などは、あんなに分厚い教科書を毎日学校まで持っていくのだろうか? そして、分厚いということは、当然保管場所に困るということなのだ。その点、電子書籍であれば保管場所はまったく問題にならない。そもそも、データをローカルに保管する必要すらない。Kindleの場合だと、ノートやブックマークも含めて、すべてAmazonのサーバ上に管理されている。
最後に、10だ。誤植などは本にはつきものである。これは、紙だろうと電子だろうと変わらない。紙の場合は、誤植があった場合、正誤表をWebサイトなどで公開することになる。この正誤表の問題点は、公開されたことがわからないことだ。何となく出版社のサイトを見ていて正誤表に気づくことがある。
一方、電子書籍であれば、アップデートをネット経由で配布すればよい。誤植が発見された時点で、逐次配布することができる。実際、私の持っているKindle書籍の1冊は、端末付属の3G回線を介してアップデートされた。事前にアップデートに関するメールもきたし、大変満足している。したがって、この点も電子書籍のほうが便利だ。
さて、こうして電子書籍と紙の書籍を比べてみると、電子書籍のほうが消費者にメリットがありそうだ。もちろん、紙の書籍にも良い点があるということは私も認識している。例えば、芸術的な装幀や、芸術的な装幀や…うーん…そうだ、乱暴な扱いにも強い!
だが、一般的な読書であれば、少なくとも私は電子書籍を好むだろう。だから、私は電子書籍を安くしろとは言わない。紙の書籍と同じか、あるいはちょっと高くても電子書籍を選ぶ。実際、電子書籍には、サーバの運用や、原価より低く設定された端末本体の値段(カミソリ本体とカミソリの刃の話と同じだ)など、紙の書籍にはなかったコストもかかっているのだ。
電子書籍の値段を考えるとき、これらのメリットを中心に考えれば、自ずと適当な値段がわかるだろう(上記のように、私の答えは、紙と同等かちょっと高くてもよい)。書店や出版社の立場で考えると、電子書籍でできることを更に増やせば、これはつまりサービスを充実させることであるから、値段を上げてもよいだろう。
もう何十年も前から、これからは電子書籍の時代だと言われてきたが、ようやくその時代がやってきた。電子書籍を中心に、本のあり方というのも変わってくるのかもしれない。なお、出版社や書店が、どうしても電子書籍を紙の書籍より安くするというのなら、私はもちろん大歓迎である。
いかに作るか、何を作るか
今日は朝から、Twitterで、SIerがどうのこうのというツイートが流れている。あるあるネタで、Excelでバージョン管理とか、私も大いにあるあるである。何だかSIerが皆に嫌われているようにも見えるが、SIerが好きで頑張っている人もたくさんいるはず。一部の人が、こうして自虐ネタをやっているのだろう。
彼らが自虐ネタに走るのは、SIerが彼らの思い描いていたエンジニアリングの世界とは異なるからではないだろうか? つまり、彼らはSIerが自分に「合ってない」と感じている。実は、私もその口だ。では、エンジニアリングの世界に何が起きているのだろうか?
少なくとも、日本の大学の情報工学や計算機科学の学科で教えているエンジニアリングは、SIerがエンジニアリングと称しているものとは全く違う。大学では、エンジニアリングとはコードを書くことだ。一方、SIerでは、エンジニアリングとは書類(主に仕様書)を書くことを指す。大学では、エンジニアリングの道具はエディタとコンパイラだが、SIerではWordとExcelが道具だ(優秀なSIerはMicrosoft Projectも使う)。
大学で教えていることとSIerでやっていることの違いは、エンジニアリングに対するアプローチの違いである。すなわち、「いかに作るか」と「何を作るか」の違いである。私が学生時代、ソフトウェア工学の世界ではパターンがはやっていた。私も授業でデザインパターンを習ったが、これはまさに「いかに作るか」のレシピである。一方、私が会社に入って上司に教えられた「顧客の要求を云々」とは、「何を作るか」を考えるということだ。
「いかに作るか」と「何を作るか」の境界は曖昧だ。おそらく、単純なものほどこの境界が曖昧になり、複雑なものほど境界がはっきりしてくるのではないか。例えば、ハサミを作るとして、「いかに作るか」と「何を作るか」という視点はほとんど同じものを指す。しかし、スペースシャトルを作るとなれば、これらの境界はかなりはっきりするだろう。
実は、この「何を作るか」「いかに作るか」という着想は、私が考えたものではない。JAISTの日比野先生の言葉である。私は、LispマシンELISの設計者でもある先生と知り合う機会を得た。あるイベントの打ち上げの時、先生はこのような趣旨のことを仰った。「これまでの日本はアメリカのモノマネであった。アメリカ製品をお手本に、それを『いかに作るか』を考えればよかった。しかし、日本が経済の先頭に立った今、これからは『何を作るか』を考えなければならない」と。
高度成長を通して、日本のエンジニアは、アメリカをお手本とすることで、「何を作るか」をほとんど考えずに済んだ。すべてのリソースを「いかに作るか」に集中することができた。かつて、日本の電機メーカーもIBMの互換機で荒稼ぎした時代があったが、それは単に当時の日本の労働力が安かっただけではなく、「何を作るか」はアメリカに考えてもらうという「ズル」をしていたのだろう。
我々日本人にとってのエンジニア像は、今もなお、「いかに作るか」を考えるエンジニアなのだろう。だから、多くの若者がSIerを目指し、そして失望する。これは、学校教育が開発の現場に追いついていないといってもいいのかもしれない。
現代のコンピュータシステムが解かなければならない問題は複雑だ。したがって、「何を作るか」という視点が欠かせない。日本の多くのSIerがやっている仕事がこれだ。SIerに就職するということは、残念ながら、住み慣れたコードの世界を離れ、Excel方眼紙の世界で生きていくということを意味する。
しかし、エンジニアリングの醍醐味は、やっぱり「いかに作るか」を考えることだと考える人もいるだろう。私もその一人だ。そういう人達はどうすればいいのだろうか? 答えは、かつての日本企業と同じように、「ズル」をすることだ。すなわち、誰かが「何を作るか」を定義してくれた問題を解くのだ。ただし、普通に解いてはダメだ。ずっとうまく解かなければならない。
Googleを考えてみれば良い。Googleの創業時、彼らの商品は検索エンジンだけだった。彼らは「検索エンジンとは何か」とは考えなかった。彼らが成功したのは、検索エンジンを「いかに作るか」を考えたからだった。そして、彼らは検索エンジンという問題を、ほかの誰よりもずっとうまく解いた。
私は「何を作るか」よりも「いかに作るか」に興味のある人間だが、SIerの仕事には敬意を払っている。彼らが「何を作るか」を定義してくれなければ、「いかに作るか」を考えることはできない。また、日比野先生の仰る通りなら、「何を作るか」を考えるSIerは、これからの日本の成長産業である(もちろん、大失敗する産業かもしれない)。
SIerが云々という話題が聞かれるようになったということは、多くの人が「いかに作るか」と「何を作るか」の違いに気づき始めたということだろう。違いがわかったということは、次にとるべきアクションも、じきに明らかになるのではないか。いかにもSIerというような大企業がやっているようなことと、スタートアップがやっていることを比べてみるとヒントがあるかもしれない。私も含め、多くのエンジニアが幸せな人生を送れるようになるとよい。
彼らが自虐ネタに走るのは、SIerが彼らの思い描いていたエンジニアリングの世界とは異なるからではないだろうか? つまり、彼らはSIerが自分に「合ってない」と感じている。実は、私もその口だ。では、エンジニアリングの世界に何が起きているのだろうか?
少なくとも、日本の大学の情報工学や計算機科学の学科で教えているエンジニアリングは、SIerがエンジニアリングと称しているものとは全く違う。大学では、エンジニアリングとはコードを書くことだ。一方、SIerでは、エンジニアリングとは書類(主に仕様書)を書くことを指す。大学では、エンジニアリングの道具はエディタとコンパイラだが、SIerではWordとExcelが道具だ(優秀なSIerはMicrosoft Projectも使う)。
大学で教えていることとSIerでやっていることの違いは、エンジニアリングに対するアプローチの違いである。すなわち、「いかに作るか」と「何を作るか」の違いである。私が学生時代、ソフトウェア工学の世界ではパターンがはやっていた。私も授業でデザインパターンを習ったが、これはまさに「いかに作るか」のレシピである。一方、私が会社に入って上司に教えられた「顧客の要求を云々」とは、「何を作るか」を考えるということだ。
「いかに作るか」と「何を作るか」の境界は曖昧だ。おそらく、単純なものほどこの境界が曖昧になり、複雑なものほど境界がはっきりしてくるのではないか。例えば、ハサミを作るとして、「いかに作るか」と「何を作るか」という視点はほとんど同じものを指す。しかし、スペースシャトルを作るとなれば、これらの境界はかなりはっきりするだろう。
実は、この「何を作るか」「いかに作るか」という着想は、私が考えたものではない。JAISTの日比野先生の言葉である。私は、LispマシンELISの設計者でもある先生と知り合う機会を得た。あるイベントの打ち上げの時、先生はこのような趣旨のことを仰った。「これまでの日本はアメリカのモノマネであった。アメリカ製品をお手本に、それを『いかに作るか』を考えればよかった。しかし、日本が経済の先頭に立った今、これからは『何を作るか』を考えなければならない」と。
高度成長を通して、日本のエンジニアは、アメリカをお手本とすることで、「何を作るか」をほとんど考えずに済んだ。すべてのリソースを「いかに作るか」に集中することができた。かつて、日本の電機メーカーもIBMの互換機で荒稼ぎした時代があったが、それは単に当時の日本の労働力が安かっただけではなく、「何を作るか」はアメリカに考えてもらうという「ズル」をしていたのだろう。
我々日本人にとってのエンジニア像は、今もなお、「いかに作るか」を考えるエンジニアなのだろう。だから、多くの若者がSIerを目指し、そして失望する。これは、学校教育が開発の現場に追いついていないといってもいいのかもしれない。
現代のコンピュータシステムが解かなければならない問題は複雑だ。したがって、「何を作るか」という視点が欠かせない。日本の多くのSIerがやっている仕事がこれだ。SIerに就職するということは、残念ながら、住み慣れたコードの世界を離れ、Excel方眼紙の世界で生きていくということを意味する。
しかし、エンジニアリングの醍醐味は、やっぱり「いかに作るか」を考えることだと考える人もいるだろう。私もその一人だ。そういう人達はどうすればいいのだろうか? 答えは、かつての日本企業と同じように、「ズル」をすることだ。すなわち、誰かが「何を作るか」を定義してくれた問題を解くのだ。ただし、普通に解いてはダメだ。ずっとうまく解かなければならない。
Googleを考えてみれば良い。Googleの創業時、彼らの商品は検索エンジンだけだった。彼らは「検索エンジンとは何か」とは考えなかった。彼らが成功したのは、検索エンジンを「いかに作るか」を考えたからだった。そして、彼らは検索エンジンという問題を、ほかの誰よりもずっとうまく解いた。
私は「何を作るか」よりも「いかに作るか」に興味のある人間だが、SIerの仕事には敬意を払っている。彼らが「何を作るか」を定義してくれなければ、「いかに作るか」を考えることはできない。また、日比野先生の仰る通りなら、「何を作るか」を考えるSIerは、これからの日本の成長産業である(もちろん、大失敗する産業かもしれない)。
SIerが云々という話題が聞かれるようになったということは、多くの人が「いかに作るか」と「何を作るか」の違いに気づき始めたということだろう。違いがわかったということは、次にとるべきアクションも、じきに明らかになるのではないか。いかにもSIerというような大企業がやっているようなことと、スタートアップがやっていることを比べてみるとヒントがあるかもしれない。私も含め、多くのエンジニアが幸せな人生を送れるようになるとよい。