ユメのチカラ

デバッグ方法論

実践的なデバッグ方法論（デバッグの仕方、事例研究）も強く求められている。デバッガーというツール依存のTipsではなく、ソフトウェアのデバッグというプロセスそのものの形式化である。

人々は誰に教わるでもなく自分のデバッグのスタイルを持っている。自分なりな定石を獲得している。しかしそれを明示化して人に伝えようと試みる人は少ない。伝承がまったく不可能なような議論も少なくない。

わたしはオープンソースの時代こそデバッグの方法論を広く共有できるチャンスに満ちた時代だと考えている。いくつか事例を紹介しつつ解説する。

優れたプログラマは優れたデバッグ方法論を持つ。そのデバッグ方法論をぜひ共有化したい。そのためには情報公開が要である。

デバッグとはプログラムの不具合を修正するプロセスである。テストなどによって発見された何らかの不具合を期待する結果に修正する作業である。テストとデバッグの区別が十分ついていない初心者プログラマもいるが、これは明確に異なるプロセスである。テストは不具合を見つけるプロセス。デバッグはその不具合を直すプロセスである。

生産性の高いテストというのは単位時間あたりたくさんのバグ（不具合）を発見したテストであり、バグを発見したテストについては、テストに成功したというべきである。

一方生産性の高いデバッグというのは単位時間あたりたくさんのバグを修正したものである。

デバッグのプロセスというのは、不具合を認識（それは仕様だという場合もある）、現象を確認（再現方法の確認）、問題の理解、修正、直っていることの確認みたいな感じになる。

問題修正の部分だけをデバッグと狭義に捉える人もいるが、問題を理解しない限り問題は修正できないし、問題を理解するためには現象を再現し確認する必要もあるので、それらも含めたプロセスと認識するのが正しいと思う。

不具合というのは、ある入力に対して期待する出力（状態変移）と異なる出力という風に考えられる。期待する出力というのは、仕様を定義した人によって定義されるので必ずしも利用者のそれではないので、悪名高き「それは仕様です」ということが起こる。

それはともかく、ユメのチカラからデバッグ方法論についてのエントリをみてみよう。

プロセスプログラミングの実践方法
http://blog.miraclelinux.com/yume/2006/07/post_93da.html
デバッグのプロセスを記述することによって、デバッグのプロセスそのものをデバッグしようと言うことを提案している。プログラマとしての技量を向上させるにはデバッグ力（リョク）を向上させなければいけないが、その方法論としてデバッグのプロセスを記述し公開し共有することによって世界の誰かの目にふれさせバザール的に進化させようという試みである。

デバッグの話（昔の日記から）
http://blog.miraclelinux.com/yume/2006/07/post_b753.html
昔の日記（シリコンバレー日記）から引用している。

「ソフトウェア開発の非常に人間的な部分であるデバッグのプロセスをもっともっと深く理解したい。その思いは10年位前と変わらない。しかしながらこの10年で自分がどれほど進歩したかと言うと正直言って忸怩たるものがある。商用ソフトウェアを作っていた当時と比べて自分の専門性がどれだけ研ぎ澄まされたかと言うとほとんど進歩していないのではないだろうか。そう考えると道はとてつもなく長く険しい。

しかし10年前と現在で大きく変わったことがある。OSSとインターネットである。

10年前わたしが記述したバグ情報はすべてプロプライエタリな情報として企業の壁の中にあり同僚以外と共有することができなかった。わたしの書いたコードは門外不出だし、変更記録も、バグデータベースの記述ももちろん知的所有権の名の元に幽閉されている。

10年前はわたしとあなたは微視的なデバッグの記述を共有できなかった。

ところが10年たってわれわれはオープンソースと出会い、わたしはわたしのコードだけではなく、わたしのつたないデバッグのプロセスをあなたや世界中の誰かと自由に分かち合うことができるようになった。

なんていうことだ。

[中略]

OSSとインターネットというのはすごい環境である。」

本当にすごいことである。これを使わない手はない。自らのプログラマとしてのプロフェッショナルな価値を向上させるためにもデバッグ方法論・事例を公開し共有したいものである。

gdbの実践的使い方
http://blog.miraclelinux.com/yume/2006/09/post_fa59.html
「ソースコードの読み方」でも紹介したが、OSS定番のgdbの実践的使い方である。

トラブルシューティングの実際
http://blog.miraclelinux.com/yume/2006/10/post_5353.html
これも「ソースコードの読み方」で紹介したが、MySQLで\(半角)→＼(全角)に化けるという問題（円マークが全角の＼に化ける）についてどのように問題を分析していったかという事例である。問題領域の知識というのは必要であるが、そのトラブルシューティングの足跡というのは参考になると思う。

大規模ソフトウェアをgdbを利用して微視的視点から理解をする
http://blog.miraclelinux.com/yume/2006/09/post_8096.html
こんどはPHPでの問題である。同様に問題をどう認識して、ソースコードレベルで理解するかというプロセスを書いている。

コードを読むな、理解しろ
http://blog.miraclelinux.com/yume/2006/10/post_e3d6.html
rubyの実装をCPUキャッシュミスの観点からデバッグ（？）した事例を示している。oprofileを利用してL1キャッシュミスを計測しそれをチューニングしたというお話である。rubyの実装への実用的な価値はないのであるが、キャッシュミスをどう削減するかという事例にはなっているので参考になると思う。

PHPだろうがMySQLだろうがrubyだろうが、その構造の全般的な理解は必要ではあるが、ソースコードがあるんだから時間をかければ（早いか遅いか、上手か下手かはあるとしても）だれでも再現可能なプロセスである。

