趣味プログラマーの憂鬱と楽観(4): 悪書、悪問、くり返し

このシリーズで書きたかったのは、声なき声というのか、プログラミングにチャレンジしてみたはいいけど上手くいかない、失望や期待はずれの連続で、それでもそんな思いをしてるのは一人じゃないぞ、ということを自分以外の自分のような誰かに届けられたらいいなとか、あるいは教える立場にある人が、それまで自分が想像していたのとはまた別の、教える先にいる人を発見する機会になればいいなとか、そういう目的があって書いてきたのだけど。

果たしてその役割を果たしているだろうか？それとも、今後そういう役割を果たしうるだろうか？
まあ、今すぐにはそんなこと、わからなくたってよいのだけれど。

悪書とは何か

以前に菊地成孔さんのジャズ講義（というか音楽理論の初歩の初歩の授業）を受けていたとき、何々という本はほんとに悪書だよ！（笑）と、それは必ずしもおとしめる意味ではなく、なかば愛憎入り交じったような、というか愛情を土台にしながら、という感じで幾度となく言っていたのだけど、それを聞きながらぼくは「悪書」という言葉の耽美なる魅力というのか、一度で良いから言ってみたい日本語、みたいにしてそれを思い描いていた。

しかしながら音楽理論の勉強や自分の本業においてはあまりそういう機会には恵まれず、さらにしかし、プログラミング入門という趣味の機会においてようやくそういう存在に遭遇できたとは言える。

といってもだからといって、ぼくが悪書だと感じた対象をここで取り上げていくということはなくて、なぜならそんなことをしても誰もトクしないというか、あるいは僕にとって「こりゃヒドイ」と思ったものが他の誰かにとっては「サイコー」ということもあるかもしれず、そんな機会を奪いたくもなければそんなことで1ミリの責任もとりたくはないから、そういう話はしない。

ではどんな話なのかというと、悪書の定義のようなことについてサラッと触れてみたい。

サラッと触れてみたい、というのは単にサラッとしか触れようがない、ということでもあって、悪書とは何か、といえば、

それ以前のページで触れていない概念や語句を、何の説明もなく使用し、その後も説明しない本

のことである。

これで終わり。

じつにシンプルな定義だが、これをやってしまう入門書のいかに多いことか。
しかし慌てて付け加えるなら、そういう本を作ってしまう誰かが愚かである、という話ではなくて、むしろそれは誤植（文字の間違いというか）を避けられる本が原理的にないのと同じぐらい、人間が作る以上は避けがたい問題でもある。

たとえば、この「たとえば」という言葉について僕がここで説明する必要があるのか、ないのか。
たとえば、上でぼくは「誤植」について「文字の間違いというか」と注釈を付けたが、それが本当に必要なのかどうか。
誰を読者として想定するのか、ということに応じてこの判断の結果は変わるし、誰が判断するのか、ということに応じてもまた変わってきてしまう。

これはぼくが仕事でやってる一般的な（でもないけどとりあえずプログラミング関連ではない）書籍編集においても似たことはあって、ルビをどの漢字に振るのか、なんてのは毎回かなりきつい選択になる。

このようなときには最初に「対象読者」というのを大体決めておいて、さらには本の冒頭などに「対象読者はこのぐらいのレベルですので」なんて書いておくことで、それを言い訳にして「この語句なら注釈不要」「これはなんか言っとかないとまずい」みたいな判断をしやすくなるわけだが、ようはこの基準がグダグダ、というかほとんど考慮や精査が成されていないと考えられるものがプログラミング入門書における悪書であると言える。

悪問とは何か

悪書に似た存在として「悪問」がある。
悪問とはここで言う意味においては、「マズイ練習問題」のことである。

よくプログラミングの入門書には練習問題が各章の末尾などに置かれていて、ぼくが手伝っているPerl入学式でもTV番組中のCMのように定期的に登場するけれど、これにもまた良問と悪問がある。

では悪問ではない良問とは何か、ということをまず言ってみると、それはそれまでの授業・講義において触れた要素だけを使った問題のことであり、その問題で初めて出てくる要素を使わない問題である。

