ユメのチカラ

日本語文字コードのお話

レガシーエンコーディングプロジェクトというのをやっていて昨日その検収があった。

開発そのものは一段落したのだが、まだ、事務処理が残っているので、全て完了というわけではない。

プロジェクトの背景として、Unicodeによるオープンソースソフトウェアの国際化が普及した結果として、日本語処理にいろいろな問題(文字化け)が発生したというのがある。奇妙に聞こえるかもしれない。Unicodeというのはソフトウェアの国際化のためにやっているのではないか？ソフトウェアが国際化すれば文字化けは解消するのではないか？話が逆じゃないのか？という疑問があるだろう。ところがだ、Unicodeによって解決した問題ももちろんあるがそれによって生じた問題もある。

例えば、日本語を表現する文字のエンコーディングとして、シフトJIS、日本語EUC、JISコードなど複数あるが、それぞれのコード変換で文字化けする場合がある。あるいは〜のような文字が文字コード変換で文字化けする。機種依存文字(まる一)が変換できない。

これらは、Unicodeを中心とした変換テーブルを使っているが故に発生する。例えばシフトJISから日本語EUCへの変換は、まづシフトJISのコードをUnicodeに変換し、その後、日本語EUCへ変換する。そうするとシフトJISで未定義の文字はUnicodeに変換できないし、日本語EUCで未定義な文字も変換できない。機種依存文字は日本語EUCで定義されていないので変換できないのである。

一方、シフトJISと日本語EUCのエンコーディング(ビットの組み合わせ)は機械的なアルゴリズムによって変換できるので、そのようなアルゴリズムを利用して変換している場合は情報の損失なく変換できる。

プロジェクトのWikiページに代表的なエンコーディングの対応関係を示すが、JIS X0208(漢字)の1区1点から94区94点の文字については各エンコーディング毎にマッピングは可能である。

JIS X0208の85区〜94区は、まるまる空領域(文字が定義されていない)のだが、マイクロソフトが定義したシフトJIS(CP932)では89区から92区にNEC選定IBM拡張文字というのが定義されている。

Unicodeを利用したマッピングだと、シフトJISからUnicodeへの変換はできるが、日本語EUC側に対応する文字がないので変換できない。これがアルゴリズムでシフトJISの85区1点を日本語EUCの85区1点に、85区2点を同様に85区2点へと変換していけば、コードの場所そのものは保存されるので、シフトJISから日本語EUCへ双方向で変換できる。従来の(太古の)ソフトウェアはそのようにして日本語のエンコーディングに対応していた。従ってある区点番号に文字が定義されていようがいまいが、その区点番号そのもので相互変換できたので、例え日本語EUCで文字が表示できなかったとしても再度シフトJISへ変換しなおせばデータは復活できたのである。ところが、Unicodeを利用したマッピングだと未定義な文字なので、どうころんでも一度変換に失敗すると復活させるすべがない。

この問題に対する解の一つは、日本語だけを特別あつかいをして、シフトJISと日本語EUCの変換アルゴリズムをソフトウェアに埋め込むというものがあるが、文字コードの種類（N）が増えてきたらN*(N-1)組の変換アルゴリズムを実装しなければならなくなって現実的とは言えない。(昔はごりごり、そーゆープログラムを書いていたのだけど)

もう一つの解は、シフトJISの文字種に対応した日本語EUCを定義してしまう事である。すなわち、機種依存文字とよばれるものNEC特殊文字(13区)、NEC選定IBM拡張文字を89区から92区に配置してしまうのである。これらの文字集合はeucJP-msとして知られていて、オープングループの日本ベンダ協議会が定義した。

今回のレガシーエンコーディングプロジェクトでは、eucJP-ms以外に、cp932、ISO-2022-JP-MSとCP51932を9つのOSS(libiconv/glibc/Perl/Ruby/Python/PHP/PostgreSQL/MySQL/nkf)について実装した。

文字化けのように昔から良く知られていて皆が解決が必要だと思っている問題でもよく見てみるとまだまだ整備されていないというものはOSSでも少なからづあるという事である。こーゆー問題を一歩一歩地味だけど着実に解決していくことがOSSの価値を高める事になるのである。

リンク：
Legacy Encoding Project Wiki
http://legacy-encoding.sourceforge.jp/wiki/
Sourceforege Project
http://sourceforge.jp/projects/legacy-encoding

日記など：
http://d.hatena.ne.jp/hyoshiok/20060316#p1

