プログラムと美しさ：序章　―動けばいいのか？―

　コンピュータは優れた計算能力を持っているが、言われなければ何もしない。コンピュータを動かすための命令を記述したものをプログラムという。それを組む作業がプログラミング、組む人がプログラマである。Windows や Excel、iPhone アプリといったソフトウェアは、どれもプログラムでできている。

　プログラマは、人間とコンピュータの橋渡しとなるプログラミング言語を使って命令を記述する。世の中にはいくつものプログラミング言語があるが、簡単な英単語で構成されるのが一般的である。記述された命令から成るテキストは「ソースコード」、あるいは単に「コード」と呼ばれる。ソースコードはコンピュータが理解できる言葉に翻訳され、実行に移される。翻訳を行うのはコンパイラやインタープリタと呼ばれる特殊なプログラムである。

　プログラムには、「こう動きなさい」「次にこうしなさい」「こういうときはこうしなさい」といったことが綿々と綴られている。「そうなったとき」のケースをあらかじめ洗い出し、どうするかを決めて書いておくのである。

　プログラムを渡されたコンピュータは、盲目的な従順さでそれを実行に移す。余計な気を利かせることは一切ない。「雨天中止」とそこに書いていなければ、嵐でも運動会は決行される。想定外の動きをしたら、それは不具合である。あるいは単に想定漏れという。「どうするか」には、ユーザーに判断を求めたり、データベースから過去の成功事例を参照することも含まれる。学習・推論を行うプログラムも今では一般的だが、究極的な仕組みは変わらない。結果は状況に応じた非決定的なものであっても、それを導き出すロジック自体は、あらかじめ与えられたとおりの決定的なものである。

　硬い。融通が利かない。面白みがない。

　コンピュータやプログラムがそうであるならば、それを相手にするプログラマも思考に柔軟性を欠く人が多いのではないか。感情よりも論理を優先する傾向が強そうだ。プログラミングの現場というのはきっと、数値化できるメリットのないものは容赦なく無駄と切り捨てる、ゴリゴリの実利至上主義社会なのだろう。

　そう推測する方も少なからずおられると思う。

　しかしそのプログラミングの現場で、しばしば「美しい」という言葉が違和感なく発せられ、最上級の褒め言葉として歓迎されるのはどういうわけだろう。

　美的要素など邪魔にしかならないのではないか。

　念のために添えておくと、ここで取り上げる「美しい」は、ソフトウェアを動かしたときに表示される画面の美しさのことではない。プログラムの美しさと画面の美しさに直接の関連性はないと言ってよい。見た目は美しいけれど中身はぐちゃぐちゃ、というケースは決して珍しくない。

　プログラムとは、第一義的にはコンピュータに指示を与えるものである。そして、指示を受けるコンピュータは美しさを解さない。どんなに汚いプログラムだろうと、命令が正確に記述されてさえいれば正しく動作する。だが、プログラムには別の側面もある。

　プログラムを読むのはコンピュータだけではない。人間も読むのだ。人間とは他人であり、ときに未来の自分である。作成中にも読み返すし、リリース後も調査の必要があれば読む。不具合があれば修正するし、機能追加があれば再利用が検討される。書かれたプログラムは、人間によって繰り返し見られ、変更され、利用される運命にある。

　ここに美しさの意義が生まれてくる。

　実際、プログラミングにおいて美しさは、邪魔などころか価値がある。それどころか重要である。品質を確保するには不可欠でさえある、とされている。

　プログラムにとって美とは、少なくとも縁遠い存在ではないのである。もちろんプログラミングは芸術ではない。技術である。その「美」は絵画や音楽における「美」とは性質も基準も異なるものだろう。しかし「アート」の語源は技術であるというから、その語源に却って技術に宿る美しさに目を向けてみるのも、あながち無駄とは言えまい。

　人間的行為の代表格である美術とは一見対極にあるコンピュータ・プログラムの世界。そんなところにも「美」が存在し、広く価値を認められている。美術について門外漢の私が美について語るのはおこがましいことではあるが、その点はご寛容をいただき、あまり表に出ることのないプログラムの世界を、ちょっと覗いてみるつもりで気軽に楽しんでもらえれば幸いである。なお、読み進めるにあたってプログラムの知識は必要ない。例として挙げるのは普通の日本語である。

序章
第一章　その美の特徴
第二章　見た目と冗長性
第三章　ロジック
第四章　命名
第五章　アーキテクチャ
第六章　リファクタリング
第七章　デザインパターン
第八章　正規化
終章