これを逆転したものが悪問であって、悪問とはそれまでの講義に出てきていない内容を問題中に出してしまう。
たとえば、「この問題を解くためには何々関数が必要です。何々関数の使い方はこうこうです」みたいなことが問題文の最後にしれっと付いてたりする。

講義中に出てきた情報だけでは答えが出せず、そこに新たな知見を加えなければ回答できないような、それを悪問と僕は呼ぶ。

これがいわゆる応用問題とか、演習問題とか言われるものならばまだ良いとは思うが（あるいは何かの試験とか）、ここでいうのは「入門者向けの練習問題」であって、それはそういうものではない。
そこでは「講義は講義、練習問題は練習問題」でなければいけない。

問題文の中に新たな情報が入ってきたら、それはもう練習問題ではなく講義の一形態になってしまう。
くり返すが、「講義は講義、練習問題は練習問題」でなければいけない。

伝統芸能の世界では口伝（くでん）というものがあって、師匠と弟子が間近で向き合い、師匠が1フレーズ何かを言って、弟子がそれをそのまま真似する。
それが終わると師匠は次の1フレーズを言って、弟子はまたそれを真似する。そしてそれが延々と続く。

練習問題とはその口伝のようでなければいけない。
講義中、生徒には講師がやっていることを真似している時間はない。なぜなら講師の話を聞き、やっていることを真剣に見なければならないからで、同時にその他のことを並行してできる人もいるだろうが、入門者にそこまで求めるのは間違っている。
何かをゼロから身につけさせるのだから、元々は何もできない誰にでも、それを出来るようにする前提でなければならない。

講師が何かを教えて、ひと区切り付いたら、「では自分で同じことをやってみましょう」というのが練習問題であり、それまでただ「見ていただけ」のことを「今度は自分でやってみる」というのは、周りから見たら何も進展していないように見えるかもしれないが、本人にとってはかけがえのない第一歩であるに違いない。
そのような時に、その場でまた新たな情報を与えてしまったら、さっきまで聞いていたことをただ初めてくり返す、というその貴重な機会を奪ってしまう。

だから練習問題で講義になかった情報を付け加えてはいけない。

頭ではなく体に教える

ただ真似するだけ、というのは機械になる、みたいなことに近い。初めはわけもわからないまま言われたとおりに体を動かし、やがて何も考えなくてもその通りに寸分の狂いもなく動けるようになる、というのが入門者のそもそも習得すべきことであるとぼくは考える。

というか、考える、というのはある程度土台ができていなければ実行できないオプションなのであって、まずはまともに体が動くようになるまでひたすら真似させる、慣れさせる、ということが肝要なのである。

まともに体が動くようになる、というのはまあ、たとえとして言ってるわけですが、少し具体的に言うなら、とりあえず講義を聞いて、そこで講師がやったとおりのことを生徒が幾分のずれもなくなぞれるようになる、というのがそれであり、そうなったらその上でようやく、「ところでこういう道具を使うともっとラクになるよ」みたいな話ができるのであって、そんな便利情報を入門の段階にある人間に次から次へと渡したところで、理解するどころか本来得るべき基礎がその中のどれであるかという優先度をわからなくさせるだけである。

だから、まずは単純なことをくり返させなければいけない。教える側からすれば退屈かもしれないし、そのことを想像することすら困難ではあるかもしれないが、入門者にとってはそのただ真似するだけという体験が実は大冒険であったりもする。もしもそれを退屈だと思う生徒がいるなら、そういう生徒を集めた別の場所を作るか（それはもはや入門者向けではないが）、その講義なり本なりを入門者向けではないものとして初めから設定し、そのようなものとして周知しなければならない。

僕はこのシリーズで、趣味プログラミングは効率が悪い、と幾度か書いたけれど、それはこの「単純なくり返し」の実現が非常に難しい、ということの言い換えでもあると思う。
くり返しによる効果というものは、短期間にやれば1,2,4,8,16,32..のように加速度的に増えていくけれど、1回ごとの間をあけてしまえば毎回ゼロからのスタートになって1,1,1,1..みたいな感じになる。

これをどう乗り越えるか、というのが結局のところ、入門者にとっての最初の大きな難関なのであり、逆に言えばその点さえ意識できれば、いろいろだいぶラクになるんじゃないかとも思う。