謝辞：
本プロジェクトはIPA (情報処理推進機構) の 2005年度下期 オープンソースソフトウェア活用基盤整備事業 で「オープンソースソフトウェアにおける統一したレガシーエンコーディングの変換機能の開発」として採択され支援を受けた。

大規模ソフトウェアの効率的な理解（その6）、リグレッションテスト

この「大規模ソフトウェアの効率的な理解(その4)」で巨視的理解、微視的理解という視点を紹介した。前者はソフトウェアをマクロから見ていわば俯瞰する。いわば鳥から見た図だ。後者は細部から全体像を把握する。いわば蟻の目である。地面にはいつくばっている。そのどちらの視点も忘れてはならない。Google Earthみたいに、自由に宇宙から眺めた視点からぐんぐんズームアップしていって、一つ一つのビルまではっきりくっきり見えるミクロの視点まで自在に動きまわらなければならない。

また、「大規模ソフトウェアの効率的な理解（その5）」で動的理解、静的理解という視点を紹介した。デバッガで1ステップ1ステップ実行するのは、微視的な動的理解であり、ソースコードを一行一行読むのは微視的な静的理解である。

リグレッションテストというのは、自動化テストの一種で、あらかじめ予想される出力結果を準備して、ソフトウェアを実行し、その実行結果と、予想した出力を比較し、予想どおりならOKそうでないならNGというように報告するものである。

最近ではテスト駆動型開発などのように最初にテストを準備して、その後に実装にはいるというベストプラクティスが広く実用化しているが、継続的な開発の場合、前バージョンで利用したテストがそのままリグレッションテストになる。

リグレッションテストは、巨視的な動的理解と言える。実装の詳細にたちいらないで(ブラックボックスとして)、入力と出力の組でソフトウェアの挙動を理解するという立場である。

大規模ソフトウェアの場合、ソフトウェアの隅々まで詳細に把握しているということは通常ない。大規模ソフトウェアのある機能を変更、追加する場合、自分の意図しない挙動を発生させることがある。いわばバグを作りこんでしまうことがある。リグレッションテストが整備されていれば、それを早期に自動的に発見できるので、大胆にソフトウェアを修正することが可能になる。リグレッションテストが整備されていないと、影響範囲を特定する事が困難なので変更量は可能な限り局所化最小化しなければならない。

リグレッションテストを整備しておけば、自分のソフトウェアの対する理解を仮想的に極大化できるのである。

OSSの実装も単にソースコードやドキュメントを整備するだけではなく、リグレッションテストをどれだけ充実するかという視点で議論、評価される時が来ているように感じる。よりOSSが大規模になり、修正が頻繁に求められるようになるとリグレッションテストが整備されているかいないかで、その変化に対する対応力が全然かわってくるのである。

Test Early Test Offten

シリコンバレー精神

「ウェブ進化論」でおなじみの梅田望夫による「シリコンバレーは私をどう変えたか」の改題、文庫化したのが本書である。「シリコンバレー精神」が96年から2001年ごろの5年間、「ウェブ進化論」はその後という感じである。梅田望夫の原点がこの本にある。うれしいことに著者自らによる文庫本新規書き下ろしのあとがきが本書のインサイドストーリを解説している。

自らが書いたものを自らが解説すると言うのは究極の解説である。文庫本の解説と言うの無駄極まりない盲腸のような存在であって無駄がゆえにヨタ話としては非常に面白かったりするが、おめーはそれを見たのかよというような突込みを入れたくなるようなアバウトな解説もあったりして玉石混合である。

しかし、「シリコンバレー精神で本書を書いた」なんていうのは本人以外わかりようがないし、その後のエピソードなんていうのも本人だからこそ書けることである。新規書下ろし60枚のあとがきは間違いなくお勧めであり梅田望夫ファンには「ウェブ進化論」を解題する上で格好なテキストとなっている。

それはともかくシリコンバレーをシリコンバレーとして特徴付けていることを一つだけあげるとしたらそれは何か？5年前に本書を読んで、わたし自身も90年代当事者として生活した経験を持つものとして感じることは、梅田の言う「シリコンバレーの凄いところは、ナードを搾取しなかったことにある」につきる。

失われた10年を取り戻すために日本は様々な制度改革を行い仕組みとしての直接金融だなんだというのを整備し会社法を引き合いに出すまでもなく器としての起業支援というのが整ったようにみえる。産業活性化のためにベンチャー支援だ～というお題目が聞こえてくる。まあ、ありがたいことである。

