ユメのチカラ

Googleを支える技術

Googleという不思議なサービスを提供するそのコンピュータシステムの内側に公開された資料だけを利用して迫った良書である。

Internetの向う側のGoogleというシステムについて、われわれは日々利用しているにもかかわらず殆ど何も知らない。少なくともわたしは技術的な側面について殆ど何も知らない。神秘的な、都市伝説的なもの、例えば、20%ルールとか、そんなことぐらいしか寡聞にして知らない。

本書はGoogleの分散ストレージ(GFS/BigTable/Chubby)、分散データ処理(MapReduce/Sawzall)、運用コスト、開発体制などについて公開された論文などを引きながら解説している。

コンピュータシステムというのは極論すれば、いかに速くするか、いかに安くするかという2軸で発展してきたようなものだから、Googleという巨大システムをどのようにエンジニアリングするかという観点からもこの速くすること、安くすることの実務的な教訓というのは大変興味深い。

RDBMS(関係データベース管理システム)というソフトウェアは多量なデータをいかに格納し、検索するかという観点から開発発展してきたものだが、Googleは、それを地球規模の巨大システムに実装したものと言える。

わたしが本書で最も興味を引かれたものは、分散ストレージや分散データ処理の話ではなく、運用コストの章であった。そしてわたしはこの章が本書の最もユニークなところでしかも最も重要なところかと思う。

フツーのプログラマが計算コストと言うときアルゴリズムの計算量の事を指す場合がおおいと思うが、計算にいくらかかっているかという観点から議論するということは、あまりないと思う。

ムーアの法則のすごいところは、18ヶ月で半導体の集積度は倍になる、すなわちコストが半分になると言い切って、フツーのプログラマにそれを意識させたことである。コストが半分になるのだから、それを意識したプログラミング、すなわちメモリがどんどん増えていく、あるいはメモリがどんどん安くなることを前提としたプログラミングが正しいこととされた。そのようなパラダイムでソフトウェアサイエンスは進化していったようなものである。

コンピュータの高速化の流れも、ムーアの法則にのとって、クロックを高速化する事によって、命令セットアーキテクチャを変更する事なく、様々な実装上の工夫によって、高速化していった。ソフトウェアにとっては、ほとんど何もしないで高速化していったわけであるから楽な時代であったと言える。

ところがクロックをどんどん上げて行くことによって、電力消費量もそれに比例してどんどん増加していって、発熱の問題などが顕在化してきた。そこで、クロックを上げることによる高速化ではなく、マルチコア化等による高速化などが必要になってきた。同様に消費電力あたりの性能を上げるための様々な工夫が必要になってきた(←今ここ)

計算機の消費電力は電気代というお金になる。Googleが利用している計算機は、2000ドル〜3000ドル程度の普通のIAマシンのようであるが、その消費電力が増加の一途をたどり、年間運用コストがそれを上まわるかどうかという事である。

電気代だけではなくてデータセンターの建設費、効率的な電力消費設計などがコスト負担にどんどかかってくる。プログラマは昔はムーアの法則をメモリ空間の増大などと一次元的に考えていればよかったが、今後はメモリ空間はまあそこそこあるとして、消費電力をどう効率的に利用するか、省電力プログラミングが求められてきているような気がする。

消費電力を半分にできれば運用コスト(電気代)は半分になるし、ばかでかいデータセンターの建設も先送りにできる。サーバー機の重要なコストファクタが電気代というのが常識になってくるとプログラマのプログラミングパラダイムも随分変化してくる。

速くするだけではなく、電気代を節約する速さが求められるのである。

モバイル機器なんかは電池の持ちが商品価値そのものを決めたりするので、もっと重要である。バッテリーのサイズが半分になればデザインの自由度も随分増すだろうし、なにより軽くできるし、ハードウェアコストも安くできる。プログラムが物理的なデザインに影響を与えるのである。

プログラマがもっとコストなどの側面に意識を持つべきだと思うのだが、その意味で本書の第5章などは大変興味深くかつ意義深いと思う。

省電力プログラミングというパラダイムをそろそろ真面目に考えないといけない時期である。

Googleを支える技術 ……巨大システムの内側の世界
サポートページ
http://gihyo.jp/book/2008/978-4-7741-3432-1/support

Happy Hacking Diary(著者：西田圭介氏の日記)
http://d.hatena.ne.jp/nishidakeisuke/20080428

Papers Written by Googlers
http://research.google.com/pubs/papers.html

未来のいつか/hyoshiokの日記(電気代)
http://d.hatena.ne.jp/hyoshiok/searchdiary?word=%c5%c5%b5%a4%c2%e5

未来のいつか/hyoshiokの日記(省電力)
http://d.hatena.ne.jp/hyoshiok/searchdiary?word=%be%ca%c5%c5%ce%cf

勉強をしなおす

いくつになっても勉強だ。昔とった杵柄。錆びたナイフを研ぐ。

という事で日頃なにげなく使っているEmacsのマニュアルを再読する事にした。会社の机の上にO'reillyの Learning GNU Emacs、Writing GNU Emacs Extensionsそして竹内監訳のGNU Emacsマニュアルがある。竹内監訳のGNU Emacsマニュアルの初版は1988年2月である。20年前である。いくら何でも日進月歩、秒進分歩のIT業界の時間感覚でなくても古すぎるだろうと思わなくもないが、機能がテンコ盛のEmacsにはversion 18ころの古典的な、基本機能をおさらいするには、サイズ的にも丁度いい感じである。

正直に告白すると、Emacsを日々使っているが自分で拡張を書いたりelispで手間仕事をちゃかちゃか片付けるという事はほとんどしていない。何かのきっかけでもないとマニュアルを読みかえすということもほとんどしない。ぐぐればどーにかなる。だけど、一見時間がかかると思えても基本にたちかえってみることは悪い事ではない。

今使っているEmacsは22.1.1だ。Ubuntu 8.04にデフォルトでついてくるやつである。10数年Emacsを使っているけど全然使いこなしている感じがしない。ちゃんと基本にもどって勉強しなおしてみよう。きっと新しい地平線が見てくるに違いない。

