教授からメールが来た。月曜日のゼミ、内容が乏しくて考えが足りないのだそうだ。

ただそれだけの内容で、別に責められているわけでもなければ非難されているわけでもない。にもかかわらず、こんなにヘコむのはなぜだろう。僕は自分のことを、他人がどうこう言うからということに影響されない人間だと思っていたのだが。まさかこんなくだらないことで、こんなにショックを受けるとは。教授はある意味で僕を見放していて、そういう指摘をしてこないと油断していたのもあったが、警戒していなかったからと言って、ただこれだけのことでショックを受けるという自分の弱さに愕然とさせられる。

確かに僕は、目上の人間を恐れすぎるところがある。尊敬する人に対して礼儀を尽くしたりある程度慎重になるのはいいと思うのだが、どうもそれが過度になりすぎている。僕の今のテーマは船長をモデル化すること。実際はそんなのは無理だ。船長に限らず、人間を何らかのモデルで表せるのであればそれだけでノーベル賞ものだ。幾多の学者が、それが分からずに生涯を終えているのだ。

というわけで、重要な部分、必要な部分も含めてそぎ落とすことになる。たとえば、コンピュータで表現する場合は、人間の感情的な部分はすべて欠落することになる。プログラムを作る人間次第では表現できるのかも知れないが、それが僕にできるはずもない。

だから、どこまで妥協するかが焦点になる。できないことはできないと言って、自分に何ができるのかを探している友人とはずいぶん違う。できないことを、いかにできているようにごまかすか。言ってみれば、これが僕の研究の裏の焦点だ。

それが悪いとは思わない。できないことはできないと言っていてはブレイクスルーは生まれない。ただ、それは僕のような保守的な人間のやる仕事ではない。初めは教授のプログラムを変換するだけだったのに、ずいぶん大がかりな話になってきた…。

モデルを作るだけであれば、やってやれないことはない。教授自身も言っていたが、船長の仕事なんてのは、言ってみれば船を港から港まで、障害物にぶつけずに運ぶだけだ。出発地と到着地が港であるとは限らないが、そんな細かいことはどうでもいい。

考え方は幾通りもある。船長はフローチャートで描かれるようなアルゴリズムであるとすれば、まずは航海計画を立てて、その通りに船を運航する。水路やなんやらかんやらとあるが、そんなものは航海計画を立てる時点で考えているだろうから、運航時に考える必要はあるまい。いや、そこを考えないとすることで、モデルの簡略化を図るのだ。自分の視界に船などの障害物が見えたとき、その航海計画から外れるかどうかを検討する。これは、単純な条件分岐でいい。自分の針路方向から２０度以上外れていれば衝突の危険はないと考える、などだ。このような条件分岐を繰り返して、自分の挙動を決定する。これは旧来の考え方であり、古いプログラミング言語になじみやすい考え方だ。だが、見てもらえれば分かるとおり、実際にこんな考え方をする船長がいるとは考えにくい。いつも同じ思考パターンで、それこそコンピュータのように考える船長などいるだろうか。

次の考え方は、イベントドリブンという考え方。これは、もともとはオブジェクト指向の考え方、のはずだ。よく知らないが。上に挙げたものとそう違うわけではないが、船長は基本的には何もしない。初めに航海計画を準備したら、状況が変わらない限りひたすら同じ速度で運航を続ける。

そこで、何かイベントが起こる。たとえば、運航計画から船が外れる、などでもいい。ただまっすぐ走っているだけなのだから、運航計画で航路が曲がっていれば、船は外れるに決まっている。すると、船長はアクションを起こす。計画の航路に船を乗せるよう、舵輪を回すのだ。正確には舵輪を回すように指示するわけだが、そんなのはこの際どうでもいい。

このように、イベントが起きたときに船長が何らかの反応を示す、というのを書き連ねても１つのモデルができる。ただ、条件分岐と考え方は同じような気はするが。ただ、実際そういうものではないだろうか。普通に目的地に向かって歩いているとき、何もなければまっすぐ歩き続けるものだ。なんら原因となる事象がないのに突然立ち止まったりする奴は変人だろう。そういう人間もいるが、そういうのを考慮に入れていたらキリがない。突然逆走する船長などいないのだから、表現する必要もない。本当は必要なのかも知れないが、そんなことやってやれるか。知ったことか。僕は妥協を繰り返すのだ。

