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

遥か昔に下記のようなものを書いた。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年間経験を積みその驚きは確信になった。

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

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