ソフトウェアの作り方を考える

「開発工程を別々に担当してはいけない」は思いのほか多数のブックマークを頂いた。コメントやブックマークを拝見しながらあれやこれや考えた。わたしの飛躍する思考というか雑な議論で辟易している方もいらっしゃるかとは思うがもう少しお付き合いいただければ幸いである。

わたしの経験は、このブログの読者の皆さんはご存知かもしれないが、ソフトウェア製品の開発経験に偏っている。米国系ハードウェアベンダーでコンパイラやRDBMS製品を開発していた。その後西海岸のソフトウェアベンダーに転職してそこでRDBMS製品の開発に従事した。そしてOSSの可能性を信じてミラクル・リナックスの設立に参加したのが約7年前である。顧客向けアプリケーション、例えば社内システム構築（人事、財務、購買などなど）の経験はない。

さて先の「開発工程を別々に担当してはいけない」ではいろいろな論点をごった煮風に突っ込んだものだから分かりにくくなったので、いくつか細かく分けて考えてみる。

人月のワナ。

多くの人が指摘しているようにソフトウェアの価値をかかった工数（人月）で評価するというのはまるっきりナンセンスである。熟練者が一ヶ月で作成できるものを初心者が6ヶ月かかったとすると、後者に6倍お金が払われるか、それだけの価値があるか。もちろんない。

この場合の正しくは、ある実装した価値、通常は機能で近似するかと思うのだけど、それに見合った価格が支払われるべきである。単位機能を実装する工数が少なければ少ないほど、利益があがるので、ソフトウェア開発における生産性向上のインセンティブが発生する。人がソフトウェアを作る以上、一人一人の専門性、技術を向上させることに高いインセンティブが発生する。企業にとっても、未経験者（安い人材）を雇用し、その利ざやで稼ぐのではなく、より専門性の高い人間を雇用し、その生産性の高さで利益をあげることに、そして教育やトレーニングに投資すること（生産性や品質の向上に繋がる）に合理性が発生する。

ソフトウェアである機能を実装するために、設計、プログラミング、テストという工程があったとして、それを工程ごとに分離して、それぞれを単能化することによって生産性を向上するという、古典的な工場モデルがソフトウェア生産に適用可能なのか。ひたすらネジを取り付けるだけの自動車工場なんていうのがいまどきありうるのか。ソフトウェアの設計とプログラミングそしてテストというのがそもそも分離可能な工程なのか？

わたしは、そのような工程を単純に分離することは難しいし、分離することは専門性を高めることには繋がらないと思っている。分離することによって、生産性が向上するという証拠もほとんどみたことがない。ソフトウェアを実装する能力を高めるためには、渾然一体のプロセスである、設計、プログラミング、テストを等しく経験しなければならないと考えている。その経験を積むことによって一人一人の専門性すなわち生産性が向上していくと考えている。

テストとプログラミングをするものは分けるべきだと言う議論ももちろんあるが、ここでいうテストは実装の妥当性を評価するいわゆる内部テストに相当する部分で、仕様の妥当性を検証する統合テストあるいは受け入れテストのところではない。昨今ではテスト駆動型開発という手法で広く取り入れられている方式である。

ということで、工程分離することによって生産性が向上するという可能性が少ない、むしろ悪化すると考えている。一方で機能による分離では生産性向上がみこめると考えている。

ITゼネコンうんぬんかんぬんはまた別のお話なのでいつの日か別にお話することにしたい。

開発工程を別々に担当してはいけない

古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。

特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。

よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。

ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。

一度固定した文書は次のフェーズで変更するとなると、手戻り工数が莫大になってしまうので、通常は、前工程で決めたことは、後工程で変更はしない。後工程で変更しないという前提で文書を作るので、いろいろ長期間にわたって検討などをするのであるが、実装してみないとわからない事などもいっぱいあるので、なかなかそうは上手くいかない。

実装してみて、できたものは最終ユーザからみると使えないものでも、仕様書に明記されていたものをその通りつくっている限り実装者(製造)の責任ではない。

大量な文書を作るし、各フェーズのレビューの工数も重いので開発スピードは遅くなりがちで、当初予定していた利用環境やユーザの要求というのも時間とともに変化するので、実装が終了した時点では仕様そのものが陳腐化するという事もすくなくない。ひらたく言うと、一生懸命つくっていたのに使えないものができてしまったということである。

ユーザアプリ開発、SI(System Integration)の現場では、おおかれすくなかれ上記のようなパターンがあって、それに元請け、下請けという産業構図がはめこまれていて、元請けが大手ベンダー、下請け、孫請けが中小ベンダーという風になっていたりする。大手がゼネコンの立場になって、多くの下請け、孫請けを使って大規模システムを構築する場合、いろいろな意味あいを含めてITゼネコンといったりする。

工程を別々に担当することによって、数々の問題が発生する。

通常は上流の方が単価が高く、下流の方が単価が安いので、だれも下流をやりたがらない。下流工程は結果として単価の安い経験の浅いエンジニアをつけることになる。工程は通常、組織によってわぎりにされているので、下流工程の作業をやる人がノウハウをためて上流作業をになうという機会がない。元請けはいつまでたっても元請けだし、孫請けはいつまでたっても孫請けである。孫請けの経営者も経営者で、単価は安くても、とりあえず人の分だけ売上があがるので、大手にぶらさがっていれば食いっぱぐれない。そのため経営の緊張感はない。利益率は低いがどうにか食っていける。というような構造がある。

下流にいけばいくほど単価のたたきあいになるので経験豊富なベテランを配置することが難しくなり、若年層エンジニアを使いすてることにならざるをえない。いわゆる35歳停年説である。

業界全体としてエンジニアを使い捨てにすることには百害あって一利もない。にもかかわらず、抜本的な対策、方策がとられているようには見えない。

なぜなんだろう。

わたしには、この工程によって作業を分担するという方法が諸悪の根源であるように思えてならない。小さい会社が何十人もエンジニアを集められないので元請けになれないという事情があるというのは百歩譲ってあるとしよう。大規模な開発をするため何社かで共同作業が必要だったとしよう。その場合の分担を工程ごとに輪切りにするのではなく、機能ごとに縦に切る事を提案したい。