頭のいい人たちはシリコンバレーの仕組みのコピーにうつつを抜かしているのだが成功したと言う話は聞かない。もちろんそれは半分は成功した。仕組みとしての直接金融とかベンチャーキャピタルとか株式上場とかの環境は整備されている。その意味で半分は成功した。もう半分のシリコンバレーを支配する精神について日本と言う地域で再現可能なのだろうか？

それを考えたい。

日本では文系理系という枠組みがあって政府の仕組みやら政治経済の多くはいわゆる文系が支配している構造になっている。ごく例外的に理系的な人々が重宝がられる分野があるが通常は文系のほうが（生涯）賃金も高いことが知られている。最近でこそ特許料にまつわる裁判などで理系が生み出した価値について再評価が行なわれているがまだまだ例外的である。

価値を生み出すのは人間である。コンピュータや機械が自動的に価値を生み出すわけではない。文系とか理系とか関係なく人間が価値を生み出す。ソフトウェアという得体の知れないものをあやつってそれに本能的とも思えるほどの才能を発揮するものを梅田は「ナード」と呼んでいるが、シリコンバレーの凄みはそのナードを搾取しなかったことにある。そして徹底的に彼らが価値を創造する環境を整えた。

プロフェッショナルとして成長していくためのコミュニティ、大学を始めとする智の実験場、人材の流動性、人材評価システム。そこぬけの楽観性。

梅田はオープンソースの未解決な問題を7つあげた後、次のように書く。

「これらに共通する本質的課題は、ナード世界とビジネス世界の新しい関係の構築にある。そしてそのためには『ナードたちはなぜプログラムを書くのか』という哲学的問いに答える努力をしていかなければならないのだ。
　しかしその問いに対する答えを、日本で考えることはできない。なぜなら日本社会や日本企業は、ナードの価値を全く理解せず、ナードを大切にしてこなかったし、今も大切にしていないからである」（ナードの価値、186ページ）

99年に日本に戻ってきてひょんなことからミラクル・リナックスの創業に関わった。そしてその時来わたし自身への宿題は、日本という地域でシリコンバレー的な精神を再現することは可能なのだろうかという問いかけである。まだ結論は出ていない。しかしインターネットとオープンソースという潮流はそれを可能にするとわたしは考えている。もちろん一社だけでできることは限られているが少しずつ仲間を増やしナードの価値を理解し大切にする社会を作りたいと考えている。

Lions' Commentary on UNIXを読む。

UNIXバージョン6のソースコードとそれの註釈と解説をした伝説の名著である。日本語訳もある。ISBN4-7561-1844-5

当時のUNIXの中核部分はたった1万行弱のコンパクトなプログラムであった。そのために学生が学習するためにはもってこいだった。

  UNIXはすでに利用可能なシステム上で実行されている。
  UNIXはコンパクトで理解しやすい。
  UNIXは広範囲に渡る非常に有用な機能群を提供している。
  UNIXは元来おもしろく、実際多くの分野で新天地を開拓している。
  まえがき(249ページ)

現在のOSはどれもこのサイズをはるかに凌駕している。Linuxは数百万行のサイズである。

OSを教えるための主なアプローチとして次の3つがあるとLionsは記している。

1) 一般原理

基本的な原理を詳細に説明し、さまざまな既存のシステムを参照しながら解説する。(中略)多くの学生はここから十分に学び取るほどには習得もしないし、経験を積むこともない。

2) ビルディングブロック

学生達は自分たちで小さな、あるいは"おもちゃの"オペレーティングシステムを組み立てられるようになる。確かにこれは価値ある学習になることがあるが、正確に系統立てて学ぶには、実際のオペレーティングシステムの複雑さと精巧さを取り込まないわけにはいかない。

3) ケーススタディ

これは元々、コンピュータサイエンスに関するACMカリキュラム委員会の報告の中のシステムプログラミングコースのために推奨されたアプローチである。
10年前、適切なシステムを十分な学生に利用できるようにするコストは単純にいって高過ぎたので、「コースの大部分を１つのシステムの研究にあてる」ことを唱えるこのアプローチは非現実的であった。
10年がたち、経済状況は際立って変化し、ミニコンピュータシステムが研究の主題になるならば、もはやコストはそれほど問題にならなくなっている。既存のシステムの詳細な分析に取りかかるアプローチの持つ多くの利点はこの時点で到達可能である。
われわれは、あらゆる局面で、稼働しているオペレーティングシステムを学生が研究する機会を得ることは非常に有益であると考える。
その上で、コンピュータサイエンスを専攻している学生が自分のキャリアの中で少なくとも一度はかなり重要なプログラムを読み、理解することに直面することは、確かによいことである。

