2011年12月21日水曜日

ハッカーセントリックな企業文化

TechLION vol.5に行ってきた:

http://www.usptomonokai.jp/wp/?p=2068

自称プロの酔っぱらいである楽天のよしおかさんが、「ハッカーセントリックな企業文化」について語るということだった。Twitterを見ていると、すでに楽屋でビールを飲んでおられたようだった。さすがプロである。

よしおかさんはこう言う:
良いソフトウェア、良いシステムを作りたいなら、最高のプログラマを雇うべき。見も蓋もない話なんですよ。
ここで言う「最高のプログラマ」というのが、ハッカーということなのだろう。

では、ハッカー的モノづくりと、非ハッカー的モノづくりを隔てるものは何だろうか? どうして、ハッカーのほうが素晴らしいモノづくりができるのだろうか? これは、ハッカーと非ハッカーがモノづくりに対してとる態度の違いに現れているように思う。

モノづくりにおいて、リスクを回避する最も簡単な方法は、モノを作らないことだ。もちろん、モノがなければシステムは作れないので、実際にはコンポーネントを買ってくることになる。これは、実際に私の現場でも行われていて、COTS(Commercial Off The Shelf)というカッコイイ名前で呼ばれている。

COTSを利用するメリットは、そのコンポーネントに関するあらゆるリスクをベンダーに転嫁できる(と非ハッカーは考える)ことだ。COTSのバグが見つかったら、ベンダーへ怒りの電話を入れればよい。彼らが徹夜で直してくれるはずだ(と非ハッカーは考える)。

ハッカーは、既存のコンポーネントを組み合わせてシステムを作る事自体には反対しない。むしろ、そのようなモノづくりは「巨人の方に乗る」ものとして賞賛されさえする。実際、ハッカーはオープンソースのコンポーネントをよく利用する。問題は、そのコンポーネントに対する「態度」だ。

例えば、あるコンポーネントでバグが見つかったときに、「そのコンポーネントはCOTSなので私には関係ありません」と言って責任逃れをするのは非ハッカー的態度だ。このような言い訳はハッカーとしてのプライドを大きく傷つけるものだし、こういう言い訳をする人間はハッカーではないと他のハッカーから見なされる。

ハッカーがオープンソースを好む理由もここにある。ソースがあって自分でいじくり回すことができるからこそ、すべての責任を取ることができる。すべてをコントロールすることができる。責任逃れはできないのだ。

ここからわかることは、ハッカーは自分の作った製品やサービスに対して非常に責任感が強いということだ。これは、ハッカーの一見自由奔放なイメージとはかなり違う。実は、非ハッカーのほうが責任感がない。非ハッカーは、いかにして責任を取らずに済むかを考える。

だから、もし本当に素晴らしいモノづくりがしたいのなら、ハッカーの態度を真似るべきだ。次に何か責任逃れをしようと思うときがあったら、グッとこらえて「自分の責任」にしてしまおう。自分でデバッグに乗り出そう。そして、いつでもそうできるようにオープンソースを採用しよう。

でも、どうしてもハッカーセントリックな企業文化が自分の会社に根付かないのなら、他のハッカーを探して別の会社に移るというのも手かもしれない。世の中には、ハッカーはたくさんいるはずだ。

2011年12月17日土曜日

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. 引数vstartとvendで渡された仮想アドレス空間(範囲)についてPGSIZE(4KB)ごとにkfree関数を呼び出す
kfree関数は、以下の処理を行う:
  1. 引数vで渡された仮想アドレスが以下の条件にない場合、パニックする:
    • ページ境界に合っていない
    • endより小さい
    • v2p(v)がPHYSTOP以上である
  2. vから1ページ分、メモリ領域を1で埋める
  3. vをフリーリストにつなぐ
ここで、v2p関数は、上記のP2Vマクロの親戚で、仮想アドレスvからKERNBASEを引き、仮想アドレスを物理アドレスに変換するものである。同種の関数・マクロには、他にp2vとV2Pがある。

以上で、フリーリストの初期化の第1段階が完了した。これで、4MBまでの範囲で、メモリアロケータはページを割り当てることができる。

フリーリストの初期化の第2段階であるkinit2関数は、main関数のかなり後のほうで、以下のように呼び出されている:

kinit2(P2V(4*1024*1024), P2V(PHYSTOP));


4MBからPHYSTOPまでの物理アドレス空間を、フリーリストに登録する。以上でフリーリストの初期化はすべて完了し、メモリアロケータを使用することができる。

2011年12月13日火曜日

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から引用する:

+--------10------+-------10-------+---------12----------+
| Page Directory |   Page Table   | Offset within Page  |
|      Index     |      Index     |                     |
+----------------+----------------+---------------------+
 \--- PDX(va) --/ \--- PTX(va) --/ 

仮想アドレスは、それぞれ10ビットのページディレクトリインデックスとページテーブルインデックス、そして12ビットのページ内オフセットからなる。それぞれの意味を以下に示す:
  • ページディレクトリインデックス:当該仮想アドレスに対応する物理アドレスをマップするページディレクトリエントリを指す
  • ページテーブルインデックス:当該仮想アドレスに対応する物理アドレスをマップするページテーブルエントリを指す
  • ページ内オフセット:上記2つによって指定されるページ内のオフセット(このページのアドレス+オフセットが物理アドレス)
アドレススペースの作成は、main関数からのkvmalloc関数の呼び出しで行う。setupkvm関数でページディレクトリを作成し、それをswitchkvm関数でCR3レジスタに設定する。関数の呼び出し関係を以下に示す:


main
:
+->kvmalloc
|  +->setupkvm
|  |  +->mappages
|  |     +->walkpgdir
|  +->switchkvm
:


