From the Software Design Gallery の連載開始にむけて

私事で恐縮ですが、 私のホームページは、おかげさまで５年目を迎えることができました （2000年4月現在）。 公開を始めたころは Windows95 が発売されて半年たったころで、 Netscape が Microsoft の牙城をインターネットによって 脅かそうとしていました。 Sun は、ブラウザの上でプログラムが動くアプレットを開発し、 Java 言語が彗星のごとく現れたりと、 非常にエキサイティングな時代だったと思います。
Microsoft は、Inetenet Explorer を無料で配布したり OS にデフォルトで付けたりと、 独占禁止法に違反するほどのあらゆる手段を使って、 Netscape に商売のチャンスを減らしました。 これら圧力にも、Netscape の機能が勝っていたころは まだ支持者も大勢いたのですが、 開発力を結集した Microsoft のリリースラッシュにより、 機能的にも Microsoft に軍配が上がってしまい、 かなりのシェアが奪われました。

Netscape 社はこの危機的な状況において、世紀の大決断をしました。 Netscape のオープンソース化です。 ソースを公開することによって、世界中のフリーソフト開発者の 強力な開発力を獲得しようとしました。アンチ Microsoft という立場もあり、かなりの開発者が協力してくれるものと 信じられていました。 しかし、現実はうまく行きませんでした。
私の推測ですが、その理由は主に２つあったと思います。
１つは、オープンソースであっても ライセンスは Netscape 社が持つために、 フリーの精神を持った開発者の 意欲をあまり掻き立てるものではなかったのではないかと思います。
もう１つは、Microsoft との激しい競争のために、 ソースがかなり複雑になっており、 どこをどう直したらいいかわかりにくかったり、 部品ごとの依存性が激しかったために１つの修正をすると 別の修正部分探さなければならなかったりという、 いわゆるスパゲッティ・プログラムだったそうです。
私もフリーソフトを提供しているので、 オープンソースの動きには共感できるのですが、 スパゲッティ・プログラムという技術的な理由が原因の１つで うまく行かなかったと思うと残念で仕方ないです。

オープンソースやフリーソフトは、それだけで『強み』を 持っていると思います。 それは、ただで使えるということだけではありません。
１つは、プログラムを共有財産にできるため、 誰でも使うことができ、同じ物を無駄に作らなくて済むこと。 もう１つは、多くの人が利用することで厳密な試験に相当する チェック機能が自然に働くことことでしょう。
しかし、フリーであることの弱みもありると思います。 たいていは少数の高度なプログラマが作成してるので、 ある程度以上の規模以上のものは作れないと思います。 また、高度なプログラマは、内部のアルゴリズム的な高度さや シンプルさに興味を持つために、抽象的でわかりにくいものが 出来あがる傾向があると思います。 （私のプログラムや文章も多分そうでしょう）。 Perl は素晴らしい拡張性を持っていますが、 そのソースは読みやすいものではありません。 ワープロソフトなどの論理的につまらないものも 生まれにくい傾向があると思います。 フリーのプログラマは、自己満足のために行っていることが多いので、 プログラム・ソースもあまり読みやすいとは言えないと思います。 （すべてがそういうわけではありませんが）

しかし、先ほど説明したフリーの強みは、 コストの少ない流通の仕組みを取り入れることが出来れば、 フリーでなくても出来ないことはないでしょう。 プログラマは残業ばかりで大変な職業だと思います。 そこにフリーの強みが取りこめたらいいのではないかと 私は常々考えています。

Microsoft の構内では、 オープンソース・コミュニティと同じような 自由な雰囲気を作ろうと工夫されているようです。 その一方で、COM のルールを作ったり、 デファクト・スタンダードとなるような規格や プログラミング・スタイルを作ったりと、 自由を奪うようなことも行っています。 ルールというものは何でも、自由を奪ったりコストを支払う代わりに、 よりよく活動することが出来るようになります。 たとえば、COM は再利用性を高めるための技術ですが、 COM に準拠するためには非常にコストがかかります。 しかし、COM に楽に対応できるような開発環境が そろってくると、よりよく活用することが出来るようになります。 依然としてルールは残っているのですが、 コストよりもメリットの方が大きくなっています。

読みやすく汎用的なプログラムを作成することは、 ほとんどのプログラマの興味深いテーマだと思います。 これから始まる連載では、私の長年のプログラミングの現場の経験に 基づいて作り出された読みやすく汎用的なプログラムにするための ルールを紹介します。 言いかえれば、オープンソースが理想とするプログラムの流用性、 つまりコストを少なく流通できるためのルールを重点的に説明していきます。 場合によっては、価値観の違いによってメリットよりも コストが大きいこともあるかもしれませんが、 そのときは、自分のいいと思った部分だけ吸収すればいいでしょう。

スパゲッティ・プログラムにならないようにすることは、 プログラマーにとっては常識ですが、他人のプログラムは 読みやすいものではないというのも常識です。 読みやすいプログラムにすることも常識ですが、 過去に自分が作ったプログラムを読めないという冗談は よく聞きます。 再利用して開発効率を高めることもよく聞かれますが、 そのために汎用性を高めることに工夫がされるだけで、 理解しやすいことを考慮していないことも多くあります。 ドキュメントを書いて理解しやすいようにしようというのも よく聞かれますが、ソースを直訳しただけのドキュメントのために、 ソースと内容が一致させるのが難しかったりします。 人員を追加投入しても、現在開発中のものを理解するのが 大変であるために、あまり効果が無いこともよく聞かれます。

このようなネガティブな常識や冗談は、これから連載していく、 理解しやすいプログラム、再利用しやすいプログラム、 依存性の少ないプログラムにしていくことで、 無くすことが出来るでしょう。

連載では、他にも、開発効率を上げるためにデバッグ方法や テストケースの作成方法、 プログラムの性能を自然に上げるための工夫、 これらの際に必要となると考えられるツールなど、 プログラム開発に関する一般的なことも広範囲にわたって 解説していこうと考えています。

しょっぱなから、難しい話になってしまったかもしれません。 しかし、なるべく簡単な文章になるよう心がけ、 少しでも多くのプログラマの役に立てることができればと思います。