OSほどの複雑さをもったものを学ぶためには、適切なコース、カリキュラムが必要だが、Lionsの著書は適度な分量で入門書として適していると思う。OSが持つべき機能をトップダウンで解説した一般原理アプローチの教科書は多いが、学生がそこから学ぶものは低いという立場をLionsはとる。わたしも、その通りだと思うが、OSが持つべき共通のアーキテクチャというのはあるので、その語彙を統一するためには標準的な教科書は必要である。

一方でケーススタディから学べるものは多い。実際の実装上のトレードオフ、数々の制約の中でのトレードオフなど理論ではないドロ臭さを学べる。

オープンソースソフトウェアの実装は、先人の知恵を学ぶ宝庫である。それをどのように学ぶかという方法論が実は強く求められているのである。

なぜソースコードを読むのか？

遥か昔に下記のようなものを書いた。1999年当時私はオラクルの開発部隊に所属していた。1998年に米国ネットスケープがそのコードをオープンソース化し、世間ではいったいオープンソースとは何かということが良く知られていなかった頃の話だ。当時の様子がよくわかるので再録する。ちょっと長くなるが読んでほしい。

日経ソフトウエア1999年9月号、77ページ 掲載
よしおか ひろたか

Eric S. Raymondは、「The Cathedral and the Bazaar」という有名な論文で、フリー・ソフトウエア(後にオープン・ソース・ソフトウエアと呼ばれるようになる)がどのように開発されていくか、そして発展していくのか、一般の人々にもわかりやすい形で解説した。従来型の大規模ソフトウエアの開発を「Cathedral(大聖堂)」型開発、オープン・ソースの考え方に基づいた開発を「Bazaar(市場)」型開発と定義したのだ。

私は、あるデータベース・ベンダーに勤務している。Eric S. Raymondに言わせれば、Cathedralのプログラマであろう。信頼性の高いソフトウエアを開発するためには、ソフトウエア開発体制の「整備」とか「管理」とかが必要であるというパラダイムにいる。白状するとこれまで私は、明確なプロジェクト・リーダーもいなければ管理者もいない、技術的なロードマップも明らかでなければ、厳密な品質管理も定義されていない場当り的なプロジェクト(つまりフリー・ソフトウエアのことだ)によって、品質の高いソフトウエアが生まれるわけがない、と思ってきた。

例えば、私の日常生活はこんな感じだ。

朝、テスト担当者からメールが届いている。私が昨日、行ったプログラムの変更によって、リグレッション・テストにdiffが出たという。ついては、そのdiffが予期するものか予期しないものかを教えてほしい、という内容だ。多くの読者にとっては、チンプンカンプンなメールだろう。

一般に、データベース・エンジンのような大規模ソフトウエアは、プログラムの変更を毎日管理していて、担当者(例えば私)が変更したプログラムは、すべて構成管理データベースへ登録される(この登録をチェック・インと呼ぶ)。多くの担当者がそれぞれ変更を行っているから、時にはその変更が予期しない副作用を生じさせることもある。そこで、毎日その変更点を取り込んだソースコードからソフトウエアを構築し(これをデイリー・ビルドと呼ぶ)、テストにかける。これをリグレッション・テスト(回帰テスト)と呼ぶ。昨日まで正常に動作していたリグレッション・テストが今日の変更分から動作しなくなったとすると、昨日の変更が最もあやしいということになる。少しでも変更したら、すべてテストをやり直し、それを延々毎日繰り返す。まあ、きわめて単純な作業である。

メールに出てきたdiffというのは、そのリグレッション・テストで、昨日までの結果と今日の結果に「違い(UNIXのコマンドdiffからきている)」があった、という意味である。プログラムの機能を変更したのだから、その意図通りのdiffであればよいが、意図と違う副作用であれば問題だ。その判定は変更者にしかできない。したがって、私のところに問い合わせのメールが来たわけだ。

私はそのメールを読んで、「ああ、これはシンタックス・チェックを厳しくしたから、従来はノーチェックでうまくいっていた命令がエラーになったんだな。だからこのdiffは安全なやつだ、うんうん…」、とかいうことを考える。そして、実際にテストのログを見て、自分の仮説が正しいことを確認し、担当者に返事を書く。「このログは意図した変更だから問題ない。新しいテストのログをチェック・インしてくれ」と----Cathedral型開発には、そのような管理の仕組みがある。

