Microsoftに捧ぐ
理論的にはソフトウェアが壊れるということはない。長く使っているうちにビットがすり減ってしまうということはあり得ない。何かがうまく動かないのは、はじめから壊れていたのだ。それにも関わらず、世界中のプログラマが、ソフトウェアが壊れていくさまを目撃する。昨日までうまく動いていたものが、今日はコアを吐く。 バグを見つけたら修正しなければならない。しかし、そのバグフィックス自体が、新たなバグを持ち込む可能性がある。したがって、ソフトウェアにはメンテナンスが必要である。このメンテナンスには終わりはない。ソフトウェアは「リリースしたら終わり」の製品ではない。 ソフトウェアベンダーは植木屋と同じである。植木屋は、植木を「リリースしたら終わり」ではない。何十年、ときには何百年も成長し続けるという植物の性質上、植木にも終わりのないメンテナンスが必要である。この点では、日本の植木職人もヨーロッパの庭師も同じであ
読むために生まれ: エンジニアのジレンマ
技術は何を作ればいいかは教えてくれない。技術は如何に作ればよいかを教えるのみである。世界で最も優れたエンジニアとは、何を作ればいいか教えてくれれば何でも作ってみせると約束する者である。 優れた技術を持つはずのエンジニアが、精巧なゴミを作り続ける理由はここにある。今日のゴミはWebインタフェースを持ち、明日はAndroidアプリとなる。だが、どんなにキラキラかがやいていようと、どんなにフワフワしたおまけが付いていようと、ゴミはゴミである。 皮肉なことに、優秀なエンジニアは、自分の作っているものがゴミだと知っている。単に、ゴミ以外に何を作ればいいか知らないのだ。エンジニアのジレンマである。 技術とは如何に作るかについての知識である。知識とは形式化され体系化され教育によって学ぶことができるものである。技術と教育システムの発達した現代においては、教育によって優秀なエンジニアを育てることができるよう
若いエンジニアへ
エンジニアなら誰でも突貫工事に喜びを見出した経験がある。深夜2時の夜食を共にした同僚のことは、その職業人生を通じて忘れることはない。しかし、そこにいかなるドラマがあろうとも、突貫工事は例外である。これを常態としてはならない。 メーカーの組込みプログラマとしてエンジニアのキャリアをスタートした私は、「よい製品はよいプロセスから生まれる」ことを頭に叩きこまれた。素晴らしい製品を生み出す工場は静かである。常に誰かが大声で叫んでいるような工場には明らかにプロセス上の問題が認められ、素晴らしい製品を生むことは決してない。 本物のエンジニアは突貫工事を好まない。突貫工事とはプロセス上の誤りであり、つまり誰かが大声で叫ばなければならないということだからである。エンジニアの仕事は計画され、コントロールされたものでなければならない。 長時間労働によって成果を生み出そうとすることも、やはり例外としなければなら
リアルタイム・コンピューティングとカント主義
ミラクル・リナックスに入社してちょうど3ヶ月が経った。試用期間が終わり、正式（？）に採用となった。散々遅刻したのにクビにならなかったので、ほっとしている。これからはフレックスタイムが使えるので、大いに寝坊できるとうものだ。 4月末に、「実績レビュー」なるものがあった。社長以下各セクションのトップを集め、プレゼンを行い、この3ヶ月の仕事を見てもらって、継続して雇うかどうかを判断してもらおうというわけだ。これが、1時間も時間がとってあった。長い。 困ってしまった。私のプレゼンのスタイルは、「瞬発力で勝負」というものであって、せいぜい15分がいいところ。そもそも、1時間もしゃべる話題がない。うっかり口を滑らせて、「Linuxでリアルタイム・コンピューティングをやりたい」と言ってしまったところ、思いの外盛り上がった。 コンピューティングの世界で、「リアルタイム・コンピューティング」ほど誤解されてい
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の逆アセンブルであったという。もちろ
『オペレーティングシステム 設計と実装 第3版』を読んだ
1953年、ワトソンとクリックによりDNAの二重らせん構造が発見されたとき、生命には神がかり的なものは何もないことが明らかとなった。以来、生命をめぐる神学上の諸々の問題は、科学とエンジニアリングの問題となった。本書を読めば、読者は、オペレーティングシステムのカーネルについて同じ発見をすることになる。 本書は、私の家の積読本コーナーにもう長いこと置かれていた。本書の原書が出版されたのが2005年。本書は、その翻訳として2007年に出版された。翻訳が出版されてすぐに手に入れたのだが、ずっと読めずにいた。何度か読もうと挑戦したものの、途中で挫折してしまっていた。読書会にも参加したが、途中で脱落してしまった。 今回、何度目かの挑戦で、ようやく読み終えることができた。実は、この本を読むのには、少々コツがあったのだ。本書は、1000ページを超える大著である上、本の後ろ半分がソースコードという、かなり特
『Operating System Design: The Xinu Approach, Linksys Version』を読んだ
実際のOSのソースコードを示して解説する教科書といえば、TanenbaumのMINIXが有名である。本書は、Dougras ComerによるXINUというOSにつての同様の趣旨の本である。このような本があるという事は、以前から知ってはいた： XINU（"XINU is Not UNIX"の略）オペレーティングシステムの開発について述べた優れた本。＜中略＞この本はオペレーティングシステム概論の授業の副読本としてうってつけで、UNIXカーネルの授業でLionsのテキストと一緒に使っても良いくらいだ。（『Life with UNIX』p.127） この記述は本書の初版本に関するもので、LSI 11というPDP-11をワンチップ化したハードウェアを対象に書かれたものである。Amazonで調べてみると、本書はその後、PC版やMac版が出ていたようである。しかし、長いこと絶版となっていた。 ところが最
忍び寄る全体主義
私が三菱電機を辞めた理由のひとつは、組織のもつ全体主義的傾向を嫌ってのことだった。全体主義とは、皆が同じ考えをもつことではない。そんなことは不可能だ。全体主義とは、皆が同じ考えをもつことを強制することである。従って、全体主義のもとでは、人は皆と同じ考えを持っているふりをするようになる。 ひとつ象徴的な例がある。私のいた事業所では、改善活動が行われていた。いわゆる「カイゼン」活動である。製造業なら、どこでもやっていると思う。職員全員について、改善のノルマが課せられていた。技術者も、事務職員も、現場の職人も例外は認められない。通常は1月に1件以上だった。 どういうわけか、改善の効果は、節約時間によって計られることになっていた。そして、年度ごとにトータルの節約時間が定められ、各セクションにその時間が割り当てられた。この時間は最低の基準とされた。 誰の目から見ても、この改善活動は馬鹿げていた。一人
技術者の倫理
ミラクル・リナックスに入社して1ヶ月経った。3月からまた新しい人（NetBSDハッカー！！）が入ったので、昨日は歓迎会だった。つまりは飲み会なのだけれども、ミラクルの人たちと話していてひとつ驚いたことがある。彼らは、会社の飲み会で技術の話をするのだ。往年の親指シフトから、最新の（？）GNU Hurdまでが話題に上がった。 技術者には個性というものがある。強みである。もちろん、弱みともなりうる。前職の三菱電機では、マネジメント上の最大の焦点とされたものに、技術者の個性の無効化がる。無効化という言葉が過激すぎるなら、均質化と言い換えてもよい。逆に、ちょっと過激な言葉を使うならば、前職のマネジャーたちは、技術者を交換可能な標準化された部品とみなした。 天才的技術者がいたとする。すべての製品を彼の天才に頼っていたとする。ある朝、彼が交通事故に遭うようなことがあれば、直ちに事業は破綻する（スーパーコ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
