スケールしないシステム, スケールする教育

2005-11-01

近況

久しぶりに会った大学での指導教官の教授はウェブ・プログラマになっていた. 書架には Struts や JSF の本が並び, Eclipse はいいねえという. Emacs キーバインドが使えるからだって... ゼミの輪読では Eclipse の本を読み, プラグイン・アーキテクチャに感銘を受け自分の作るウェブアプリもフレームワークにしようと目論むも難しい, などと言う. そりゃそうだけれど, ところでここは離散数学とアルゴリズムの研究室だったように記憶しているのですが.

教授のつくるアプリケーションではドメイン・ロジックを XML で記述し, JSF と Java のコードを出力する. そのトランスレータも自分で作ったらしい. なんとまあ. 一応現役のプログラマ(であるはず)の私が有閑(であるはずの)大学教授にテクノロジの話題で遅れをとるとは. 学生の頃はいつもこうだったものの, それはもっぱら専門分野の話であった. 悔しい. 苦し紛れに三桁の振替休日ストックをもつ同僚の話をもちだし職業プログラマの苦難を訴えるも, 私も前期は週休一日で大学に泊まったりもしたよ, 明日の授業までに作らないと, てね. そう棚の上の寝袋を指差しあしらわれた. JSF, Eclipse, DSL, おまけにデスマーチまで...久々に味わうその強い敗北感を噛み締める.

スケールしないシステム, スケールする教育

教授が作っていたのはウェブでのオンライン教材だった. e-learning のようなもの. C 言語の演習について一部を肩がわりするものらしい. よくある 4 択や, あるコードを実行した後の変数値の推測などの問題を授業の進行に沿って提供する. またそれだけではなく, 内蔵する C 言語サブセットのインタプリタによってテキストフィールドで与えられたフラグメントを評価/実行したり, 例題のプログラムをステップ実行して見せたりという機能もつくったと自慢していた.

動機は実習を強化する方針の新カリキュラムにあるらしい. プログラムを組めないまま卒業していく学生があまりに多いため実習を強化したが, ただ既存の課題をプログラムを書かせるだけの実習ではコピーとペーストが蔓延する. また初学者にとって, エディタとコンパイラだけを頼りにコードを書くのは意欲があっても敷居が高く挫けやすい. そこで従来の実習に加えてウェブで(コードを書くよりはとっかかりやすい)プログラミングの問題を解かせることにしたのだという. 私の在学中よりはだいぶ (倍以上) 実習の時間が増えていた. そうした状況で教師側の負担増を抑えるためにオンライン教材での支援を狙っているそうだ. ふーん. 野心的だなあと感心する.

ひろくウェブで公開されているアプリケーションと違い, 大学の教材としてのアプリケーションは利用者数の面でスケールする必要はない. 学生数の上限は決まっているからだ. 教授はこのアプリケーションを他の講義でも使えるようにするという野望を持っており, コンテンツ数でのスケールはしたそうだった. けれどもフレームワークの成熟度や伝えきく他の教官の意欲から窺うにそっち方面のスケールもしばらく心配はなさそう. やや気の毒ではあるが, そもそもこのアプリケーションが典型的な Situated Software であり, それをスケールする難しさは作った当人がもっともよく自覚しているようだった.

しかし一方で, このアプリケーションには問題領域特有の危急かつ不可避なスケール上の目標がある. しかもそれがもっとも克服困難な課題であることが話していてわかった.

それは学力に関するスケールの目標, 端的に言えば, "アホな学生にもわからせる" ことだ. (教授はそういう直接的な言い方はしませんでしたが.) 学力や意欲の高い学生は課題を用意すれば(場合によってはそれさえしなくても)勝手に勉強して理解を進める. しかし(中心的な顧客であるはずの)学力や意欲の低い学生は, いかにさぼって単位をとるかに注力するばかりで問題の理解には消極的だ. 彼らは計算機科学の分野で脳みそを駆動するコストが極めて高いため, 比較的得意である人的資源の活用やパターン照合, 分岐網羅に類するアプローチでウェブ・アプリケーションの用意する課題をこなしてしまう. そのイタチごっこをどううまく回避するか, いかにウェブ・アプリケーション(で支援された講義や実習)を通じて C 言語やプログラミングをわからせるか. イタチを追い払うのではなく, イタチを抱擁する. それが難しいのだということだった.

