夢空間への招待状

ドミノ倒しを御存知だろうか。 小さな牌（ドミノ）を平らな床の上に立てて一列に何個も並べておく。 一個倒れたら隣のドミノにぶつかって隣のドミノも倒れ… と連鎖反応的に次々に倒れていくのを見て楽しむ一種のゲームである。

ドミノ倒しの面白さは最後にパタパタと連続してドミノが倒れていくのを見るところにあるわけだが、 その段階に至るまでの準備ははっきりいって緊張ばかりの単純作業である。 何しろ何百個、何千個というドミノを並べていくのである。 誤って途中の一個をコン、と倒してしまったらもうおしまいだ。 倒した先のドミノがあれよあれよと倒れていってしまうからだ。

プログラムの開発はドミノ倒しに似ている。 プログラムは完成したものを使うところに意味がある。 中途半端にできあがったもの、 暴走したりデータを壊したりするプログラムに お金を払ってくれる奇特な人はあまりいない。 しかし、あるプログラムが完成（といえる） 段階にいたるまでの開発作業は緊張また緊張の連続である。 ドミノ倒しでドミノを一個一個並べていくように、 プログラマはプログラムを一行一行書いていく。 全体がこれで完成した、と思っても、 プログラムの中のたった一行のバグのせいで、 システムを壊し、プログラムが暴走するかもしれない。 しかもやっかいなことに、その事件が起こるのがいつであるかも予測できない。 プログラム開発中かもしれないし、 出荷直前かもしれない。 あるいはまたプログラム出荷一年後かもしれないのだ。

プログラムの代わりに、例えばビルディングを考えてみよう。 土台を固めて、鉄筋を組んで、コンクリートを流す。 床や壁を作って内装を整える。 エレベータもできてもうすぐ完成である。 そういう段階に到ってから、ある人がビルの中の一個のネジをドライバーではずしたとしよう。 たったそれだけの行為でビルがガラガラと音を立てて崩れるということがあるだろうか。 もちろんそんなことはない。 ネジをはずしたらドアが一個動かなくなったり、 壁の絵が落っこちてきたり、 蛍光灯のスイッチが効かなくなったりするかもしれないが、 ビルの存続が危うくなることはほとんどないと言えよう。 ビルのような建築物では小さな修正は小さな変化を引き起こすし、 大きな修正（例えばあるフロアに爆弾を仕掛けるとか…）は大きな変化を引き起こすのである。 修正の量と変化の度合の間に大きなギャップはない。

修正の量と変化の度合の関係をプログラムについて考えてみよう。 ソースプログラムの中からデタラメに選んだ一行を削除したとしよう。 運がよければその削除箇所はコンパイル時に発見され、大事には到らない。 しかし運が悪いとその修正は発見されにくいバグとなり、 しかもシステムをクラッシュさせるかもしれない。 例えていえば、ビルのネジを一本はずしただけで三日後にビルが崩壊してしまうようなものである。 誰がそんなところに住むだろう。 誰がそんなビルを買うだろう。

小さな修正が小さな変化を生むとは限らない。 たった一行の修正がプログラム全体の存続にいつも関わっている。 へたをすると、 まるでドミノ倒しのようにプログラムがパタパタと連鎖反応を起こして倒れてしまう。… プログラム作成の怖さはそのあたりにあるのかもしれない。

大掛かりなドミノ倒しをするときには、何十個に一つストッパーを入れるようである。 万一途中のドミノが倒れそうになっても、 その破綻がシステム全体の破綻には結びつかないようにするためである。 プログラムの開発にもそのような「ストッパー」が存在するとよいのだが。

もちろん、現在開発されているプログラミングの道具や手法などは もともとそのストッパーに相当する技術のはずである。 コンパイラを使って不用意な誤りを前もって検出するとか、 プログラムを部品に分けてそれぞれを試験しておくとかいった技術は、 すべてこれプログラムを安定稼働させるためのものである。 しかし、まだ決め手となるアイデアは存在せず、 あちこちに崩壊の恐れを秘めたプログラムが出回ることになる。

プログラムを書きながら、私は考える。 「いま修正しているこの行はドミノを倒すことにならないか、 重要なネジをはずすことにならないか」 小さな修正であっても細心の注意が必要だ。 プログラミングはまだまだ未熟な技術なのである。

リンクはご自由に。フィードバックはお気軽に。
Copyright (C) 1993 by Hiroshi Yuki.
All rights reserved.
hyuki@st.rim.or.jp
http://www.st.rim.or.jp/~hyuki/
http://www.st.rim.or.jp/~hyuki/dream/