一方オープン・ソース・ソフトウエアはどうだろう。プログラムの変更は、大多数の善意のプログラマたちがよってたかってソースを読み、レビュー(ピア・レビューと呼ぶ)することによって行われる。多くの目があればそれだけ早く問題は発見され解決する。それがBazaar型開発だ。ここにソースコードを公開する意味がある。

ソースコードを読むチカラ

私が驚いたのは、このピア・レビューの方法論が、Linuxのような大規模で複雑なソフトウエア開発でも機能する、ということだった。結局、私はこの素朴な、しかし協力な方法論の重要性を十分よく理解していなかった。それは、前述したようにCathedralのシステマチックな仕組みの中にいるためなのか、それとも単に私が愚か者だからなのか、あるいはその両方なのかはわからない。だが、ある時、ふと気がついたら世界観が変わっていた。そんな感じなのだ。

オープン・ソース流の開発では、コアのコードを最初に書く少数のプログラマと、そのコードをよってたかって改良、変更する大多数のプログラマがいる。そして大多数のプログラマにとって重要な技術は、プログラムをゼロから設計して実装する技量よりも、むしろ先人の書いた大量なコードをすばやく読んで理解するチカラだ。

今後、すべてのソフトウエアがオープン・ソース化されることはなくても、何らかの形で、オープン・ソースは一般化し普及していくことだろう。このとき、ソースコードが公開されていても、それを読みこなせなければ宝の持ちぐされである。

ソースコードを読む。その基礎的な技術がオープン・ソースの時代には最も必要とされているのである。
---
(引用終)

あれから7年たった。

オープンソースは一般化し、ソフトウエア業界にいるものは誰でも知っている存在になった。大聖堂(Cathedral)のプログラマであった私にとってはバザールモデルのソフトウエア開発は驚異的なソフトウエア開発方法論であった。7年間経験を積みその驚きは確信になった。

オープンソースの利用がより広範囲にそしてよりミッションクリティカルなシステムに広がっている状況を鑑みるとこのバザールモデルでのソフトウエア開発に対する深い理解が必須になってくる。

そして大規模ソフトウエアの効率的な理解という文脈でソースコードを読むチカラの重要性はますます高まっている。

大規模ソフトウェアの効率的な理解（その5）

動的理解、静的理解

ソフトウェアの理解のもう一つの視点は、ソフトウェアの動的な理解と静的な理解というのがある。

動的というのはソフトウェアを実行した時の挙動のことをさし、静的というのはソフトウェア(プログラム)の字面をさす。

静的な側面からの理解はソフトウェアのコードを読み、そこから何らかの形でプログラムの挙動を理解していくというアプローチになる。字面からの理解ということで、ディレクトリ構造やファイル名や変数の命名規則、コードリファレンスなどが静的な理解の対象になる。

動的な理解は、デバッガによる実行、プロファイラ、トレーサー、ベンチマーク、リグレッションテスト等々実行結果による理解となる。各種ツールが理解を支援してくれる。

ソフトウェアというものは、単純化すれば、ある入力に対して何らかの出力をする機械ととらえれば、ソフトウェアを理解するという事は、その入出力の組を知ることに他ならない。動的な理解というのはまさにそのソフトウェアを動作させ、その入力と出力の組を確認することになる。マクロでとらえればそのようになるが、実際は、その入力と出力の変換方式を詳細におっていくという作業になる。

動作をどんどん微分していけば最終的にはソースコードの一行になる。何百万行の大規模ソフトウェアも最終的には一つ一つの命令に帰着する。そうするとその動作はプログラムの静的な側面になる。机上デバッグというソースコードを机上で一行一行読み理解するプロセスというのはその一行一行の静的な意味を積み重ねて動的な意味に脳内で変換する作業といえる。

動的な理解と静的な理解をいったりきたりしながらソフトウェアの挙動を徐々にとらえていくというプロセスになる。

このソフトウェアを理解するプロセスというのは、あまり明文化されていないし、各人のスタイルに依存するが、あえてそのプロセスを明記する事を試みる。それが成功(？)すればデバッグやトラブルシューティング、性能チューニングの手法の一助になるかもしれない。(ならないかもしれないが、やってみない事にはわからない)

試行錯誤を共有すること

大規模ソフトウェアの効率的理解(その5)を書いていたのだけど、たまたま読んだ、渡辺千賀さん「On Off and Beyond、シリコンバレーIT業界転職率」にインスパイヤされて話をころっと変える。

主題は転職事情ではなく、そこで引用されているThe New York Timesの記事「In Silicon Valley, Job Hopping Contributes to Innovation, By VIRGINIA POSTREL, Published: December 1, 2005」からの孫引き