setupkvm関数では次の処理を行う:
  1. ページディレクトリ用に1ページ(4KB)を割り当てる
  2. 次の各カーネル領域について、mappages関数を呼び出すことで、ページテーブルを作成し、ページディレクトリエントリに書きこむ:
    • I/O空間
    • カーネル(テキストと読み込み専用領域)
    • カーネルデータ
    • その他デバイス
  3. 作成したページテーブルを、1のページディレクトリに書き込み、返す
ここで、各カーネル領域は任意の大きさでよい。mappages関数に領域のサイズを渡すことで、必要な分だけページテーブルが割り当てられる。

mappages関数は次の処理を行う:
  1. walkpgdir関数を呼び出し、引数で渡された仮想アドレスに対応する、ページテーブルエントリを取得する
  2. エントリにマップする物理アドレス、アクセス権、存在ビットを書きこむ
  3. 領域全体をマップし終わるまで1から繰り返す
walkpgdir関数は次の処理を行う:
  1. ページディレクトリから、ページディレクトリインデックスに該当するエントリを引く
  2. 1で引いたエントリの存在フラグが立っていれば、ページテーブルを取得する(エントリに記述されているアドレスに存在するはず)
  3. 2でない場合、関数の引数でallocフラグに真が渡された場合(この場合はそうである)、新たに1ページ取得し、これをページテーブルとする。このページテーブルの物理アドレス、存在ビット、書き込み可ビット、ユーザ空間ビットを、1で取得したエントリに書きこむ
  4. 2または3で取得したページテーブルから、ページテーブルインデックスに該当するエントリのアドレスを返す
以上で、アドレススペースを作成した。ただし、ここで作成したのはページテーブルまでで、物理ページの割り当ては行っていない。次回は、テキストに従って、物理メモリの割り当てに進みたい。

2011年12月8日木曜日

スキルかセンスか?

ちょっと前の話になるのだが、「デザイナ&エンジニア交流会」というのに参加してきた:

http://design1.chu.jp/setucocms-pjt/?p=1770

SetsucoCMSというオープンソースのCMSがあって、それを作っている子たちによく遊んでもらっている。今回、彼らが勉強会をやるということで、私も誘われた。デザイナやエンジニアと言っても、ここでは「Web」デザイナ、「Web」エンジニアである。Webにとんと疎い私としては、そこはまったくの異文化圏である。そこでの交流は、なかなか刺激的であった。

中でも非常に新鮮だったは、普段接することのないデザイナと話す機会を持てたことだ。そして、彼らと話してわかったことには、どうやら彼らは、デザインがセンスだとエンジニアに思われていることに強い不満を持っているらしい。

確かに、「デザイン」というと、何だか芸術的なものを連想してしまう。実際、私もデザインはセンス、つまり才能によるところが大きいのだろうと何となく思っていた。しかし、デザイナの彼らに言わせれば、デザインには理論があり、練習によって習得できるものであって、したがってデザインはスキルであるという。

ここでちょっと野球を考えてみる。長嶋茂雄さんといえば往年のスター選手だ。あるとき、ホームランの打ち方を聞かれた長嶋さんは、「ボールが来たら、よく見て打て」と大真面目に答えたそうだ。長嶋さんにとっては、それがホームランの理論であり、練習によって習得したということだろう。

デザイナが、デザインがセンスだというエンジニアの思い込みに不満を持つということは、その裏返しとして、彼らは、エンジニアリングはスキルだと思っているのかもしれない。しかし、この思い込みが必ずしも正しくないことは、プログラマなら誰もが知っている。

確かに、プログラミングには理論が存在する。ソフトウェア工学と呼ばれているものがそれだ。プログラミングの外にいる人の目には、プログラミングとはソフトウェア工学の実践であって、練習によって習得できるものと映るかもしれない。しかし、そうだとしたら、どうしてこんなにも多くのソフトウェア開発プロジェクトが失敗するのだろう? プログラマはみんなあまりにも怠惰過ぎて、練習を怠っているということだろうか?

私が思うに、プログラミングは野球みたいなものだ。ソフトウェア工学は長嶋さんのホームラン理論に似ている。この理論は間違ってはいないが、本当にホームランを打とうとするなら、理論以外の何かが必要だ。そして、重要なことは、あの長嶋さんでさえ、毎回ホームランを打てたわけではないということだ。

交流会の後の懇親会で、私はデザイナの一人に、「エンジニアリングはスキルですか?」と聞かれた。私は、「ある部分はスキルでしょう。しかし、センスが必要な部分もたくさんありますよ」と答えた。この時は酔っ払っていたのでうまく説明できなかったが、私が言いたかったのは、つまるところエンジニアリングとはホームラン理論だということだ。

だから、デザイナは、自分たちがやっていることがスキルかセンスかなんて悩む必要はないと思う。たぶん、デザインもホームラン理論だ。部外者から見るとセンスに見えるかもしれないが、実際にはスキルとセンスの混合物なのだろう。

最後に、今回の交流会を主催し、そして私を呼んでくれたSetsucoCMSのみんなにお礼を言おう。彼らはとても若く、パワフルで、情熱に溢れている。そして何より、彼らはものづくりに対してとても真面目である。彼らの今後の活躍には私は大きく期待するし、また、今後もこういった交流会に呼んでほしいと思う。

2011年11月20日日曜日

電子書籍は安い?

Amazon Kindleの日本語版が年内登場とか言っている。日本でも書店や出版社などが独自に電子書籍を出していたが、各社ばらばらで足並みが揃っていないようで、私は買い控えていた。Kindle DXですでに英語版を利用している身としては、今回のAmazonの発表は非常に嬉しい。もっとも、私のKindle DXで日本語書籍が読めるのかという心配はある。400ドルもしたのに…。

