■ - 作品メモランダム

【追記】2006/12/18 22:20　慶應MMCメールマガジンへのリンクを修正しました。

ご無沙汰しております。2006年の後半は、春から教えに行っている専門学校で、ゲーム・デザイン（企画方法）に加えてプログラムの概論講義を担当しています。

プログラムなどと言うと、挑戦してみたことがない方には見当がつかない、なにやら難しいことのように思われるかもしれませんが、コツさえ飲み込んでしまえばそんなに大変なものではありません。実際、理解しなければならない基本的な文法事項は、自然言語に比べたらぐっと少なく、ルールを覚えるだけなら時間もそれほどかからないはず（それを高度につかいこなしてエレガントなコードを書くには経験とセンスがかかわってきもしますが）。

また、一つの言語を使いこなせるようになれば、第二のプログラム言語、第三のプログラム言語と、足を伸ばすのは難しいことではありません（これは自然言語にも通じるところですが）。

しかし、実際に学生さんにプログラムを教えてみると、問題はもう少し別のところにあることがわかってきました。プログラムができなくて困っているという学生さんたちの話を聴いていると、どうやら彼らがわからないのは文法ではなくて（それも場合によって理解が追いつかないこともありますが）、むしろ、どうしたらプログラムを書き下せるようになるのか、ということが問題であるらしいのです。

そもそもプログラムをするというのは、どういうことかと言えば、それは「コンピュータを使ってこんなことをさせよう」というアイデアを、コンピュータが理解する命令語に書き換えること、翻訳することです。彼らが「わからない」と言うのは、アイデアをどうしたらうまくプログラム言語で翻訳できるのか、というそこのところなのでした。

はじめこれを耳にしたとき、少し不思議な感じがしました。というのも、自分がはじめてパソコンを手にした1980年代初頭には、市販で流通しているソフトの種類も多くないし、まだたいした性能ではなかったコンピュータ用の市販ゲームも「これなら自分にもできそう」と思わせるほどの（と言うは易しなのですが！）ものでした。だものだからもう、自分でゲームを作りたくて作りたくてしょうがない。

「パソコンにこうさせたいんだけど、どうしたらいいのだ？！」という気持ちが先にたって、その問題を解決するために文法書やプログラム例と首っ引き。あるときは、雑誌に延々と掲載されているリスト（プログラムを印刷したもの）を根気強く入力していく（これと『Wizardry』の魔法入力のおかげでタッチタイプを身につけました）、要するに泥縄式に気がついたらプログラムができるようになっていたのです。

よく知られた例では、『Ultima』シリーズの生みの親、ロード・ブリティッシュことリチャード・ギャリオット氏があります。アメリカにおけるPC用ゲーム創世の歴史をたどった好著『ダンジョンズ＆ドリーマーズ』を読むと、ギャリオット少年がどのようにしてゲームのアイデアを発想し、それをノートに書きとめ、プログラムしていったかが綴られています。

要するに、プログラムを学ぶために学ぶというよりは、「これが作りたい」というのが先にあったわけです。言い換えれば是が非でもプログラムをしたい動機がある。

どうも学生さんの話を聴いていて思ったのは、プログラムが書けないと悩んでいる人の多くは、この動機を持っていないらしいということでした。

同時にもう一つ、これは私が勝手に推測しているだけですが、どうもいろいろなプログラムの教科書に出てくるサンプル・コードを見ても、どうしてそんなふうに書けるのかがわからないのではないか。要するに、結果物だけを見るから、最初からそういうきれいなプログラムが書けないといけないという先入観も生じてしまう。

もちろん、文芸における江藤淳ではないですが、頭の中で文章を完成してから筆をおろすというやり方をするプログラマーもいるかもしれません。が、管見では自分も含めて、プログラムというのは、頭から順番にきれいに書き下していくものではないわけです。むしろ、スケッチをするように、全体をざっと描いてみて、バランスがよければはじめて細部を描きこむ、そんなふうにしてプログラムを書いていきます。

だから、実際にプログラムを書くところを順を追って観察すれば、あっちにいったりこっちにいったりしながら、徐々に全体が完成に近づくというプロセスが見えるにちがいありません。

「こういうアイデアをコンピュータ上で実現したい！」と思ったら、つぎにすべきことは、そのアイデアをコンピュータの処理としてはどんな順序で組み立てたらよいかという処理の流れ（構造）を考えて、それをざっとスケッチし、あらためて細部を書いていく。実際にはプログラマーの頭の中ではこんなふうに事態が進んでいく、というその過程を見せたらどうか。そう思って黒板を使って、プログラミングする私の思考の痕跡を再現して見せたりしています。

そこで、はじめは「こうすればうまくいくだろう」と思って書いたプログラムを、あとになって別の箇所との整合性をとるために書き換えたりするところも丸見えにしてみる。絵画でも映画でも小説でも工業製品でも料理でも理論でも思想でもなんでもそうですが、過程を全部飛ばして完成した姿だけを見るとわけもなく圧倒されることがありますが（そして一度は圧倒されてよいわけですが）、順を追ってどうしてそうなったのかを知ることで、それを真似たり自分でも習得してみるといったことがしやすくなる、ってこれは当然といえば当然のことでした。

文法はわかったのにプログラムが組めない、という問題を解決するために、「動機を持っているか？」というプログラム以前の前提的な事柄と、アイデアと完成したプログラムのあいだをつなぐ思考と記述のプロセスを知る、という別の問題に置き換えてみている次第です。これが果たしてうまくいっているのかどうかはまだわかりませんが、少なくとも自分では（半ば習慣化＝自動化しているために）あまり省みたことがなかったプログラムを書き下すときに脳裏で起きていることを対象化できておもしろいのであります。

かように、ある問題に遭遇したとき、どうしたらよりよく対処ができるかといえば、それはたぶん、その問題を問題にしている条件を見極めることでありましょう。そこを見つめない限り、上記の例で言えばいつまで経っても（あるいは、あるときはっと気がつくまで）、プログラムが書けるようになる気がしない、という気分にとらわれたままで問題は未解決にとどまります。

最近、問題はどうして問題なのかということを考えた『問題がモンダイなのだ』（ちくまプリマー新書50、筑摩書房、2006/12、ISBN:4480687521）という本を相棒・吉川浩満（id:clinamen）とともに書きました。書店でご覧いただけたら幸いです。