when there is a lot of technological uncertainty, the fastest way to find the best solution is to permit lots of independent experiments.

のくだり。

シリコンバレーやボストン郊外のルート128界隈の地域的な強みと言われているものは、一社に依存しているのではなく(日本の企業城下町とは全然異なることに注意しよう)、高い人材流動性と地域として試行錯誤を許容するカルチャーと言ってさしつかえない。核となる大学がある種の緩衝地帯を構成している事実もみのがしてはいけない。試行錯誤は大学ではじまり、ある程度、目が出てきそうになったらベンチャーに形をかえ、ビジネス上の試練を経て世の中のメインストリームになるか忘れさられるか。壮大な実験を彼の地でおこなっている。

ともかくやってみる事である。うまくいくかいかないかよくわからないけど、ともかくやってみる、そーゆーカルチャーである。賭金は高いがリターンも大きい。

通常はそのような試行錯誤は、その人の経験として蓄積される。チームでの仕事は当然チームメンバーで共有されるが、チームが解散し、それぞれ別の会社に移っても、ゆるやかに共有されるので、地域としてのベストプラクティスが徐々に蓄積されていく。

そこで、オープンソースだ。

OSSの評価プロジェクトを他社とやっている。スケーラビリティ上の問題をいろいろ発見している。問題点は発見したので、それを解決するパッチを作ろうという話になった。通常のプロジェクトであれば、試行錯誤の結果、何かしら効果のあったパッチを成果物として公開するというスタイルをとるだろう。普通はそうだ。

しかし、本当の価値は、パッチという結果ではなく、そこに至るプロセスである。試行錯誤して、効果のないパッチを山のように作ることである。その効果のなかった筋の悪いパッチの山から、われわれは何を学ぶかという点にある。

それらの経験は従来は個人に帰属していた。そしてその経験量が個人の資質とあいまってエンジニアとしての成長を促していた。

試行錯誤も含めて共有できれば、一人のエンジニアが経験できる量をはるかに凌駕する擬似経験ができるのではないか？無駄なパッチは無駄ではないのである。

全速力で試行錯誤を繰り返し、多くの失敗を重ね、その経験を会社の壁を乗り越え共有する。全く新しいコラボレーションのスタイルがオープンソースだから可能になる。

オープンソースというのは本当にとてつもないパラダイムである。

大規模ソフトウェアの効率的な理解（その4）

巨視的、微視的な理解

大規模ソフトウェアを理解する視点として、巨視的な理解、微視的な理解というのがある。巨視的な理解では、ソフトウェアをトップダウンに全体像から細部へと理解の道筋をたどる。一方、微視的な理解では、逆に細部から全体像へとボトムアップな理解の道筋をとおる。

規模の理解というのは、典型的な巨視的な理解の手法であり、ソースコードの解析は微視的な手法である。どちらも重要な視点で、それぞれの手法をバランスよく利用する必要がある。

大規模ソフトウェアの場合、微視的な視点からスタートすると、その規模のため、時間がおそろしくかかるという特徴があるので、最初は、巨視的な理解からはじめるのが王道である。その理解のプロセスの中で、興味のあるサブコンポーネント(論理的あるいは物理的な部分)へ到達したとして、そのサブコンポーネントの理解は徹底的に微視的な視点からはいるという方法もある。

例えば、あるソフトウェアのバグ修正などという作業の場合、ある程度の巨視的な理解の上、どの部分でバグが発生しているかを同定した後は、ソースコードレベル(微視的な)の理解をしつつデバッグをするというプロセスになる。

またコードリーディングは典型的な微視的な理解の方法論である。(ひらメソッド、コードブログなども参考にされたい)

巨視的理解、微視的理解それぞれに必要なテクニックやツールというのがあるので、それについてもプロのプログラマとしては十分訓練しておく必要がある。

巨視的な理解    規模の把握(ファイル数、行数など)、ディレクトリ構造、ドキュメントの精査、プロジェクトのポータルサイトの確認(サイトマップ)、メーリングリスト、掲示板等コミュニティサイトの確認、名前付け規約の確認、ソースコード管理システム、バグ管理システム、

微視的な理解    ソースコード、ソースコードリファレンス、ChangeLog、バグデータベース、ソースコード管理システム(バージョン間の差分)、検索エンジン、メーリングリスト