よく、電子書籍の値段はいくらが適当かという話題を見かける。書店や出版社も、適正な価格付けに困っているのかもしれない。消費者にとっては、中間に書店や卸業者が入らない分、電子書籍は紙の書籍に比べるとコストが安いように思える。したがって、当然、電子書籍の値段は紙の書籍より安くしろということになる。実際、Amazon.comのKindle書籍は、紙の書籍に比べて圧倒的に安い。

しかし、ちょっと待ってほしい。モノの値段というのは、はじめに利益ありきで決まるものではない。物の値段は、「消費者がいくらなら買うか」によって決まるものではないのか? 消費者が1万円出してでもほしいと思うものなら、たとえ原価が100円であっても1万円で売っていいはずだ。だから、いったん中間の書店や卸業者のことは忘れて、いくらなら電子書籍を買うか考えてみよう。

私が英語版Kindleを使っていて、これは便利だと感じた機能はざっと以下のようなものだ:

  1. (当然ながら)普通に読書できる
  2. ブックマークできる
  3. ノートをかける
  4. わざわざブックマークしなくても直前にどこを読んでいたか記憶しており、次に端末を起動したとき、そのページを開いてくれる
  5. Kindle端末以外にも、PC、Webブラウザ、スマートフォンなどで読める
  6. 上記端末等で、書籍、ブックマーク、ノート、直前に読んだページを同期できる
  7. 検索ができる
  8. 1000ページを超えるような技術書でも楽に持ち歩くことができる
  9. 保管に場所をとらない
  10. 誤植等があった場合、本のアップデートができる