とはいえ実習の強化とこのアプリケーションの導入によって, 講義やペーパー・テストの時代と比べれば改善された感触はあるという. 贔屓目があるとは言え, それだけ労力を割けば何かしら効果はあるに違いない.

私のいた大学は割と二流の私大で, 少子化による学力低下の影響をもろに受ける. 低学力な学生を鍛えるのは学級崩壊のような事態をおこさないための準備なのだからとても重要なのだという. たしかに. 母校への思い入れも少ない私には他人事だけれど, 当事者にとっては雇用もからむ切実な問題だ. しかしアホ学生の扱いというのは多くの大学がおそらく数十年もの間なにもできなかった(しなかった)問題なわけだから, 解決はなかなか難しいだろう. 定員は変わらず正規分布の母数が少なくなるから学力が下がるのは当り前なんだけれど, 誰も危機感ないんだよねえと教授は笑い, 理工系の人は応用が苦手なのかもしれませんねえと私は相槌をうつ. 大学の先生も思ったより大変な仕事だなあとやや同情し, デスマーチを避けるためにはアプリケーションの自動テストを用意した方がいいですよ. 忙しくてもね. そんな話をして別れた.

スケールの係数

何か違和感があり, 家に帰ってからはその違和感について考えていた. 学力についてスケールするというけれど, 何かがスケールするには入力として資源が必要だ. 教授が見込んでいる資源はもっぱら彼自身の時間と計算機の能力であるように見えた. しかし個人の時間はすぐに尽きる. だから当面のスケール元は計算資源ということになる. (4-CPU の Sun Fire を買ったと言っていたし...そんな予算があるとは...)

対象学力をスケールするために計算機資源を使うというのはわかりにくいが, 彼の思惑はアプリケーションをインテリジェントにすることで計算機資源を有効活用しようというものだった. たとえば課題のプログラムをチェックする検証エンジンを書き, 誤りを指摘したり助言をだしたりする. 速い計算機を買えば検証エンジンは多少重くてもいい.

確かにそのアプローチは可能かもしれない. しかしなんとなくうまくいかない気がする. それは Semantic Web の危うさに似ている. SW もシステムのインテリジェンスと計算機資源に大きく依存している. これらが上手くいかないと感じるのは, おそらくそれが複雑すぎるからだろう. 複雑なシステムはスケールしない.

複雑さは CPU bound であることもあるが, 多くの場合は人間の脳で bound する. 要するにアルゴリズムはあるけれど時間がかかりすぎて問題が解けないことより, そもそもアルゴリズムを思いつけないことが多い. ソフトウェアのインテリジェンスでアホな学生を鍛えようとしたら CPU より前に人間の脳が bound するだろう. Brooks を引くまでもなく, 人を増やしても複雑さは解決しない. インテリジェンスは個人の能力で bound する極めてスケーラビリティの低い要素だ. 従ってそれに依存するシステムはスケールしにくい. 他の資源でスケールする必要がある.

おそらく人的資源に頼るのが一番ベタで確実な方法だろう. たとえば計算機室の見張りと称してウェブをみているTAをもっとこき使う方策を考える, 退屈な会議の内職を, 外部のアルバイトやボランティアを, 資源として使えるようなシステムを考えてみる. 質問に答える, 答案にコメントする, さぼりを指摘する. 褒める. 無駄話や愚痴の相手になる. 他者によるそうした継続的なフィードバックとコミュニケーションが低学力層のフォローアップに寄与するとしたら(赤ペン先生とか家庭教師とかってそういうもんだしね.) 現状はその不足が問題だと考えることもできる. つまり学力のスケールは人的資源で bound していると言える. 流通の不備でだぶついている資源(TA, ポスドク無職, ひきこもり OB など)をそこに用いることができたら, それはまさに情報化と言えるだろう. 実習ワークフロー・ソーシャル・ネットワーク・ロジスティクス(・わけわからん) !

しかし書いているうちに SW と同じくらい無茶な話に思えてきた. 大学の先生は大変だよねほんとに...