そんなこともあろうかと……



 コンピュータのプログラム(program)とは、文字通り「事前に書いたもの」という古典ギリシア語に由来する言葉。


 その仕組みを、いま必要な範囲で簡単に言えば、コンピュータに対する命令を、予め仕組んでおいたもの。例えば、Wordなどの文書作成プログラムで、文書を作り、メニューから「印刷」を選ぶと、プリンターから印刷されます。これは、Wordをこしらえたプログラマーが、「もし、ユーザーさんが、「印刷」という命令を選んだら、いま画面に表示されている文書を印刷せよ」と、コンピュータに、予め命令してあるため実現されているわけです。


 もう少し言えば、皆さんが或るソフトを使って何かをするとき、そのソフトをこしらえた人は、皆さんが何かをするよりもずっと前に、そのソフトをプログラムしたという次第。つまり、事前にコンピュータに対する命令を書いておいた、pro-gramしておいたわけです。翻って言えば、事前に書かれていない命令は、どうしたって実行するわけにはいかないのです。


 何を言いたいかというと、プログラムというものは、「そんなこともあろうかと……」という想定の塊だということです。なんだか話が飛んだように見えるかもしれませんが、このことについて少しお話ししてみたいと思います。


 先ほどの例に戻ってみましょう。Wordでユーザーが「印刷」を命令したとします。このとき、パソコンにつながっているプリンターの電源が入っていなかったらどうでしょう。命令は受けとったけれど、印刷はできません。もしここで、プログラマがこの事態を想定していないと、Wordは存在しないプリンターに向かって「印刷せよ」という命令を虚しく送ることになります。もちろん、待てど暮らせど印刷は始まりません。


 そこで、「そんなこともあろうかと」の出番です。プログラマーは、そういう場合に具えて、「もしスイッチが入って使える状態のプリンターが認識できない場合は、ユーザーに「プリンターがつながってませんぜ。それとも電源入ってますか?」と確認せよ」と事前に命令を書いておくのです。こうしておけば、先のような場合、画面に説明が出て、ユーザーは、「あ、いけね。プリンターのスイッチ入れてなかったや」と気づくわけです。


 これは分かりやすい例ですが、他にも実に細かなことについて、プログラマーは事前にいろいろな事態を想定して、先回りの手を打っておきます。ですから、よくできたソフトは、「そんなこともあろうかと……」の塊なのです。2010年6月に地球に帰還した探査機はやぶさのことを連想してみてもよいかもしれません。はやぶさは、トラブルに次ぐトラブルに見舞われましたが、設計者が事前に「こんなこともあろうかと……」と準備しておいた対策が功を奏して、はやぶさは無事地球まで還ってくることができたのでした(その経緯を、「宇宙戦艦ヤマト」を使ってうまく解説した動画もありましたね)。


 ですから、ソフトウェアをつくる場合、「どんなトラブルが生じうるか」ということを、事態が起こる前に想定する想像力プログラマーに求められる能力の一つになります(実際には、プログラマーだけでなく、どんなソフトをどのようにつくりあげるかということを設計する仕様設計者が別にいる場合もありますが、ここでは簡略化しておきます)。ですから、逆に考えると分かるように、事前の想定が甘いプログラマーがこしらえたソフトウェアは、穴だらけで、思ってもみなかったようなトラブルがどんどん生じたりします。


 ここでもう一つ考えなければならないことがあります。先ほど、プログラムというものは、コンピュータに対する命令だと言いましたが、これは多くの場合、英語を基にした言葉、プログラム言語という人工言語で書くものです。つくろうとしているソフトが複雑であればあるほど、当然のことながらプログラムは大規模になってゆきます。つまり、命令の数が増えていきます。プログラムは、ちょうど英語の文書のように、1行ずつ改行しながら書かれるので、遠くから見ると、詩のように見えるかもしれません。


 さて、ここで問題が生じます。プログラムがあまりに大きくなると(「長くなる」とも言います)、つまり行数が増えると、つくっている本人にも完全には把握できなくなってしまうのです。落語風に言うなら、そこが人間てェやつの浅はかなところ。要するに、記憶が追いつかないのです。


 自分で書いておきながら、厖大になるにつれて、記憶が曖昧になっていきます。いえ、かつて書いたプログラムを見直せば、その部分については思い出せるのですが、いま取り組んでいる場所に意識を集中させているときは、さしあたって用事がない部分のことを忘れていたりします。


 また、たくさんの命令を書き、たくさんの「こんなこともあろうかと……」という想定をしてゆきますので、どうかするとあっちで書いた命令と、こっちで書いた命令とが衝突したり、矛盾するなんてこともあるのです。例えば、1万行のプログラムがあるとして、1行目に書いたことと、1万行目に書いたこととが齟齬を来したりするわけです。プログラマーは、自分がこしらえているものであるにもかかわらず、そのプログラムで何が生じるかということを全部すっかり把握しているというわけではありません。


 これは喩えて言えば、「チェス」を考え出した人(という単一の人物が仮にいるとして、その人)が、ルールを考えたからといって、そのルールから生じるあらゆる盤面を把握しているわけではないのと似ています。なにしろ、最初の10手くらいで、既に天文学的な組み合わせがあると言います。


 というわけで、プログラムというものは、面白くもなかなか厄介です。そこでプログラマーに必要なもう一つの素養は、自分が間違っている可能性をいつも念頭に置ける、ということです。自分がここまでつくってきたプログラムは、どこかにミスがあるんじゃなかろうか、いまはうまく働いているように見えるけれど、なにかそこに問題があるんじゃなかろうか、と絶えず懐疑できるということです。ちょっと気取って言うなら、かのモンテーニュが言うところのQue sais-je? (私は何を知っているだろうか?)というあれです。


 自分の記憶では把握しきれないほどのコンピュータに対する命令、そうした命令の組み合わせから把握しきれないほどいろいろな状態が生じること、そして、自分も間違っている可能性があること、自分は何をどこまで把握しているか/していないかを常に疑うこと。こうしたことをも想定しながら、プログラム、つまり、事前にコンピュータに対する命令を書くのですから、なかなかどうして大変なことです。



 しかし、プログラムの面白いところは、つくりながらも自分のミスや想定しきれていなかったことを、随時「発見」しつつ、より頑強な、より確実で安定した動作を保証するためのソフトウェアを組み上げてゆくことでもあります。開発を通じて、多様なミスを経験している人ほど、先に述べた自分の可謬性に対して謙虚にもなり、事前の想定も厳しくなります。そういうふうに振り返ってみると、プログラミングとは、どこか自己鍛錬の修行のようなもの、自分に気づくための鏡のようなものでもあるようです。


 先日のエントリーでも少し述べましたが、こうしたコンピュータのプログラムの持っている仕組みを基にして、いろいろな物事をアナロジカルに捉えてみたいと思っているところです。今回は明示的に書きませんでしたが、そこには潜在/顕在ということも深く関わっています。これについてはまた今度。