さて、以上のような機能を備えたKindle端末(単なる端末というよりは、Amazonのサーバを含めた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回線を介してアップデートされた。事前にアップデートに関するメールもきたし、大変満足している。したがって、この点も電子書籍のほうが便利だ。

さて、こうして電子書籍と紙の書籍を比べてみると、電子書籍のほうが消費者にメリットがありそうだ。もちろん、紙の書籍にも良い点があるということは私も認識している。例えば、芸術的な装幀や、芸術的な装幀や…うーん…そうだ、乱暴な扱いにも強い!

だが、一般的な読書であれば、少なくとも私は電子書籍を好むだろう。だから、私は電子書籍を安くしろとは言わない。紙の書籍と同じか、あるいはちょっと高くても電子書籍を選ぶ。実際、電子書籍には、サーバの運用や、原価より低く設定された端末本体の値段(カミソリ本体とカミソリの刃の話と同じだ)など、紙の書籍にはなかったコストもかかっているのだ。

電子書籍の値段を考えるとき、これらのメリットを中心に考えれば、自ずと適当な値段がわかるだろう(上記のように、私の答えは、紙と同等かちょっと高くてもよい)。書店や出版社の立場で考えると、電子書籍でできることを更に増やせば、これはつまりサービスを充実させることであるから、値段を上げてもよいだろう。

もう何十年も前から、これからは電子書籍の時代だと言われてきたが、ようやくその時代がやってきた。電子書籍を中心に、本のあり方というのも変わってくるのかもしれない。なお、出版社や書店が、どうしても電子書籍を紙の書籍より安くするというのなら、私はもちろん大歓迎である。

2011年11月14日月曜日

いかに作るか、何を作るか

今日は朝から、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というような大企業がやっているようなことと、スタートアップがやっていることを比べてみるとヒントがあるかもしれない。私も含め、多くのエンジニアが幸せな人生を送れるようになるとよい。

2011年10月29日土曜日

ネコのこと

わけあって実家へ帰ってきている。実家ではネコを飼っている。私が大学へ入学したのが2000年で、その年の冬にやってきた。その時はまだだいぶ若く、夜になると家の中を走りまわったりしていた。あれから11年、もう13歳くらいになったのではないかと思う。歳のせいか、走りまわるようなことはなくなった。ほとんど一日中寝ている。

さて、そんな我が家の御ネコ様は食事にうるさい。気に入ったものしか食べない上、その好みもころころ変わる。人間の食事は塩分が強いので、なるべくキャットフードを与えるようにしている。ネコは腎臓が弱い。最近のお気に入りは、ユニ・チャームの「ねこ元気」シリーズのレトルトタイプである。

このレトルトだが、一袋の容量が40gで、一日に3〜4袋与えるようにと書いてある。うちのネコは、食い意地が張っているのか、だいたい一日に5〜6袋も食べる。したがって、頻繁にドラッグストアへ行っては、このレトルトを買い占めることになる。

このレトルト、年齢によって、1歳以上、7歳以上、10歳以上、13歳以上と、年齢ごとに種類が分かれている。お店には種類ごとに少しずつしか置いていないので、母は、7歳以上〜13歳以上までを買い占めている(さすがに、1歳以上では若すぎると思う)。

ここでわからないのが、何の違いによって種類が分かれているのかということだ。袋の裏の表示を見比べてみたが、原材料、栄養ともに大きな違いは見られない。ユニ・チャームのWebサイトを見てみても、掲載されていない。

ペットを飼っている人ならわかるだろうが、ペットは家族である。家族には、よくわからないものを食べさせたくはない。ペットフードとはいえ、メーカーはそれが「食品」であることを認識して欲しい。これは、ペットの健康のためであり、また飼い主の安心のためでもある。

ちなみに、我が家の御ネコ様は、そんなことなど何も気にせず、何歳用でも喜んで食べている。心配するのは人間だけか…

2011年10月18日火曜日

Dennis Ritchieへ

http://jp.techcrunch.com/archives/20111015what-can-we-learn-from-dennis-ritchie/

今このアーティクルを書いているマシンはUbuntu Linux 11.04。バックグラウンドでは11.10へのアップデートを行っているところだ。アップデート完了まで30分ほどかかるようなので、先日亡くなったDennis Ritchieについて書いてみたい。

Ritchieといえば、K&RのRの人だ。プログラマの本棚には必ずK&Rがあることと思う。私のK&Rは1997年5月1日の第2版211刷だ(共立出版から出ている石田晴久先生の翻訳。そういえば、石田先生もお亡くなりになられた)。

この本は、私が高校生だったころ、近くのパソコンショップで購入したもの。もう無くなってしまったが、帯に「K&RのC」と書いてあって、「これがあの有名なK&Rか」と購入した。私の本棚の技術書の中では一番古いのではないかと思う。

通学途中の電車で読み、大学に入ってからもリファレンスとして参照した。本を大事にする私でも、この本は索引が取れてセロテープで付けてあるなど、ボロボロになっている。10年以上の付き合いだ。

そんなC言語の生みの親がRitchieだ。そして、C言語のキラーアプリケーションがUnixであり、UnixがなければLinuxはなく、今ここでUbuntuのアップデートをすることもなかっただろう。高級言語でOSを書くというアイデアは、まさしくイノベーションである。

Ritchieは今年の春に日本賞を受賞している。日経サイエンスに、どこかで見たことのあるヒゲのおじさんが出ていると思ったら、Ritchieだった。UnixとC言語の発明による功績だった。地震の影響で授賞式はキャンセルされたらしい。

だから、Dennis Ritchieはまだまだ健在なのだと思っていた。Ken Thompsonも、Brian Kerninghanも、Rob Pikeも、みんな元気だと思っていた。

クリント・イーストウッドの映画に、『スペースカウボーイ』というのがある。危機に陥った人工衛星を修理するために、往年の宇宙飛行士が結集するというストーリーだ。同じように、世界のどこかでまだPDP-11でUnixが動いていて、それを修理するためにベル研のメンバーが結集するというのもストーリーとしては面白い。

そろそろアップデートが終わる。K&Rは今後も私のバイブルだし、C言語も使い続けていくだろう。さようなら、C言語とUnixをありがとう。

2011年10月11日火曜日

よしおかさんが困ってる

「いつまでもよしおかさんでいいのか?」なんて言っていたら、

http://yshigeru.blogspot.com/2011/09/blog-post_25.html

本当によしおかさんが困っていた:

http://d.hatena.ne.jp/hyoshiok/20111010

何に困っているかというと、
  • 会場の確保
  • 当日の運営あれやこれや
ということらしい。

会場の確保が難しいというのはよくわかる。昨今、どこの会社でも、セキュリティ関連が厳しくなっているのだと思う。私の会社などは、扱っている製品がアレなせいもあり、よその人間を会社の敷地内に入れるというだけでも保安課が腰を抜かしてしまう。

よく参加させてもらっているGenesis Lightning Talksや、一度だけ開催したShibuya.lisp Hackathonでは、Oracleさんを利用させてもらっている。最近ご無沙汰しているOpenSolaris勉強会も最近はOracleでやっているようだ。

聞いたところによると、Oracleさんはコミュニティ活動に力を入れていて、勉強会やカンファレンス等に会場を提供する専門のセクションを持っているらしい。Oracleさんにちょっと当たってみようか。

当日の運営あれやこれやというのは、私もぜひぜひ協力させていただきたいと思う。鎌倉勤務なので、都内まで移動に時間がかかる(1時間ちょい?)のだけれど、ちゃんと計画を立て、強い意志をもてば、やれないことはないと思う。

というわけで、よしおかさん、ボク、やります!!!

2011年10月10日月曜日

大学の役割り

「大学で学んだことが社会に出てから役に立たない」という話をよく聞く。先日のLT祭りの懇親会でも、この話がちらっと出た。

この話を聞いて私がいつも思うのは、電気や機械や材料のエンジニアはどう思っているのだろう? ということだ。どうも、この手の話は情報系のエンジニアによく聞くような気がする。

例えば、大学ではアルゴリズムやデータ構造の授業がある。しかし、実際には大抵のアルゴリズムやデータ構造はライブラリになっていて、新しくアルゴリズムを設計するよりも、それらライブラリを持ってきて組み合わせるほうが多いと思う。

だから、多くの人が、大学で学んだことが社会に出てから役に立たないと言うのは、同意できることではある。情報系出身ではないプログラマもたくさんいて、例えば、彼らのアルゴリズムに関する理解は甚だ怪しいものではあるが、それでもよくやっている人はたくさんいる。

工学の知識というのは、基礎理論から応用までの幅広いスペクトルになっていて、これを大学ではどう教えるかということなのだと思う。 これは、情報工学に限ったことではないはずで、じゃあ、他の工学の分野ではどうやって教えているのだろう? と、思うわけだ。

ちなみに、私は製造業で働いているので、周囲に電気や機械のエンジニアがたくさんいる。彼らからは、大学の授業が役に立たないなどというボヤきは聞こえてこない。

私個人の感想としては、やっぱり、大学の授業が直接的に役に立つという機会は少ないように思う。でも、私はその手のことが好きなので、大学の授業は楽しかったし、大学へ行ってよかったと思う。

医者を養成するための医学部や法律家を養成するための法科大学院があるように、プログラマを養成する職業訓練大学校があってもよさそうなものではある。経営学にはビジネススクールあるわけだが、文系の学科の人なんかは、また違った思いを持っているのだろうか?

2011年10月9日日曜日

LT祭りに行ってきた

昨日は、都内で開催されたLT祭りに行ってきた。LTのワークショップがあって、実際に手を動かしながらLTの作り方を学べるということだった。最近はあまり勉強会などへ参加していなかったので、久々の遠征となった。

http://kokucheese.com/event/index/17631/

私も、たまに勉強会やイベントなどへ行ってLTをやったりする。LTをやると、終わったあとにいろんな人が声をかけてくれたりして、人見知りな私には、LTは友達を作る大切なツールである。

今まで我流でLTを作ってきたのだけれど、LTの達人たちの作り方を伝授していただいた。LTの作り方をプレゼンで教えていただいたのだが、そのプレゼン自体、みなさんやっぱりうまいなぁ。

内容に関しては、マインドマップとかKJ法とかマンダラートとか、その手の思考技術は結構バカにしていたのだけれど、いざやってみるとそれなりにアイデアが湧いてくる。プレZEN風のスライドも、素材さえ用意してあげればそれなりに作れる。

というわけで、もっとたくさんの人と、LTで知り合うことができるといいな。

2011年10月4日火曜日

大事なことはすべてBSDで学んだ

半年に一回くらいBSDが触りたくなる。Software Designの今月号の特集がFreeBSDだったので、早速触りたくなってしまって、Ubuntuの入っていたPCをつぶしてFreeBSDにしてしまった。9.0-Beta3である。

2002年前後、ASCIIがBSD Magazineなる雑誌を出していて、なんとも怪しげなマニアックな濃い雰囲気を醸しだしていた。砂原先生など、Unix界の大物(要するにオッサン)が登場し、「PCでUnixをやるならBSDだ。Linuxなんかダメだ」と主張しておられた。

当時はLinuxも2.2とかそのへんで、LinuxとBSDとどちらが良いかというような議論もあった。私は、砂原先生たちのその濃い雰囲気にやられてしまって、FreeBSDを使い始めた。これが私とBSDとの出会い。

当時は、FreeBSDも3とか4とかそのくらいだった。学校に行かない不良大学生だった私は、大学のプログラミングの演習なども、全部自宅のFreeBSDでやってしまった。大学のマシンはLinuxだったが、ユーザランドでプログラミングする限りではほとんど変わらない。

その後、研究室に入ってもFreeBSDを使い続け、私とBSDとの付き合いは大学を卒業するまで続いた。

私は、BSD上でUnixとUnixシステムプログラミングを学んだ。Lispの処理系も書いたし、正規表現のパーサーも書いた。しかし、それ以上に、私がBSDから学んだことの中でもっとも大事なのは、BSDに流れるハッカー精神である。

Linuxにもハッカー精神はあると思う。しかし、Linuxのそれは、BSDのそれとはちょっと違うように思う。単に世代の違い、若者とオッサンの違いかもしれない。

BSDのハッカー精神には、燦々と太陽の照りつける中、カリフォルニアの大地を土煙を上げながらオープンカーでひた走る、そんなイメージがある(カリフォルニア行ったことないけど)。

ないものは自分で作ってしまえ。ソースがあるなら改造してしまえ。ビル・ジョイなんかは、viを発明する前はcatでコードを書いていたのではなかろうか?

というような、古き良きハッカー精神をBSDからは学べたと思う。就職してからSolarisやLinuxに浮気したけれども、なんかしっくりこないのは、このBSDの古き良きハッカー精神とLinuxやSolarisのハッカー精神との間の「ズレ」を感じていたのだろう。

というわけで、せっかくFreeBSDもインストールしたことだし、しばらくいじってみようかと思う。大事なことはすべてBSDで学んだ。

2011年9月29日木曜日

テクノロジーを感じる

新しいKindleが発表された。デザインを一新してキーボードのなくなったKindle、タッチパネルを搭載したKindle Touch、そしてAndroid搭載のKindle Fire。

今回の発表の目玉はやっぱりKindle Fireだ。Android搭載Kindleはずっと噂されていたわけだが、まず、とにかく安い。iPadなんかよりもずっと安い。

そして、コンテンツ。これまでのKindle事業でAmazonのコンテンツは十分だ。加えて、映像や音楽もやるという。Amazonは、Kindle Fireという端末を通して、あらゆるコンテンツを供給しようとしている。

さらに、Kindle Fireに搭載されるブラウザとして発表されたAmazon Silk。これまでブラウザ側で行っていた処理をクラウド上で行って、ブラウザに送信するという仕掛けになっているらしい。これで、Amazonのクラウド事業とKindle事業がひとつにつながったわけだ。

今回の発表で私が感じたこと、それはAmazonはテクノロジー企業だということ。ただのネット本屋ではない。私のような技術屋は、製品やサービスそれ自体ではなく、その後ろにあるテクノロジーを見てニヤニヤしてしまう。逆に言うと、Amazonは、そういう後ろ側のテクノロジーをさりげなく見せてくる。

これは、AppleやGoogleについても言えることだ。彼らも、自分たちがテクノロジー企業だということを自覚している。彼らの製品やサービスにはテクノロジーを感じる。テクノロジーは、彼らのアイデンティティの一部なのだ。

一方、最近の日本企業はといえば、少なくとも私はニヤニヤできていない。ゲーム業界なんかでは素晴らしい製品があるのかもしれないが、ゲームをやらなくなって久しい私にはよくわからない。少なくとも、3DSにテクノロジーを感じることはできなかった。ゲームで3Dというのは、昔ながらのアイディアである。

日本が世界に誇る工業製品といえば、自動車がそうだろう。日本は、EVやHVではかなり先行している。日本のEV、HVの需要は、世界市場の半分を占めるという。HVなどは、市場に投入されてからかなり時間も経っており、多くのオーナーたちがHVのあまりの燃費のよさに感動していることだろう。

しかし、私は日本のEVやHVにはテクノロジーを感じることができない。なぜか?

日本の自動車会社はうまくやりすぎたのだ。彼らは、従来の自動車を置き換えるものとしてEVやHVを設計してしまった。それも、誰にも気づかれないよう、こっそり置き換えてしまった。背後にあるテクノロジーを、製品の中に隠蔽してしまった。

どちらがよいとは一概に言うことはできない。Amazonのようにテクノロジーを感じさせる製品やサービスを作るか、あるいは日本の自動車会社のようにテクノロジーを製品の中に隠蔽してしまうか。

少なくとも私は、Amazonのようにテクノロジーを感じさせてくれる製品が好きだ。だから、きっとKindle Fireは買ってしまうだろう。日本語コンテンツが充実すれば、の話ではあるが。

2011年9月25日日曜日

いつまでもよしおかさんでいいのか?

そう言えば、最近カーネル読書会がない。単にスピーカが見つからないだけなのか、会場の手配が難しいのか、それともよしおかさんがやる気を失ってしまったのか。

カーネル読書会といえばよしおかさん、勉強会といえばよしおかさん。確かによしおかさんはキーパーソンなのだけれど、ちょっとよしおかさんに頼りすぎているかなと思う。何となく、「そのうちよしおかさんが動いてくれる」という空気がある。

私も社内勉強会をやっているけれど、ちょうど私がよしおかさんみたいなポジションになっている。声をかければみんな集まってくれるのだけれど、私が動かないと何もしてくれない。私が社内勉強会の発案者なのだし、積極的に動いていきたいと思っているけれど、たまに悲しくなる時がある。

よしおかさんも、カーネル読書会をやっていて、たまに悲しくなる時があるのではないだろうか? よしおかさんももういい歳なんだし、会場の手配からピザの注文から何からお任せする段階は過ぎたのではないだろうか? そろそろよしおかさんに感化された次の世代が育ってもいいころでは?

と言うと、「じゃあ、お前がやれ」という話になるのだが…。実際、自分がやると考えると、ひとつだけクリアできない問題が。どうやってスピーカを探すか、だ。よしおかさんはどうやって探してきていたのだろう?

例えば、Shibuya.lispでは、その道の有名人にメールで突撃するというのをやっている。結構快く引き受けてもらえる。しかし、これは相手がどこで何をやっているか(あるいは過去に何をやったか)がわかっているからできること。

カーネル読書会みたいに、カーネルやオープンソース全般ということになると、そもそも、どこで、どういう人が、どういうことをやっているかがわからない。だから、結局よしおかさんみたいな人に頼ることになる。

ということで、私としては、どんどん外に出て行って人脈を広げることから始めようかな。

2011年9月22日木曜日

日本は日本は

先の震災の影響もあるし、また不況や円高のせいもあるだろうけれど、「日本はこれからどうすればいいか?」とか「このままでは日本は新興国に負けてしまう」みたいな一種の焦りのようなフレーズをよく目にする。新聞でも見るし、雑誌の表紙にも並んでたりする。

こういう日本は日本はという論調には、少し違和感を感じる。どうも日本は日本は論者は、「日本経済」というものを孤立した系として捉えすぎているようだ。

もうだいぶ前から、世界はグローバル経済になっていると言われている。グローバル経済とは何だろうか? 例えば、日本経済、アメリカ経済、中国経済などという各国の独立経済があり、これらがつながってグローバル経済が形成されているという捉え方もできる。

しかし、世界にはひとつのグローバル経済なるものがあって、どこまでが日本経済、どこまでがアメリカ経済などと分離することはできないという捉え方もできて、私はこっちのほうが現状のように感じる。

例えばAppleを考える。Appleはアメリカ国内には製造工場は持っていない。台湾にアウトソースし、世界で販売している。では、アメリカAppleはアメリカ経済の一部であって、日本Appleは日本経済の一部なのか?


経済学的には、どこの国に税金を払っているか、どこの国の人々を雇用しているかという話があるのだろうけど、観念的には、Appleはどこの国の企業でもない。これをグローバル企業と呼ぶのだろう。

そして、グローバル企業によって形成される経済をグローバル経済と呼び、これが21世紀の新しい経済なのだろう。グローバル経済というのは、従来の各国の独立経済が単につながったものとは違う。そもそも、各国の独立経済などというものは存在しないのだ。

日本企業、とくに製造業は生き残りに必死である。日立はテレビの製造を辞めてしまった。一方で、トヨタは国内の製造工場は絶対に必要だと言っている。

でもこれって、国内とか国外とか分けて考える、つまり各国の独立経済を考えてしまうから難しくなってしまうのであって、そもそも日本経済なんてものは無い、あるのはグローバル経済ただひとつと考えれば、シンプルな解決策が見つかるのではないのかなと思う。

結論が出たところで、「じゃあ、結局日本はこれからどうすればよいの?」と考えてしまうと、また独立経済のパラダイムに戻ってしまって、話は無限ループしてしまうのである。経済学って難しい。

2011年9月12日月曜日

キャリアについて悩む

このところキャリアについて悩んでいる。と言っても、キャリアアップして年収1000万とかそいういうものではなく、単に「最近やりたいことできてないなぁ」とい程度のことだ。

日本は本当に豊かになってしまって、人々が仕事に求めるものが「経済」ではなくなってしまった。では、人々は仕事に何を求めるかというと、それは、「やりがい」とか「楽しさ」だと思う。

いわゆるWeb系といわれている人たちを見ていると、彼らが簡単に会社を辞めていくのに驚かされる。早い人だと1年くらいで辞めていく。この間「転職しました」とか言ってたなと思ったら、もう次の会社へ行っている。

技術のコモディティ化というのはひとつの理由かもしれない。私は最新のWeb技術のことはまったくわからないのだが、でも、はてなとlivedoorだと使っている技術は同じようなものなのかなと想像はできる。

この点、我々組み込みの世界というのは、独自技術というのが多い。標準化も進んでいるのだが、それでも「VxWorksでPOSIX APIが使えます」という程度。この世界で会社を移るというのは、それだけ障壁が高い。

さて、私は入社6年目になるが、最近の仕事は「やりがい」もないし「楽しさ」もない。私はもともと低レイヤの開発をしたかったわけだが、会社(というか業界?)の方向性として、低レイヤはベンダーに任せ、アプリケーションレイヤの開発に注力するというのがある。そうすると、私としては、「最近やりたいことできてないなぁ」となる。

会社を移るかどうするか? 大体キャリアってなんだろう? 非常に悩むところである。

2011年9月1日木曜日

そろそろチャレンジしてもいいんじゃない?

エンジニアとしての生き方』という本を読んだ。おもしろくて一晩で読んでしまった。今の会社の仕事でいろいろ考えることもあって、なんとなく行き詰まりも感じているので、考えさせられる内容だった。

ウチの会社は、なにせ創業が大正時代という典型的日本企業、典型的終身雇用、典型的年功序列、その上お役人も天下ったりするのである。

今の会社には、新卒で入社してから5年半ほどお世話になっている。とても良い会社で、上司も同僚も良くしてくれる。給料も良い。が、不満もある。本当はガリガリ開発する仕事をしたいのだが、ウチの会社も例によって業界特有のITゼネコン体質なのだ。したがって、EmacsよりもWordとExcelがお友達なのである(ちなみに、最近私はEmacsからviに乗り換えた)。

そこで、私は一種のジレンマに陥ってしまう。今の会社の待遇には大満足で、経済的・物質的にはなんの不満もない。しかし、肝心のお仕事にはまったく満足していない。さて、どうするか?

ここで本書である。本書のテーマは、一言で言うと「若者よ、もっとチャレンジしなさい」ということだと思う。終身雇用なんてもう当てにならないのだし、だったら好きなこと・楽しいことを仕事にしたほうがいいではないか。

最近は私もドラッカーなど読むようになってきた。ドラッカーの言葉で、「知識労働者はボランティアと同じだ。知識社会においては仕事そのものが報酬となる」というようなことがどこかに書いてあったような気がする。

私もあと数ヶ月で30である。これまでは、「アラサー」と言いつつも追いかける側であった。今後は追いかけられる側になるのだ。そろそろチャレンジしてもいいのではないかと思った。

2011年8月16日火曜日

サイエンスキャンプの思い出

毎年行われているセキュリティ&プログラミングキャンプ(セプキャン)が今年も行われた:
http://d.hatena.ne.jp/hyoshiok/20110816
こういうイベントを見ていると、最近の子は羨ましいなと思うわけだが、 よく考えると私もこの手のイベントに参加したことがあった。サイエンスキャンプというイベントだった。ちょっとググッてみたら、今もやっているらしい。高校生を国立の研究機関などに3日くらい行かせて、科学の最前線を見せようというものだった。

私は、理由は忘れてしまったのだが、埼玉の理化学研究所を選んだ。今もそうだと思うが、当時、そこではDNAやタンパク質の構造解析を行っていた。解析にはコンピュータが使われていて、たぶん私はそこに興味を持ったのだと思う。まだ、バイオインフォマティクスなどという言葉も聞いたことがなかった頃だ。

NMRを使ってアミノ酸の構造を解析し、立体構造を推定するというデモを見せられた。ちなみに、その時使われていた計算機はシリコングラフィクスのO2であった。ただのパソコンオタクだった私はNMRが何なのかも理解できなかったが(研究員の方にかなり丁寧に解説していただいたが、それでもわからなかった)、科学の最前線を感じることはできた。

この時の経験が影響したのかわからないが、大学・大学院ではNMRの大家に師事し、化学・生物学へのコンピュータの応用を研究した。この頃、バイオインフォマティクスとか盛んに言われるようになった。結局、就職して全く別の方面に進んでしまったのだが、それでもサイエンスキャンプは私の青春のいい思い出だ。

さて、今回のセプキャンといいサイエンスキャンプといい、ともに若者、とくに10代の子たちにこうした経験をさせることはすごくよいことだと思う。

10代の子たちは、生まれた時から失われた20年である。私はかろうじて失われた10年世代で、まだバブルの雰囲気を引きずる時代で育ってきた。しかし、今の子は、物心ついた時から不景気だ不景気だと言われ、緊縮財政だとかムダ遣いをやめろとか、挙句にスーパーコンピュータはいらないとか言う政治家もいる。

こんな時代では、若者は夢が持てない。想像力を働かせることができない。大志を抱くことができない。今の若者はどーのこーのと言う大人がいるが、そんなの当たり前だ。

では、どうするか? それは、若者に投資することである。若者への投資といえば教育ということになるが、従来の意味での教育からは少し視点を変えて、若者の夢へと投資するのだ。

セプキャンもサイエンスキャンプも、これは若者の夢への投資である。大人たちは、科学技術の最前線を見せることで、「私たちはここまで来た。アナタたちは何をするか?」という質問を若者へ投げかけることで、若者の想像力を喚起する。

理化学研究所で私についてくれた研究者の方は、当時30歳過ぎくらいの方だったと思う。私もその年齢に近づいてきた。私もそろそろ投資家の側に回る時がきたのだと思う。もちろん、私は技術者としてはまだまだ未熟だと思う。しかし、それなりの経験はしてきたつもりだ。セプキャンなり何なり、私も、若者と過ごす活動ができたらよいと思う。

2011年8月14日日曜日

Scientific Linux 6.1でLinux 3.0.1をビルド

ビルドは簡単。GRUBの設定で悩んだ。忘れないようにメモしておく。

■ビルド

kernel.orgなどからソースを取ってくる。ここでは、/usr/src/linux-3.0.y以下に展開したものとする。

まず、デフォルトカーネルの.configをコピー:
# cd /usr/src/linux-3.0.y
# cp ../kernels/2.6.32-131.6.1.el6.x86_64/.config .
次に.configの設定。設定を変更しない場合でも、この操作は一度実行しておかなくてはならないみたい:
# make menuconfig    <- 設定変更しない場合は何もいじらず設定画面を終了する
# make oldconfig
あとはmakeするだけ。ThinkPad X61で1時間半くらいで終わった。案外早いものである:
# make 
■インストール

arch/x86/boot/bzImageというのができている。こいつがカーネル本体。このファイルを、/boot以下にコピーする:
# cp arch/x86/boot/bzImage /boot/vmlinuz-3.0.1
次に、モジュールをインストール。モジュールのインストールは、makeコマンドを叩けば自動でやってくれる:
# make modules_install
これで、/lib/modules以下にモジュールがインストールされた。

■GRUBの設定

ブートできるようにGRUBの設定を行う。

まずは、initrdというRAMディスクのイメージを作ろう。カーネルは、起動時にこのRAMディスク上でディスクのファイルをマウントするなどの処理を行うらしい。詳しくはこちら→http://jibun.atmarkit.co.jp/lskill01/rensai/lpicdrill06/lpicdrill01.html
# cd /boot
# mkinitrd initramfs-3.0.1.img 3.0.1
次に、/boot/grub/grub.confの設定を行う。デフォルトカーネルの設定がすでに書かれているので、これを参考に記述すればよい(と思う)。マニュアルはinfo grub。私は以下のようにしてみた:

default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
#hiddenmenu
title Scientific Linux (2.6.32-131.6.1.el6.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.32-131.6.1.el6.x86_64 ro root=/dev/mapper/vg_sllaptop-lv_root rd_LVM_LV=vg_sllaptop/lv_root rd_LVM_LV=vg_sllaptop/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet
        initrd /initramfs-2.6.32-131.6.1.el6.x86_64.img
title Scientific Linux (3.0.1)
        root (hd0,0)
        kernel /vmlinuz-3.0.1 ro root=/dev/mapper/vg_sllaptop-lv_root rhgb quiet
        initrd /initramfs-3.0.1.img
hiddenmenuをコメントにすることで、起動時にカーネルを選択できるようにする。デフォルトは0(Scientific Linuxのデフォルトカーネル)で、タイムアウトは10。

titleで始まる行が2つあるが、1つ目がデフォルトカーネル。2つ目が今回ビルドした3.0.1のカーネル。initrdには上で作った3.0.1用のinitrdを指定してあげる。

以上で、3.0.1カーネルのビルド&インストールは完了。再起動すれば3.0.1が選択できる。あとはカーネルをガンガンいじるのみ。何かおかしくなってもデフォルトカーネルでブートすれば大丈夫(かな?)。

2011年8月13日土曜日

日本の得意なシステムエンジニアリング

もう先月のことだが、中国高速鉄道(いわゆる中国新幹線)の事故がおきた。事故の犠牲者には非常に気の毒だと思う。しかし、この事故は、日本の新幹線がいかに優れているかを世界に示すものでもあった。

日本の新幹線は、開通以来一人の死亡事故も出していない。先の東日本大震災に置いても、新幹線は安全に停止し、かつ迅速にダイヤ復旧することができた。

東京オリンピックの前年の1964年に開通した東海道新幹線であるが、この新幹線計画は実は戦前からの国鉄の悲願だった。戦前は、「新幹線」とは呼ばず、「弾丸列車」と呼ばれた。

弾丸列車は、電車方式ではなく機関車方式であった。区間も、東京ー大阪間をゆうに越え、東京ー南京間を結ぶものであった。もちろん、南京まで列車で行くためには海を渡らなければならない。九州から船で朝鮮まで列車を運ぶ方式、九州から朝鮮までトンネルを掘る(!!)方式が考えられたという。

一方の中国新幹線は、開通までわずか5年。中国は急ぎすぎた。いくら日本やヨーロッパから技術導入しても、やはり短期間での付け焼刃の技術ではダメだった。日本の新幹線は、戦前から考えに考えつくされたものなのだ。

新幹線はシステムだ。私もエンジニアなのでよくわかるが、システムというものは、単に要素技術がそろえば作れるというものではない。それぞれの要素技術を組み合わせてシステムとする力、システムエンジニアリング力とでもいうものが必要だ。

私は、このシステムエンジニアリングこそが日本の生き残る道だと思っている。もう家電やケータイは韓国や台湾に任せればよい。彼らのほうが良い仕事を安くできるだろう。

日本は、実はシステムエンジニアリングが得意だ。新幹線はもちろん、他にもプラント(日本の浄水場の水は世界一安全)、発電所(日本の原発も世界一安全。議論はあるだろうが、少なくとも先の大震災までは)などなど。

しかし、例えば新幹線は、日本の主要な輸出品目ではない。最近になってようやく海外への売り込みが始まったばかりである。しかも、JR東海とJR東日本で別々に売り込むなど、これでは買う方も混乱するのではないか。

中国新幹線は、日本の重工メーカーが車両技術を輸出した形になっている。しかし、新幹線は単なる車両ではない。システムだ。だから、単に要素技術としての車両を売るのではなく、新幹線としてのシステムを売るべきだった。

よく言われるように、国鉄民営化の際、単純にJRを地域で分けてしまったのがよくない。地域で分けるのではなく、「JR新幹線株式会社」を作るべきだった。そうして、新幹線に関する運用ノウハウをすべてここに集約し、このノウハウとセットで新幹線を売り出すべきだった。

大震災以降、日本再生・経済復興が叫ばれる。単に日本経済を「もとに戻す」のではなく、「次へ進める」ものであってほしい。