つまり、ある機能について、一社ないしは一人が仕様の決定から設計、実装、内部テストまで担当するのである。キモは設計者と実装者は同一人物とするのである。これを分離しない。

なんでこんなことを言うかというと、実装と設計は不可分で、実装をしてみて初めて気がつくこと、設計をしてみて初めて気がつくことなどがあり、実際の設計と実装というのはいきつもどりつのプロセスである。このいきつもどりつがない限り、いい実装などはできはしない。設計と実装を分断している限り、しょぼい設計としょぼい実装にしかならない。初めから完璧な設計などはないのである。完璧な設計でない以上、しょぼい実装しかうまれてこないのである。

工程を分離するのは悪なのである。

工程を分離するために専門性が蓄積されない。より高度な実装を作成するインセンティブも発生しない。

『「渡された仕様書を実装するサラリーマンプログラマ」の悲哀』にあるのは工程を分離されたプロジェクトの悲哀であって、サラリーマンかどうかは無関係である。

わたしはソフトウェア工場というコンセプトそのものを否定するつもりは毛頭ない。工学的なアプローチによってより品質の高い(バグ密度の低い)ソフトウェアをより少ない工数で生産するということは可能であると思う。QC活動のような方法論ですら有効な場面は少なくないと思う。

しかしXPで実践されているようなベストプラクティスの多くは工程の分離ではなく設計と実装の渾然一体となったプロセスである。

日本のソフトウェア開発の現場の国際競争力のなさというのがあるとしたら、ITゼネコンをよしとした、上流下流工程を是認したソフトウェア生産方法論にあるのではないか。そこに構造的な問題があるのではないかと思うのである。人月で工数をはかる事がやりだまにあがっているが、根本的な問題は、工程を分離して、下請けにだすというソフトウェア生産方法であると思う。

ちなみに、米国のソフトウェア製造業では(マイクロソフトもオラクルも)、設計する人がコードも書くのである。それが一般的な姿である。わたしの場合(DEC時代もオラクルの時)も、そうであった。

プログラマの仕事はプログラムを読むことである/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/10/post_9db7.html

Intelのマニュアルを読む

Intel 64 and IA-32 Architectures Software Developer's Manuals　は下記にある。
http://www.intel.com/products/processor/manuals/index.htm

どれから読んだらいいか、よく分からないということであれば、 Volume 1: Basic Architectureをざっと見て、 Volume 3A: System Programming Guideに行くというのがオーソドックスかと思う。インストラクションセットの解説（ Volume 2A/2B）は辞書的に必要な命令について適宜参照するという形になる。

マイクロアーキテクチャについてざっくり知りたい場合は、Intel 64 and IA-32 Architectures Optimization Reference Manualの第2章がコンパクトにまとまっている。

最近のCoreマイクロアーキテクチャやPentium 4やXeonのNetBurstマイクロアーキテクチャについて紹介されている。

Coreマイクロアーキテクチャのところを読むと、In Orderのフロントエンドが4つの命令デコーダが、命令をμOPに変換し、Out of Orderの実行コアに送り、サイクル当たり6個のμOPを実行し、In OrderリタイアメントユニットがμOPの実行結果をサイクル当たり4つプログラム順に変換する。なんてことが書いてある。

14段のパイプライン、3つのALUなどなど。

フロントエンドには、BPU(Branch Prediction Unit)、Instruction Fetch Unit、Instruction Queue、Instruction Decoder、Stack Pointer Tracker、Micro-fusionなどの機能がある。機械語をμOPにサイクル当たり4つ変換する。

実行コアはフロントエンドから供給されるμOPをOut of Orderで実行する。renamerによって、レジスタ名を大量にあるマイクロアーキテクチャの内部レジスタ名に変換する。（いくつ内部レジスタがあるかは記されていない）。Reorder buffer (ROB)はμOP実行結果を保持する。ROBは96個のエントリを持つ。Reservation Station (RS)はμOPのすべてのソースオペランドがそろうまでキューに並べスケジュールする。RSは32個のエントリを持つ。

実行コアがサイクル当たり最大6個のμOPを同時に実行するというようなことが書いてある。その他メモリアクセスをどのように高速化しているかなど興味深いお話満載である。ぜひ原文にあたって欲しい。

wired society

3連休でブログネタも尽きたことだしなにを書くかなどと考えていて、趣味のインテルのマニュアルを読んでいたところ、割り込みと例外の章（Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide, Part 1）をたまたまめくっていたのでそれについて書こうかなと思ったのだが、急に気が変わる。

昔ウェブ人間論を読んだ時に書いた感想をたまたま読んで、ああ、インターネットは人々と結線(wired)したのだなあなどと再確認した。http://blog.miraclelinux.com/yume/2006/12/post_2666.html

Wiredという雑誌があったけど（今もあるのかな？）、日本語版も出ていたがいつのまにかになくなってしまった、インターネットは我々を結線したというのが非常にインパクトがある概念だった。

世界がインターネットで繋がっている。

すげーぞ、それはというワクワク感であった。

ハッカーがなぜプログラムを書くかという問いかけに私自身まだ明確な回答は持たない。持たないが、自らの自由意志でプログラムを書く多くのハッカーを知っている。給与を貰うプロのハッカーから100％自由意志で誰からも拘束されないでコードを書くハッカーまで様々な人たちがいることを私は知っている。

なぜハッカーはプログラムを書くのか。

21世紀の謎である。しかし、インターネットのおかげで彼らはインターネットに結集した。インターネットは彼らを結線した。

それによってとてつもない価値の再生産が始まった。

結線された社会はそうでない社会よりも幸せなのか。ハッカーはその社会にどのような役割を演じるのか。

疑問はつきない。









下記はボツにした原稿。もったいないのでそのうち使うかもしれない。

割り込みは現在実行中のプロセスとは独立に発生する。例外は現在のプロセスの実行によって引き起こされる。例えばゼロ除算とかページフォルトとかは例外である。