トラブルシューティングの場合、前提条件としてあるソフトウェアについての巨視的理解については、ある程度おわっているとして、いきなり微視的な作業からはじまる。例えば、ある不具合についてバグデータベースを検索し、同様の不具合があるのかないのかの調査、エラーメッセージを検索エンジンで調査するなどのフェーズがある。問題を再現したら、デバッガを利用しつつソースコードの解析、分析などをしながら問題点の詳細な理解などをしていく。その時に必要な道具立てもいろいろかわってくる。

このようなツールと手法あるいはプロセスについては明文化した教科書がないので、各人がそれぞれのスタイルで長年の経験のなかで培っている。今回あえて自分のプロセスを公開するのは、このことによって、多くの人に参考にしてもらうとともにさらなる改良をほどこしたいと思っているからである。それがインターネット時代あるいはオープンソース(バザールモデル)の基本的なスタイルであるからだ。

公開することによって進化する方法論といっても差し支えない。
読者諸氏のコメント、トラックバックなどを強く期待するところである。

それぞれのツールと手法についてはまた別途記す。

大規模ソフトウェアの効率的な理解（その3）

規模の把握

大規模ソフトウェアの理解はいろいろな観点からのアプローチがある。ソースコード一式(通常tarballと呼ばれている)を入手し、適当なディレクトリに展開する事からはじまる。tarballではなく、CVSのようなソース管理システムから直接入手する場合もある。

tar.gzというような形式の場合、$ tar xvzf XXXX.tar.gz というようなコマンドで展開する。$ cd XXXX してざっとディレクトリをながめる。通常、READMEないしINSTALLなどのファイルがあるので最初にそれを良く読む。またDocsなどというドキュメントを置いておく場所があれば、その中になにがあるかをざっと見る。

いきなりソースコードを変更するのではなく、このようにディレクトリ構造を調べたり、規模の把握をしたり、おおまかな骨格を理解するようにする。ディレクトリ構造は当該ソフトウェアの物理的構造をあらわしている。ソースコードのディレクトリ、テスト、ドキュメント、各種ツールなどなどからなる木構造になっている。

大規模ソフトウェアの森に地図もなしにいきなり飛び込むと迷子になってしまうので、ソフトウェア構造の下調べとして、規模の把握やディレクトリ構造の調査、そしてドキュメント類から名前付け規約などを調査しよう。

ソースコードの分量を知るには
$ find -type f |egrep '\.([chp](xx|pp)*|cc|hh)$'|wc -l
でファイル数が表示できる。ソースコードの行数は
$ find -type f |egrep '\.([chp](xx|pp)*|cc|hh)$'|xargs wc -l
ファイル数が多いと最後のwcのあとに、さらに
$ find -type f |egrep '\.([chp](xx|pp)*|cc|hh)$'|xargs wc -l|grep total
とする。

自分がこれから格闘しようとしているソフトウェアの正確な規模もしらないで、どのようにしてそれに取り組むのか。tarballを展開して最初にやる作業はソフトウェアの規模の確認というのは王道だと思う。小規模なソフトウェアであればたいした準備もなく格闘できるかもしれないが大規模ソフトウェアであればやはりそれなりの心構えと準備が必要である。どのくらいの装備が必要かは自らの経験とソフトウェアの規模と複雑さによる。

プログラマが感じるソフトウェアの規模と複雑さは、その人の経験とスキルにかなり依存する。新人にとっては、1万行のソフトウェアでも十分大規模に感じるだろうが、ベテランプログラマであれば小規模に感じるだろう。いずれにせよ、規模を把握して心の準備をしよう。

大規模ソフトウェア探索の旅はそれから始まる。

大規模ソフトウェアの効率的な理解（その2）

ソフトウェアの規模を大体下記のような感じでわたしはとらえている。

規模         行数
小規模       10万行以内
中規模       10万〜100万行程度
大規模       100万行以上

ソフトウェアを構成する行数でおおざっぱにくくっている。あるいは開発に関与する人数によっても同様にくくれる。

規模         人数
小規模       10人以内
中規模       10人〜100人程度
大規模       100人以上

ここで見ているのはあくまでも量での視点で，質的な複雑さとか難しさは一切見ていない。いずれにせよ規模の観点からいうとLinuxカーネル(あるいは定番のＯＳＳ)というソフトウェアは大規模なソフトウェアである。そして大規模ソフトウェアを開発するのにはそれなりの難しさというか小規模なソフトウェアを開発するのとちょっと違ったテクニックを必要とする。そのようなテクニックとか開発のプロセスとかは現場で経験して徐々に身につけていく種類のものでソフトウェア工学の教科書にもあんまり載っていなかったりする。ある意味でこれは各社のソフトウェア開発の現場が持っているノウハウなわけだけれどそれ自体はシリコンバレーあたりでは明文化されてはいないがある種の共通の認識みたいなものがあったりする。その明文化されていない開発プロセスをＯＳＳという題材を利用して明らかにしたいなあと思っているのである。

