やや不適切な例だが、「将来システム開発の言語はＣ＋＋になると思いますか、 イエスかノーで答えてください」のような質問を考えてみる。もっとも、これは 極端すぎる例で、アンケートのように特別な場合を除けば「イエスかノーで答え てください」のように回答方法を指定する質問は、最近は希だ。質問者の意図が あからさますぎて嫌われるのだろう。戦略上も、このようなアンケートなら もう少し瞹昧に質問しておくものである。
雑多な解釈を二分するという発想は、物事を簡単に考えるためには効果的だ。 従って、二分す る種類の質問が必ずしも有害とは限らない。むしろ問題は、二分されたデータの 解釈である。「どっちかというとＣ＋＋が増えるんじゃないか」程度に考えてい る人が、うっかりイエスと答えた後で、「あなたは今後Ｃ＋＋がＣに取って代わ ると主張していますが、…」と一方的に決めつけて発言したかのように解釈され るのが困るのである（実はもっと困るのは、これで引っ込みが付かなくなって相 手のペースに乗ってしまう回答者なのだが）。質問の内容によっては「ケースバ イケースですよ」とか「どっちとも言えないなあ」という回答があるはずだが、 意図的にこのような可能性が排除されてしまうのだ。瞹昧に解釈すべき事柄を強 引に一方的に決めつけるのである。
ネットで実際に発言を読んでみると、 「これは二分法ですね」と強引に解釈したり、 「この論法は典型的なレッテル貼りですね」とレッテルを貼る人がいて面白い。
*
「プログラムは芸術作品か工業製品か」というテーマがある。NIFTY-Serveのプ
ログラマーズフォーラムでは、フォーラム設立当時から延々と議論されているが、
なかなか決着が付かない。私もこの議論には時々参加する。私のプログラマーと
しての主張は「プログラマーは芸術的でなければならない」という強い妄想に支
えられている。従って、まず明らかに芸術性を無視することは許されない。ただ
し、この質問にはあえてイエス・ノーで答えることを避け、「プログラムは工芸
製品である」と真ん中を取ることにしている。回答だけ見るとほとんど頓智のよ
うなものだが、割と本質的な所をうまく表現したと思っている。すなわち、工芸
製品とは一体何だろうか。つまり、プログラムは芸術作品としての性質も持って
いるし工業製品としての性質も持っている、と言っているのだ。どっちか片方し
か許さないという発想がそもそもおかしい。
スーパージャンプ連載中の「緋が走る」というマンガは、現在最も気になる作 品だ。このマンガは陶芸家を描いた作品であり、タイトルの「緋」というのが何 かはマンガを読めばわかるが、早い話がプログラミングとは何の関係もないのだ。 しかし、もしあなたがプロフェッショナルのプログラマーであろうと考えている なら、この作品に多少は興味を持つに違いない。
師匠が主人公の美咲に陶芸の心得を伝授するシーンで、次のようなセリフが出 てくる。
「人はいつしか“用”の中に“美”を求めるようになったこれは、ソフトウェアにもそのままそっくり当てはまると思うのだ、ただ、現 在流通しているソフトウェアのうち一体何本にソフトウェアなりの美が極められ ているか考える時、落胆に似た感情を抱かざるを得ないのも事実である。
“美”は人間にしか持ちえない崇高なる意識だ
“用”と“美”―― これが一体となって初めて焼物は芸術と呼ばれる」
同じシーンで、焼物に芸術を追い求めるのもよいが、それは２割にしておけと 師匠は言う。残りの８は作家ではなく職人に徹する。なぜかというと、芸術に走 ると食えないというのである。
実は私は作曲が趣味なので、これが何となくわかる（プログラマーの中に音楽 好きの人が多いのはソフトウェアの芸術性に関連した結果であって決して偶然で はないと思う）。出来た曲は、NIFTY-ServeのFMIDIORGという、文字通りオリジナ ル曲のMIDIデータを扱うフォーラムで公開している。今年になって「歌姫」とい う連作の曲を作った。今でもFMIDIORGにあるはずだ。コピーフリーの扱いにして あるので、興味のある人でMIDI音源を持っていない人は誰かにダビングしてもら ってください。これは篠崎砂美氏の書いた同名のファンタジー小説を読んでいた く気に入り、イメージを曲にしたものだ（決してイラストにつられたわけではな い…と思う）。
さて、この曲が全然人気がないのだ。自分では自信作だと思い上がっているの だが、まるで受けない。その理由もなぜか意外とよく分かる（※下手な曲だから だという声あり）。100%自分の趣味に走っているからだ。要するに自己満足なの である。私はアマチュアだからこれでいいのだ。他人が満足する曲を書く必要は ないのである。しかしプロの作曲家だとこれでは駄目だろう。食えないと困るか らである。だから陶芸家の心得としては作家２、職人８で作れという台詞になる。 安易に同列として比較するのもどうかと言われそうだが、プログラミングの芸術 性を主張する私としては、作家２、職人８という割合がプログラマーの場合にも かなり当てはまると思う。
*
陶芸はハードウェアだから、ソフトウェア100%のプログラミング作業とは、い
ろいろ違うこともある。最も大きな違いは、陶芸は一発勝負という点だ。気に入
らないと、作品は叩き壊してもう一度最初から作らなければならない。ソフトウ
ェアは部分修正が容易である、という建て前がある。
しかし、プログラムを作り慣れた人は、これが建て前に過ぎないことを知って いる。ソフトウェアは確かに小さなパーツの寄せ集めだが、部分が全体に影響す るという性質も持っている。全く独立した別のアプリケーションでさえ相性の問 題で動かないことがある程だ。結局、経験的に、部分修正は決して容易でなく、 むしろ安易な部分修正が一見無関係な他の処理の支障となることを危惧すべきだ。 もちろん多くのプログラマーが多くの工夫を続けてきた。モジュール化によって 独立性を高めるというのも一つのアイデアである。確かにこの工夫はある程度成 功する。ところが、完璧に独立した処理というのが難しい。なぜなら、所詮一つ のソフトウェアは一つのハードウェアの資源を使い回して動作しているからだ。 あるモジュールを修正した結果、処理時間が多少長くなり、他の処理が動作しな くなることがある。プログラミング上は、これらのモジュールは全く無関係で独 立している。制約は、それぞれのモジュールが使うことを許された時間配分とい う、プログラムに見えない所に現われるのだ。
このような特殊な場合があるにしても、できる所から独立性を高めて、処理が なるべく独立して変更できるように工夫するのは無駄ではない。Ｃ言語で簡単な のは変数のスコープを利用した独立性の確保である。
/* List */
/* スコープの説明のためのリストであり、厳密な意味ではC言語ではない */
int 全ファイルから参照可能な変数;
static int このファイル内で参照可能な変数;
void foo(void)
{
int この関数内で参照可能な変数;
if (..) {
int このブロック内で参照可能な変数;
}
}
さて、このようなことは誰でも知っている。問題はむしろ、各変数をどのよう なスコープに割り当てるべきかという指針だ。つまり「こう分けられる」ではな く「どう分けるべきだ」ということが肝心である。本を読めば大雑把な指針は書 いてあるかもしれない。しかし最も重要なのは、やはり各人の経験である。変な 分け方をして失敗したなら次回に繰り返さない。このようにして最適なブロック 化を身に付けるのである。何が失敗で何がよくできたかの判断が重要だ。これは 感性半分、理性半分の問題である。少なくとも、ぱっと見ただけで「こりゃ問題 外だ」と感じなければならないようなケースはある。
参考文献 「緋が走る」ジョー指月原作、あおきてつお漫画 スーパージャップ連載中、単行本スーパージャンプコミックス１〜２巻(C) 1993, 1996 Phinloda, All rights reserved