わたしはPHPやMySQLあるいは題材にしたrubyの実装についてはほとんど知らない。しかしC言語が読めて各種ソフトウェアツール(gdb/find/grep/xemacs/cscopeなどなど）が使えれば特に難しいことをするわけでもなく大抵のことができる。

コードを読むチカラ、コードを理解するチカラ。デバッグするチカラ。

OSSの時代にはそれらが強く求められている。

そしてインターネットとOSSのおかげでデバッグの方法論は世界中で共有できるようになったのである。素晴らしい世の中になったものである。

上で紹介した事例についてじっくり読んで自分自身のデバッグ事例についてぜひトラックバックで教えてほしい。世界はあなたのデバッグ事例を待っている。

ツッコミ力

ツッコミカではなくてツッコミ力（リョク）。

一昨日記した「ソースコードの読み方」が思いのほかすごい量のはてなブックマークを頂く。現時点で466個も。わたしの歴代一位のブックマークである。ありがとうございます。（ぺこり）
http://b.hatena.ne.jp/entry/http://blog.miraclelinux.com/yume/2007/08/post_d6bd.html

タグの種類で見てみると、programming（プログラミング）、あとで読む、code reading、ソースコード、ソースコード、読み物、まとめ、などなど。

コメントを記している人はそれほど多くない。あとで読むというタグが多いというのも特徴だ。

多分、「あとで読む」というワイルドカードをつけた人の心理としては、取りあえずブックマークでもしとくかというような感じかと思う。実際読むかどうかは別として。なんとなくブックマークしておけば安心みたいな心理かなと。よくテスト前にあたふたと友人のノートや過去問題をコピーして安心して結局勉強しないみたいなものとにている（本当かな？）。

アクセスログを見ていると、わたしが紹介したリンクへのアクセスというのは
コードを読むな、理解しろ
http://blog.miraclelinux.com/yume/2006/10/post_e3d6.html
へのアクセスが一番多くて約10％前後。それ以外へのアクセスはほとんどない。しょぼしょぼ。

やはり、忙しい人の心理としてざっと目を通して、面白そうだったらブックマークして、そのうちのごく少数の人がリンク先までたどっていくという感じかと思う。

わたしはどちらかというとリンク先までたどっていってずっぽりハマってふと気がつくと何時間もたっていたという傾向が強い。づんづん縦型サーチをしていくみたいな。

閑話休題。

ブックマークがいっぱいつくというのは「炎上」みたいなイメージがわたしには微妙にあったのだが、今回のは純粋に参考にしようみたいな感じなので、コメントやタグもしごく真っ当（？）というか当たり障りのないものばかりで半分ほっとしている。やっぱり、コメントとかで罵詈雑言を浴びせ倒されるというのは気分がよくないし。（わたしは誉められて伸びるタイプである←自分で言うな）

ブックマークのコメント欄でツッコミをいれるというのは、トラックバックを打つよりお気楽なので、ブックマークされる側にとっては本音というかカジュアルな意見が聞けてそれはそれでうれしい。

ブックマークはページビューの何倍もうれしいが、ちょっとしたコメントが書いてあるとさらにうれしさが倍増するので、励ましのコメント絶賛募集中である。

全然ツッコミ力のお話にならなかったような気がするが、ま、いいか。

チューニング

パフォーマンスチューニングというのも非常に重要な問題だ。黒魔術のようなかんじもしなくもないが、ヨタ話をいろいろ書いてみる。

性能の問題が表面化した場合、やみくもにパラメータをいじくりまわして問題を悪化させてしまう場合があるが、そーゆーことは避けたい。

何が問題なのか、定量的なゴールを明確化しないと、単なる感覚論になってしまって不毛な時間をついやすことになるので注意が必要である。

パフォーマンスチューニングの参考書はいろいろあると思うので適宜みつけだしてほしいが定番のこれはというのは、あるようでいてよくわからない。データベースのチューニングという題材での書籍はいろいろあるがいかんせん製品特有のTipsにかたよったものが多くてあまり汎用性がなかったりする。Oracleのパラメータを勉強するというのはそれはそれで必要なのだけど、わたしが目指しているものとちょっと違う。

ここでは一般的なアプリケーションのチューニングくらいの軽いノリのお話をする。

チューニングするくらいだから性能に満足していないという前提であるが、性能に特に不満がないのなら無理をしてチューニングする必要はない(当たり前だけど)。

性能とはここでは速度の事を言うことにするが、それ以外でもメモリ消費量だとか、ディスク消費量だとか別の次元でのチューニングというのもありえる。

CPU、IO、メモリなどはCPU時間、IO時間などを計測すれば、どこがボトルネックになっているかわかる。ロック競合の場合、CPUやIOはまだまだ余裕があるのにスループットが出ないなどの現象がでたりする。

いずれにせよ現状を正確に理解することが第一歩になる。

CPUボトルネックの場合、アルゴリズム、データ構造の改良などが必要になるが、そのまえに定量的な測定がかかせない。

速度を計測する基本は、時計である。実行にどれだけかかったかを計測する。それこそストップウオッチからはじまって、Linuxでは time コマンドを利用したりする。アプリケーションからであればgettimeofday()なんかを利用する。もっと精度をほしければTSC(time stamp counter)を利用するとよい。

実行プロファイルをとる。

linuxの場合oprofileが利用できるので、それを使おう。

ユメのチカラでは下記のエントリーが参考になる。

Rubyのプロファイリング
http://blog.miraclelinux.com/yume/2006/10/ruby_0b0e.html

実際にrubyの実装を題材にoprofileで計測し、ボトルネックを発見した事例を示している。

コードを読むな、理解しろ
http://blog.miraclelinux.com/yume/2006/10/post_e3d6.html

上記の性能チューニングのお話のまとめである。パッチの作り方も含めて事例を示している。ボトルネックを発見できれば、比較的簡単に解決策は見つかる。

もうすこし本格的なカーネルチューニングは以下である。

Linux Kernel 2.6.18とCache Pollution Aware Patch
http://blog.miraclelinux.com/yume/2006/09/linux_kernel_26_2c2c.html

2.6.18に採用されたカーネルパッチは下記のプロジェクトで作ったのだが、iozoneというベンチマークを実施し、oprofileでCPUキャッシュミスを計測した。そのボトルネックの部分についてカーネルパッチを作成し、効果を検証した。

キャッシュミスを発見するのはoprofileを利用すれば簡単にできる。ただ、その現象を解決するカーネルパッチの実装は(自分にとっては)簡単ではなかったが、パターンを発見したので今後同様の現象であれば、同じ方式で解決できる。

詳細については下記の報告書を参照されたい。

2005年度オープンソースソフトウェア活用基盤整備事業
「OSS性能・信頼性評価／障害解析ツール開発」
OS層
〜CPUスケーラビリティ評価編〜OS-cpu.pdfをダウンロード

闘うプログラマ

わたしが紹介するまでもなく、「 闘うプログラマー〈上〉」、「 闘うプログラマー〈下〉」はビル・ゲイツの野望を実現すべく雇われた「伝説のプログラマ」デイブ・カトラーのＮＴ開発物語である。

わたしはデイブ・カトラーに会ったことはないがDEC時代にいろいろ伝説は聞いていた。一番、有名な都市伝説は、Windows NT (WNT)というのはVMS (DECのベストセラーマシンVAXのOS)を一文字づつずらした名前にしたというものである。誰かがデイブ・カトラーにその真偽を問うメールをしたところ、今ごろ気がついたのかよ、という返信が来たという。90年代初頭にそのようなメールがでまわっていたような記憶がある。

それはともかく鬼軍曹のような風貌のプロジェクトリーダ率いるＮＴ開発物語はザカリーの筆力もありぐいぐいと人を引きつける。

それは栄光と挫折の物語である。20世紀最後の商用ＯＳ開発物語と言ってもいい。このような大規模な商用ＯＳ開発はあとにも先にもマイクロソフトでの開発が最後になるであろう。専用ＯＳや小規模なそれの開発は今後も続くであろうが、商用でクローズな世界での大規模新規ＯＳ開発は今後は見られないであろう。

ＯＳＳ(オープンソースソフトウェア)がＯＳの作り方を大聖堂(伽藍型)からバザール型へ変えてしまった。マイクロソフトは今後も大聖堂型でソフトウェアを作り続けるだろうが、NT開発物語のような社運をかけたOSの新規からの開発はもやはないのではないだろうか。

90年代の初頭というのは、そのような時代であった。商用ソフトウェアベンダは自社の基幹ソフトウェアを社運を掛けて開発していたのである。一か八かで、掛金全部をその製品の開発に掛けた。

この本を読んだ当時わたしはDECからOracleに移ったばかりで、本物のプログラマ達がおりなす壮大な20世紀のドラマに心を踊らされたものである。

そしてそのような大規模ソフトウェア開発というのはマイクロソフトをはじめとする米国のソフトウェア企業にしかなかった。米国OracleからOracle 8の開発に参加しないかと声をかけられたのは正にそのころである。Oracle 8の開発というのは当時の米国Oracleにとっては一か八かの大勝負のプロジェクトであり、そこには間違いなく人を引きつける何かがあった。

わたしは一兵卒としてその開発に参加した。正直言って36歳での参加というのは若くないし、はたして使いものになるのか不安に大きかったが、このまま日本という地域で現場を見ないまま終るのか(？)、それともリスクも含めて一切合切腹をくくってチャレンジするのか、その選択でわたしは後者を選んだ。

朝から晩までコードを書いてテストをしてデバッグをする。それを延々日々繰り返す。プログラマとして充実した日々を過したように思う。

いつの日か「闘うプログラマ」の現場に立合いたいと思っていたのがOracleで実現した。自分なりにいつの日かにそれを総括してみたいと思っていたのだが、オープンソースに出会い、大規模ソフトウェアの開発は社内ではなく社外文字通り地球規模でおこなわれつつあるという予感を感じたのである。

21世紀はマイクロソフトやOracleに勤務しなくても大規模ソフトウェア開発に参加できる。素晴しい機会に満ちているではないか、そう思ったのである。オープンソースの奇跡と言ってもいい。

下記は1998年8月に記したシリコンバレー日記である。
----------------------------------
1998年8月5日(シリコンバレー日記より)
大聖堂とバザール
今年は本当にいろいろ日記を書いている．今日までに３０数本書いている．近年まれにみる快挙である．それだけネタに困らなかったのかもしれない．今年の頭に日記を復活した時，わたしの中には，１９９７年にわたしが何をしたかを忘れないうちに記そうという気持ちがあった．１９９７年のことでその予告をしたのだけれど昨今昔のネタはほとんどでてこない．それもこれもNetscapeの決断である．ソースコードの公開である．Mozillaで，http://www.mozilla.org/を紹介しつつ自分の期待を語った．

わたしは年頭になにを語りたかったのか？それを今から思い返してみるとこんなことだ．わたしはある大規模ソフトウェアプロジェクトに参加した．それも設計の初期の段階から，実装，テスト，リリースまでプロジェクトの一員として日々一喜一憂しながら関わった．そしてそのプロジェクトの成果は出荷された．それを自分なりに消化した形で総括したかった．

多くの人が関わるプロジェクトである．そこには人間のドラマがあるはづである．何かして，それはうまく行く場合もあるが失敗する場合もあるのだか，そこからなにがしかを学んでいく過程を記録に残しておきたかった．それは一つは自分のプログラマとしての成長の記録になるはづだし，内側からみたソフトウェアプロジェクトの貴重な資料にもなりえるのではないだろうかという思いがあった．

一人のプログラマがシリコンバレーに来て，そこでプログラマとして働くということはどういう事か？それを明らかにしたかったのである．それもできるだけ平易な形で．

ブルックスはＩＢＭのＯＳ３６０の開発の経験から「ソフトウェア開発の神話」という名著を記した．キダーはデータジェネラルのミニコン開発を「超マシン誕生―コンピュータ野郎たちの540日 (1982年)」で克明に記述した．ザカリーは「闘うプログラマー」でマイクロソフトのＮＴ開発部隊の生態を明らかにした．失敗と苦悩とそして栄光の物語である．

誰でも自分の行動を正当化する．過去は美化される．思い出は時として理想化され，記憶は風化する．

プログラマとしてのキャリアを続けていく以上，前のプロジェクトから何を学んだかを記すことは，記憶を風化する前にしなければいけない自分自身への宿題でもあったわけだ．

その作業が遅々として進まないうちにもっと自分にとって面白い事件が発生した．それが今回のモジラの解剖である．これは仕事ではない．単なる趣味の延長である．しかしながらその趣味は自分のプロフェッショナルな領域とほとんど重なる．プログラムの開発スタイルも開発されるものも全く異なるにもかかわらずプログラムを作るという個人的な作業の上では共通点も多い．すくなくとも自分の心の中でプロジェクトを楽しんでいるという意味では会社でのプロジェクトもモジラも同じスタンスにある．そして年頭に大規模開発の現場の話を誰かに伝えたいと思ったようにわたしは今起っているオープンソースの流れを誰かに伝えたくて伝えたくてしょうがなくなってきたのだ．

今年Ｎｅｔｓｃａｐｅがソースコードを公開するにあたっていくつかのエッセイを紹介していた．そのうちの一つがEric RaymondのThe Cathedral and the Bazaar(大聖堂とバザール）である．これは山形浩生によって日本語に翻訳されている． 伽藍とバザール を参照．

その論文には口上として「Ｎｅｔｓｃａｐｅがソースコード公開をするにいたって理論的な根拠となった論文」とか書かれていたのだけれど，わたしは，いくらなんでもそんなことはあるまいと思った．つまり，恥ずかしながら「わたしのあくまでの想像ですが，ネットスケープのお偉方が，件の論文を見て，おお，この論文いい事書いてあるから，いっちょこのモデルでやってみよー，そーだ，そーだ，とかいう事を取締会議かなんかでやったかというとたぶんそんなことはありえないんじゃないかなあ．そんな論文があろうがなかろうが，それと独立にネットスケープは決断したわけですね．その仮定が正しいとすると，理論的根拠というのはいいすぎなのではと思ったです．少なくとも謝辞の中にネットスケープの人の名前は一人もでていないし，直接的な関連はないのではないでしょうか？」などと能天気に記していたのである．ところがである．当該論文のエピローグにその後の話が載っていて，Ｎｅｔｓｃａｐｅの取締役がＥｒｉｃにメールを出し，２月４日の戦略会議に招待されたとかいうエピローグまで紹介されているのである．わたしはまるっきり間違っていた．赤っ恥をかいたのである．

Ｅｒｉｃは，従来型のソフトウェア開発の方法論を大聖堂（Cathedral）アプローチと呼んでいるのだが，大聖堂を組み立てるように注意深く管理されたアプローチと，バザールのような混沌としたスタイルを対比している．そして明らかなことにわたしは大聖堂のプログラマであった．自分自身はＧＮＵの事やＬｉｎｕｘに一定の理解を示しつつもバザールがすぐそこまで来ているということに全く気がついていなかったのだ．

大聖堂には大聖堂の掟やスタイルがある．その開発はなかなか面白い．ものを作ることは人間を根源的に満たすなにかがあるのかもしれない．そんなことを記したかったのかもしれない．

それがモジラの登場でいきなりバザールにぶっこまれて迷子になりそうになりながら，そのバザールの面白さダイナミックさに一気に虜になってしまったのである．そして，奇妙なことに自分の中では矛盾なく大聖堂もバザールも同時に楽しんでいるのである．

なかなか不思議な時代感覚である．
----------------------------------
http://web.archive.org/web/19990424133227/www.best.com/~yoshioka/d/98/i980805.html (文字コードをシフトJISにして読んでください)

ソースコードの読み方

ソフトウェア工学の標準的なカリキュラムにソースコードの読み方というのがあるのかないのか知らないが、プログラマとして最も重要な資質の一つにコードの読解力というのがある。

ついでに言えば、大学や専門学校であまり教えられているとはいえないけど、実践では常に必要とされているものとして、テストの方法論、デバッグの方法論、性能向上の方法論、メモリなど各種資源の削減方法論などなどがある。国際化、移植性なども重要な単元であるがソフトウェア工学の中で教授されていると言う話はあまり聞かない。コードのハック一般についてどこかで議論されているのだろうか。経団連あたりで議論しているのだろうか？

閑話休題。

ソースコードの読み方ということで、最近では「コード・リーディング」というそのものずばりの教科書も出ているので状況は好転しつつある。コードの読み方はオープンソースの時代になり、間違いなく広く情報を共有できるようになった。これはいいことである。時代の進歩といっても差し支えない。

カーネル読書会ではその道の優れたプログラマにお話を聞くが、わたしは時々、どうやってデバッグをしているかとか、どうやってコードを読むかというような質問をする。暗黙知としてハッカーがもっているものを言語化してもらってどうにか形式知にしたいと思っている。

しかし、そうは言ってもまだまだ職人芸の世界で、なかなか優れたプログラマの技法というのが形式知化されているとは言いがたい。定石を集めたいところである。

ユメのチカラでは下記のエントリを記した。

コードを読むな、理解しろ
http://blog.miraclelinux.com/yume/2006/10/post_e3d6.html

これはoprofileを利用してrubyをハックした事例である。コードを読むのは端から端まで直列で読んでいたらいくら時間があっても読みきれない。コードを読むには、コードを読まないテクニックが必要でそれを紹介した。ブックマークやトラックバックもいっぱいいただいた。

トラブルシューティングの実際
http://blog.miraclelinux.com/yume/2006/10/post_5353.html
実際にあった問題を、ソースコードの観点から理解するという事例である。使っている道具立てはgrep/findなどなど標準的なものばかりだ。別段トリッキーなことをしているわけではない。包丁とフライパンだけで料理を作るようなものである。職人は道具を使いこなす。その技を見てほしい。

なぜソースコードを読むのか？
http://blog.miraclelinux.com/yume/2006/08/post_3771.html
そのものずばりの話題について記した1999年ころの記事である。大聖堂のプログラマであったわたしがオープンソースの潮流に触れその可能性にわくわくしていた感覚がある。「ソースコードを読む。その基礎的な技術がオープン・ソースの時代には最も必要とされているのである。」と断言しているが、その確信は今でもゆるぎない。

下記は大規模ソフトウェアの効率的な理解という観点で記した。ざっくり通しで読んでいただければ幸いである。

大規模ソフトウェアの効率的な理解
http://blog.miraclelinux.com/yume/2006/08/post_cae5.html
「OSSの時代こそ大規模ソフトウェアの実装の効率的な理解の方法論が求められている。企業が自分が作ったソフトウェアを自社のエンジニアに教育（OJT）するのと違って、OSSはそのような内部構造の教育コースがない。自分のすぐそばにコア開発者がいないので簡単に聞くことが難しい。
中略
その実践的な方法論についていろいろ議論していきたいと思う。」

大規模ソフトウェアの効率的な理解（その2）
http://blog.miraclelinux.com/yume/2006/08/2_2d39.html
ソフトウェアの規模を下記のように定義した。
    規模         行数
    小規模       10万行以内
    中規模       10万〜100万行程度
    大規模       100万行以上
ソフトウェアを構成する行数でおおざっぱにくくっている。あるいは開発に関与する人数によっても同様にくくれる。
    規模         人数
    小規模       10人以内
    中規模       10人〜100人程度
    大規模       100人以上

大規模ソフトウェアの効率的な理解（その3）
http://blog.miraclelinux.com/yume/2006/08/3_dc26.html
規模の把握。

大規模ソフトウェアの効率的な理解（その4）
http://blog.miraclelinux.com/yume/2006/08/4_4b7e.html
巨視的、微視的な理解という観点を提示している。

大規模ソフトウェアの効率的な理解（その5）
http://blog.miraclelinux.com/yume/2006/08/5_de60.html
「動的というのはソフトウェアを実行した時の挙動のことをさし、静的というのはソフトウェア(プログラム)の字面をさす。」
動的理解、静的理解という側面から解説した。

大規模ソフトウェアの効率的な理解（その6）、リグレッションテスト
http://blog.miraclelinux.com/yume/2006/08/6_570e.html
「OSSの実装も単にソースコードやドキュメントを整備するだけではなく、リグレッションテストをどれだけ充実するかという視点で議論、評価される時が来ているように感じる。よりOSSが大規模になり、修正が頻繁に求められるようになるとリグレッションテストが整備されているかいないかで、その変化に対する対応力が全然かわってくるのである。」

gdbの実践的使い方
http://blog.miraclelinux.com/yume/2006/09/post_fa59.html
gdbをデバッガとしてしか利用していないとしたらその威力の10%も利用していない。gdbはソースコードを読むためのツールである。「gdbはソースコードの理解を助ける偉大なツールなのである。」

gdb/xemacs/cscopeの使い方
http://blog.miraclelinux.com/yume/2006/09/gdbxemacscscope_e0da.html
「プログラムの状態は変数の値の変化によって変化していくわけだが、変数は、宣言され、値を代入され、参照されるなどして利用される。」

おまけ：
カーネル読書会とよしおかの野望
http://blog.miraclelinux.com/yume/2006/07/post_69b1.html
「ソースコードを読むことは楽しい。そういうと、多くの人は怪訝な顔をする。無理強いはしないしするつもりもないし、もちろんできないのであるが、ソースコードを読むことが楽しいということを少しでも多くの人に伝えたくて、あるいはそのような同好の士を発掘したく、ぼそぼそと続けている。」

本日のエントリーはソースコードの読み方という観点からまとめてみたが、テストの仕方、デバッグの仕方、性能問題の発見とチューニングなどなどについてもいつかは記していきたいと思う。コメント、トラックバックなどをお待ちする。

追記：
はてなブックマークを多数の方に付けていただいている。（これを書いている時点で100を越えている。）どうもありがとうございます。下記も参考になると思う。
大規模ソフトウェアをgdbを利用して微視的視点から理解をする
http://blog.miraclelinux.com/yume/2006/09/post_8096.html
gdbを利用して、どのようにソースコードを理解するか事例を紹介している。実際にあった事例なので、瑣末なめんどくさい事も含めて参考になると思う。現場はそのような瑣末なことがらにみちみちているのである。

世界陸上

ハゲタカのことをしつこく書いたので、数字がぐう～んと上がった匂いがするよ。というわけで普段TVはあまり見ないのだがTVネタを書くとページビューがぐう～んと上がるようである。

というわけで数字を上げるという二匹目のドジョウ狙いで世界陸上である。TBSががしがし放送をしているようである。しかし今ひとつ盛り上がらない。自分的にはなかなか感情移入できていない。

ウィキペディアで世界陸上というのはいったいなもののか調べてみた。2年に一度開催されるのか。ふむふむ。200前後の国や地域から参加者があるのか。へー。オリンピックより多いのか。

世界陸上選手権 - Wikipedia
http://ja.wikipedia.org/wiki/%E4%B8%96%E7%95%8C%E9%99%B8%E4%B8%8A

スポーツナビ | 世界陸上2007大阪
http://sportsnavi.yahoo.co.jp/other/athletic/iaafwc/2007/index.html

Suica

Suicaの定期券を使っている。便利は便利である。

先日、東京メトロの職員が知人の氏名と誕生日を入力し該当者の電話番号等個人情報を入手して、あろうことかそれをブログで公開していたという事件があった。

悪意のある内部犯行者には、個人情報が筒抜けということである。東京メトロの管理責任も問われるところであるが、内部犯行に対しては有効な防衛策というのは、なかなか難しいかもしれない。

むかし、「切符を買う」（未来のいつか）という日記を書いた。氏名、誕生日、電話番号、住所、などの個人情報と、わたしがいつどの路線を使ってどこに行ったかという情報が結びつく。それが誰かにこっそり知られ可能性があるというのは、それはそれで相当気持ちが悪い。

政府要人であればそのようなプライバシーというのがなくてもしょうがないが、ふつーの人間の行動履歴ですら全てトレース可能というのは、ちょっとやりすぎのような感じもしなくはない。

積極的に情報を捨てる(集めない)というアクションをとる組織が信頼感を集める時代が来るかもしれない。

シリコンバレーの思い出

今から約10年くらいまえにシリコンバレーにいた。米国Oracleのデータベースエンジンの開発部隊にいた。さらにそれを遡ること数年前、米国DECのデータベースの開発部隊、これは東海岸(New Hampshire州Nashua)にあった、で開発していた。

われわれはよく欧米とか言う。欧州の国々の文化と米国の文化を一緒くたに議論したりしがちである。しかし、米国と英国ですら文化的には随分違うし、ドイツ、スペイン、スウェーデンなどなども相当違うのではないかと想像する。

米国ですら、東海岸と西海岸も生活してみて、これが同じ国かというほど違う。東海岸といっぱひとからげに言うのも語弊があるかもしれないが、ニューハンプシャー州の住んでいたところと、西海岸のシリコンバレーでは気候も回りの人々も随分違う。

東海岸の米国DECは典型的な垂直統合型ビジネスモデルで、会社の文化も、西海岸の水平統合型の米国Oracleとは全くことなっていた。前者が破壊的イノベーションで破壊される側で後者が破壊する側であった。

会社での意志決定のスピードも前者と後者では随分違った。前者は慎重、後者はスピード重視というイメージである。これはたまたまそうであったのか、それともシリコンバレーという破壊者の巣窟であったからなのかはよくわからないが、わたしが想像するにやはりシリコンバレーという米国でも例を見ない特異点だからだと思う。

シリコンバレーの青い空と解放感。人々を引きつける何か。

シリコンバレーはIT産業に従事する者なら一度は働きたいというあこがれの地でもある。一方で80年代のボストン郊外にはDEC以外にもDG、Wang、Appolo等々(これらは全て今はない。全て破壊された)様々なハイテクベンチャーが勃興していて、ボストンにはMITやHarvardなど全米屈指の大学があって、こちらもあこがれの地であった。

それでも、やっぱり西海岸と東海岸では雰囲気が随分違った。西海岸はUnixで東海岸はLisp。西海岸はアバウトで実践的で、東海岸はフォーマルで理論的みたいな印象である。

西海岸の空の下でビールを飲みながら友人とよた話をするのが好きだった。

日本の社会と比べて、はるかに組織より個人を尊重している。大企業の看板よりも小さくても何をやっているかを重視するような空気がある。小さい会社でも専門性のある会社が大企業と対等にコラボレーションして、すざましいスピードで新しい価値を創造していく。そんなイメージである。

日本では小さい会社は大企業の下請け、孫請けというピラミッドに組み込まれていて、なかなか対等なコラボレーションというのは難しい。個人は組織に抹殺されている。

オープンソースの場合、その価値観は180度ひっくりかえる。組織ではなく個人。

梅田望夫はシリコンバレー精神 -グーグルを生むビジネス風土 (ちくま文庫)のなかで「なぜなら日本社会や日本企業は、ナードの価値を全く理解せず、ナードを大切にしてこなかったし、今も大切にしていないからである」(187ページ)と記している。文庫のための長いあとがきで「日本の旧来型大企業の中ではこの状況に変化はないが、若者たちが主役の日本のネット産業は、ナードを大切にすることの意味に気づき始めている」と若干修正している。(ここでナードというのは、コンピュータプログラムに優れたちょっと変ったやつくらいの意味である)

シリコンバレーがいまだに特異点である事は間違いないだろう。日本の旧来型大企業の姿もおそらくそうであろう。しかし、わたしは東京という地域でナードを大切にする企業というのが多くはないが生れつつあるという実感を持つし、旧来型大企業ですら、その内側には、ナードの価値を理解する人々が増えつつあると思う。

別にすべて変える必要もなければ変わらなければならないということもない。自分の近傍がナードの価値をみとめ、それを搾取せづ、ちゃんとビジネスとして回っていけば、それはそれで幸せである。

シリコンバレーをコピーするために、リスクマネーの導入やら、様々な制度改革をおこなって、日本でも、ベンチャービジネス振興だなんだと行なわれているが、それももちろん大事だと思うが、ハードウェアではなく人なんだよなあ。行動するエンジニアとか、経営者とか、中間管理職とか、そーゆー有象無象の人なんだよなあ。看板で仕事をするのではなく個人として行動する人なんだよなあ。そーゆー人がある程度増えてくれば、東京という街も楽しいことをおこせるよ。そんな事を思うのである。

梅田望夫はそーゆー事はシリコンバレーでしか発生しないと考えているが、わたしは東京でもミラクルは起せると考えている。それが彼がシリコンバレーにいる理由ならば、それがわたしが日本に戻ってきた理由でもある。

オープンソースがそれを可能にした。それに未来を見付けた。だからわたしはここにいるのである。

再放送：「ハゲタカ」

というわけで、NHKドラマ「ハゲタカ」ロビー活動中。昨日は大空電機の株主総会。アラン、TOBの準備だ。

第五回の本日。鷲津と治のPRIME11での対決が見ものである。マネーゲームに興じるのは鷲津か治か。それとも…。

大空電機というモノ作りの会社の価値はどこから生まれるのか。特級技能士レンズ磨き職人の加藤がいい味をだしている。東京オリンピックの時に入社してひたすらレンズを磨き続けて40年。そのような熟練工を育てるには10年、20年の時間がかかる。簡単にコピーできるわけではない。熟練工の技は長い訓練、経験によって培われる。

イノベーションのジレンマはそのような熟練工を育てることを拒否しているのだろうか。

シナリオ、構成、カメラワークなどなど、NHKの職人技と大森南朋（鷲津役）、松田龍平（治役）、柴田恭平（芝野役）などの渋い役者たちのコラボレーションが光っている。

mixiで「ハゲタカ」を検索してみると、おびただしいほどの「ハゲタカ」にはまった人々を発見できる。何が人々をこれほどまでに引き付けるのだろう。録画したDVDを何度も何度も繰り返してみて、そのたびになにかしらを発見する。それを誰かに伝えたくなる。そんなドラマである。

ユメのチカラ
ハゲタカ
http://blog.miraclelinux.com/yume/2007/04/post_ab38.html

NHKドラマ「ハゲタカ」
http://blog.miraclelinux.com/yume/2007/08/nhk_40ec.html

職人気質
http://blog.miraclelinux.com/yume/2007/04/post_063f.html

ハゲタカ公式ページ
http://www.nhk.or.jp/hagetaka/

渋谷で働くドラマディレクターの日記
http://www.nhk.or.jp/hagetaka-blog/250/4349.html

ハゲタカ詳細ロケ地情報
http://loca.ash.jp/info/2007/d200702_hagetaka.htm

    * 第３３回放送文化基金賞のテレビドラマ部門「本賞」　受賞
    * 第３３回放送文化基金賞のテレビドラマ部門「出演者賞」　受賞（大森南朋）
    * 第４４回ギャラクシー賞「優秀賞」　受賞
    * マイベストテレビ賞グランプリ　受賞
    * 第６回放送人グランプリ「特別賞」　受賞

    * 原作 - 真山仁
    * 脚本 - 林宏司
    * 音楽 - 佐藤直紀
    * 演出 - 大友啓史、井上剛、堀切園健太郎

ビバ　ハゲタカ廃人

コインロッカー・ベイビーズ

「 海の向こうで戦争が始まる」のあとがきで村上龍は、

この作品を書きあげた夜、あるバーでリチャード・ブローディガンに会った。「二つ目の本になる小説を書いたよ」そう言うと、ブローディガンは「ふうん」と横を向いた。この野郎、おめでとうくらい言ったらどうだ、と思ったが、彼はその時機嫌が悪かったらしい。もう一度僕に向きなおるなり、「大事なのはね、三作目だ」と短かく言った。

と書いている。

「処女作なんて体験で書けるだろ？二作目は、一作目で取得した技術と想像力で書ける。体験と想像力を使い果たしたところから作家の戦いは始まるんだから」

コインロッカー・ベイビーズは彼の渾身の力を込めた初めての書下し長編である。プロの作家として一人立できるのかそれとも芥川賞作家としてだけで終るのか、その分水嶺になった作品である。

彼の近未来小説の中では、この作品が最も好きだ。 「愛と幻想のファシズム〈上〉」、「愛と幻想のファシズム〈下〉」 、 「希望の国のエクソダス 」、「半島を出よ」など強烈なドライブ感を持つ作品は少なくないが、やはりプロフェッショナルな作家としての一里塚をうちたてたこの作品が最も好きだ。

村上龍と言えばセックスとドラッグと暴力という古いイメージを持つ世代（いったい誰だよ）は、コインロッカー・ベイビーズとあわせて半島を出よを読みたい。

読め。

減量

4月に76kg前後あった体重がいまや70kgを切っている。体脂肪もぐぐっと減った。（30近くあったのが20ちょっとと言う感じ）
特に難しいことをしたわけではなく、食べる量を減らしたのと、歩く距離を増やしたことが大きいと思う。
キョリ測http://www.mapion.co.jp/route/を使うと歩いた距離が測れてついでに消費カロリーなんかもわかって楽しい。消費カロリーも中生ビール換算とかあんパン換算とかできて、ｘｘKmあるいて中生何本分だというのが分かる。
歩いて移動するというのもいろいろ発見があって楽しいということを再認識した。

東京タワーを登る/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/04/post_e2c8.html

grubでのエラー

たまにはカーネルネタ。というかgrubネタ。

カーネル(vmlinux)をビルドして/bootにそれをコピーしgrub.confに今ビルドしたカーネルのエントリを追加する。いつものパターンである。

リブートする。立ち上がらない。

Error 13: Invalid or unsupported executable format

ビルドしたカーネルで立ち上がらないと凹む。まあ、そーゆー時はGoogleである。grubのマニュアルをインターネットに発見する。

曰く
13 : Invalid or unsupported executable format
     This error is returned if the kernel image being loaded is not
     recognized as Multiboot or one of the supported native formats
     (Linux zImage or bzImage, FreeBSD, or NetBSD).

チンプンカンプンである。Multibootというのは何だ？
サポートするネーティブなフォーマットでない？

Linuxの場合zImage or bzImageと書いてある。むむむ、/bootにはvmlinuxという圧縮していないイメージをコピーしたぞ。

ということで、arch/i386/boot/bzImageをvmlinuz-xx.xx.xxとしてコピーし、再起動してことなきを得た。

通常はbzImageをコピーするのだけど、crashコマンドとか利用する時は圧縮しないカーネルが必要なので、それから起動しようとしたのだけど、だめだと言うお話であった。

北鎌倉

ふと思い立って、北鎌倉へ散歩した。横須賀線に乗って北鎌倉で降りる。改札の踏み切りを上り方面にわたる。駅前の光泉でいなり寿司の折り詰めを買う。浄智寺から源氏山公園へ抜けるハイキングコースを歩く。頂上でさっき買ったいなり寿司をぱくつく。銭洗弁財天へ下りる。夕方だったので、売店は既に閉まっていた。小銭を洗って、鎌倉方面へ下りる。途中法務局前の交差点にある鰻屋（うな豊）でうな丼を食す。小町通りに出てぶらぶら。
ちょっと涼しい一日だった。

カーネル読書会のおしらせ(第79回)

日時：8月23日、18時半開場、19時ころ開始
会場：ミラクル・リナックス、セミナールーム

お題：Fault Injectionについて
発表者：美田さん
Fault Injection はエラーをわざと起こし、通常テストすることが難しいエラー処理の部分をテストするためのフレームワークです。このしくみや使い方の説明、これまでにこれを使って検出したバグなどについて話す予定です。

18:30頃、開場
         Lightning Talks
19:00頃、お題開始
20:30頃、懇親会開始

場所はいつもの、ミラクル・リナックス社セミナー会場地図
http://www.miraclelinux.com/corp/about/maps_google.html

今回は一人5分の LT (lightning talks) も募集します。
LT発表希望の人は直接わたしまでメールでお題をください。

開場した後は、だらだらと自己紹介やらLTやらをやりますので、時間の許す限り早めに来た方が面白いお話をきけるかもしれません。

会場で、ピザとビールの懇親会つき。（予定価格1000円）
懇親会参加希望の方は、懇親会参加と明記してください。

登録はいつもの宴会君
http://utage.org/enkai/
宴会コード kernel070823

会場の都合で35名で締切ます。

お休み

いや～暑いっすね。連日猛暑猛暑。酷暑酷暑。史上最高気温を更新って、どーゆーことよ。こーゆーときはお休みとってうだうだするのがいいのだが、何が難しいと言ってお休みをとるのがなかなか難しい。段取りが悪いのか、それとも精神的なものなのか。

まあ、２～３日のおやすみだったら取れないこともないが、日本では数週間の休みを取るというのはありえない。

梅田望夫が人と違うことをする (http://d.hatena.ne.jp/umedamochio/20070816/p1)でサバティカル（研究休暇）について書いているが、日本の企業でサバティカル的に長期休暇を取るというのは聞いたことがない。長期勤続特別休暇みたいなのはあるかもしれないが（例えば10年勤続で5日間の特別休暇みたいなやつ）、5週間ど～んと休みます、なんてことは聞いたことがない。育児休暇というのはあるけど。

人々が自由に長期間休めるようになると日本の社会組織、会社組織はどのように変わるのだろう。

まあ、仕事の引継ぎとかいろいろ大変なことがいっぱいでてくると思うが、それはそれでどうにかなるような気もしなくもなく、むしろ、引継ぎをすることで様々なことが明文化されて、かえってよかったりして、なんてことを思わなくもない。

お休みした～い。

NHKドラマ「ハゲタカ」

その男、悪魔か救世主か

公式
http://www.nhk.or.jp/hagetaka/

再放送決定！

総合
8月19日（日）夜9時50分〜 第1回「日本を買い叩け！」
8月20日（月）夜10時〜 第2回「ゴールデン・パラシュート」
8月21日（火）夜10時〜 第3回「終わりなき入札」
8月22日（水）夜10時〜 第4回「激震！株主総会」
8月23日（木）夜10時〜 第5回「ホワイトナイト」
8月24日（金）夜10時〜 最終回「新しきバイアウト」

本放送
2007年2月17日（土）〜3月24日（土）
毎週土曜日NHK総合21：00〜21：58（BS-hiは18：00〜18：58）

原作：真山仁（「連鎖破綻」「虚構の砦」「マグマ」）
脚本：林宏司（「ビッグマネー！」「離婚弁護士」「医龍」）
音楽：佐藤直紀（「GOOD LUCK!!」「海猿」「ALWAYS三丁目の夕日」）
演出：大友啓史 井上剛 堀切園健太郎

2月に本放送をした時の視聴率が平均7%という民放では即打ち切りのようなありえない視聴率をたたきだしたにもかかわらづ、そのドラマの完成度の高さゆえ、数々の賞をそうなめにした伝説のドラマがこの夏蘇る。

ゴールデンタイムの帯(おび)で6夜連続というこれまたありえない形での再放送。NHKのやる気を感じさせる。

再度録画してリピート見だ。家族友人知人と一気見だ。ハゲタカ合宿でもなんでもして四の五の言わづともかく見ろ。

鼻息あらくお勧めしているわけであるが、たかがテレビドラマでそんなに熱くなるなと自分でも思う。たかがテレビドラマである。見なくても人生に影響はないし、見たからといって何か得になるかと言うとそうでもない。

夏の暑い日に暇つぶしにビールでも飲みながら見る。

しかし、誰かと語りあいたくなるようなドラマである。シナリオが素晴しい。構成が素晴しい。NHKのスタッフの熱い思いが伝わってくるドラマである。

ハゲタカブログ：渋谷で働くディレクターブログhttp://www.nhk.or.jp/hagetaka-blog/200/4324.html

ハゲタカ/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/04/post_ab38.html

ウィキノミクス

マスコラボレーションはいかに世界を変えたか。

ピアプロダクションでは、財産権という概念が逆転する、なんていう話は俄かには理解しがたい現象ではないか。成果物を他者が勝手に利用しないように制限をかけるのではなく、無償で他人に利用させむしろそれを奨励するというようなことが理解できるだろうか。

インターネットによってコストゼロでマスコラボレーションが仮に可能になったとして、その事例を見せられたとして、自分のビジネスには関係ないどこか別の世界で起きていることではないかと思うのがほとんどなのではないだろうか。

自分のこととして理解してあらたな行動をこの本から起こすと言うのはほとんど考えられない。既にマスコラボレーションのことを十分理解しそこにビジネスチャンスがあると考えている人は、この本があろうがなかろうが行動しているだろうし、そうでない人は、この本があろうがなかろうが何もしないだろう。

オープンソースは既に市民権を得られたといっても過言ではないが、それでもいまだにそれを信頼していない人は少なくはない。

フリーソフトウェアから始まったソフトウェア開発の新しい潮流は、その華々しい成果にも関わらず、多くの人はそのメカニズムに注意を払おうとしていないし、払うつもりもない。

ソフトウェアがどのように作られるかと言うのは多くの人たちにとってどうでもいいことである。それは否定しないが、ソフトウェア企業の中にもそのような無理解な人が数多くいる。

ソフトウェア企業に勤務している人々はソフトウェア企業がオープンソースと言う破壊的イノベーションに侵食されている事実に早く気がついたほうがいいと思う。

自分は関係ないというのは単なる願望で、事実はそうでない。

この潮流は誰にも止められない。

産業経済における知識の独占が急速に崩れつつあるときに企業はどのように行動すべきか。もちろん答はでていないし、完璧な回答というのも見出されていない。

社内に研究開発の組織を持つのではなく社外にそれを求める。そんなことがありうるのか。そんなことを実施できるのか。それによってビジネスを行なえるのか。多くの人は戸惑いいぶかしく思う。

資本主義が高度に発達した結果、地球規模のコラボレーションのインフラを我々は手に入れた。著作権をはじめとする財産権の概念も我々の幸福を追求するために様々な変容を迫られている。

社会的共有資本としてのオープンソースを位置つけたときそれを健全に発展させるにはどのような制度設計が必要なのだろうか。社会としてのコンセンサスをどのように醸造させるべきなのだろうか。

それは、ウィキノミクスという潮流に乗り遅れまいとビジネスパーソンをあおるのではなく、もう少し大所高所から、「カネ儲け」だけではない何物かを、議論すべきではないか。

公的基盤と私企業のバランス。それをどのようにすることが地球規模での幸せにつながるか。

インターネットは誰にも所有されていない。誰でも自由に使える。このアナーキーなメカニズムによって芳醇なコミュニケーションのメディアを我々は手に入れた。

地球規模のマスコラボレーションを当たり前のように空気のような存在として使いこなす人々が間違いなく増えている。

その人々は企業という枠組みをいとも簡単に乗り越える力を持つ。そのような世界ができつつあるのである。

書評 - ウィキノミクス/404 Blog Not Found
http://blog.livedoor.jp/dankogai/archives/50835758.html

イノベーションのジレンマ

先日、「オープンソースは資本主義の破壊的イノベーションである」などと書いたのであるが、イノベーションのジレンマをぱらぱらめくってみた。
http://blog.miraclelinux.com/yume/2007/08/post_7b5e.html

破壊的イノベーションによって破壊された企業に勤めていたという個人的な体験からか、この本に書かれている事例はインサイダーから見ても非常に興味深い。

あなたは、あなたの会社の基幹製品がいとも簡単に破壊的イノベーションにより破壊されていくさまを経験したことがあるだろうか。その貴重な経験からあなたは何を学ぶのだろうか。

収益が悪化し大幅な赤字を記録した企業の常としてコアビジネス以外を売却する。DECの場合は、教育ビジネスであったり、ストレージ部門であったり、DEC Rdbのようなソフトウェア部門であったりする。資産を売却するので一時的なバランスシートの数字は好転するが、もはや自立的な復活は望めないデススパイラルに陥ってしまっている。そしてこのスパイラルにはまった企業で復活した例はほとんどないとクリステンセンは指摘する。

そのプロセスの中で、希望退職プログラムなどを含め社員がどんどん辞めていく。破壊された企業から破壊する企業へと人材は流動する。

わたしはDECを94年に退職し、日本オラクルへ転職したわけだが、その典型例と言っていいかもしれない。その当時は全く意識していなかったのだが、Oracleのデータベースはクリステンセンの言う破壊的イノベーションそのものであった。

Rdbチームに身を置いていたものとして当時のOracleのRDBMSは冗談としかいいようがなかった。性能はプアだし、機能も貧弱だ。信頼性もサポートもお話にならなかった。しかし、仮にそうだとしてもOracleは破壊的なイノベーションであった。顧客はもっと簡単に利用できるRDBMSを求めていたし、様々なハードウェアやOSで走るOracleに魅力を感じていた。DECのRdbを購入すればVAX/VMSというマシンにロックインされてしまう。それはもはや価格競争力の低いハードウェアプラットフォームであった。

Rdbチームが感じていたものは典型的な持続的イノベーション企業にいるものの典型的な反応である。自分たちのビジネスが破壊されつつあることにいかに鈍感であるか。

破壊的イノベーションというのは画期的な技術による破壊ではない。技術そのものはむしろ未熟で改良の余地が多いが、ローエンド市場ではそれでも十分であったり、まったく新しい市場では破壊的な力を持つ。

それにしても恐ろしい話である。

皆様にはじっくり読んで頂きたい教科書である。

Asianux Server 3

先日、弊社次期製品Asianux Server 3の製品説明会を開催した。たまには宣伝もしないといけないので。

http://www.miraclelinux.com/products/linux/axs3/index.html

従来はミラクル・リナックスという製品名で販売していたが、今後はずばり、Asianux（アジアナックス）というブランド名でいく。これは、日中韓三ヶ国でのプロジェクトも2003年12月に発足以来4年半、十分ブランドも浸透したことだし、アジアに基づくディストリビューションとして、がっつり行きますという宣言だとご理解いただきたい。

IT産業というのは、米国の一極集中型のビジネスで、製品もビジネスモデルもすべてと言っていいほど米国に依存している。自由であるはづのオープンソースの業界も正直なところ米国に多く依存している。しかし、お客様に提供する価値と