XMLデータベース開発方法論（2）　Page 2/4

スケーラビリティの重大な誤解、
“大は小を兼ねない”

川俣 晶
株式会社ピーデー
2005/7/22

■情報の規模が変わると性質は変わるか？

　規模が変わると性質が変わる事例は世の中に多いとしても、われわれがいるこの情報処理の世界でも同じことがいえるのだろうか？

　1つの考え方として、「ない」という解釈があり得るだろう。なぜかといえば、情報には実体がない、つまり重さも体積もないからである。層流や乱流という現象は、重さや体積のあるものが流れるから発生するのであって、重さも体積もない情報ならば同じ結果になるはずがない。情報が増えても減っても、もともとない重さや体積が変化するわけではないのだから、情報の規模が変わったからといって、性質が変化するはずがないという解釈である。

　しかし、この解釈は、筆者の個人的な経験からは肯定できない。なぜなら、情報の規模＝情報量が増えたことによってそれまでうまくいっていた方法論がうまくいかないような事例に何度か直面したことがあるからだ。重さも体積もない情報であっても、やはり規模が変わると性質が変わるのではないかと思う。

　実際に、情報量が変わることで性質が変わっているように見える事例を見てみよう。題材は、プログラムに変数宣言は必要かという、一種の宗教論争である。

　コンピュータのプログラム言語では、数値や文字列などの値を格納するために、変数という機能が使用される。変数には名前を付けて扱うのが一般的である。さて、変数を扱うに当たって、1つの宗教的な対立が存在する。それは、変数の利用に先立って「XXXという名前の変数を使います」という宣言を書き込むことが必要か否かということである。

　変数宣言不要の場合、ソースコード上の好きなところに好きなように変数名を書き込むことができる。そして、ソースコード上に出現した変数は、すべて自動的にそのような変数が存在するとして扱われる。一方、変数宣言を必須とした場合、使用するすべての変数について、それを宣言するためのコードをソースコードに書き込まねばならない。書かないとすべてエラーとなり、ソースコードは受け付けられない。

図6　変数の宣言

　両者を比較すると、前者の方が書くべきコード量が少ないことが分かるだろう。つまり、変数を利用するコードはどちらも必要だが、変数を宣言するコードは、変数宣言不要の場合にはなくてもよいからである。

　ここから分かることは、変数宣言とは、プログラムを実行するために必須の情報ではないということである。そう、書かなくても動くのである。書かなくても動くというのに、理屈を付けて無理やり宣言を書かせようとする態度は言語道断。実際に、変数宣言不要の言語でどんなプログラムも書いてきたが、何の問題もなかった。どうして変数宣言などを高圧的に要求するのか、その理由がまったく分からない……、というのが変数宣言不要派のよくある意見と感じる。

　しかし、このような意見は、筆者の実感とはかけ離れている。なぜかといえば、変数宣言不要の言語で深刻なトラブルを経験しているからだ。例えば、もう25年ぐらい前の話だが、ごく初期のパソコンであるNEC PC-8001に組み込まれていた変数宣言不要のプログラム言語、N-BASICで何度も苦労させられた。これによって記述されたプログラムで、まったく原因が推測できない異常動作があったのだが、一晩かけて地道に異常動作を追いかけた結果、ささいな変数のスペルミスが原因だと分かる、というような経験を何度も繰り返した。

　原因が変数のスペルミスとはどういうことだろうか。例えば、goukeiという変数名を間違えてgokeiと打ってしまっても、変数宣言不要の言語はエラーとしない。単にgoukeiとは別のgokeiという変数があるとして処理するだけである。しかし、見た目が似ているので、リスト全体を目で確認していても、この手のスペルミスは見落としやすい。つまり、一度はまると、なかなか異常動作の原因が分かりにくい問題になるのである。

　では、たかが変数名のスペルミスのために一晩もの時間を浪費したくないとしたら、どのようにすればよいのだろうか。答えは簡単である。変数宣言必須のプログラム言語を使えばよいのである。このような言語では、宣言していない変数はすべてコンパイル時にエラーになるので、スペルミスが即座に分かる。しかも、どこで間違えたかをコンパイラが教えてくれるのである。リストの中から間違いを探す必要すらない。

　問題は、宣言するためのコードを書くための手間が増えることだが、最近の新しいプログラム言語では、変数を初期化する（最初の値を設定する）コードと宣言を一体で書くことができるケースが多いので、さほどの負担増というわけではない。例えばC++、Java、C#などでは、変数「a」に「123」を入れるためには「a=123;」と書くが、これに「整数型の変数aを宣言する」という意図を加えるには、「int a=123;」と書けばよく、追加に要するのは「int（半角空白）」の4文字だけである。行数も増えない。Visual Basicでも、Visual Basic .NETになってから宣言と初期化を1つの構文で行えるようになり、例えば「Dim a As Integer = 123」のように記述することで、同じ意図を表現できる。この程度の負担増で、一晩掛けてソースをにらんでスペルミスを探す苦労を回避できれば安いものである。

