考える

　今回のは基本的には実験作だ。ぶっちゃけて言えばテストだ。

　システムの第一次実装。どんな感じで組めばうまく行くか確認する。本当に上手く動くのか。上手く動いたとして、どんな感じに見えるのか。今後どういう方針で組むのか。そういったことを確認するのが第一だ。

　確認した後、一から作り直すことになるだろう。分かってる時に書いたコードと、分かってないときに書いたコードでは設計思想が根本から変わる。コードにはわかってることしか書けず、理解が深まればコードもガラリと姿を変える。一度でも動かせば、動かす前と比べて必ず理解は深まる。

　最優先すべきは動かすこと。このシステムは、ある程度人物がいないとあまり面白くならない。しかし目的は動作の確認だ。たくさん人物を作ったら作るのが大変だから、最小限にとどめることになる。

　もしこのシステムが本当にいいものだったら、見て、パクって、より面白く仕上げる人がでてくるかもしれない。システムには著作権なんて概念は通用しないし、特許も取れない。先に面白いものを作られてしまったら、俺の手柄なんて何の考慮もされないだろう。作り損だ。

　俺が面白いシステムを作ったという事実が必要だ。システムが面白くても内容がつまらない場合、システムもつまらないようにしか見えない。人数を絞れば、おそらくつまらないものに見えるだろう。

　人数を絞ったバージョンは公開しない。普通に考えればそういう結論になる。

　このシステムのエラーチェックは完璧だから、途中で人数を増やしても減らしても全てエラーとして検出できる。

　人数を絞ったバージョンをまず作り、動作を確認し、直し、人数を増やす。そして公開する。

　１からの作り直しがなければ狙ったスケジュールで間に合うかもしれない。

　なんてったって、Reflector.NETを使えば、ソース公開してなくたってソースコードがほぼ丸ごと手に入るんだよな。たいした規模じゃないから、手直しして、新しく作り直して、動かす。一ヶ月でも出来るかもしれない。

　Reflectorを使って得たコードをまんま使ったら、法的に問題にできるかもしれない。多分しないけど。多分起こらない最悪ケースに備えるのは実にむなしいな。

　公開しなきゃいいのだ。面白くなってから公開すれば。あるいはこのシステムはどうあがいても面白くならないということが明らかになってから公開する。それが正しいだろう。

　最初のバージョンは四人だな。三人いないと物理的に動かない。四人いないとテストにならない。そっからちょっとずつ増やしていって、十人になったら判断も下せるだろう。