巨大なビルディングブロックになったシステム

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

NetBeans開発プロジェクト10年超の蓄積！API設計の経験や考察をまとめた一冊

この記事は、書籍『APIデザインの極意 Java/NetBeansアーキテクト探究ノート』の内容を、Think IT向けに特別公開しているものです。

この連載では、何回かに分けて本書の内容を紹介します。今回は前回に続き、第1章の一部を掲載します。

今までのソフトウェアの発展

1940年代と50年代初期には、プログラミングは困難でした。人々は、コンピュータの言語を話すために機械語を学び、レジスタの大きさとレジスタの個数を知らなければなりませんでしたし、最悪の場合には、スクリュードライバを持って、個々の計算ユニット間に信号を物理的に伝える線を接続しなければなりませんでした。アルゴリズムを考案するために必要な時間と、労力をかけて実行可能なプログラムに変換する時間を比較すると、かなりの時間が退屈で機械的な作業に費やされていました。

FORTRANは、神の恵みとも言えるような簡素化をもたらしました。経験主義者が得たように、制限はあるものの数学式を計算する世界をプログラマに与えました。プログラマは、もはやアセンブリ言語を理解したり、コンピュータの技術的な内部を心配したりする必要はありませんでした。プログラマは、これらの詳細を完全に忘れて、もっと重要な事柄、すなわち、数学式について、それを計算するためのアルゴリズムへ変換することに集中できました。FORTRANは、人々が計算できることをわずかに制限するだけで、ソフトウェア開発プロセスを簡略化しました。経験主義にとっては、大きな勝利です。

しかし、プログラミングはそれでもまだ簡単なことではなく、さらに簡略化する余地が多くありました。COBOLなどの新たな言語が、「初心者プログラマでも扱える」や「経営者が読める言語」というビジョンを持って登場し、プログラミングに関連するある種の仕事を簡略化しました。今日、COBOLで新たなシステムを作成することを真剣に検討している人はいません。しかし、その頃、COBOLは、アセンブリ言語あるいはFORTRANと比べて、データベースへのアクセスと操作に必要な知識の量を劇的に減らしました。経験主義は増加しつつありました。

しかし、誰もがこれを気に入っていたわけではありませんでした。推察を信じる人々は必ずいるものです。つまり、世界とそこに存在する物事は推察可能であるべきだと信じる人達です。そのような人達は、私達の周りにいますし、プログラマの中にもいます。50年代、ジョン・マッカーシー（John McCarthy）は、強力な理論的基盤を持つラムダ式の数学モデルに基づいたLISP言語を生み出しました。数学は、ほとんど合理主義的な分野であり、その基盤は、純粋な論法に支えられています。LISPの設計では、「数学的な整然性は、何よりも重要である」とする期間があったとされています。それは、合理主義の兆候だったのです。LISP言語は役立つ必要がないし、実装可能である必要もなく、純粋で綺麗で合理的である必要があったということです。

コンピュータ科学には、ヨーロッパと米国という2つの流派が存在してきたと言われています。米国はたいてい実用主義的ですが（もちろん、実用主義は米国で生まれています）、ヨーロッパはたいてい優れたビジョンを探求しています。コンピュータエンジニアリング設計でも同じことが観察できます。ヨーロッパ人が機能性よりも合理性を好んだ様々な例があります。メッセージに基づく計算とセマフォ同期パターンを生み出したエドガー・ダイクストラは、「計算に関する厳選著述：個人的見解（Selected Writings on Computing: A Personal Perspective」^※1。で、「強い数学的な嗜好を持つ厳格なエンジニアリング原則としてプログラミングは登場した」と述べています。そうであれば、私達は合理主義へと進んでいくことになったでしょう。しかし、私が周りを見渡して、人々が会計プログラム、病院患者データベースなどをプログラムしているやり方を見てみると、料理で数学がほとんど不要なのと同じぐらい数学は使用されていないと感じます。実際、優れたアルゴリズムは、数学的背景を必要とするかもしれません。しかし、Pascal、Oberon、それに他のシステムの生みの親であり、影響力を持つヨーロッパ人ニクラウス・ヴィルト（Niklaus Wirth）は、「単純で優雅な解法は、より効果的であるが、見つけるのは難しく時間を要する」と述べています。もちろん、彼は正しいです。市場投入までの時間が成功の評価尺度の1つである時代においては、純粋で綺麗な解法への終わりなき探求へ投資する時間はありません。

[※1] Edsger Dijkstra、Selected Writings on Computing: A Personal Perspective（New York: Springer-Verlag, 1982）。

今日のソフトウェアエンジニアリングの世界では、合理主義的取り組みの存在する場所はないことを認める時期に思えます。それは、特に合理主義の教会で祈るプログラマの数が不足しているからです。あるいは、図1が示すように、ほとんど完全にプログラマが不足しています。これは目新しいことではなく、ダイクストラの別の言葉「優れたプログラミングは、今日の平均的なプログラマの知的能力をおそらく超えている」がそれを表しています。それは、真実です。しかし、新たなプログラムに対する熱望は大きくなっています。それに対して何が成し遂げられるでしょうか。

合理主義や経験主義が普通の人々にとっては全く重要でないといった具合に私達が世界を理解している事実に従えば、明白な助言は無知になることです。プログラミングでの状況も似ています。世界、すなわち、少なくとも私達の社会は、すべての人々が働くために哲学者である必要はありません。社会は、教育が十分でない人々、すなわち、もっと無知な人達の居場所が存在する形で構成されています。そして、それでも物事は機能しているように思えます。同様に、ソフトウェアエンジニアリングでも、すべてのプログラマが高等教育を受けた科学者である必要はありません。私達が今日行っているような、あるいは、それ以上のソフトウェアを作り出したいのであれば、プログラマが無知であっても信頼できるシステムを生み出すためのシステムを必要とします。

図1: HTMLの仕事を求めています（Will code HTML for food）

実際、前述の無知は、プログラミングで全く認識されていないわけではありません。単にキーボードで好き勝手に文字を叩いても、コンパイル可能なプログラムにはなりません。コードの書き方を知っていることが、実際プログラマには必須です（TVコマーシャルを見て、理解し、議論できる能力は、ある種の人間社会では必須のスキルであるのと同じです）。ソフトウェアエンジニアリングの無知の核心は、プログラマが多くを知ることなく、それでも優れた結果を達成させることです。一般的に、どの知識が必要で、どの知識が不要かを述べることはできません。しかし、目標は、開発者がすべてを知らなくてもよいコーディング方法を見つけることです。すなわち、開発者が必要な知識を選択することです。私は、それを選択的無知（selective cluelessness）と呼びます。