　さて、ここからが核心である。この話は、変数宣言必須派が正しく、変数宣言不要派が間違っている、ということを示すために書いたわけではない。実は、両者はどちらも正しい意見を述べているのではないかと思うのである。もちろん、この2つの主義は、絶対に相いれない。特定の宣言を「書け」「書くな」と主張している以上、両者の主張を同時に実践することはできない。それにもかかわらず、なぜどちらも正しいといい得るのだろうか？

　ここから先は、あくまで筆者の個人的な感想であり、別の解釈があり得ることをお断りしておく。

　実は、この2つの主張は、主として想定するソースコードの規模が違うのではないかという感想を持っている。実は、ソースコードが十分に短ければ、変数のスペルミスなどすぐに発見できるのである。すぐに見つかるスペルミスをコンパイラに発見させるためにわざわざ宣言を書くなど、非効率的と考えるのは合理的である。つまり、変数宣言不要派の主張は正しい。しかし、ソースコードの規模が大きくなってくると、たかがスペルミスであろうとも、探し出すのに要する苦労は爆発的に大きくなる。ここで注意すべき点は、苦労はソースコードの量に比例しないことである。例えば、100行のソースコードから1分でスペルミスを発見できる場合に、1000行のソースコードから10分でスペルミスを発見できるのかといえば、そうではない。なぜならソースコードが長くなるにつれ、正しい変数の数も増え、それを把握するために必要な労力も増えるためである。それを踏まえて作業を行えば、おそらく10分よりももっと長い時間を要するだろう。

図7　スペルミスを探す労力 （この図はイメージを示すもので具体的な数値を反映したものではない）

　もちろん、プログラム言語の進歩の中には、このような爆発的な労力の増大を低減する機能が含まれる。例えば、「ソースコードの特定範囲（スコープと称する）で利用できる変数を限定する」といった機能は当然のように取り入れられている。これにより、変数のスペルミスを探す範囲が限定され、労力は軽減される。

図8　プログラム言語の進歩

　しかし、それが成し遂げてくれるのは、労力の増大を低減するだけであって、増大そのものを完全に消し去ることはおそらくできない。そして、拡大し続けるユーザーからの要求にさらされたソースコードは、規模を膨らませ続けねばならない。労力が低減されても、ソースコードの規模が膨らめば、やはり苦労は減らない。このような状況で、変数のスペルミスという問題に対処するには、変数宣言を必須にするというのがリーズナブルな選択となる。つまり、この条件に当てはまる場合は、変数宣言必須派が正しい。

　ここでもう一度確認しておこう。変数宣言がリーズナブルとなるのは、あくまでソースコードの規模が大きい場合であって、ソースコードが十分に短い場合、話は別である。そして、世の中には、短いソースコードで十分に扱えるニーズもあれば、長いソースコードを必要とするニーズもある。つまり、変数宣言必須派も、変数宣言不要派も、いずれも実際に使って有用な主義を掲げた者たちであり、両者の差は適用対象の規模の差にすぎないと筆者は考えるのである。しかし、情報の分野にあっては、規模の差を明確に意識するケースが多くはないために、正しい主義は1つしかあり得ないと思い込み、どちらか片方だけを支持するような態度が見られると感じる。そのような者たちが議論を行っても、おそらくは恨みしか残らないだろう。それは建設的な議論というよりは、宗教論争と呼ぶに値する内容となる。

　余談だが、オブジェクト指向プログラミングの流行も、ソースコードの規模との関連性が強いのではないかと考えている。オブジェクト指向プログラミングは、プログラムの複雑さの増大に対処するために用いられるという意見をしばしば聞くが、人間の手に負えないほど複雑なプログラムとは、つまり規模の大きなプログラムということになる。もし、規模が十分に小さければ、どれほど混乱したソースコードであっても時間をかけて解きほぐせば扱えないことはないからだ。実際、小規模なプログラムを記述するために使われるスクリプト言語の世界では、オブジェクト指向ではない言語も多く見られるが、それらの言語も問題なく実用のツールとして用いられている。このような事例は、ソースコードの規模が変わるとそれが持つ性質が変化し、その性質に適応するための言語の在り方も変わるという状況を反映したものではないかと感じる。（次ページへ続く）

2/4

Index
XMLデータベース開発方法論（2） スケーラビリティの重大な誤解、“大は小を兼ねない”
	Page 1 ・前回のおさらいと今回のテーマ ・自らの最終学歴を語る三重苦 ・化学工学の華はスケールメリット ・層流と乱流、規模（スケール）が変わると性質が変わる例
	Page 2 ・情報の規模が変わると性質は変わるか？
	Page 3 ・情報は人間の思いどおりにならない ・規模から見たRDBとAWKの違い
	Page 4 ・CPUパワーの拡大と中間領域の拡大 ・次回予告

XMLデータベース開発論

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）