割り込みも例外も発生するとそれに対応したハンドラを起動し様々な処理を行なう。例外の場合、ゼロ除算とかは当該プロセスに通知して実行を終了するものから、ページフォルトのようにOSによって適切に処理されるものまで様々なものがある。

IA-32の場合は、おなじみの下記のマニュアルの第5章を参照のこと。

Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide, Part 1
http://www.intel.com/products/processor/manuals/index.htm

リアルタイム系OSの場合、割り込み処理を一定時間で処理することを保証しなければいけないのでなかなか大変である。

Latencyの隠蔽

プログラマたるものコンピュータの基礎的な知識は必要だと多くの人は言うのだけど、じゃあどこまでが必須でどこまでがオプション（？）なのかというと明確な線引きがあるわけではない。まあ、Kernelとかコンパイラとかをゴニョゴニョする人はCPUのキャッシュがなんたるかくらいは理解していないといろいろ大変かと思う。

時間と空間を交換するというのはコンピュータだけの世界ではない。街のコンビニだって、店頭に並んでいるものはすぐにアクセスできるけど、店頭にないものはすぐにアクセスできないので、在庫量がある一定水準を下回ったら発注のトリガーがかかる。コンビニはその発注サイクルがデパートとかに比べれば異様に多いので、クロックを上げて性能を出すPentium4みたいなものである。発注単位も非常に小さくて、それこそ弁当一個でも平気で発注しちゃうという感じである。在庫をほとんど持たないので、キャッシュミスした時のペナルティは、そのまま機会損失である。倉庫のようなディスカウントストアもあるが、そちらの発注単位はでかくて、大きな空間が必要なので土地のコストが安い郊外に立地している。

アクセスコストとメモリコストの差に注目して記憶領域を階層化するのは、CPUキャッシュだけではなく、メインメモリとディスクキャッシュなどでも行われている。

CPUのレジスタとメインメモリアクセスの速度は100倍くらい違うので、性能を意識する場合CPUキャッシュがどのようなメカニズムで働いているかを十分理解しないといけない。

メモリアクセスは遅い(ユメのチカラ)で指摘したとおり、メモリアクセスが遅いことを前提にいろいろなチューニング方式が考えられるが、一番単純なのは、プリフェッチである。

順アクセスの場合、次にアクセスされる番地が予想できるので、その番地にあらかじめアクセスしておく。そうすれば実際にそのデータが必要になったときにはキャッシュでのアクセスになるので、メモリアクセスを待つと言うことはない。例えばメモリアクセスに200クロックかかっていて、L1キャッシュのアクセスが2クロックだったとすると、L1キャッシュヒットだと残りの198クロックを無駄に待つ必要がないのでより高速な処理ができる。

あるメモリにどのようにアクセスするかはプログラムを書いた人が知っているはずなので、プログラマが陽にヒントとして与えてもいいし、コンパイラがそれを何らかの方法で認識し、積極的にプリフェッチをかけるというのもある。

最近のプロセッサだとメモリアクセスのパターンを見て、順アクセスを検知すると自動的にプリフェッチをする場合もある。投機的なメモリアクセスである。

あらかじめ準備をしておくというのがlatency隠蔽の基本的な考え方である。

もう一つの方法は、時間がかかる処理と並行して、別の処理を実行するというもので、直列に処理をすすめると、長いlatencyを持つものを待たないといけないので、スループットが上がらない。そこで並列に処理できるものをどんどん処理していくという考え方である。

入出力もlatencyが大きいので、入出力と並行して別の処理をするというものである。

スーパースカラなプロセッサは同時に複数の命令を処理するので、そーやって、スループットを向上させたり、latencyを隠蔽したりする。

