PR

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

2014年9月12日(金)
Jaroslav Tulach(ヤロスラフ・ツゥラッハ)柴田 芳樹(しばた よしき)
APIデザインの極意 Java/NetBeansアーキテクト探究ノート
NetBeans開発プロジェクト10年超の蓄積!API設計の経験や考察をまとめた一冊Amazon詳細ページへ

この記事は、書籍『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)と呼びます。

著者
Jaroslav Tulach(ヤロスラフ・ツゥラッハ)
NetBeansの生みの親で、初期のアーキテクト。NetBeansは当初、Java統合開発環境として開発され、現在はJavaScript・Ruby・PHP・C/C++などにも対応。今も、オープンソースプロジェクトで開発が続けられている。著者は、NetBeansを支える技術の生みの親として、このオープンソースプロジェクトの成功に貢献。現在も、プログラマーの設計スキルを向上させる新たな方法を探求しつつ、このプロジェクトに参加している。
著者
柴田 芳樹(しばた よしき)
1959年生まれ。九州工業大学情報工学科で情報工学を学び、1984年同大学大学院で情報工学修士課程を修了。以来、様々なソフトウェア開発に従事。ゼロックス社のパロアルト研究所を含め、5年間米国に駐在してソフトウェア開発に携わる。現在はソフトウェア開発、教育、コンサルテーションなどを業務としている。 本書の翻訳を担当。

連載バックナンバー

Think IT会員サービス無料登録受付中

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスの概要とメリットをチェック

他にもこの記事が読まれています