ちなみに、船の動きを数式で記述するのが科学的なやりかたではないかと思われるかも知れないが、そもそも、そのやり方から脱却するシステムを構築しようとしているのだ。だから、あらかじめ数式で動きを記述するのは禁止だ。となると、やはり上記のように受動的なモデルになる気がするが…。ちなみにこのたぐいのモデルは、調べてみたがまったく見つからなかった。僕の調べ方が足りないのはあるだろうが、あまりこういうモデルを構築する人はいないのかも知れない。

余談だが、教授がもともと作っていたモデルは、上のどちらとも違う。とにかくまわりにいる船を近かろうが遠かろうが片っ端から調べ、その中で一番近い奴を決定する。そして、その一番近い奴との距離に応じて次の行動を決定するのだ。だから、なにもなくても船長は常にあたりを調べまくり、その中で衝突を避けるルートを考える。このルートの決定は、４つの力による。まずは目的地に向かう力。なにがあっても目的地には向かわなければならない。そして、衝突を回避する力。近くに船がいたら、逆方向に行かなければならない。次に、追従力。これは却下するかも知れないらしいが、前に船がいたら、そのあとに従おうとする力だ。前の船と同じルートをたどっていれば間違いない、と言う発想らしい。それが現実の船長を表現しているのかどうか、僕には分からない。そして、最後に群れの中心に行こうとする力。船は一種の群れになって行動する傾向があるから、その群れの中心に向かう力があるとしているのだ。僕は、そんなことがあるかい、と思うが、なんせ船のことなんて何も知らないので、そういうことがあってもおかしくないのかも知れない。

だいたい、船のことを知らないのに船長のモデルを作ろうとしていることからして間違っているのだ。そして、そんな中、妥協を少なくしてやり過ごそうとした僕が一番大きなミスを犯している。友人がどうやっていようと知ったことではないのだ。いかに日本語が不正確であろうが、質問されたときに返せないような根拠のないことを書き連ねていようが、とにかく形にしなければならないのだ。それでは意味がないが、意味がなくてもやらなければ論文は書けないのだ。

僕にはバイトもあるし、ゲームだってやめるつもりはない。ホームページだって作りたいし、ゲームだって作ってみたい。論文に全精力を費やすつもりなどないのだ。僕の目的はシステム構築とプログラムを学ぶことであって、船を知ることではないのだ。論文なんて、その目的のついでに過ぎない。書かなければ大学を卒業できないから書くだけだ。

これが、若さというものだろうか。目的をきっちり定めれば、論文にこだわることなんて無意味だと、もっと早く気づいたはずだ。とにかく妥協を繰り返し、なんでもいいから形にするのだ。プログラミングの段階まで持っていけば、あとは何とかする自信はある。例えそのシミュレータがシステムとしてきわめて貧弱で、拡張性に乏しく現実を反映していなかったとしても、それは能力のない僕にやらせた教授が悪いのだ。やりたければ自分でやれ。モデルなんぞ自分で作れ。そしたら僕がプログラムを書いてやるから…。

今さら言う間でもないが、卒論の目的はこの逆である。現実を反映するモデルを作り、それを正確に表現する、柔軟なシミュレータを開発することだ。まあ、本当にできれば３年をかけるに値する仕事だろう。できないと悟ってしまったが。

なぜできないか？その一番の原因は、具体的な教唆を示せる人間がいないことだ。教授や助教授は、概念ならいくらでも語れる。しかし、卑近で具体的な方法論を語るべき人間ではないのだ。そもそも、それを考えるような人間でもない。結局のところ「先輩」という存在は大きいのだ。だれにも尋ねられない以上、僕は１人で調べるか、でっち上げるかしかない。調べられないことは分かったので、あとはでっち上げるという選択肢のみだ。

やれやれ…。

2003.07.08 (Tue) 23:02:44