Computer Architecture: A Quantitative Approach（David A. Patterson, John L. Hennessy ）を読んで、基本的な概念をおさらいしたいところである。(下記）

機械語ではマシンの挙動は理解できない。(未来のいつか/hyoshiokの日記）
http://d.hatena.ne.jp/hyoshiok/20070916#p1

山勘で分岐先を実行することを投機的実行と呼ぶ（ユメのチカラ）
http://blog.miraclelinux.com/yume/2007/09/post_6814.html

Model View Controller

Smalltalkでの実装が元祖とされているが、データと手続きをつかさどるModel、表示をつかさどるView、ユーザーの入力（イベント）を処理するControllerという要素に分離し設計実装するソフトウェアモデルである。

Web系のアプリケーションの設計では定番のパターン。

正直言うと、そっち方面の経験も土地勘も乏しいので理屈の上ではわかっていても自分の血となり肉となっている感じはしない。

メモリアクセスは遅い

多くのプログラマにとってメモリアクセスの速度を気しなければならない状況というのはめったに無いが、OS、ライブラリ、コンパイラ、RDBMSなどの実装をする時には意識をしなければならない場合がある。

IA-32 Intel Architecture Optimization Reference Manual (order number 248966) をひもとくと6章にOptimizing Cache Usageというのがある。

マイクロベンマークの定番 lmbench http://www.bitmover.com/lmbench/ では、一次キャッシュ(L1)や二次キャッシュ(L2)を測定してくれる。例えば、わたしが利用しているノートだと、L1が1.776nsでL2が5.3490ns、メインメモリアクセスが139.4nsである。

Memory latencies in nanoseconds - smaller is better
    (WARNING - may not be correct, check graphs)
---------------------------------------------------
Host                 OS   Mhz  L1 $   L2 $    Main mem    Guesses
--------- -------------  ---- ----- ------    --------    -------
asianux2. Linux 2.6.9-3  1700 1.776 5.3490  139.4

クロック数でいうと、L1が3クロック、L2が9クロック、メインメモリが237クロックくらいになる。

L1とメインメモリでは2桁のアクセス速度の差がある。CPUのクロックはムーアの法則によって18ヶ月で倍になると言われていたが、その間のメモリ速度の向上は数%で、年々そのギャップは広がる傾向にある。

近年、性能向上のためのクロック数の向上は消費電力の上昇をまねいたため、性能向上のためにはクロック向上ではなくコア数の増加という傾向になりつつある。それにしても、CPUの速度向上にくらべてメモリ速度の向上ペースは低いので、そのギャップの拡大はおわっていない。

昔はCPUのクロックと同じ速度でメモリにアクセスできたが、現状では100倍程度遅いことを覚悟しないといけない。

性能を極限まで追及する時には、そのキャッシュの振舞いを理解する必要がある。リストをたぐるような操作はアドレスが連続していないので最悪毎回キャッシュミスをひきおこし、メインメモリにアクセスする必要が生じる。従って速度が2桁遅くなる。一方配列を順アクセスする場合は最初の一回はキャッシュミスをおこすがその後はキャッシュにデータがあるのでメインメモリにアクセスしなくてすむので高速な実行が可能になる。

リストやハッシュはキャッシュに厳しいが配列はキャッシュに優しい。

リスト処理の場合は次にアクセスするところ(nextポインタの指しているところ)が分るので、あらかじめプリフェッチをしておけばlatencyを隠蔽できる。

Rubyの RejectKaiji2007で発表したRubyのキャッシュミスを削減した話はキャッシュミスをプリフェッチで削減するというアイデアを実装したものである。

RejectKaigi2007
http://blog.miraclelinux.com/yume/2007/06/rejectkaigi2007.html

一方プリフェッチというのは今あるデータを追い出して新しいデータをキャッシュに置くという事であるから、追い出されたデータがすぐに必要になるとキャッシュミスを発生させる場合がある。これをcache pollution(キャシュ汚染)という。ページのスラッシングみたいなものである。なんでもかんでもプリフェッチをしてキャッシュにのせればいいというものでもない。

そのアイデアを元に作ったのがcache pollution aware patchである。

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

CPUのクロック数の上昇は消費電力の増加をまねくのでマルチコア化が進展しているという事は先に記した。マルチコア化が進展するとプロセッサ間の同期をどうとるかがますます重要になってくる。その実装としてスピンロックがある。スピンロックはメインメモリにフラグを用意して、そのフラグをセットできたものがロックを取得でき、セットできなかったものはセットできるまでループで待つという単純な同期方式である。

あるフラグがセットされているかを毎回メインメモリに見にいくという処理は、バスをロックして、アトミックにそのフラグをセットできるかを確認することだから非常にコストがかかる。バスをロックするので他のCPUは別の場所にアクセスしようとしてもアクセクを待たされるのでスケーラビリティもでない。(100nsから200ns位メインメモリアクセスにはコストがかかることを思い出してほしい）

マルチコアになってキャッシュに優しいロック方式あるいはロックなしの同期方法が求められている所以である。

メモリアクセスにまつわるバイナリハックの場所はまだまだいっぱいある。

mixiのスケーラビリティ

mixiの生みの親“バタラ氏”が語るMySQLの意外な利用法

サービス開始から3年余りで会員数が1000万人を超えたSNSの「mixi」。そのシステムはOSSで構築されており、データベース管理システム（DBMS）には「MySQL」を使う。急増するトラフィックをさばくために負荷分散を重ねた結果、現在ではサーバ1000台以上が連なる超分散システムへ。その中でMySQLが果たす役割とは。http://techtarget.itmedia.co.jp/tt/news/0709/12/news01.html

という記事があった。

日記だけで4億件。サーバは1000台以上。アクティブユーザは6割を超える。すさまじい規模のサービスである。すべてOSSで構成されていて、自社開発のコードでサービスをささえる。

当初一人のユーザから始まったサービスも2ヵ月後には1万人を超え、さらに半年ほどでデータベースをサービスごとに分割（水平分割と呼んでいる）し負荷対策した。しかし1年4ヶ月で100万人を超える会員数の増加は、それだけでは持たず各種IDごとにテーブルを分割している。これを垂直分割と呼んでいるが、DBMS的にはテーブルを水平方向に切っているので水平分割と呼ぶのが正しい。垂直分割というのは通常は列を縦に切ることをいう。例えばあるテーブルに（ID、A、B、C）列があったとして、それをテーブル１（ID、A、B）、テーブル２（ID、C）などと分割することを垂直分割という。

それはさておき、ユメのチカラでもmixiのスケーラビリティは何度か取り上げた。昨年の7月第65回のカーネル読書会でバタラさんに発表してもらったときのレポートである。下記二つをあわせてお読みいただきたい。

５００万倍のスケーラビリティ
http://blog.miraclelinux.com/yume/2006/07/post_7ad0.html

システムを1ユーザから500万ユーザまで約2年半でスケールアップしたというお話で、苦労話満載の非常に興味深いものであった。様様な試行錯誤をへて現在のシステムにいたっているが、1ユーザから500万ものユーザをサポートするなどというスケーラビリティはあらかじめ設計されていたものではない。問題にぶつかるたびに一つ一つ問題を解決していって今に至るということである。この500万倍のスケールアップと言うのは本当にとてつもないことである。そのとてつもないことを飄々とこなしているバタラさんのお話が興味深かった。

LiveJournalのアーキテクチャ
http://blog.miraclelinux.com/yume/2006/07/livejournal_a718.html
こちらはmixiが利用している、mod_perlやmemcachedなどのコンポーネントの話で、それはLiveJournalと同様のアプローチである。

大規模Webサービスを提供するためには、様々なレイヤーでの経験が必要になって、ネットワーク、データベース、OSなどなどどんどん深堀をしていく必要がある。OSSの場合はすべてホワイトボックスなので、やろうと思えばいくらでも深堀をすることができる。それはサービス提供者にとっては価値を生み出す源泉となる。

フリーソフトウェアの価値観

80年代に消滅しかけたハッカー倫理を実現するコミュニティは、リチャード・ストールマンの孤軍奮闘ともいうべき活動によって細々とだが生き延びていた。

リチャード・ストールマンはソフトウェアは私有すべきではないという信念のもとFSF (Free Software Foundation)を立ち上げ、GNU (GNU's Not Unix)　というUnix互換のOSを作ろうとしていた。エディタ（emacs)、コンパイラ(gcc)、shell script (bash)、デバッガ(gdb) などなど様々なフリーソフトウェアを精力的に開発し、公開していった。

MITのAI研究所はLispマシンの商用化によって壊滅的な打撃をうけていた。優秀なハッカーたちは高給で商用Lispマシンベンダに雇用され、ソフトウェアの共有は、知的財産権の名の下に不可能になった。DECがPDP-10のサポート中止した結果、彼らのよりどころであるITSの未来も閉ざされた。

リチャード・ストールマンは占有ソフトウェアを書くくらいならウェイターにでもなったほうがましだ、だけどそれは自分の才能を浪費することになる、と後に語っている。

しかしながらリチャード・ストールマンの不屈の精神と努力によって80年代のGNUプロジェクトは着々と成果をあげていた。OSカーネルを除いては。

そして90年代Linuxが登場する。当時フリーのPC UnixといえばBSD Unixを移植した386BSDなどいくつかのライバルがいたことにはいたが、BSD陣営はAT&Tとの訴訟問題を抱えていたし、開発方式も、ごく少数のコアメンバーによる開発という従来型の方式で、爆発的に普及するまでにはいたらなかった。

Linuxはそれらのソフトウェアとまったく異なる手法で開発されている。Linuxの開発は、ごく初期の段階から、大勢のボランティアたちがインターネット上で共同作業する形で進められていった。誰かがすべてを監視するワンマン体制によって維持されていたわけでもない。Linuxカーネルのクオリティはリリースを毎週行い、数日中に寄せられてくる何百と言うフィードバックを素早く反映して次のリリースを行なうという無邪気なほどに単純なアップデートを頻繁に繰り返すことで維持されていったのである。このようにリリースを極めて頻繁に行なうことで、Linuxカーネルに次々と追加されたコードの善し悪しは、進化論的に淘汰されていった。そして、この開発方式が成功したことに驚かぬ者はいなかった。中略。真のプログラマたちが活動の場とするインターネットが社会の主流に躍り出たおかげで、彼らの文化そのものも表舞台でもてはやされるようになった。
（真のプログラマたちの国ーー概略史、オープンソースソフトウェア、倉骨彰訳）

リチャード・ストールマンのはじめたフリーソフトウェア運動はリーナス・トーバルズという若者ハッカーとインターネットの勃興によって新しい形で再出発したのである。彼は古きよき時代を知る最後のハッカーであったが、インターネット時代の最初のハッカーはリーナス・トーバルズと言ってもいいと思う。

ビル・ゲイツに代表される、ソフトウェアのコピーなんてとんでもない、独占的な所有権を持つことで、開発投資を回収し、利益を得て技術革新を促進するのだ、という考え方は、ビジネスモデルとしては非常に分かりやすく、結果として彼を世界一の金持ちにし、マイクロソフトを世界一のソフトウェア企業にした。

ソフトウェア商用化は結局のところハッカーにとっても大きな影響をあたえ、ソフトウェアの印税を貰って金持ちになるという誘惑に多くのハッカーたちは抗えなかった。80年代から90年代のソフトウェアベンチャーはビル・ゲイツモデルのコピーと言えるだろう。

しかしながらハッカー倫理に象徴的に語られている、情報公開が善で、コンピュータは世界を良く出来るという考え方は、人がなぜプログラムを作るのかという根源的な問いかけに、もちろん経済的な成功（金持ちになりたい）もあるにはあるけど、それ以外の動機もありうるのだということを示した点で興味深い。

Red Hatが株式公開をしたとき、梅田望夫は

レッドハットの勃興は、貪欲で力強い資本主義がオープンソースという怪物をもぐいっと飲み込んでしまった瞬間であった。「あどけない顔をした天才たち」は、あっと言う間に資本主義に飼いならされたのである。
資本主義に飼いならされたLinux。199ページ。シリコンバレー精神。梅田望夫

と記している。確かにフリーソフトウェアあるいはオープンソースが資本主義（ビル・ゲイツモデル）に飲み込まれたという空気もあった。

しかし、8年経ってみて、周りをみわたしてみると、情報公開は善で、コンピュータによって世界を変えてやるということを本気で思って実践している若きプログラマたちを沢山発見できる。

確かに彼らはリチャード・ストールマンほどフリーソフトウェアと声高には主張しないが、彼らは彼らが作ったプログラムによって世界になんらかのインパクトを与えることをモチベーションとしている。もちろん、経済的な動機が全くないといえばウソになるかもしれないが、それがトッププライオリティではない。

ビル・ゲイツに代表される知的財産権をたてにとったモデルと、フリーソフトウェア・オープンソースに代表されるハッカーモデルとで、どちらがより価値を継続的に生み出すのか。ハッカー的価値観を持った方法論というのが注目されている所以である。

先日開催されたITproチャレンジにはそのような若手ハッカーが集まっていたことを付記しておく。

ITpro Challengehttp://itpro.nikkeibp.co.jp/ev/challenge/index.html
http://itpro.nikkeibp.co.jp/article/Watcher/20070906/281310/

オープンソースソフトウェア　彼らはいかにしてビジネススタンダードになったのか
http://www.law.co.jp/okamura/OpenSource_Web_Version/Web_version991206.html
Web版は無償で公開されている。

第2章、真のプログラマたちの国―概略史、エリック・S・レイモンドを参照。

ハッカー倫理/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/09/post_972f.html

ビル・ゲイツの手紙/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/09/post_af17.html

ITpro Challenge/未来のいつか
http://d.hatena.ne.jp/hyoshiok/20070907#p2
ITpro Challengeその２/未来のいつか
http://d.hatena.ne.jp/hyoshiok/20070908#p2

ITPro Challenge無事終了/404 Blog Not Found
http://blog.livedoor.jp/dankogai/archives/50908309.html

チューニング

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

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

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

パフォーマンスチューニングの参考書はいろいろあると思うので適宜みつけだしてほしいが定番のこれはというのは、あるようでいてよくわからない。データベースのチューニングという題材での書籍はいろいろあるがいかんせん製品特有の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をダウンロード

カーネル読書会のおしらせ(第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名で締切ます。

LL魂

夏の祭典。LL Spirit (LL魂)  に行ってきた。

個人的な感想など。

昨年のLLゴングのパイプ椅子は、おじさんには拷問に近いものがあったが、今年のホールの椅子は適度に座り心地もよく快適であった。実行委員会の皆様、ご苦労様でした(ぺこり)。

和田先生は、あいかわらづお元気そうでなによりだった。ステーブンレビーのハッカーズの話からはじまって(この本はハッカー倫理を知るうえで重要なテキストなのである)、ハッカーズ大辞典などを紹介しつつ、ハードウェアハック(微分機械(？)って何みたいな)のお話など、大変楽しい講演であった。帰宅してから先の2冊を本棚からとりだしパラパラめくったのは言うまでもない。

しかし、オレ様言語の作り方でパネルディスカッションができちゃうほど日本という地域にはオレ様言語をつくっている人がいっぱいいるのね。すげーな、本音できたよ。という感じである。

学校でコンパイラの作り方とかは習うけど、オレ様言語を作ってしまえというような危険思想をうえつけられるということはまあない。オトナの事情というやつで、研究職に進む人には、言語では論文とおらないよ(これが殺し文句)、企業に行く人には、言語では食えないよ(これも殺し文句)。大抵はそれであきらめるのが良い子の姿である。

それにもかかわらづ、わらわらとオレ様言語一派が勃興しているのは、やはりRubyのまつもとさんの影響に違いない。諸悪の根源はまつもとである。

オレ様言語どころかハリボテOSと称してオレ様OSまで作ってしまう輩もわらわら居て、日本という地域の将来を深く憂えるものである。(これはまた別の話)

人の話を聞いていると、なかなか楽しそうである。オレ様言語という自分が神の立場になって、すべてを決定する世界観こそプログラミングの醍醐味のような気がしなくもない。(いかんいかん、だんだん危険思想にそまりつつある)。しかし寝る間もおしんでそんなことをしたら、体に悪そうだ。睡眠不足におちいりそうだ。仕事にも影響があるかもしれない。と考えるのがフツーのオトナである。

自分の世界観をオレ様言語に投影するというのは、これはやってみたものだけしかわからない快感があるらしい(伝聞)。危険な世界だ。麻薬みたいなものである。(とは言っても麻薬をやったことがないので、よくわからないのだけど)

自分も高校生くらいのときに、なんの役にたつのかわからないただプログラミングが楽しいというだけのプログラムを作っていたわけだが、モノ作りの原点というか何かを作りたいという欲求に素直になればオレ様言語作りというのも究極の趣味のような気がしないでもない。プログラミングを目的にしちゃいかんと、一方のオトナのわたしが囁くのであるが、一方のチョイワルオヤジ(死語)のわたしが気持ちイイことして何が悪いと囁くのである。和田先生なんて、一生(？)好きなことをやっていて世間から後指をさされていないではないか、そんな生き方もあるではないか、などと思ってしまう。

しかし、ただでさえ時間がないのに、人生のプライオリティのなかで、こーゆー無限地獄の趣味を持ってしまっていいのだろうか(オトナの判断)。しかし、金はかからないし、ギャンブルにあけくれて家庭崩壊ということではないし、まあいいんではないだろうか(悪魔のササヤキ)。と揺れ動くオヤジ心なのである。

LL魂というのは人の魂をわし把みにしてぐわんぐわん揺振るイベントなのであった。

恐しいイベントである。

(通勤電車の中でニヤニヤしながらオレ様言語を妄想していたというのはナイショである。)

LL Spirit 感想。トラックバックリスト
http://karetta.jp/article/blog/ll-spirit/132858/trackbackList#trackbackList

Ottawa Linux Symposium 2007 (ols2007) まとめ

というわけで、Ottawa Linux Symposium 2007 (ols2007)を総括してみる。

出席者は750人程度で、昨年より微妙に減少しているのは、kernel summitを併設しなかったからと言われているが、本当のところはよくわからない。それでも、2.6.22にパッチを出した約800人中、少なくとも100人以上は参加していたわけだから、地球最大のlinuxの技術会議と言っていいだろう。

企業からの参加者も多くて、発表者の所属をざっとみるとIBMとIntelがさすがに両巨頭である。まるっきり個人で発表しに来ているというのはあまりいないようだ。昨今は企業がスポンサーになって開発を主導しているという流れをあらわしている。

アマチュアスポーツからプロスポーツへギアがかわりつつあるという感覚かもしれない。プロスポーツになるともちろん得られるものもあれば失なわれるものもある。インディーズからメジャーレーベルでデビューする事によって得られるものと失なわれるものみたいなものなのかもしれない。もちろんわたしはメジャーレーベルでデビューした経験がないのでよくわからないけど。

いづれにせよ、プロになって、技術がより高度化、専門化した部分は確実にあって、発表の中にも、これってIntelの中の人じゃないと、ちょっと手が出せないよなあというものもいくつかあった。

一方で企業とコミュニティとのかかわりというと、やはり個人的にはカーネル読書会の席でいろいろ勝手を言ったTOMOYO Linux BOFが印象深かった。日本にとじこもっちゃいかんいかんいかん。ばんばん(机を叩く音)。Ottawaに行くべきだ、LKMLにデビューすべきだ、アップストリームにマージするべきだ、などと人様に向って大変エラソウな事を言ってOttawaまでひきづり出したTOMOYOチームの皆様の健闘には大きな拍手をおくりたい。余計なお世話みたいなものではあるが、結果としてTOMOYOの皆様が少しでも楽しんでいただけたら望外の喜びなのである。ご苦労の方が多かったみたいで、若干もうしわけない気もしないわけではないが、まあ、この経験が共有されるということは非常に価値が大きいので、ご容赦いただければ幸いである。

まだまだ日本の企業はコミュニティとのかかわり方についての経験値がたりないと思う。実感として。英語の壁もあるかもしれないが、本当のところ英語の問題ではなくコミュニケーションの問題なのだけど、それは経験をつんで、失敗と成功を重ね自ら獲得しないといけない。擬似的な経験値を積むのにカーネル読書会はいろいろな意味でいい場所なので、どしどし利用してほしいと強く思った次第である。

http://tomoyo.sourceforge.jp/wiki/?OLS2007-BOF

TOMOYO Linux
http://blog.miraclelinux.com/yume/2007/02/tomoyo_linux.html

企業発OSSのコミュニティアライアンス戦略
http://blog.miraclelinux.com/yume/2007/02/oss_446d.html

OLS 2007 (3) -- TOMOYO Linux BOF
http://blog.miraclelinux.com/yume/2007/06/ols_2007_3_tomo.html

人月の神話と大聖堂とバザール

人月の神話を先日読みかえしたので、今度は「大聖堂とバザール」を読みたくなる。「大聖堂」で自分のはてな日記を検索してみると

蕎麦屋
http://d.hatena.ne.jp/hyoshiok/20060808#p1

大聖堂とバザール
http://d.hatena.ne.jp/hyoshiok/20040622#p2

というのを発見する。前者はどうでもいいよた話であるが、後者はそのものズバリという感じのものである。

山形浩生のCathedralを伽藍と訳すのは、どう考えても誤訳に近いと思う。世間では「伽藍とバザール」でとおっているが、わたしはあくまで「大聖堂とバザール」というタイトルにこだわる。人月の神話での挿絵は伽藍ではなく大聖堂だと思う。「大聖堂とバザール」に対するわたしのコメントを書く前に紙面が尽きてしまった。（うそうそ）

なぜソースコードを読むのか？／ユメのチカラ
http://blog.miraclelinux.com/yume/2006/08/post_3771.html

人月の神話

Frederick Phillips Brooks Jr., "The Mythical man-manth: essays on software engineering", Anniversary edition. フレデリック・Ｐ・ブルックス Ｊｒ．「人月の神話」新装版、狼人間を撃つ銀の弾はない。滝沢徹他訳

わたしが紹介するまでもなくソフトウェア開発の古典中の古典である。先日の「情報システム学会(ISSJ)、情報システムのありかたを考える会」での発表のために、久し振りに読みかえしてみた。

原書は1975年に出て、長いこと読み継がれてきて、今だにその指摘は古びていない事に驚かされる。16章からは、初版以降に書かれた論文、評論になるが、やはりこの書の本質は、初版時点で書かれた1章から15章であろう。

第1章「タールの沼」。大規模システムプログラム開発がタールの沼にはまってもがき苦しむ、恐竜やマンモスみたいなものだと記している。今でも、そのようなプロジェクトは枚挙に暇がない。ソフトウェア開発の難しさを端的にあらわしている表現である。

「新聞を読んでいると、二人のプログラマが改装ガレージで、大開発チームが最大限の努力で作り上げたものを凌ぐ重要なプログラムをいかにして作成したか、という記事をたまたま見つけることがある。(中略)
それなら、どうしてソフトウェア産業の開発チームはそうしたひたむきなガレージ二人組にすべて取って代わられてしまわないのだろうか」(第1章、4頁)

ソフトウェア製品とプログラムの作成の本質的な違いは、前者にはマニュアル、教育、サポート、継続的なアップデートなどがついていて、後者は単なる実行可能なプログラムというところにあり、前者を製作するにはプログラムを作るより大変な工数がかかるということにある。

ソフトウェア工学の歴史は、大規模なソフトウェア製品をいかにしてタールの沼にはまらないようにして作るかという歴史に他ならない。

「ソフトウェア産業がガレージ二人組に取って代わられてしまわない」というBrooksの指摘はある面、正しかったが、一方でインターネットやオープンソースソフトウェア(OSS)の発展は、「ガレージ二人組に取って代わられた」事例のようにも見れる。

1975年の時点で、世界(地球)規模のソフトウェア開発環境は存在しなかったし、それを見通すということは、Brooksであっても不可能である。しかし21世紀になって、地球規模のコラボレーションが可能になり、コミュニティによる開発というのが、ソフトウェア産業を取って代わるほどの影響力を持ちはじめているという点は指摘してもいいと思う。

確かに単一の銀の弾丸はなかったかもしれない。しかし、インターネットというメディアとコミュニテーによる開発というのは、「ガレージ二人組」が世界にインパクトを与える可能性がある事を示した点で意義深いものである。

Brooksはプログラミングがなぜ楽しいかという事も記している。

• 物を作り上げる純粋な喜び
• 他の人々に役立つものを作ることの楽しさ
• 複雑なパズルのような組み立て部品を完成させ、それが巧妙に転回するのを眺めるおもしろさ
• つねに新しいことを学ぶという喜び
• 非常に扱いやすいメディア(媒体)で作業する喜び。その上、プログラムというのは、詩人の言葉と違って、現実に動いて働きだす

一方で、プログラミングの苦しさも記している。

• すべて完璧にこなさなくてはならない。呪文の一字一句たりとも正しくなければ、魔法は使えない。
• 壮大なコンセプトをデザインするのは楽しいものの、シラミの卵ほどの微細なバグを見つけ出すのはそれこそ単純労働だということである
• あれほど長い間苦労してきた製品が完成時(またはそれ以前)には時代遅れに見えてしまうことである

OSSにかかわる多くの人は、プログラミングに楽しさを見いだしている。一方でプログラミングの苦しさを上手に回避している。一人で膨大な単純作業をやるのは苦しいが、コミュニティで開発すれば、それも苦ではないという事かもしれない。喜びは参加者の分だけ倍増し、苦しみは参加者の分だけ割引かれる。

Brooksの「人月の神話」は読めば読むほど味がでてくる名著である。

まだ読んでいない若い技術者にはぜひ読んでほしいと思う。強くお勧めしたい。

情報システム学会(ISSJ) 情報システムのありかたを考える会

情報システム学会の「情報システムのあり方を考える」会に参加した。

オープンソースソフトウェアの潮流というタイトルで小一時間ほど放談をさせていただいた。特に目新しい事を述べたわけではないが日頃考えていることを好き勝手にお話しした。いろいろなコメントをいただいたが、皆様どのような印象をおもちになったか興味深いところである。

OSSの可能性として、日本のこれから会社を停年退職するシニアエンジニアの皆様が、コミュニテーベースの開発に参加する事をわたしは期待している。日本の重厚な人材の集みを利用した世界貢献であり、それによって、日本という国が、単に経済的に