かつて、わたしはモジラの解剖というウェブのページを持っていたのだが(今は残念ながらないが、ウェブのアーカイブに残骸が残っている。文字化けするときは、Microsoft Internet Exploreの場合：表示＞エンコード＞日本語（シフトJIS）Mozilla Firefoxの場合：表示＞文字エンコーディング＞日本語（Shift_JIS）)、モジラを題材に大規模ソフトウェアの理解のプロセスを記そうとした。大規模ソフトウェアの開発にはある種の定番があるのでそれを記してみたい。

注：ひらさんとの議論はどちらかというとコードリーディングという大規模ソフトウェアの理解の一部分としてわたしはとらえている。

梅田望夫氏との対談イベント：「シリコンバレーのビジネス風土」と「オープンソースの思想」

長年の友人でもあり、ベストセラー「ウェブ進化論」の著者の梅田望夫氏と対談をします。申込方法その他は、梅田さんのブログを参照ください。

わたしが紹介するまでもないですが、梅田さんは長年シリコンバレーでコンサルタントとして活躍するかたわら株式会社はてなの取締役としてまたアクティブなブロガーとして日々進化(？)しています。

8年前オープンソースという超新星が登場して以来、オープンソースとインターネットというキーワードは常に彼と議論する時の軸足になっていました。この10年、これからの10年について、どんな対談になるか今から楽しみです。

2006年9月1日(金)夜、東京で、対談イベント：「「シリコンバレーのビジネス風土」と「オープンソースの思想」」を開催します。8月10日頃から書店に並ぶ拙著「シリコンバレー精神」(ちくま文庫)の刊行を記念したイベントでもありますが、本ブログ読者との「ささやかなオフ会」という意味合いもあります。

対談イベント:「「シリコンバレーのビジネス風土」と「オープンソースの思想」」

• 2006年9月1日(金)
• 時間：19:00-20:00（その後、懇親会あり）
• 場所：東京都内（赤坂周辺）
• 会費：懇親会費用（実費）として1,000円〜2,000円程度（当日受付にて徴収させていただきます。領収書の発行は致しません。）

My Life Between Silicon Valley and Japan
http://d.hatena.ne.jp/umedamochio/20060801/p1

なお、対談および懇親会の様子はYouTubeなどにアップする予定です。熱いぜ〜

大規模ソフトウェアの効率的な理解

大規模ソフトウェアの開発が大企業によって行なわれていた太古の時代、新人はそのプロジェクトに配属されるや膨大なドキュメントを渡され、とにもかくにもそれを読むことを要求された。わからないことは隣の先輩に聞いて覚えた。失敗はどやされるが、それがいい経験になって少しずつ大規模ソフトウェアの全貌を理解していった。すぐそばにその大規模ソフトウェアを作った人がいるから細かいところも突っ込んでわかるまで聞くと言うことができた。大規模ではあるが秩序だった管理システムがあり見通しは悪くなかった。ある意味牧歌的な時代であった。変化もそれほど激しくなかった。

一方OSSの場合、一人のコア開発者がこつこつ自分の興味の赴くままその核となる部分を開発する。ある程度、機能もそろったところで、アルファ版みたいなものを公開する。サイズもそれほど大きくない。ソースコードもまだごちゃごちゃしていないので、構造を理解することはそれほど難しくない。

しかし、定番のOSSであるLinuxカーネルやMySQL/PHP/PostgreSQL/Samba/Perl等々は十分でかくて、ソースコードのサイズも100万行を超えるものが珍しくない。なんの準備もなくそのソースコードの森に飛び込めば確実に迷子になる。初期のころから関わっている開発者ならまだしもぽっとでの新人がすぐに全体像を理解できるほど単純でも小規模でもない。

OSSの時代こそ大規模ソフトウェアの実装の効率的な理解の方法論が求められている。企業が自分が作ったソフトウェアを自社のエンジニアに教育（OJT）するのと違って、OSSはそのような内部構造の教育コースがない。自分のすぐそばにコア開発者がいないので簡単に聞くことが難しい。

頼りはソースコードとメーリングリストとポータルサイトだ。Googleも助けてくれるが隣に聞く人はいない。ソースコードを効率的に理解する方法論がいまこそ求められているのである。

その実践的な方法論についていろいろ議論していきたいと思う。